Why we need LSMW version 5.0
LSMW is a very powerful and easy-to-use tool for data transfer, for which lots of materials are available on SCN and SAP marketplace:
http://scn.sap.com/docs/DOC-26158
http://scn.sap.com/docs/DOC-4092
Unfortunately most of the projects I’ve been involved in use it for initial data migration only.
However LSMW comes with a program to transfer data to the SAP system periodically. So why do we always develop custom programs when it comes to periodic interfaces? Is it really because each interface has its own very specific needs?
No.
I’m convinced the reason for it can be found in those 5 major missing features regarding periodic data transfer:
- LSMW doesn’t support logical files (for legacy data).
- When dealing with interfaces it is a common practice to transfer files from initial repositories to archive/error repositories. Surprisingly LSMW doesn’t provide any option to move the import file.
- Within “Field mapping step”, LSMW editor to add abap rules is anything but user-friendly.
- During “Convert data” step, and unless you code it yourself in “processing times” :
- LSMW doesn’t add skipped records to an error file for later re-processing
- LSMW doesn’t offer the possibility to log every message into SLG1
LSMW version 4.0 was delivered in 2004.
What if SAP now released an upgraded version 5.0 to address those pain points ?
š
PS: I wish I could submit an idea on https://cw.sdn.sap.com/cw/community/ideas but no session is open for data migration at the moment.
You should have a look at the Best Practices for Data Migration. I agree LSMW is a great tool, but have recently made the move over to the Data Services tool and the pre packaged jobs for data migration and data quality are a breeze to learn and extremely powerful. Leverages the same root technology as LSMW (BAPI and IDOC). What I like about it (aside from the pre packaged content available out of the box), is the ability to build in lots of validations on the data so that you can ensure your data is very clean prior to loading it up into SAP. In addition there are data quality add ons that let you deduplicate your data as well. I've also been using it for interfaces between the legacy system and SAP and it works well here to. You can see more at http://help.sap.com/bp-datam
You need to have the "SAP BusinessObjects Data Services 4.0" in order to use "SAP Best Practices for Data Migration and Data Quality V2.40". This costs quite some money, while LSMW always has been free. But it just is another step in the SAP strategy to move services from the ERP application to an external service application (like SRM, CRM, ..).
MH
Hello Martin,
It seems that we both replied at the same time.
Thanks for sharing your thoughts too (and I must admit that I agree with you š ).
Take care,
Nicolas;
Hi Eric,
Thanks for sharing. But last time I checked SAP BusinessObjects Data Services was not free of charge. Is it?
Indeed I was expecting someone to argue that we can use SAP XI, or dedicated third party tools... but this will cost you money, and for the purpose I'm exposing here it would be like bringing an elephant to kill a mouse...
Regards,
Nicolas.
Hi Nicolas,
Did you tried SXDA and SXDA_TOOLS? š
Another adavantages of SXDA is you can do paralel processing and file splitting, it only uses LSMW as the mapping tool.
The major problem I see here, is what you already said, the maping tool it's a pain but IMHO the major disvantage is the file should have a specific structure to deal if you have one header and various diferent level of items. An example of what I'm saying is having 3 telephones in a flat format:
http://scn.sap.com/thread/3341140
Or if you have all the marketing attributes of the BP in a flat format (which makes more sens than have a Header position file format for each marketing attribute) the file can be complex and more complex so it's really a pain only to format the file in the fromat whcih lsmw is able to work otherwise be prepared to code in the end of record.
If you really like lsmw I believe you will love sxda š
Cheers!
Luis
Hi Luis,
Thanks! Indeed I should have mentioned SXDA as I'm using it as well to parallelize data import... But I didn't know the limitations mentioned above could be bypassed. So is there any document you can share, or a blog you could write to explain the best practices when it comes to using SXDA?
The reason I'm asking is the following: I don't know how to use logical files for the MAPping task... so I don't know how to use import files with current date in the name of the files for example. Plus, I know that SXDA will be able to create IDOCs for errors that happen during the LOAding task, but what about errors during the MAPping task? And if I choose to save erroneous records in a file instead of generating IDOCs, I'd like to see the records from my initial import file, not some complex idoc format created by LSMW.
So, I agree that SXDA is very powerful when it comes to the LOAding task... but I'd really like to read more about the MAPping task (the one I'm talking about in this blog post). Because reading your answer I'm realizing that maybe I'm not using SDXA to its best.
Cheers,
Nicolas.
Actually I don't have any document and to be honest with you, I didn't used logical files in my data transfers, I was too excited so I rushed answering š
Indeed you can work with them via SXDA_TOOL
Object type: DXPROJECT
Program type: BAPI
Program: CREATE
If you press the button COPY from there you can upload files from the backend into logical or physical format.
And in the MAP task there is the option is there a column to which can contain P/L for the file kinds, but looks like this is inherit from the LSMW, so my mistake... sorry about that š will lbe fun to understand why do you have this column if only can be physical objects...
Another thing is when the mapping fails, fails you can't correct the original file, you can only correct the files once you pass the MAP task, in the LOA process, and as you well said, in hard to handle idoc format, I would say in it defence, once you get use to it, is pretty easy to modify it patience and control+f š
So I must agree with you, as long as MAP is stuck with LSMW you can say bye bye to those features.
BTW why do you want to double check in MAP if LOA also do the checks?
Indeed in SXDA you can use many steps to upload your data into SAP system: map, split, check, load, etc. But whatever number of steps we use, I think we should be given the opportunity to have one final error file containing exactly the same records as the initial file, minus successfully loaded records. And I'd like to keep the input file in some Archive repository for further reference if needed. The most surprising is that such a tool already exists in ISU (industry specific ECC module for Utilities).
But in CRM for example, at the moment if some records cannot be mapped during LSMW step, they are simply lost. So I don't want to "double the checks between MAP and LOA" steps, I just want the system to give me the exact number of errors that happened during ALL the steps š
Cheers,
Nicolas.