IDoc vs APIs

[former_member821195]

With S/4HANA, everyone says API is the preferred approach for integration. I am trying to understand why older robust technologies like IDoc are no longer preferred, especially for an Inbound scenario.

Sorry, if this a dumb question. But, I would like to understand Why, if it is one.

Suppose a Sales Order creation in a system takes 3 sec via a BAPI (Time taken by IDoc processing, API processing, VA01 etc should be very similar to this, because they all go through the same processing logic in SAPMV45A)

When an external system calls S/4HANA to create a Sales Order via the API (https://api.sap.com/api/API_SALES_ORDER_SRV/overview), since this is a synchronous call, the call is handled in a dialog workprocess. This means that, throughout the execution of the logic in Sales Order creation, the dialog workprocess is held by the external caller, not releasing it to other users. According to the above assumption, that is 3 sec. In reality, most companies do not single thread their Sales Orders. This means, there may be multiple parallel calls into SAP, on various threads/dialog work processes to create Sales Orders. At some point of time, it could also result in all available dialog work processes occupied by middleware application, trying to create Sales Orders in SAP. At that time, business users logged onto SAP, will need to just wait for the slow system to respond.

Agreed that, SAP has provided parameters to control the number of workprocesses occupied by RFCs/a particular user etc. Suppose, the total available number of dialog work processes is 100 and the SAP administrator has setup a limit such that only 50% can be used by Integration user. This means, Integration engine can only use up to 50 dialog wps, which in turn means, it can only submit 50 concurrent Sales Orders into the SAP system. Mostly, threads on Integration Engine are built to run independent of each other. One thread on the Integration Engine need not know that there are already 50 connections active into SAP, and that it should Wait!! This could result in Integration Engine formatting all the data in correct format, go through every firewall to reach SAP, only to be rejected by SAP, because of the connection threshold.

Wouldn't it be better to use asynchronous Sales Order submissions into SAP? A great example is the robust IDoc framework. If Sales Order creation in a system takes sometime to go through the validation, lookups, rules, defaults, determinations etc., creation of an IDoc in the system happens in just milliseconds, because it doesn't go through any such steps. This means, the Integration Engine just submits the data and gets out of the SAP within milliseconds, freeing up the resources much quickly than using a synchronous API call. This also means, threads are available to exchange lots of data within a short period of time. Since IDoc data can be batched/packaged easily, multiple IDocs for many Sales Orders, can be submitted into SAP within a single call.

Talking in CRUD terms: I feel like, CRUD action performed by the Integration Engine in both scenarios are CREATE

API call: CREATE Sales Order (3sec synchronous call)

IDoc submission: CREATE a Request to Create Sales Order (few milliseconds asynchronous call)

When IDocs are received in SAP, SAP can leisurely process them according to its available capacity, and send confirmations back to the Integration engine, which can then pass it back onto the original caller.

There is another API based on SOAP (https://api.sap.com/api/SALESORDERBULKREQUEST_IN/overview) that SAP published for asynchronous A2A communication, but support only for limited sub-entities: header partner, header pricing element, payment plan item, item, item partner, item pricing element, and schedule line. oData API & IDoc support much more elements than this list. I haven't used this SOAP-API yet, hence not sure of how this handles the work process dilemma that I explained above.

Why is SAP still pushing everyone to use synchronous APIs, and why is there a broad idea floated around saying IDocs are obsolete (or atleast inferior to oData APIs) and should be avoided? Shouldn't this decision be absolutely based on whether the call should be synchronous/asynchronous? If there is no requirement for an synchronous response, why at all should the Integration Engine be allowed to hold the dialog work process?

[AlexGourdet]

Thank you for visiting SAP Community to get answers to your questions.

As you're looking to get most out of your community membership, please consider include a profile picture to increase user engagement & additional resources to your reference that can really benefit you:

• Profile https://developers.sap.com/tutorials/community-profile.html
• Tips for Questions: https://community.sap.com/resources/questions-and-answers
• Consider to take our Q&A tutorial at: https://developers.sap.com/tutorials/community-qa.html.

I hope you find this advice useful, and we're happy to have you as part of SAP Community!

All the best,

Alex

[DominikTylczyn · Accepted solution]

Hello parajude

That is an excellent question, really. I do agree 100% with your comments / statements on IDoc interface. It's mature, robust, efficient. I don't see any technical reason why SAP would kill IDocs in S/4HANA. Out of experience, they are still there in S/4HANA on premise and they are doing fine. They are widely used and more often than not there are no API alternatives.

I also hear people talk about IDocs being sunset. But I'm not able to find that information either in S/4HANA simplification list or in S/4HANA compatibility scope. So I tend to think, that it is just talk and delight with APIs. I don't see any merit in that, especially that SAP CPI supports IDoc integration Send IDOC from Cloud Platform Integration to ECC (inbound Part2)

Best regards

Dominik Tylczynski

[Ryan-Crosby · Accepted solution]

That and it's also the cornerstone for EDI integration into SAP. Can you use APIs...?? sure... will they do the job that IDocs will given that IDoc structures mirror EDI standards...?? nope.

[former_member821195 · Accepted solution]

Hello 3a9e4ce873a94034b33dc62b0ce600ee

Thanks for taking time and patience, to read through my very long question. I am very glad to know some others also shares my same thoughts.

I know that S/4HANA On-Premise still supports IDocs and have used them myself.

Please see this blog for example written by an SAP employee: https://blogs.sap.com/2018/11/15/s4hana-cloud-output-management-configuration-for-channel-edi/. It is written for S/4HANA Cloud Output Management and says "Channels ‘IDOC’ & ‘XML’ are deprecated & shouldn’t be used for system integration." Generally, functionalities are first released in Cloud and then later extended onto OnPremise versions. So, by that nature, I am guessing, this statement will soon be applicable to OnPremise versions as well.

Other resources that indicate IDoc is "Old" and API is the "Future":

EDI Connection of SAP S/4HANA with APIs Instead of IDocs – Protect Your Investment

As a best practice, when updating data in SAP, using a BAPI or RFC is usually preferable to using an...

Most of the latest S/4HANA APIs are OData based ones, so it’s a good idea to look for OData APIs fir...

Best Regards,

Jude Parakulam

[DominikTylczyn · Accepted solution]

I'd suppose that trying to make IDocs obsolete has something to do with the push to the cloud. I guess SAP is trying to unify integration options and thus is promoting APIs. But let's be realistic - I don't think SAP will stop supporting IDocs any time soon. There is too much legacy and too many customer would go ballistic if IDocs are really phased out.

SAP has already tried that with LE-WM. They put LE-WM in compatibility scope and pushed customers to migrate to EWM. From software provider perspective, it made sense, to keep only one code base to manage warehouse processes. Customers pushed back and all of the sudden "stock room management" popped up.

I think we can safely enjoy IDocs for quite sometime.

[Ryan-Crosby · Accepted solution]

parajude the output management blog mentions not to use the IDoc or XML options, but there is another option of EDI, which is tied to IDoc, cXML, or other data format options.

[former_member821195 · Accepted solution]

Thanks ryan.crosby2 for joining the conversation

I guess the issue is, someone higher-up in the organization took a decision to implement API-First approach to build integrations. When they hear from SAP, that there are oData APIs available in S/4HANA and more are being published with every release, they want all the integrations into SAP also built by API approach. To convince them to use any non-API technologies, is becoming a real-task, with more and more blogs being published supporting API usage.

I am sure some others may have faced this at other clients (or may face in future) and that's why I decided to publish my thoughts here, to hear opinions from other fellow developers.

Best Regards,

Jude Parakulam

[Ryan-Crosby · Accepted solution]

parajude Hmmm, that's an interesting take to lock into a single path of API for all integration... my guess would be that said individual doesn't have boots on the ground, and have a keen understanding of the reality of what goes into different integration projects whether it be A2A, B2B, etc. Is it single or bulk? Does it need to be asynchronous vs. synchronous? API via OData can present challenges as you have noted when there is need for bulk. Not an advisable approach to make your decision regarding how to integrate when you have not had a chance to quantify and/or qualify relevant information. Don't use IDoc any longer because it's not sexy and I don't have something new to pitch... that kind of mentality.

Regards,

Ryan Crosby