There is no general procedure for all transports. It depends on the content but I guess you could say there is a similar template for workbench transports (repository objects) and a similar template for customizing transports.
Let’s take a workbench request that involves PROG (program) or REPS (report source code).
In both instances you should first check the export log. By export log I mean the detailed export log (click on the log icon to the left of "Export"). It is not enough to look at the return code and say it was less than 8 so all must be ok. This log overview read from the cofile is not sufficient. Please drill down into the detailed log file or go to AL11 -> DIR_TRANS/log and check the export log file. If the request is ABCK9000001 then the export log file will be ABCE9000001.ABC
Check that the object was exported.
You should see something like :
Start export R3TRPROGZPROG ...
0 entries from SMODILOG exported (PROGZPROG
1 entry from TADIR exported (R3TRPROGZPROG
0 entries from SMODISRC exported (CIPROGZPROG
0 entries from SMODISRC exported (CUPROGZPROG
0 entries from SMODISRC exported (CVPROGZPROG
0 entries from SMODISRC exported (PRPROGZPROG
0 entries from SMODISRC exported (SVPROGZPROG
REPOS ZPROG AM exported
End of export R3TRPROGZPROG
Point to note. If you are exporting table attributes (for example) you should ensure that the revised version is being exported (as in the revised active version) and not the previous active version. If you see in the export log file a warning like TABL <table name> is not active , then when you import this to the target system you will be importing the current active version and not the new revised version. Please ensure you export the new revised version. If you see a case like this where the import has already taken place then you should activate the table structure (technical attributes) and create a new change request. Please do not attempt to re-export the change request from the command line with tp export.
Once you are happy the object was exported please then check the detailed import log file. Again drill down into the log overview or goto AL11. The detailed log file for the import of ABCK9000001 is ABCI9000001.<sid> where <sid> is the import system.
Please check that the object in question was imported.
You should see something like :
Start import R3TRPROGZPROG ...
1 entry for TADIR imported (R3TRPROGZPROG
0 entries from SMODILOG (PROGZPROG
0 entries from SMODILOG (PROGZPROG
0 entries from SMODISRC (CIPROGZPROG
0 entries from SMODISRC (CIPROGZPROG
0 entries from SMODISRC (CUPROGZPROG
0 entries from SMODISRC (CUPROGZPROG
0 entries from SMODISRC (CVPROGZPROG
0 entries from SMODISRC (CVPROGZPROG
0 entries from SMODISRC (PRPROGZPROG
0 entries from SMODISRC (PRPROGZPROG
0 entries from SMODISRC (SVPROGZPROG
0 entries from SMODISRC (SVPROGZPROG
REPOS ZPROG A replaced.
1 entry for TRDIRT imported (ZPROG
REPOTEZPROG A replaced.
End of import R3TRPROGZPROG
If you are happy that the object was imported then you should compare the version history of the objects. You can compare the version history for repository objects via SE38 -> Utilities -> Versions -> Version Management.
In there you will see a "REMOTE comparison" button. You can also compare the active version to any versions in the version database.
If you notice a difference between source and target then it is also possible that another transport was involved in changing the object in the target system. You should check via SE03 for any change requests or check directly via table E071 (use SE16) for the object. If the object was a program called ZPROG then you check E071 for field OBJ_NAME = ZPROG.
For the above analysis you must have access to both the source and target systems.
Let’s take the example to customizing.
Let’s say a customer says they transported a table view (which is made up of a table(s) ) and a certain entry is not visible in the target system.
This is how you can check and confirm.
You start the same way you did for a workbench request.
You should first check the detailed export log as per above. Drill down in the log file and check that the object(s) was exported
For customizing requests – these involve table entries. So what you will be checking is that the table entry(ies) was/were exported from source and imported to target. A customizing change request does not tell you what data is being exported/imported. If you drill into the object list the only information you will get is the table key(s). So from the table keys you must determine the table row(s) that are being exported/Imported.
So in the detailed log file for export and import you should check that the table key listed is exported/imported. Lets use an example and you were exporting data from table T005T then that would mean checking the export log file for something like this :
Start of export of R3TRTABUT005T
X entries from T005T (000I*)
End of export of R3TRTABUT005T
And then for the import log file something like this :
Start of import of R3TRTABUT005T
X entries from T005T (100I*)
End of import of R3TRTABUT005T
Notice this says 100I* and not 000I* that is because in this example I export from 000 and import to 100.
If you are happy with the detailed log file it is now time to check the table level entries on the source system and see if those same entries were imported to the target system.
Open the transport request in SE01 (or SE09, SE10) and double click to reveal the object list (see below)
Double click on T005T above and you will get this screen :
Double click on 000I* and you will get this screen :
Sticking with T005T as an example with table keys 000I* you would go to SE16 -> T005T (on source)
Input :
SPRAS = I
LAND1 = *
Hit F8.
You will get back the row(s) that will be transported.
Then logon to target and do the same. So for example if the import was to client 100 in the target system then be on client 100 when checking T005T with
SPRAS = I
LAND1 = *
If the source and target table entries match but the customer still says then entry is not on the target system then the problem is on the application level and you can have the application take a look.
If the rows are different on table level but the export and import log files say all was ok then it’s time to check if any other transport could have made a change since on the target system. You can check this with SE03 or directly with E071K (for table keys).
- SAP Managed Tags:
