RDS for SAP data migration through IDOC's

[vijy_mukunthan]

Dear Experts

  Just now we have installed BODS 4.1 and RDS also installed now. I am in the process of exploring the RDS. I found all the migration objects is available in the form of IDOC's. Now my questions are

1. How to work on custom IDOC's. Do i need to extensively code on R/3 side to upload the custom fields. Like user exit or BADI for custom fileds
2. If yes then i would say implementation time through RDS will remain more or less same time.
3. Through BODS or by RDS migration objects is there any way without coding on ABAP R/3 side, Can we achieve migrating custom fields

  Please let me how to achieve above requirements by RDS

Thanks

Vijay Mukunthan

[Former Member]

We are using RDM Thanks everyone for suggesion

[vijy_mukunthan]

Hi All

   For the custom fields have we have enhance the IDOC segments and also necessary coding has to be placed on the user exit. On the front end BODS side the IDOC has to be called with additional Z segments.

Regards

Vijay Mukunthan

[FrankDensborn]

Hi Vijay,

So you were able to enhance the Rapid Data Migration content and the IDoc? That sounds good! Please let me know in case you still have any questions.

Best regards,
FRANK.

[Former Member]

Hi Frank, We are migrating from ECC to HANA(Central Finanace) thru RDS, Idocs is prebuild in RDS, Can we use BAPI instead of IDOCS  if yes any suggestions why ? Thanks

[FrankDensborn]

In case you're migrating to SAP S/4HANA, we do have a specific Rapid Data Migration package for that:

http://service.sap.com/rds-dm2s4op

This package is using all the new interfaces for S/4HANA and most of them will still use IDoc to send out of SAP Data Services, even though a BAPI is called in the S/4HANA system. Only one new business object, the new S/4HANA Business Partner is using a remote function call (RFC) of a fm (that we created as a wrapper - but not a BAPI).

To answer your question, SAP DS supports calling a BAPI directly. But why would you do that when you have BDBG transaction to create IDoc interfaces out of all asynchronous BAPIs? A BAPI call will keep the network traffic open until it is posted while an IDoc will send the information first and then the posting is handled in a different step. That improves performance and enables to run biger packages in parallel. Again, at the end for most of the given pre-defined DS jobs a BAPI is called at the end in the target system.

Hope this helps,

FRANK.

[Former Member]

Thanks frank for responding, if we want to implement deltas after the initial load and  our delta job should run every 30 mins and the data has to be loaded to CFinance,Basically we dont want to interrupt users, the system has to be up and running for the users,at the same time our delta jobs has to be running in this scenario which one is best loading thru IDOCS or BAPI Thanks

[vijy_mukunthan]

Hi Undam

  I would recommend to use standard RDS jobs for you delta load. Since the solution is already available you need to schedule based on your needs. If you need to use BAPI or RFC you need to develop from the scratch. I would suggest if only the data volume is much high then you can go for BAPI else you can go ahead with standard RDS Jobs.

Thanks and Regards

Vijay

[FrankDensborn]

Hi Undam,

In addition to Vijay's correct answer above, you can always start with the standard jobs in DS coming with the RDM content. Even though the show up as IDoc, most of them are using BAPIs already (e.g. the Material Master object due to performance reasons for the Mass Upload BAPI rather the MATMAS IDoc type). So why does it show as IDocs? You can use a so called BAPI/ALE interface (transaction code BDBG) to call asynchronous BAPIs locally on the remote system rather than performing a BAPI call from outside. Why are we doing this? Again, performance reasons. A live BAPI call through the network from outside would keep the connection open all the time until the BAPI is completely posted. By using the BAPI-ALE IDoc interface, we can split into send (the IDoc is send with all the data and stored locally on the SAP system - this is the only time for network traffic) and then process the IDoc processing (which then calls the BAPI locally) in a separate task on the SAP system. This can be done in the background and by leveraging parallel processing to get the best performance.

Hope this helps!

Best regards,

FRANK.

[FrankDensborn]

Hi Vijay,

You are right, the standard content of the Rapid Data Migration RDS packages brings the content with the standard IDoc interface for SAP standard only. So custom objects are not pre-built with the package. However, we incorporated the foundation to include custom coding as easy as possible:

1) IDoc

We are using the standard interface technology IDoc. IDocs do have an enhancement concept which is described in the online help. There are three main cases and all of them are supported, however two need additional coding:

• Z-fields: Additional fields in existing tables lead to IDoc segment extensions
  With the IDoc segment versioning concept this is easy to realize without any ABAP coding
• Z-tables: Additional IDoc segments will be necessary and lead to a new IDoc version
  With the IDoc versioning concept you can easily add Z-segments with leveraging provided user exits
• Custom business objects:
  You can even create a complete own IDoc message type in Z-namespace for own stuff, leveraging the given ALE layer of the IDoc middleware

2) Enhancement guide

With the RDS package we offer an enhancement guide which helps you to modify the jobs and data flows in the SAP Data Services content according to the changes in the target IDoc structure to reflect additional fields and tables. We built it as a step-by-step guide following for a sample IDoc type but will work similarly for any IDoc.

Best regards,

Frank Densborn.

[vijy_mukunthan]

Hi Experts

Is anybody there to comment on this topic?.

Regards

Vijay Mukunthan