Transporting BI Objects (DEV->Quality->PROD)

Transporting BI Objects 

Use

Development projects for Business Intelligence (BI) are generally not performed in a productive system. They are normally carried out in one or more development systems depending on their scope.

If you carry out your development projects in a development system, you have to transport the development to a target system (a test or production system).

To do this, the standard transport system has been enhanced in BI to provide the BI transport connection. Using the transport connection in your BI development system, you can collect a consistent amount of new or changed BI objects and then transport them using the Change and Transport Organizer (CTO).

Procedure

  1.  In Data Warehousing Workbench, choose the Transport Connection functional area (transaction RSOR) by choosing the pushbutton in the left navigation window or by choosing the menu option Goto → Transport Connection.

You can display or hide the left hand navigation window in Data Warehousing Workbench by choosing  Navigation Window On/Off.

  2.  Collect objects that you want to transport and check the settings.

More information: Collecting Objects

Objects Being Transported for the First Time (Package $TMP)

  3.  To transport the selected objects, choose  Transport Objects. The Change Object Directory Entry dialog box appears.

  4.  Under Attributes, in the Package field, enter a transportable customer package (beginning with Y or Z).

 

This prompt only appears once for all collected objects. If you want to transport objects in different packages, you must collect the objects more than once.

You can change the package assignment subsequently.

More information: Changing Package Assignments

  5.  Save your entries. A dialog box appears where you are prompted for a transport request.

  6.  In the Request field, enter a transportable request or create a new request first.

  7.  Choose  Continue.

  8.  Choose  CTO Transport Organizer: Overview. The Workbench Organizer: Requests screen appears.

  9.  Release the individual tasks first and then the complete request.

 

Ensure that you release any requests with locked objects beforehand.

In the Collected Objects screen area, the system displays the corresponding information for individual objects in the following columns:

●  Last Changed

●  Last Changed By

●  Transport Request

●  Transport Request Holder

●  Package

  10.  In the log display in the lower screen area of Collected Objects, check the status of the transport.

Objects That Have Already Been Transported

From here on, BI objects are subject to automatic change recording since they were assigned to a transportable package when transported for the first time. This means that all changed objects are written automatically to a request, and can be transported.

Note the following for automatic change recording: If you create new InfoObjects for an InfoCube that is subject to automatic change recording, these are not automatically written to the InfoCube request. Instead, they are assigned the $TMP package. You must use the BI transport connection to collect and transport these objects or the InfoCube.

Only refrain from collecting objects using the BI transport connection if the changes do not produce any new objects.

Result

Depending on their object type, the transported objects are imported to the target system in either A, M or T version and are automatically activated using the after-import method RS_AFTER_IMPORT. The dependent DDIC and program objects are generated in the target system after the import. If objects deletions have been transported, the corresponding objects are deleted in the target system.

With the implementation of Business Add-In (BAdI) RSO_BADI_TRANSPORT, you can automatically trigger follow-on activities such as executing or rescheduling process chains once the objects have been imported. After the standard BI after-import methods have run, method AFTER_IMPORT from interface IF_EX_RSO_TRANSPORT is executed. For more information, see Implementing BAdIs in Enhancement Builder and the method documentation for IF_EX_RSO_TRANSPORT AFTER_IMPORT.

Data Warehouse Management in SAP BW

 Data Warehouse Management 

Purpose

The Data Warehousing Workbench is the central point of entry when managing most Data Warehouse Management processes. It provides tools and functions for metadata and process management.

Data Warehouse Management in BI incorporates various tools and functions:

Process Chains, Scheduler, Monitors for Load and Data Transfer Processes

You use process chains, you can automatically control load processes, the further processing of data in BI, and additional central processes in BI. The scheduler is the tool that defines the load process in BI. You can monitor the requests for load and data transfer processes using the respective monitors.

Administration of InfoProviders

In InfoProvider administration, you can display technical information about the content of the InfoProvider. This provides information on the requests that are already in the InfoProvider and allows you to rebuild InfoProviders.

Information Lifecycle Management

Information Lifecycle Management allows you to classify data according to how current it is and archive it as required. This simplifies the administration of the data warehouse and improves performance.

Authorizations

To ensure that the data warehousing solution represents the structure of your company and fulfills its requirements, you have to define who has access to which data.

An authorization allows a user to perform a certain activity on a certain object in the BI system. There are two different concepts for this depending on the role and tasks of the user: standard authorizations and analysis authorizations.

Documents and Texts for BI Objects

Information on BI objects (metadata, master data, InfoProvider data) can be managed in the form of documents. In Reporting, documents can be created, displayed and found using full-text search. In the Documents functional area of the Data Warehousing Workbench, in addition to the functions for creating, importing and exporting documents and searching within documents, there are also functions for the administration of BI document management.

In the Translation functional area of the Data Warehousing Workbench, you can translate short and long texts for BI objects.

Transport of BI Objects and Delivery of Content Objects

Transport system: BI development projects are not usually implemented in a productive system, but in a system landscape with one or more development and test systems. Using the transport connection, you can collect newly created or changed BI objects in the respective development system and then transport it into the required target system (usually a test or productive system) using the Change and Transport Organizer (CTO).

The concept of transporting and using SAP objects in various versions, which is used in the transport system, is also relevant for the delivery and usage of Business Content.

SAP delivers Business Content in the SAP Delivery Version (D version). This means that modified or active objects are not changed when you install or import the delivered Business Content.

During import of customer transports into the target system, the objects are imported either directly into the active version (A version) or into a modified version (M version). Customer-specific changes are also saved in the modified version (M version). In order to be able to use the Business Content that has been delivered or changed according to customer specifications, a customer has to convert the desired objects to an active version (A version).

The Install Business Content functional area of the Data Warehousing Workbench allows you to select (or “collect”) the objects from the Business Content that is supplied by SAP and activate (or “install”) them. This allows customers to determine which objects from Business Content they want to copy, compare with customer-specific modified objects or those that they do not want to install. The system automatically includes all necessary objects as well as the sequence of their activation.

Content that is delivered to business areas by a BI customer or consulting partner is referred to as Customer and Partner Content. The functionality of customer or partner content complements and enhances the options for using the Business Content delivered by SAP.

BW Statistics and Analysis of BI Objects and Data Consistency

In BI, Technical Content is delivered along with Business Content. On the one hand, this includes objects that allow you to analyze the processes in the BI system and to optimize them for performance (BW statistics, BW data slices, BW features characteristics) On the other hand, technical content also includes special DataStore objects that provide data for BEx personalization, for example, or for generating analysis authorizations.

BW Statistics provide data for reporting from the data warehousing (warehouse management) and OLAP areas from several BW statistic InfoCubes using a BW Statistic MultiProvider Within technical content, appropriate BW statistic queries and diagrams are also supplied for the evaluation of data.

An extensive Analysis and Repair Environment is available for performing consistency checks on the data and metadata stored in a BI system.

PROCESS CHAIN STATUS CHANGE PROCEDURE

How to change process chain (PC) status in SAP 

BW?

There are scenarios where you need to change status of a process chain or a particular step in process chain. It is easy to change the status of a step if it is data load, you can just change the status of request in the monitor and it will in turn changes the status in the process chain.
The problem is other types of processes like master data activation, custom ABAP programs etc. In these cases there is no straight forward way to change the status. You might need to change the status in the cases where we need mark these steps successful so that dependent steps get processed. There are other scenarios where one needs to change the status of a single step in the process chain or status of whole process chain.
Step by step instructions on change process chain status
1.    Right click on the failed step in the process chain monitor and go to displaying messages
2.    Go to ‘Chain’ tab and note down variant, instance and start date
 

3.    Go to SE16 and the table RSPCPROCESSLOG and enter  variant, instance and start dates from step 2 and note down log_id, type, variant, instance.
4.    Go to SE37 transaction and execute the function module RSPC_PROCESS_FINISH and enter the values from step 3 and enter the new status ‘G’ in status field and execute the FM
5.    This sets the status of the process chain (PC)

After you set the status using the FM, go to the monitor screen of the process chain, you will notice the changed status. Now dependent steps in the process chain will start running.

SAP BW REALTIME INTERVIEW QUESTIONS

1) Why we delete the setup tables (LBWG) & fill them (OLI*BW)?

A) Initially we don't delete the setup tables but when we do change in extract structure we go for it. We r changing the extract structure right, that means there are some newly added fields in that which r not before. So to get the required data ( i.e.; the data which is required is taken and to avoid redundancy) we delete n then fill the setup tables.  


To refresh the statistical data. The extraction set up reads the dataset that you want to process such as, customers orders with the tables like VBAK, VBAP) & fills the relevant communication structure with the data. The data is stored in cluster tables from where it is read when the initialization is run. It is important that during initialization phase, no one generates or modifies application data, at least until the tables can be set up. 


2) SIGNIFICANCE of ODS? 
It holds granular data (detailed level). 


3) WHERE THE PSA DATA IS STORED? 
In PSA table. 


3) WHAT IS DATA SIZE? 
The volume of data one data target holds (in no. of records) 


4) Different types of INFOCUBES. 
Basic, Virtual (remote, sap remote and multi) 


Virtual Cube is used for example, if you consider railways reservation all the information has to be updated online. For designing the Virtual cube you have to write the function module that is linking to table, Virtual cube it is like a the structure, when ever the table is updated the virtual cube will fetch the data from table and display report Online... FYI.. you will get the information : https://www.sdn.sap.com/sdn/index.sdn and search for Designing Virtual Cube and you will get a good material designing the Function Module 


5) INFOSET QUERY. 
Can be made of ODS's and Characteristic InfoObjects with masterdata. 


6) IF THERE ARE 2 DATASOURCES HOW MANY TRANSFER STRUCTURES ARE THERE. 
In R/3 or in BW? 2 in R/3 and 2 in BW 


7) ROUTINES? 
Exist in the InfoObject, transfer routines, update routines and start routine 


8) BRIEF SOME STRUCTURES USED IN BEX. 
Rows and Columns, you can create structures. 


9) WHAT ARE THE DIFFERENT VARIABLES USED IN BEX? 
Different Variable's are Texts, Formulas, Hierarchies, Hierarchy nodes & Characteristic values.  


Variable Types are 

Manual entry /default value 
Replacement path 
SAP exit 
Customer exit 
Authorization 


10) HOW MANY LEVELS YOU CAN GO IN REPORTING? 
You can drill down to any level by using Navigational attributes and jump targets. 


11) WHAT ARE INDEXES? 
Indexes are data base indexes, which help in retrieving data fastly. 


12) DIFFERENCE BETWEEN 2.1 AND 3.X VERSIONS. 
Help! Refer documentation 


13) IS IT NESSESARY TO INITIALIZE EACH TIME THE DELTA UPDATE IS USED? 
No. 


14) WHAT IS THE SIGNIFICANCE OF KPI'S? 
KPI's indicate the performance of a company. These are key figures 


15) AFTER THE DATA EXTRACTION WHAT IS THE IMAGE POSITION. 
After image (correct me if I am wrong) 


16) REPORTING AND RESTRICTIONS. 
Help! Refer documentation. 


17) TOOLS USED FOR PERFORMANCE TUNING. 
ST22, Number ranges, delete indexes before load. Etc 


18) PROCESS CHAINS: IF U has USED IT THEN HOW WILL U SCHEDULING DATA DAILY. 
There should be some tool to run the job daily (SM37 jobs) 


19) AUTHORIZATIONS. 
Profile generator 


20) WEB REPORTING. 
What are you expecting?? 


21) CAN CHARECTERSTIC INFOOBJECT CAN BE INFOPROVIDER. 
Of course 


22) PROCEDURES OF REPORTING ON MULTICUBES 
Refer help. What are you expecting? MultiCube works on Union condition 


23) EXPLAIN TRANPSORTATION OF OBJECTS? 
Dev---àQ and Dev-------àP 


24) What types of partitioning are there for BW?

There are two Partitioning Performance aspects for BW (Cube & PSA) 
Query Data Retrieval Performance Improvement: 
Partitioning by (say) DateRange improves data retrieval by making best use of database [data range] execution plans and indexes (of say Oracle database engine). 
B) Transactional Load Partitioning Improvement: 
Partitioning based on expected load volumes and data element sizes. Improves data loading into PSA and Cubes by infopackages (Eg. without timeouts).  

25) How can I compare data in R/3 with data in a BW Cube after the daily delta loads? Are there any standard procedures for checking them or matching the number of records? 

A) You can go to R/3 TCode RSA3 and run the extractor. It will give you the number of records extracted. Then go to BW Monitor to check the number of records in the PSA and check to see if it is the same & also in the monitor header tab. 
A) RSA3 is a simple extractor checker program that allows you to rule out extracts problems in R/3. It is simple to use, but only really tells you if the extractor works. Since records that get updated into Cubes/ODS structures are controlled by Update Rules, you will not be able to determine what is in the Cube compared to what is in the R/3 environment. You will need to compare records on a 1:1 basis against records in R/3 transactions for the functional area in question. I would recommend enlisting the help of the end user community to assist since they presumably know the data. 

To use RSA3, go to it and enter the extractor ex: 2LIS_02_HDR. Click execute and you will see the record count, you can also go to display that data. You are not modifying anything so what you do in RSA3 has no effect on data quality afterwards. However, it will not tell you how many records should be expected in BW for a given load. You have that information in the monitor RSMO during and after data loads. From RSMO for a given load you can determine how many records were passed through the transfer rules from R/3, how many targets were updated, and how many records passed through the Update Rules. It also gives you error messages from the PSA. 



26) Types of Transfer Rules?

A) Field to Field mapping, Constant, Variable & routine. 


27) Types of Update Rules?

A) (Check box), Return table 


28) Transfer Routine?

A) Routines, which we write in, transfer rules. 


29) Update Routine?

A) Routines, which we write in Update rules 


30) What is the difference between writing a routine in transfer rules and writing a routine in update rules? 

A) If you are using the same InfoSource to update data in more than one data target its better u write in transfer rules because u can assign one InfoSource to more than one data target & and what ever logic u write in update rules it is specific to particular one data target. 


31) Routine with Return Table.

A) Update rules generally only have one return value. However, you can create a routine in the tab strip key figure calculation, by choosing checkbox Return table. The corresponding key figure routine then no longer has a return value, but a return table. You can then generate as many key figure values, as you like from one data record. 



32) Start routines?

A) Start routines u can write in both updates rules and transfer rules, suppose you want to restrict (delete) some records based on conditions before getting loaded into data targets, then you can specify this in update rules-start routine. 

Ex: - Delete Data_Package ani ante it will delete a record based on the condition 



33) X & Y Tables?

X-table = A table to link material SIDs with SIDs for time-independent navigation attributes.

Y-table = A table to link material SIDs with SIDS for time-dependent navigation attributes.

There are four types of sid tables 

X time independent navigational attributes sid tables

Y time dependent navigational attributes sid tables 

H hierarchy sid tables

I hierarchy structure sid tables 




34) Filters & Restricted Key figures (real time example)

Restricted KF's u can have for an SD cube: billed quantity, billing value, no: of billing documents as RKF's. 


35) Line-Item Dimension (give me an real time example)

Line-Item Dimension: Invoice no: or Doc no: is a real time example 



36) What does the number in the 'Total' column in Transaction RSA7 mean?  

A) The 'Total' column displays the number of LUWs that were written in the delta queue and that have not yet been confirmed. The number includes the LUWs of the last delta request (for repetition of a delta request) and the LUWs for the next delta request. A LUW only disappears from the RSA7 display when it has been transferred to the BW System and a new delta request has been received from the BW System. 


37) How to know in which table (SAP BW) contains Technical Name / Description and creation data of a particular Reports. Reports that are created using BEx Analyzer.

A) There is no such table in BW if you want to know such details while you are opening a particular query press properties button you will come to know all the details that you wanted. 

You will find your information about technical names and description about queries in the following tables. Directory of all reports (Table RSRREPDIR) and Directory of the reporting component elements (Table RSZELTDIR) for workbooks and the connections to queries check Where- used list for reports in workbooks (Table RSRWORKBOOK) Titles of Excel Workbooks in InfoCatalog (Table RSRWBINDEXT) 


38) What is a LUW in the delta queue?

A) A LUW from the point of view of the delta queue can be an individual document, a group of documents from a collective run or a whole data packet of an application extractor. 


39) Why does the number in the 'Total' column in the overview screen of Transaction RSA7 differ from the number of data records that is displayed when you call the detail view? 

A) The number on the overview screen corresponds to the total of LUWs (see also first question) that were written to the qRFC queue and that have not yet been confirmed. The detail screen displays the records contained in the LUWs. Both, the records belonging to the previous delta request and the records that do not meet the selection conditions of the preceding delta init requests are filtered out. Thus, only the records that are ready for the next delta request are displayed on the detail screen. In the detail screen of Transaction RSA7, a possibly existing customer exit is not taken into account.  


40) Why does Transaction RSA7 still display LUWs on the overview screen after successful delta loading? 

A) Only when a new delta has been requested does the source system learn that the previous delta was successfully loaded to the BW System. Then, the LUWs of the previous delta may be confirmed (and also deleted). In the meantime, the LUWs must be kept for a possible delta request repetition. In particular, the number on the overview screen does not change when the first delta was loaded to the BW System. 


41) Why are selections not taken into account when the delta queue is filled? 

A) Filtering according to selections takes place when the system reads from the delta queue. This is necessary for reasons of performance. 


42) Why is there a DataSource with '0' records in RSA7 if delta exists and has also been loaded successfully? 

It is most likely that this is a DataSource that does not send delta data to the BW System via the delta queue but directly via the extractor (delta for master data using ALE change pointers). Such a DataSource should not be displayed in RSA7. This error is corrected with BW 2.0B Support Package 11. 


43) Do the entries in table ROIDOCPRMS have an impact on the performance of the loading procedure from the delta queue? 

A) The impact is limited. If performance problems are related to the loading process from the delta queue, then refer to the application-specific notes (for example in the CO-PA area, in the logistics cockpit area and so on). 

Caution: As of Plug In 2000.2 patch 3 the entries in table ROIDOCPRMS are as effective for the delta queue as for a full update. Please note, however, that LUWs are not split during data loading for consistency reasons. This means that when very large LUWs are written to the DeltaQueue, the actual package size may differ considerably from the MAXSIZE and MAXLINES parameters. 


44) Why does it take so long to display the data in the delta queue (for example approximately 2 hours)?  

A) With Plug In 2001.1 the display was changed: the user has the option of defining the amount of data to be displayed, to restrict it, to selectively choose the number of a data record, to make a distinction between the 'actual' delta data and the data intended for repetition and so on. 


45) What is the purpose of function 'Delete data and meta data in a queue' in RSA7? What exactly is deleted? 

A) You should act with extreme caution when you use the deletion function in the delta queue. It is comparable to deleting an InitDelta in the BW System and should preferably be executed there. You do not only delete all data of this DataSource for the affected BW System, but also lose the entire information concerning the delta initialization. Then you can only request new deltas after another delta initialization. 

When you delete the data, the LUWs kept in the qRFC queue for the corresponding target system are confirmed. Physical deletion only takes place in the qRFC outbound queue if there are no more references to the LUWs. 

The deletion function is for example intended for a case where the BW System, from which the delta initialization was originally executed, no longer exists or can no longer be accessed.