Why do all of SAP's Best Practice/Rapid deployment DS objects utilise IDOC's instead of BAPI's?.

[gary_king2]

Does anyone know why a great deal of SAP's Best practice solutions (HANA) for Data Services tend to use IDOC's to create/change the objects, like materials, for example.

I was wondering why their Material object uses the MATMAS IDOC, among others, which does not fulfill some of what we want to achieve, but which is covered by BAPI's like BAPI_MATERIAL_SAVEDATA, for example. Why did they not write DS object to make use of that instead of the IDOC. I was wondering if there is a good logical reason for this.

I know there's a lot more effort to using the BAPI, although that's not to say that there is not a lot of effort in their current solution which uses a few IDOC(s) to achieve a material creation/change. It's just that it could achieve so much more if it used the BAPI, which is remote enabled. Using IDOC's has many issues and limitations.

[FrankDensborn]

Gary,

Actually, there are quite some BAPIs used in the content. But you're right, DS doesn't call the BAPIs directly and uses IDocs instead.

Why? First of all, for asynchronous BAPIs (e.g. CREATE) you can generate an IDoc shell using ta BDBG. Actually, many of the BAPIs already come with it from SAP out of the box. While IDoc adds one more layer of shell/wrapper around it, it also provides a central monitoring and the possibility to decouple sending the data from posting the data and leveraging parallel processing. How? A BAPI call keeps the RFC connection open till the BAPI is posted. An IDoc call keeps it open until the IDoc data has been saved to the data base. So you can reach a completely different level of load and a much better performance including this extra step. Furthermore, if your IDoc inbound is set to be run by background program (which is recommended) instead of being triggered immediately, you can create server groups and process the IDocs in packages - even in parallel. Then this becomes a full two step process: DS sends the data and is done. SAP posts the data and doesn't affect your DS job anymore. DS is done once the IDoc information is stored on the data base. Error handling while posting is handled through the IDoc monitors BD87 or WE02/WE05 including reposting and all you monitoring needs.

Coming to your example for migrating material: the DS content is actually using the material BAPI and not the classical MATMAS IDoc. However, the BDBG generated IDoc that is used as a shell to call the BAPI is called MATMAS_MASS_BAPI - similar name different interface. But you are right, we're not using BAPI_MATERIAL_SAVEDATA but BAPI_MATERIAL_SAVEREPLICA (this is the BAPI type linked to the IDoc message type MATMAS_MASS_BAPI). Why? As the word 'mass' points out, this is the BAPI that is used for mass upload like in a data migration scenario while BAPI_MATERIAL_SAVEDATA is meant for single material creation. So this is why it is the better option. Data migration s all about performance.

If you're interested in more details about how to tune and tweak your IDoc inbound for a better performance, get either of my two books Data Migration to SAP or Migration to SAP S/4HANA. There is an entire chapter about how to set it up for parallel processing.

Hope this helps,
FRANK.

[former_member442248]

Hi Gary.

One reason that I can think of is iDOC gives more control to the developer. Very interesting thread in case someone from the SAP DS development team can respond. dirk.venken

Regards. S

[gary_king2]

One of the issues when using RFC calls to BAPI's etc seems to be in how we might control the commit/rollback. In the normal world we would just write a wrapper around the FM needed, make it remote enabled and control when it commits or rollback and control the returned values to identify this. However, a lot of BODS developers are either not ABAP developers or don't have Development access in SAP. In my particular role I don't have Development access, even though I've been an ABAPer for 20 years. 😉

Anyway the problem I have is that even when calling a remote enabled standard SAP BAPI, from BODS, I seem to have no control over whether we should commit or rollback based on the results. I suspect that the RFC connection/remote session will rollback automatically if not committed once the remote session is completed.

And so, I was wondering if anyone had dealt with this in BODS. Although I suspect most people would deal with this in a wrapper FM which is remote enabled.

[former_member187605]

I am sorry, I have no idea. Let's check with the DM guru's.

frank.densborn

[former_member688065]

Hi Frank,

Good Day,

Quick question I know you are data guys, I want to down load templates for each migration object for SAP Data Services like where we are downloading the templates from hana cockpit LTMC. Where we can down templates from data services for each migration like material master, vendor, customer etc.Please let me know I want down load the templates from data services or RDM Content along with ATL files beacsue these templates for functional guys to provide data to load using data services.

[LaoisExiled]

Look under

Support.sap.com\swdc > downloads > Best Practice

Search for SAP RDM S4H OP DS V6.42