Skip to Content

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

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.

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

2 Answers

  • Jan 23 at 06:48 AM

    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

    Add comment
    10|10000 characters needed characters exceeded

  • Feb 13 at 08:02 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded