Unlashing SXDA and LSMW Part 2 – Execution
This is the second part of my serie about improving the mass data transfer (insert, update, delete) experience using LSMW and SXDA and will be focused on the definition of the whole project.
For the definition please check my previous blog: Unlashing SXDA and LSMW Part 1 – Definition
Step 7: Running an execution
To show how the error is handled I create a small input file with some records OK, and some other records with errors (16 records 6 errors).
Step 7.1: Load the file to the server
How many of us know about the existence of the transaction CG3Z? Unfortunately this transaction belongs to the ECC not to CRM, so what we can do? I heard develop a custom report to perform the GUI_UPLOAD? NO, because we have our beloved SXDA (or via transaction SXDA_TOOLS)
This is another very nice feature from SXDA (SXDA_TOOLS)
As you already see It has more functionalities but I will focus on the file management, so I’ll complete the mandatory data just to be allowed to press the Copy button.
Remember to use the same name like the one you defined as input file in the LSMW (the file name is case sensitive)
Anybody is still missing CG3Z and CG3Y? 🙂
Step 7.2: Executing the data transfer run definition
We can easily execute the data transfer online or programming a Background Job.
On our scenario, we are talking about 16 record so I will execute it online.
Step 7.3: Analyzing the results
As you can see 10 records where correctly processed and 6 with error, be careful here, because the numbers can confuse you, in this test I changed the package size to 1, so will be 1 commit per transaction, but If changed the package size to 3, will count the number of packets with error, not the total amount of errors, so you need to go into the detail to see the exact amount of errors.
Step 7.4: Fix the errors.
Another advantage of using SXDA with the option Write IDoc to error files checked is the option to modify directly the IDoc format file and reprocess the data transfer with only the ones you fixed, this is pretty cool, the only thing I don’t like is for each step, one SAP GUI session is open, so ensure you only have mandatory sessions opened and close the other ones, even with that, maybe you’ll end with one active session (SXDA screen), depends how your system is configured
We will deal with the Error file options in order to fix the data and reprocess it again, the error file will open the whole error file in ALV format, the error file line will open the segment where the error was detected, this option is not always available for all the interfaces, for example with the Business Partner data transfer it only appeared the Input File and the Error file options.
The IDocs are separated by colors (red the Erroneous IDoc we selected in the previous steps, green separates each IDoc, yellow the IDoc data) at the end is a “lite” version of the WE19, you can add, remove, duplicate, segments, and of course you can edit the values, the latest will be discussed below.
Double click on the wrong segment, this is the most painful part, how you can know the wrong IDoc segment?, remember you not always have the option of the “Error file Line”, you should know the reason of the error, this can be found in the second step of the log navigation via the error message, sometimes is more intuitive, sometimes is less, you know what I’m talking about.
Once you figured out what can be wrong you need to check the IDoc segments, but which one? One way is check the segment name in the LSMW or using WE30 and find it in the list using the search (CTRL+F).
Once the changes are made, remember to save and ensure the success message pops up, otherwise you can waste some precious time in stupid errors.
Step 7.4: Resume the running execution
Sources of interest:
Help SAP documents:
and a long etc.
End of part 2:
I hope you enjoyed the blogs and looking forward to your feedback 🙂