Dependency Check and Best Practice – BPC Transport Process

Summary

Transport Process is one of the most important phase during the implementation of SAP Business Objects Planning and Consolidation (BPC) in Net weaver Landscape. This paper presents a detailed steps of transport movement from Development to QA (Quality) and to Production systems. Best practice can be determined and implemented based on the requirement dependent on the customer system.

Authors: Kanchana Subbiah, Pavan Kumar Bollineni, Dinesh Mallineni

Manual Transport of BPC Objects which are not feasible via Transport Connection:

• Audits: We are unable to transport audit reports from one system to other system as audit reports are specific to individual systems.

• Work status:  Work Status configuration is controlled by table UJT_TRANS_CHG via transaction SM30 and object type u201CWSTA. This setting allows you to control whether work status configurations are imported into your target system when importing a BPC transport. If this object is flagged to u201CDevelopmentu201D in the source system, all work status configuration within the application will be collected in the transport.

• Delta Initialization:  The data load process through Data Manager Package or Package links, where the Delta initialization is set up in the source system, they will have to be manually configured in the target system.

Transports can collect the work states that are defined as well as any work status settings that are defined. Transports do not include any work status locks that may have been set in the source system.

Dependency check for successful transport movement:

To transport successfully, make sure that the dependent objects exist either in target system or transport request. For example, application Appl1 depends on dimension Dim1, so to transport Appl1, make sure Dim1 has already exists in target system or Dim1 has been collected in the transport request Otherwise, the transport Appl1 will fail.

One more example related to DM packages. We should transport DM package folder before sending DM packages as it will check for destination folder to copy the DM package. If it didn’t find then transport fails with error messages.

Below are the three major dependency checks:

• During the transport creation process the transport framework will check the existence of the dependent entities. The transport framework will raise a warning message of missing dependent entities when the transport request is released. The user can continue to do transport by selecting “continue with warning message”. If the dependent entities already exist in the target system, transport will succeed otherwise the transport will fail.

• During the Import process a dependency check is also executed. If it fails, a roll back will happen on the single entity (corresponding to transport granularity) that encounters error during transport and it will not affect other entities.

• The Data checker is executed after importing Roll back will not be executed at this step. Error or warning message will be returned back when there are issues during this step. Besides these three types of dependency check, the transport framework will check the existence of the Environment information when the transport request is released. If the Environment information has not been collected in a transport request, a warning message of missing Environment information will be returned back by transport framework even if the Environment information has not been set as the dependent entity.

Note: If a transport fails for an object, the changes for that object are not made in the target system. The object in the target system remains unchanged. This does not affect the transport of other objects to the target system.

BPC Object Collection in a TR (Workbench Request): Best Practice.

1. Before releasing the transport, always check the object consistency and request consistency for each of the sub-tasks present under the main transport.

2. It’s a good practice to run SCI/EPC checks on the objects before capturing them and locking all objects in the transport before releasing it.

3. Always do a syntax check on the classes/BADI before capturing it in the transport. Also, once the transport moves, run the syntax check again for all the transported objects in the target system and report if any issues are found.

4. Do not capture any standard objects (like interface/class etc.) in the transport.

5. If the structure of a class changes, then the entire class needs to be transported (we cannot send only our limited changes). For example, consider a class with 4 methods that exist in both source and target systems. Now someone creates a new method in this class (total methods in source is 5 now) in the source system and you make a change to previously existing method (1-4). However, the developer does not want to send the 5th method but we would like to send the changes. We capture only our method in the transport and do not capture the newly developed method. This transport will fail.

6. It’s OK to send only the changed methods of a class (and not the entire class) in the transport if we’re confident that the class structure has not changed (no new methods added, no new global types declared, etc.)

7. Always capture all the dependent objects used in the objects to be transported (if they’re not already available in the target system).

Verify the BPC collected objects: You can verify the object technical names to validate whether you collected correct objects or not by going to transport connections. Releasing objects: You can collect objects till those are not released. Once the objects are released you can’t add any further objects to this transport. You can release the objects by right click –> “Release Directly”

Basis team will take care of moving transports form source system to destination system once objects are released.  

Common errors and Resolutions:

• Debugging Transport Issues: The Log reports the successful completion of a transport request, as well as warnings and errors encountered during the transport. To find only the transport logs specific to BPC use transaction SLG1 and in the Object field enter UJ and in the Sub object field enter UJT. Click the execute button. Messages, like the “Environment status not offline; cannot export/import transport request”, appear which guides you to the exact source of the issue.

• You can check the information related to transport failure in this screen.