There have been lots of discussions on using SAP PI or not. The same applies to my projects as well: Often enough, project management needs to make a decision on running integrations through PI.
I want to share my highly subjective point of view regarding this matter.
Using PI has its advantages, which you can find on any SAP documentation. Some of them are:
- The requirement of middleware development in .NET, Java, or even ABAP virtually disappears. You make PI configurations instead, which is theoretically easier in most cases.
- Centralizing the entire communication makes everything more transparent and managable.
- In case an integration error occurs, it is nice to have a neutral central system to do all the logging & monitoring of the data traffic.
However, there are disadvantages as well:
- PI requires an extra licence. SAP won’t give if for free at this time.
- It requires extra human resources to configure & manage & monitor everything.
- ABAP development is not enough to build or extend an integration. Every time an ABAPer does something, PI needs to be touched as well. Therefore, development time could be longer than a direct ABAP solution.
- PI inevitably has a performance cost, making the integration run slower in most cases.
- If you run everything through PI and the machine running PI gets in trouble, all of your integrations will stop.
Considering those points, here is my (once again) highly subjective evaluation.
If you have to integrate SAP with external applications (meaning: 3rd part companies outside your firewall) and you don’t want to make SAP accessible without VPN due to security reasons, using PI is a good idea. Just make PI directly accessible through the Internet, and make it communicate with SAP securely behind the firewall.
If you have lots of SAP & NonSAP systems talking to each other, having a centralized system to conduct & log & monitor all the trafic could be preferrable. This would save development time on middleware & transformation & log coding. Especially if there are lots of asynchronous integrations & the integration methods vary greatly (meaning: web service, FTP, file, RFC, etc), letting PI do the heavylifting could save even further development time. Just make sure that you are beyond the break even point.
On the other hand…
Having PI might not be worth it if you merely have a handful of internal applications communicating via simple Web services or files or something. Especially if you don’t need to develop external middlewares.
In case you have a synchronous integration, the performance cost of PI might start to be a pain – especially if it’s a GUI application facing the users directly.
In such cases, you can make the applications communicate directly, and do some minor coding for error management & data logging – instead of inviting PI to the party.
During your evaluation, please remember that PI is merely a “FedEx” application: It will carry your data package from one system to the other, but it doesn’t care what you do with it. This means, it will ensure that you get the TXT file correctly. However; if you get in trouble during your BAPI calls, PI couldn’t care less – unless you develop a secondary integration to return your BAPIRET2 or something.
Here are some further resources on the subject I found to be useful:
- http://www.architectsap.com/blog/sap-netweaver/sap-netweaver-pi-7-1-usage-scenarios-when-not-to-use-sap-pi/
- http://scn.sap.com/thread/1708405
- http://www.itworld.com/article/2758367/cloud-computing/architectural-principles-for-usage-of-sap-pi-in-a-soa-environment.html
- http://blog.mindsetconsulting.com/2011/12/when-to-use-sap-netweaver-gateway-vs-pi.html
Leave a Reply