SAP Business Planning and Consolidation functional and admin personnel generally have some issues while communicating with Basis support problems related to the BPC-NW transports operation. Missing configuration and incorrect assumptions play a major role on common errors experienced.
Here are some critical checkpoints based on years of experience fixing BPC-NW transport issues.
Just one heads-up, this is related to versions 10 and 10.1 architecture only. In case you need information on BPC7.5 transports, we can review that on a different thread.
1. Regarding system setup, the important things are:
a) RFC connection:
- The BPC RFC is not used – the RFC used by BPC Service operations.
- The BW RFC (for after import) is the only one used in the transport operation: you can check the connection name used under table RSADMINA, field TPBWMANDTRFC.
- The value for TPBWMANDTRFC must be an existing RFC/ABAP connection under t-code SM59. The connection must point to the BW client and the target host should be the server itself.
- One can test the authorization and connection by using the menu "Utilities", "Test", "Authorization Test" in the RFC configuration screen.
b) Authorizations:
- The BW RFC needs three different authorizations: profiles S_BI-WHM_RFC and S_BI-WX_RFC; and the role SAP_BPC_SERVICE. (Refer to SAP Note 1727052).
- Remember: users in Netweaver are client specific. If RFC points to client 001, the user assigned must exist and have the authorizations assigned under client 001.
2. System changes and Transports:
- Client configuration (T-code SCC4): the change options/settings over there DO NOT affect the IMPORT of transport request.
- System Change - Namespaces/Components (T-code SE06): these settings DO NOT affect the IMPORT of transport requests.
- Those settings may affect the COLLECTION and EXPORT of transport requests. Why? Because it won't involve the same type of remote function calls during the import process in SAP NW. Different methods, different results.
3. Reading the logs:
The rule of thumb for a first assessment at transport logs
Expand/Ask for ALL the transport request log contents.
Look for these clues in the logs:
Does it have only a UJT_TLOGO_AFTER_IMPORT call and an error? Nothing else.
- CAUSE: Probably configuration.
- ACTIONS: Check in the log the RFC name used and the client where the import is taking place. Check the configuration of the RFC, such as client, target host. Check authorizations for the user assigned to the RFC. Look for the status of profiles assigned under t-code PFCG.
Does it have information such as "Begin Import...", "Created (something)...", "Imported Entity/File...", BUT at some point it failed and you DON'T see data checker calls?
- CAUSE: configuration is fine; importing is working partially. Probably something related to authorization or data activation (the log should say which one).
- ACTIONS: you can check/run further traces on authorization (SU53 or ST01) against the BW RFC user. Gather more details on the SLG1 logs to know if it is not something related to object inconsistency during activation. *Remember some imports, such as Model Parameters, will trigger a lot of ‘extra’ checks for its activation in the target system. If you plan it bad, a lot can go wrong.
Does it have a DATA CHECKER entry/information near the end of the log?
- CAUSE: configuration is fine; import is working; HOWEVER mandatory data checker in the environment is throwing warnings or errors. The transport is actually running fine. It is just data checker.
- ACTION: after the transport, verify the environment contents you have tried to import and then run another Data Checker report. The clues to fix this will be in the output of the report. Remember transport is ‘granular’ in BPC 10.X, which means that something expected in the target system during validation might be missing. Classic example: script logic fails to validate due to missing dimension/members information.
Can't you find any information or useful details on the transport logs, but you know it failed?
- CAUSE: The transport likely failed with an ABAP exception and generated a dump.
- ACTION: Check under T-code ST22 for ABAP dumps matching the timestamp of the transport request import. You can check the code stack for further details on the reasons for the exception.
4. The ‘Good to Know’ stuff:
Tables involved in the export process:
- Collecting objects - UJT_GUID, E070, and E071 (the last two are standard Netweaver tables. To be precise, several E07* tables are involved, but these are the more important ones).
- Releasing 'Task Request' - UJT_GUID, E070.
- Releasing 'Customizing Request' - UJT_TRANS_OBJECT, UJT_TRANS_FILE.
Relevant tables for the import process: UJT_TRANS_OBJECT and UJT_TRANS_FILE.
If an import fails, one can revert the shadow table (UJT_TRANS*) object status for a specific request through report ‘UJT_AFTER_FAIL_PROCESS’ – but handle it with care.
If you don’t have a test system in a transport ready landscape, you can create a Virtual Target System to test exports.
Want to test imports but don’t have a transport landscape? You can create a transport of copies to manually simulate transports imports by copying the COFILE (header) and DATA file to another system (with the same component and SP levels).
If you are looking for a quick checklist for BPC transport configuration: SAP Note 2081345 has all details.
If you are looking for a checklist of common configuration and installation issues in BPC-NW: SAP Note 2069510 has more details.
Transaction codes:
SE01: check transports using a request number.
SE09/SE10: check a transport based on request status or user information.
STMS: overview of a transport system. Check routes, transport queue, add systems, imports, etc.
SOBJ: system objects. Find the matching function modules for export and import of any specific TLOGO.
SM59: ABAP connections (a.k.a. RFCs).ST01: trace authorization (and other stuff).
SU53: authorization checks buffer.
PFCG: Profiles maintenance in Netweaver. Find if an authorization profile is generated, active, has authorization objects assigned.
5. Last but not least:
Remember: any solution applied to fix a failed transport import/export procedure must be feasible in a Productive system. Manually cleaning objects in the target system before an import start is not an optimal solution – not at all. You can’t delete data from Production in order to properly transport objects and you cannot compromise or put in risk transaction or master data.
