Back in the day, if you wanted to send a Purchase Order from SAP to what we used to call Ariba Network, you knew exactly what you had to do. Fire up NACE, configure your output type NEU, set up the partner profile in WE20, define your port in WE21, and let the IDoc do its thing. It was not the most elegant setup, but once it worked, the whole concrete foundation of IDoc system keeps it persistency worked. And when something broke, you went straight to WE02 or BD87, found your IDoc, and you knew exactly where the problem was. Even you can cheat sometime by with the way troubleshooting with WE19.
Fast forward to today, and the story looks a little different. If you're on S/4HANA and integrating with SAP Business Network, you're likely dealing with something called 42K – the scope item “Automation of Source-to-Pay with SAP Business Network”. Same business outcome, different plumbing. And if you're coming from the IDoc world like I AM, the first time you see RSNAST4EDISOA and ORDERREQUEST_OUT_PROCESSING in your NACE config, you start asking questions. And you might react the same as I am, maybe It's just an upgrading of the program RSNASTED and Routine EDI_PROCESSING to cover some error handling cases.
Until you do save the Purchase Order and expect an output type get generated gonna turn green immediately to dispatch the idoc out (as I don't have flexible workflow setup in advance for testing purpose), but you refresh WE02, nothing shows up. Check back the output type just now and you see this
What do you mean by Active Receiver?
That's a fair question to ask. In the IDoc world, “receiver” was crystal clear, it was your partner profile in WE20. Vendor number, message type, port. Simple, explicit, one entry per partner. When something broke, you knew exactly where to look.
But here, there's no WE20 in the picture. No partner profile. The system fired the SOAP call, RSNAST4EDISOA did its job, ORDERREQUEST_OUT_PROCESSING ran and then it looked for something to tell it: “Hey, for this vendor, which CIG endpoint should I send this to?” And found nothing.
That “something” is what SAP calls Logical Receiver Determination (LRD). And it lives inside SOAMANAGER, not in WE20, not in NACE, not in any of the usual places a classic MM consultant would look first.
Think of it as the new partner profile. Except instead of maintaining one entry per vendor, you create routing rules and the routing key is PARTNER_ID, which is your vendor number. OR you can literally use Partner Type or Partner Role as higher level Condition, assign them to a Provider IBC Reference (your CIG channel), activate the rule, and the system now knows where to send the message.
Once maintained, you would see the difference of the way system dispatching the Purchase Order to CIG. We used to come to WE02 to check, but now no longer Idoc.
Comparing the classic way of practice where the same thing happens but the way handling is different.
- Partner profile → points to a Port (WE21)
- Port → maps to an RFC destination (SM59)
- Each RFC destination → points to a different HTTP endpoint / CIG URL
Possible, but the logic was spread across three transactions. Here it's consolidated into one routing table with explicit conditions
An alternative way of standard practice to advocate the integration between S/4HANA and SBN on top of the classic practice which is a “sehr tolle” foundation to lean on.
Either is correct.
One is where you've been. The other is where the platform is heading. The choice today, if you're on On-Premise, is still yours. But if you're moving to Public Cloud or if your next implementation is greenfield on S/4HANA, the choice is already made for you (as you are not able to find WE20 on your public cloud at all)
What I find useful is knowing both well enough to understand what changed, what carried over, and where to look when things go sideways. Because the business requirement hasn't changed at all, the Purchase Order needs to leave your system, reach the supplier, and come back confirmed. Everything else is implementation detail.
Tuan
Source link
