SAP PI's Value Proposition - Top 8 Capabilities to look for!

[kkram]

SAP Process Integration (PI in short) has gone through various iterations of innovation in the past few years. I have personally seen it evolve from its early version of 2.0 to the latest generally available version of 7.1. As I saw this year in SAP TechEd,  the next release 7.3 comes packed with some cool features. However, the idea of this blog is to discuss some of the commonly asked questions by my friends and folks in my professional network. With heavy weights like WebSphere, Tibco, WebLogic, Oracle Fusion trying to claim their market share in the Enterprise Wide Integration space, why should you (specially the ones that are SAP shops) choose SAP PI over the other for their integration needs.

Before we proceed further, please read this fine print. All the views provided below are my personal opinion and doesn't necessarily reflect my employer's. I work for my employer as a Netweaver Integration consultant but every customer's requirement is unique and you should definitely seek for professional opinion before making your business decisions. Treat the inputs in this blogs as just opinions, nothing more, nothing less.

Provided below are the list of capabilities that I think are unique to SAP PI. Other integration tools may have overlapping functionality but in my opinion, for an SAP shop, these capabilities may be attractive to choose PI.

1. Outside-in Development Approach:

This is by far my favorite feature, not only because it is very elegant in its implementation, but it is also the feature that enables hybrid integration scenarios possible (more on that later). In this approach, all data types and interface definitions are designed in the Enterprise Services Repository and are pulled in to the provider SAP system for service implementation. The main advantage of this approach is that there is a single source of truth for the data and interface definitions. This is very helpful when you have different teams for building Integration components and backend business logic. For example, PI developers will be building the data definitions in the Enterprise Repository and ABAP/Java programmers will pull these definitions to implement the business logic and provision them as consumable services. Any change to the data definitions should be first done in the PI system and re-imported in to the backend ABAP system. This provides better governance, auditing capabilities and change control.

2. Transport Management:

SAP PI is tightly integrated with SAP's Change and Transport System. With Enhanced Change Transport System (CTS+), it is possible to bundle PI development objects as ABAP transport requests. By using Solution Manager as a transport domain controller, it is possible to bundle all PI and backend ABAP developments in to an ABAP transport request. This improves the overall software logistics by providing better change control and transparency. This model also supports one-to-many transport paths, so transporting objects between multiple production systems and single development/quality assurance system is possible.

3.Integration with Solution Manager Diagnostics:

SAP PI can be centrally monitored using Solution Manager Diagnostics and with the upcoming 7.3 release, it is possible to monitor SAP PI end-to-end using Solution Manager.  I happened to see some of the cool demos the SAP team showed around integration of PI monitoring with the ‘Good Morning Page' in Solution manager. This capability is especially attractive for customers who want to implement the RunSAP methodology for production support and operations

4.Integration / Co-existence with other SAP Components

Since SAP PI is built on the Netweaver platform, it is possible to run other compatible SAP components on the same instance as SAP PI. This can reduce the total cost of ownership as well as provide a homogenous solution. For example, in the upcoming release (version 7.3), it is possible to run a Java only version of PI. This means, other Java based components like SAP Composition Environment (SAP's offering for building composite applications), SAP Netweaver BPM, SAP Netweaver BRM etc. can co-exist in the same instance as SAP PI.

5. Decentralized Adapter Engine

You can install multiple decentralized adapter engines and then connect to a central integration sever. This option is especially useful in integrating geographically distributed applications through a single integration platform. For e.g., an application hosted in a data center in Europe can integrate with an application hosted in the Americas through an adapter engine that is locally installed. This will help in reducing the application wait time because of network latency.

6. Principle Propagation / SAML support

PI supports single sign-on in an integration scenario through Security Assertion Markup Language (SAML). A sender application can securely pass its identity to the receiver application using SAML support in PI. Enterprise-wide integration often involves asynchronous/batch based messaging and in many cases involves multiple hops including the middleware. Using Principal Propagation, it is possible for the consumer service to execute the provider service using the same user ID. This greatly improves security controls and reduces maintenance efforts.

7. Out of the box integration content based on Enterprise Services

SAP provides many out of the box enterprise services. A list of available services can be obtained from the Enterprise Service Workplace (http://esworkplace.sap.com/sdn). For most of these services, pre-defined PI content is also available for download from the Service Market Place (http://service.sap.com).  Out-of-the box integration helps in reducing development time. Also, 3rd party vendors can provide their own integration content for easy integration with their applications

8. Security Model /  User Administration

SAP PI follows the same security model as other SAP applications. So it is easy to integrate SAP PI with the Central User Administration (CUA) engine or with SAP's Identity Management.  This reduces maintenance efforts and increases the transparency in role mapping.

Now, going back to point 1, I stated that outside in approach enables hybrid integration scenarios. What did I mean by that? Assume that after reviewing the above capabilities, you still chose to go with a non-SAP integration platform/ESB. In that case, you could still install the Enterprise Service Repository (say for example on a Composition Environment or even a PI system) only in your development environment, use it to create your integration artifacts like data types, message types etc., and pull these definitions in to your backend SAP applications. Once done, you could expose them as services and consume them through a non-SAP integration tool in runtime. In this hybrid approach, you still implement the goverance and controls in your development process but use a non-SAP integration tool for integration (may be to adhere to your strategic road map).

All the capabilities provided above are available in the generally available version of SAP PI. However there are some cool innovations coming our way in PI 7.3 and beyond. Though these may not be the deal breakers, it is always nice to talk about what's coming new.

Eclipse based development environment

The demo that was showed in SAP TechEd was pretty cool. As I saw/understood, both Enterprise repository and Integration Builder for Directory are integrated into Eclipse platform through a plug in. More importantly, I saw a feature where you could develop you integration scenarios in a single view. That is, both design and configuration exists within the same 'Integration Flow' (I thought Integration Orchestration was an apt name for this though). As someone who does hands on work on SAP PI (still), this is something to look for.

Java Only PI system

With many ABAP based adapters like IDOC adapter and XI adapter moving in to the Adapter Engine, it was quiet evident that PI as a Java only stack was imminent. I personally feel that dual stack implementation of PI was a complex architecture. I know some customers use PI in its ABAP only version (yes, by using different ABAP clients and implementing the file and database adapter in ABAP) but a Java only PI system means that it can co-exist with CE and other Netweaver Java based applications.

I hope I summarized the key capabilities that are differentiators for SAP PI. Again, one size doesn't fit all. It is perfectly OK for customers to choose best of breed applications. The mere fact that integrations do exist within your landscape is because you want best of breed applications and when it comes to choosing an integration platform, it is no different. However, I would like to hear from the community if my observations make sense.