Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member184681
Active Contributor

So many times I felt like I was between a rock and a hard place, when developing an integration scenario. The reason was that I have found a BAPI that perfectly matched my requirements, but did not want to go for a BAPI-RFC scenario, because of no monitoring available in the backend system. And on the other hand, I would be glad to stay with pure SAP standard functionality, for support reasons. Moreover, I found out in SDN Forums that I was not the only one to face this dilemma.

But I am happy to announce to all of you that there is a way to have your cake and eat the cake. You can stay with SAP standard AND enable monitoring at the same time, for standard BAPI scenarios. I would even say more: there are two ways to achieve this, both having some strong and weak sides, and it is up to you to decide which one matches your requirements better.

Option #1

The first way is to encapsulate the BAPI into an ABAP Proxy class. The main point here is to import the BAPI metadata to ESR first, and then use it to create the Service Interface:

Then, you just work with this Service Interface as with any other, to complete the scenario. Finally you generate a proxy class based on this Service Interface in SPROXY transaction of your backend system, and call your BAPI in the main method of this class.

For more details on generating the Proxy, please refer here:
http://help.sap.com/saphelp_nwpi71/helpdata/en/e5/004f22192b444ab0bac1364d73ea6f/content.htm
http://www.****************/Tutorials/XI/ABAPProxy/page1.htm

Option #2

The other option is to automatically generate an IDoc message type from the BAPI directly, in BAPI transaction. Simply locate the BAPI you need on the list and choose the following option from the top menu:

Then you choose a message and IDoc type to be created, a package to be used, and wrapper function modules to be created, and you have everything automatically done for you. And you can use this IDoc just like any other, which also means that you have lots of monitoring tools for your scenario.

Please refer here for further details on generating ALE interface for BAPI: http://help.sap.com/saphelp_nw73/helpdata/en/4a/644ebc4b752b1ae10000000a42189c/content.htm

Summary

One can now ask: should I go for Proxy or an IDoc? In fact, there are several decision factors that you need to consider to make a choice. First of all, you can complete an asynchronous scenario with either Proxy or IDoc, but only Proxy can be used for a synchronous one. Moreover, you can use the Advanced Adapter Engine processing for proxy even if your PI is below the newest 7.3 version, comparing to IDOC_AAE adapter being available only in PI 7.3. On the other hand, IDocs give you this useful content-based search tool in we09, that does not have any equivalent for Proxies. Finally, the final decision might depend on particular company’s general policy or preferred practice.

Afterword

In the end, I would like to clearly emphasize that I do not feel like I have just invented the wheel again. I do know that both possibilities I have described are already well known and widely used by many systems integration consultants. But for some of us, the developers , this might be a brand new idea on when and how to use these features, or how to solve one of the typical problems of monitoring BAPI scenarios that we face so often.

Labels in this area