Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

LSMW methods for high volume migrations

Former Member
0 Kudos
342

Hi All,

I am part of a data migration project. I have a question on methods to steamline the process for high volume migrations.

Current method

LegacySQL <-> ODBC <-> MS Access <-> FTP <-> LSMW <-> SAP

To partition the file size into sizeable chunks and ensure a methodology we uses MS Access to query say vendors for A to E / F to P / Q to Z, to have 3 legacy vendor source data files suitable for input.(parallel input if reuired to aid speed).

Question

Is there a suitable method out there to chop out the ODBC / ACCESS / FTP steps and just have LSMW accessing the Legacy SQL server direct, Eliminating all the effort and points of failure/error/people screwing the data in access.

Like

Legacy SQL <-> ? <-> LSMW <-> SAP

Seems a pity to go through the task of creating a robust LSMW template to have it compromised by an external converion/data transfer process.

Thanks

1 ACCEPTED SOLUTION

Clemenss
Active Contributor
0 Kudos
109

May be your SAP BASIS people can establish an RFC destination for the SQL server and get one (big) input file.

It may be suitable to write a small ABAP to split this files into chunks according to your criteria. Then LSMW them...

Hope it helps,

Clemens Li

5 REPLIES 5

Clemenss
Active Contributor
0 Kudos
110

May be your SAP BASIS people can establish an RFC destination for the SQL server and get one (big) input file.

It may be suitable to write a small ABAP to split this files into chunks according to your criteria. Then LSMW them...

Hope it helps,

Clemens Li

former_member188685
Active Contributor
0 Kudos
109

Hi

i guess Using LSMW IDOC method you can transfer ..

for IDoc method RFC destination needs to be maintained...

christian_wohlfahrt
Active Contributor
0 Kudos
109

Hi Mark!

It is possible to place (remote) SQL statements into LSMW - but you will need a (small) complicate program part, to fill all structures line for line by yourself. (Standard loop over imported file is missing?!)

But I think you can skip the ODBC - Access steps. In step read data of LSMW, you can restrict your upload to a distinct number of lines (1-1000, 1001-2000,...). So you can use one file in several steps - which should only be needed, if you have VERY high volumes.

Normally only creation in SAP takes some time, conversion and other preparation in LSMW is done in some minutes.

But fastest way of data creation in SAP is parallel IDOC booking (in as much sessions as possible) - here several splitted files will make no difference.

And if you have a creation via BDC session, then that's slow(er). But here you can have several sessions out of one file, too -> parallel run of sessions is possible.

LSMW is optimized for file input - maybe a separate (SAP) report for LegacySQL with file output is an option.

Advantages:

- no manual data handling steps

- simple report logic

- simple LSMW logic

Regards,

Christian

Former Member
0 Kudos
109

Would it be fair to say that a custom ABAP report to query the external LegacySQL data, and then save to a local file. Then use this file as the source for the LSMW. Would be a good method?

Alternatively if we are using remote acess SQL procedure within LSWM wher would we be entering the code? Or best stay clear of this option.

0 Kudos
109

Hi Mark!

Where? I guess (never done), right event is __begin_of_processing__. You can see (and change) this in LSMW, field mapping and conversion rules. Open menu: extras-layout, check all options. In best possible option, here similar coding as in separate report is needed: RFC-SQL and file filling (maybe saving can be skipped). If starting from here no normal file opening is possible, then all conversions would be manual (I don't hope so.)

Separate report sounds easier, e.g. you have version handling. On the other hand, not all coding is in one place (which does not bother me).

Personally I would go for separate report(s), maybe with some basic split/check-logic. (No old/deleted entries, some check tables with active entries...)

Regards,

Christian