Transports

 

1. Managing Change Control and Transports

This blog post addresses standards and guidelines related to changing and transporting objects within the SAP BI landscape.

 

1.1. General Standards and Guidelines

Do not create BW objects and leave them in the $TMP package. If you need to prototype or experiment, you should do so in the Sandbox or Temporary TR created for that purpose. If you cannot use the sandbox, contact your development manager and the BI Platform Health team to discuss options.

As you create objects, assign them the proper package (development class) and put them into the correct transport request, based on the standards described below.

1.1.1. Object Grouping and Sequencing

Group objects logically, and release transports in the following order to minimize errors:

1. Package (Development Class)
2. InfoAreas
3. InfoObjects, InfoObject Catalog
4. DataStore Objects
5. InfoCubes
6. Custom tables
7. InfoSources
8. Extractors on R/3 side
9. DataSources and Replication
10. Transformations
11. InfoPackages
12. Data Transfer Processes
13. ABAP Programs (non-rule)
14. MultiProviders
15. Process Chains
16. Queries and Query Elements
17. Workbooks and Web Templates
18. Planning Areas, Planning Area Variables
19. Planning Levels, Planning Layouts, Planning Packages, Planning Functions
20. Planning Folders

 

1.1.2. Grouping Objects in Transports

For new functionality change requests, group objects into your transports as described below. Each group should reside in a single transport. Do not mix object types from multiple groupings into a single transport:

Transport for Object Group 1 – The Data Model Foundation

• Package (Development Class)
• InfoAreas
• Custom data elements, domains
• InfoObjects
• InfoObject Catalogs

Transport for Object Group 2 – InfoProviders

• DataStore Objects
• InfoCubes
• InfoSets
• MultiProviders
• Custom tables
• Custom views

Transport for Object Group 3 – Extract, Transform, and Load (ETL)

• R/3 Extractors
• DataSources and Replication
• InfoSources
• Transformations InfoPackages
• Data Transfer Processes
• ABAP programs/functions used by transformations
• Open Hub Destinations

Transport for Object Group 4 – Process Chains

• Process variants
• Process chains

Transport for Object Group 5 – The Reporting Layer

• ABAP programs/functions used by query exits, or other front-end components.
• Queries and Query Elements
• Workbooks
• Web Items
• Web Templates

Transport for Object Group 6 – Planning Components

• ABAP programs/functions used in planning
• Planning Areas, Planning Area Variables
• Planning Levels, Planning Layouts, Planning Packages, Planning Functions
• Planning Folders

 

 

1.1.3. Collecting SAP BI Objects in Transports

When preparing to send BW transports up the landscape, developers and development managers must always do the following:

1. Do not release tasks under transports until you have completed all preliminary QA and adjustment activities for transport contents. After you release a task, you cannot remove those objects from the transport, even though the transport itself remains modifiable.
2. Examine transports for appropriate content. Do they contain objects you do not want to move up the landscape? If so, delete these objects from the transports via SE10.
3. As much as possible, keep your transports small.
4. Re-collect dependent objects for InfoProviders, InfoSources, Process Chains, and queries. Use the Transport Connection tool in the Data Warehousing Workbench (RSA1) to make sure you have all the necessary objects in your transports.

When using the Transport Connection tool to round up stray objects, work with one InfoProvider, InfoSource, Process Chain, or query at a time. Make sure you specify “Only Necessary Objects” as the Grouping method, as shown below:

After collecting the dependent objects, use the truck icon to add them to the transport. Take care to enter/select to correct transport for the objects collected. The transport suggested by the tool may not represent the one you actually want to use.

 

1.1.4. Changing and Transporting InfoProviders

 Standards:

If your work includes a change to an InfoCube or DataStore object, you must take steps to ensure that your transports will not result in a long-running database alteration. All development teams changing InfoCubes or DataStore objects must perform the activities described below. For purposes of simplicity, the text below will refer to both DataStore Objects and InfoCubes using the single term InfoProvider where applicable. For each InfoProvider you intend to change (and therefore transport) you must perform the following steps:

1. Check for InfoProvider Existence in Q and P: Determine whether the InfoProvider already exists in Quality and Production environments. If the InfoProvider does not exist in Quality and Production environments, you can skip the remaining steps in this procedure, and proceed to the next InfoProvider in your scope.
2. Evaluate Impact of Changes: Some changes will cause BW to adjust or recreate database tables. If the affected tables contain large amounts of data, the transport will take a long time to activate, delaying the transports behind it. If your changes will do any of the following, you must carry out the rest of this process. Otherwise, you can skip the remaining steps and proceed to analysis of the next InfoProvider in your scope.

InfoCube:

• Turning on partitioning.
• Changing the partitioning characteristic
• Changing the partitioning periods
• Adding or removing a dimension
• Removing a characteristic from a dimension
• Adding or removing key figures or units of measure
• Changing a dimension to/from a line-item dimension.

DataStore Object:

• Adding an attribute to either the key or non-key area.
• Removing an InfoObject from the key.
• Turning on the “BEx Reporting” (formerly Generate SIDs) flag.

3. Determine InfoProvider Data Size in Q and P: Determine the number of rows in the InfoCube’s fact tables or DataStore’s active data table in Quality and Production.

InfoCube:

• You can use transaction DB02 to determine an InfoCube’s fact table sizes.

DataStore Object:

You can use one of these methods:

• Oracle Stats: Look up the Oracle database statistics for the DataStore’s active data table. In both Q and P, go to transaction SE16 and browse table DBSTATTORA. On the selection screen, enter the active data table name for your DataStore Object. For custom DataStore Objects, this table name takes the form:

/BIC/A + {DataStore name} + 00

For example, for DataStore Object ZABC01GL, the active data table has the name /BIC/AZABC01GLOD00.

 

For SAP-delivered DataStore Objects, the active data table name takes the form:

/BI0/A + {DataStore name minus leading zero} + 00

For example, for DataStore Object 0FIAP_O03, the active data table has the name /BI0/AFIAP_O0300.

 

When the information from DBSTATTORA appears, the column NROWS identifies how many rows the DataStore’s active data table contains. Make sure the table contains recent statistics. Check the column ANDAT. If this column contains a date more than a month or two old, the value in NROWS may not reflect reality.

 

• Count the DataStore rows directly: In Q and P systems, go to transaction SE16. Instead of browsing table DBSTATTORA, browse the active data table itself. On the selection screen, press the “Number of Entries” button to see how many rows the table contains. Note that this can take a very long time if the table contains a large amount of data.

4. Repeat for Entire Project / Transport: Repeat the steps above for every InfoProvider in your scope, to determine the total amount of data the changes will affect.
5. Assign an Impact Classification to the Change: Based on the number of rows in all the target InfoProviders, your change will fall into one of three categories:

GREEN: Total InfoProvider Data ≤ 10M rows

YELLOW: 10M rows < Total InfoProvider Data ≤ 30M rows

RED: Total InfoProvider Data > 30M rows

NOTE: This classification applies to the cumulative total of the data in all the InfoProviders you intend to change as part of a single project or enhancement. For example, if your project will add a new dimension to four InfoCubes that each contain ten million rows in Production, then you must classify your change as RED.

6. Take Action Based on Impact Classification: Take actions as described below based on the impact classification from the previous step:

GREEN:

Send the changes to Test and Production as you would normally.

YELLOW:

Work with Production Support and Release Services to determine the best time to send these changes to Test and Production, and to make sure a sufficient window exists for importing and activating your transport(s). You can expect this transport to take anywhere from 30 to 90 minutes to activate, depending on the nature of the change and the amount of data in the InfoProvider. If an adequate window does not exist for moving this change, then you must reclassify it as RED and follow the steps listed below for RED changes.

RED:

You must take steps to ensure that you do not apply the proposed structural changes to the target InfoProvider(s) in Test and Prod while they contain data. You must carry out one of the strategies below. The strategies appear in sequence from most to least desirable:

• Drop and Reload: Before sending the transport, delete all the data from the target InfoProvider. After sending the transport, reload the data from the data warehouse layer (first level DataStore) or the source system. Work with Release Services and the Data Load team to schedule this data load during off hours. You should use this method if at all possible.

 

NOTE! If your changes apply to a first level DataStore Object, do not assume that the data still exists in the source system. Archiving activities may have archived or deleted the data that you need to reload. You must work with production support to determine whether the data you intend to delete remains available for re-extraction from the source. If it does not, you must use one of the other methods described below to affect your changes to the DataStore.

 

• Backup and Restore: Using this method, you copy all the data into an InfoProvider that reflects the old structure. You then change the original Info-Provider’s structure and reload the data.
  • Create an InfoProvider whose structure exactly matches the InfoProvider you wish to change. This becomes the “backup” or “mirror” InfoProvider.
  • Creating a transformation and data transfer process to load the mirror InfoProvider from the existing, base InfoProvider.
  • Transport the mirror InfoProvider and its transformation / data transfer process to Test and Production before you change the base Info-Provider’s structure in D-System.
  • Load the mirror InfoProvider in Production, and schedule delta loads to keep it in sync with the base InfoProvider.
  • Make the structural changes to the original InfoProvider as required in D-System.
  • Build a transformation and data transfer process to load data from the mirror back into the newly-restructured original InfoProvider.
  • Before transporting your changes to the base InfoProvider into Q or P, drop all the data from it in the target system. Then, transport the new InfoProvider definition along with the transformation / data transfer process that will reload the data from the mirror.
  • Reload the changed base InfoProvider with the data in the mirror.
  • Verify the data in the restructured InfoProvider, and resume scheduled loads from the appropriate source(s).
  • Delete the data from the mirror.
  • Delete the mirror and all the transformations that reference it. Transport these deletions to Q and P.
• Replace with Altered Mirror: Using this method, you replace the old InfoProvider with a new one that reflects the new structure. You do not make structural changes to the old InfoProvider (or if you already have, you must revert the structure back to its original condition.)

 

For an InfoCube, this will include:

• Create a new cube that reflects the new structure.
• Put the new cube in the same MultiProvider as the old cube, and changing the MultiProvider as needed to reflect any new characteristics, key figures, etc.
• Build a transformation and data transfer process to load the data from the old InfoCube to the new one.
• Copy or re-create transformations that loaded the old cube so they load the new cube instead.
• After transporting and loading the new cube, delete the data from the old cube.

 

For a DataStore Object, this will include:

• Create a new DataStore that reflects the new structure.
• Build a transformation to load the data from the old DataStore into the new one.
• Copy or re-create transformations that loaded the old DataStore Object so they load the new one.
• Copy or re-create transformations that extracted data from the old DataStore Object so they extract data from the new one instead.
• After transporting and loading the new DataStore, delete the data from the old DataStore.

 

1.1.5. Responding to Transport Errors

Your client change management policies may not permit the re-importing of transports into Test or Production. They also may not permit sequencing transports imported into Production differently than the order in which they went into Test.

These policies mostly help ensuring that you construct the contents of Production in the same way you constructed Test.

Process:

1. If you experience a transport error, review the transport logs on-line via SE10 or STMS to determine the cause of the error.
2. After you determine the cause of the error, collect required objects into a new transport. You can use the Include Objects function of the transport organizer to copy objects from the failed transport into the new one if necessary:

1. If your error occurred due to objects sent in the wrong sequence, create new transports that will send the objects in the correct sequence. You can use the BW Transport Connection tool to collect the required objects. For new functionality change requests, you must group objects into transports according to the groupings described in earlier respective section.
2. If your transport received a return code 12, you must copy the objects it contains into another transport request. Release Services will remove the erroneous transport from the Production import buffer. To assure that these objects reach Production, you must copy all of them into a new transport using the Include Objects function as described above. After you have determined and resolved the cause of the return code 12, you can then send this second transport to Quality system.

 

PS: The details of this post are generic in nature and the settings may vary based on your local BW system.

Source Credit: SAP and Project Standard Documents