Dealing with BP Replication

So what kind of tools we have at our disposal? Most of it is gather on the SAP side (1) but lets see it for us own.

For starters of course we can design our solution around a standard BAPI – BAPI_BUPA_CREATE_FROM_DATA. This one has more blogs on the internet I probably read so there is no not to dive into it here I believe. Lets sum it up with a sentence, like in every standard BAPI you fill the relevant obligatory structures and get a standard BP. This way you can integrate BP in every format, from flat file, webservice, RFC etc. You will also see that (or other ones since depending on scenarios there are more to choose from) as a part of other solutions making it a well round answer to your problems.

Then there is a second way, an API. Actually there is 2 ways to do it one is (2) a Central API and the other is (3) an SAP Business Accelerator Business Partner API. When it comes to the CL_MD_ BP_MAINTAIN=>MAINTAIN from the Central API is actually quite similar to using the BAPI mentioned in the first section when it comes to data structures that has to be filled to make it work. Since there are also a lot of blogs with some sample codes even in this case I won’t be going into details. Use cases are also the same as in BAPI, however the second API is actually a bit of different story and something I used in one of my latest projects. Since the Odata APIs can be policed and gated in many ways on the SIS there is actually a lot of control before the data reaches SAP system. Wait a minute you would say here, of course you can expose the pervious methods in the same way. The answer is yes, since SIS is quite flexible those could also be used, however this one was designed for it, with it rest methods of get/post etc. which in other cases you would’ve had to create. Apart from the configuration in the t-codes SICF (activation) /IWFND/MAINT_SERVICE (adding service) it works out of the box. The only downside I discovered after using it for some time is actually the data it returns – those are not complete BUT000/ADRC etc. records. They are sometimes, joined tables below it (BUT020 with ADRC for example as address data) others contains much less data then their database counterparts (supplier and customer roles), so this approach isn’t fitting to every scenario. Integration can be built per system so it’s quite flexible if needed.

Then there is a bit older approach – IDOCS DEBMAS/CREMAS. Unfortunately those idocs have a fatal flaw in the current S4Hana landscape. Mainly they are bound to the specific roles of a supplier and a customer. Of course they can create the main BP role, if it’s not in the system, however it’s only an addition. That’s why you will see them in older release and in specific integrations, however not as a main tool of data integration. Because this topic is going to be less and less relevant, we can skip going into details.

Finally there are standard SOAP webservices for this job – BusinessPartnerRelationshipSUITEBulkReplicate family, which unfortunately or fortunately I had the most experience with. Boy where do I start, this is a really robust tool however because of it it’s also hard to use. Since it’s a main DRF tool (7) there is a table to maintain GUIDs between systems when editing BP and other parameters. It can create or modify any existing BP role with extension, which can be done in inbound and outbound enhancement points depending on your story. However for that you need to have a specific enhancement on the webservice itself. Since it’s a webservice you can have partners that directly post messages or through some data bus like SIS where additional mapping and logic can be done. You see where I’m going – the options are numerous and when you just start the topic of BP replication, it easily get out of hands. We could go on and on, about weird validation placed in this integrations (that for example would delete the role if it’s not sent), however the same process keeps the BP in check. This interface make sures that only relevant data stay in the system and there is no discrepancy between sender and receiver, which we didn’t have in any of the previous ones. If you wrap it around on the SIS like the API you can also get all the pluses of that solution. There are also more potential usage like in (6) and probably some others I have no idea were possible.