Activation of Inactive Objects in Production

Sometimes there may be a case that in spite of successful migration of a BW object via transport, the object
continues to remain inactive. There may also be cases where we mistakenly forget to transport a dependent
object and hence the dependent object remains inactive in the Production system.
For such scenarios SAP has helped us by providing programs which activate the objects without the need for
us to transport them from development to production.
Here is a list of programs which can be used to activate the inactive objects in the system:

Below are the steps required to create an Open Hub Destination in BI 7.0

1.  Click on Open Hub Destination from left side panel after executing RSA1.

Riqht click on InfoArea where the Open Hub Destination will reside and select “Create Open Hub Destination”

Fill in the following:

• Open Hub Destination:  Z_IFSFFPT (up to 9 characters only)
• Description:  IFS FFP Interface Test
• Object Type:  DataStore Object

• Name:  ZRV_O904

2.  Click on the Destination Tab.

Select “File” from the drop down box

Select the directory… for testing purposes, save to your desktop

Click on the Application Server Box… notice the Application Server “MVSADBDV1” will be displayed initially as the default application server.

For migration to production, you want to work with Basis to setup a ‘logical file path/name’.  This will ensure that the logical path and logical name can be migrated into all environments without having to specify the server name.

For R8.1 IFS, we are using the newly created Logical File Name “Z_OPENHUB_IFS”

From AL11 in BA8, you can see the Logical File Name “Z_OPENHUB_IFS” directories

3.  Now you are ready to specify the fields for the Open Hub Destination.

Select the Tab “Field Def”.

4.  Now you are ready to create the Transformation (source).

Right click on the saved Open Hub Destination “Z_IFSFFPT”, and select “Create Transformation” from dropdown box.

5.  Select “DataStore Object” from the Object Type drop down box.

Select “ZRV_O904” from the drop down box.

Click on the Green Check Mark to continue.

6.  Now, you can do all of the activities available to a Transformation:

              Create Start Routine

              Create End Routine (see below)

              Create Formulas (see below)

Activate the transformation when completed.

7.  Now, you are ready to create the Data Transfer Process for the Open Hub Destination.

Right click on the Open Hub Destination “Z_IFSFFPT”, and select “Create Data Transfer Process” from the drop down box.

The target and source will be prepopulated, so you may not need to do anything; however, you can also specify the details. 

Click on the Green Check Mark to continue.

8.  From the Extraction Tab:

Select Extraction Mode:  Full

Click on the Radio Button “Active Table (Full Extract Only)

No steps required in the Tab “Update”.

No steps required in the Tab “Execute”.

9.  Finally, click on the Activation Icon.

Steps to copy queries from one cube to other

Log into BW system and enter the code RSZC.

Enter the source and target infocubes in the screen as shown below and click OK

This screen allows to move even the structures, KFs as shown in select component section .List of queries will be displayed only if the structure of  both the infoproviders are same else it will give a pop up message saying unable to

Select the queries u want to move to the target cube and click on transfer selections button at the bottom of the screen.This new screen will pop up to allow you to rename the technical name of the query or variable. Change the names and the click on check mark.The queries will be moved to the cube and successful message is displayed as shown below.

How to re-construct a Load From DSO

All the screenshots in this guide are thought to reconstruct a load in Opportunities Header DSO but the process is similar to any other object and can be a reference for any other DSO we need to fix data without taking new data from source system (CRM or R3).

1. Delete the existing load from the DSO.
2. Go to the Reconstruction tab and select the request we want to reconstruct and click the Reconstruction/Insert button.
3. Come back to the Request tab and monitor the progress of the load clicking the refresh button, we need continue monitoring until the request reach the green status.
4. Despite of the load will complete, it won’t be inactive (there is no value in the ID of Request column).
5. In order to activate it, we need to choose the request from the manage and click on the activate button.
6. A new window with the list of available requests in the DSO will be shown, most of the times it will only exist one in the first row of the list, let’s select it and click on the start button
7. A new window asking in which specific Server we want to run the process appears, let’s accept what is proposed by default and click on green button to allow the process to continue.
8. Once the activation is done, the request in the manage will show with all the information populated and data will be ready to be moved to the cubes or accessed by routines

Hierachy / Attribute Change Run

If hierarchies and attributes for characteristics have changed, then it is necessary to make structural changes to the aggregates in order to adjust the data accordingly.
Attribute change run is nothing but adjusting the master data after its been loaded from time to time so that it can change or generate or adjust the sid's so that u may not have any problem when loading the transaction data in to data targets.When a master data is modified or changed it gets loaded into the master data table as version "M". It is only after a attribute change run that the master data becomes activated i.e. version "A".If hierarchies and attributes of characteristics belonging to an Info Cube have been changed, It is a necessary to make structural changes to the aggregates in order to modify the data accordingly.
Attribute change run replace activating of master data ? Yes, Both do the same function- make "M" status records to "A" status.
ACR will do the activation of master data if and only if the characteristic’s attributes are used in the Aggregate. And also it refreshes the Aggregate with new attributes. That why you cannot see all available characteristics (in the system) in the list of characteristics in the screen of ACR.And ACR is not required and of course you cannot use ACR for activating the Characteristics whose attributes are not used in any aggregate.

USE: When we load Master data, the attribute change run is run to activate and adjust the master data with the existing data.Unless the change run is run, chances are transaction data loads may fail for lack of master data and reports may not display correctly even if the master data is loaded.If we have aggregates on the cubes, then the new or changed master data is adjusted with the aggregate tables during the change run.

Debug:
I would suggest double click on the cancelled job(in SM37), and view the Job Log to find out the reason for the failure of the job.You can also restart the change run using transaction CHANGERUNMONI, refer to Note 915515 for more details.
Or
look at SM50 if process is still active and check also with ST22 if there are dumps.
Or
there could be a lock situation. remember SAP doesn't allow 2 attr changeruns at the same time.

BI - R/3 Configuration Steps

Here are few checkout steps for succesful connection between R/3 and BW
- Define Logical system (SPRO)
- Assign Logical system to client (SPRO)
- Create Background Users (In both the systems- ALEREMOTE & BWREMOTE) (SU01)
- Test the System RFC Connection (SM59)
- Create the Source System Connection (RSA1 0r RSA1OLD)
- Activate the Datasources (RSA6)
- Transfer Application Component Hierarchy (RSA9)
- Source System Assignment
- Transfer Global Settings.Replicate Datasources

SAP BI vs. R/3 Reporting

 

Many companies that use core SAP ERP modules never implement a SAP BI solution choosing instead to use R/3 based reporting.  Since R/3 is by nature a transactional OLTP system and was never designed for analytics and reporting and the importance of a unified view of a companies data it is somewhat surprising that more businesses haven't found, and leveraged the power of, SAP Business Intelligence.

Comparisons

R/3 Reporting

R/3 is an OLTP transactional system used for real-time operational data.  Reporting is only available from a single system and is transaction based.  R/3 reports are more likely to be broken as the system is highly changeable based on the needs of the business and will require ongoing maintenance and support costs.  Only limited web reporting is available and most reports are simple and list based.  Many users querying significant data volumes will slow down the system and disrupt the experience of the average user.

SAP BI Reporting

BW is an OLAP reporting system mainly used for summarized data rather, although drill down to line items is possible.  It houses historical data from multiple systems (including non SAP third party sources) and even data that no longer exists in the source systems.  SAP BI offers a wide range of data analysis tools including Excel and web based analysis, scorecards, dashboards  and pixel perfect static printed style reporting capabilities.  Most reports are not real-time but are a day or more old, for small data volumes near-time (<5 minute) reporting is possible.  Users querying the dedicated BI system will not slow down the source system and as the data is stored in a more optimal way the reports are available to the user much quicker. 
In addition to the reporting options it also provides ETL functions, better security, the option to 'broadcast' reports to users in a number of different ways and formats and allows planning based on historical data.

So in summary if you are faced with this decision consider these advantages that BI reporting has over R/3:

• By offloading ad-hoc and long running queries from production R/3 system to BI system, overall system performance should improve on R/3.
• SAP BI is specifically designed for query processing, not data updating and OLTP. Within BI, the data structures are designed differently and are much better suited for reporting than R/3 data structures.
• Better front-end reporting within BI. Although the BI Excel front-end has it's problems, it provides more flexibility and analysis capability than the R/3 reporting screens.
• BI has ability to pull data from other SAP or non-SAP sources into a consolidated cube

For up to the minute operational reporting you should use R/3 but for more historical strategic reporting a dedicated BI solution provides faster performing, fully featured reports with stronger data analysis capabilities.