Architectural Principles for usage of SAP PI in a SOA environment
In our experience working with customers who want to adopt Enterprise SOA in an SAP environment, many customers tend to believe that SAP PI is a prerequisite to enabling and consuming enterprise services. Since SAP’s service management tools of SAP ESR and SAP SR are provided by the SAP PI infrastructure, customers tend to believe that they need to use SAP PI in all service interactions.
In this blog, we would present guidelines and best practices for usage of SAP PI in an Enterprise SOA environment.
Usage of SAP ESR and SAP SR for managing enterprise services:
- SAP ESR and SAP SR should be used for modeling and publishing enterprise services in the landscape.
- SAP ESR and SAP SR are provided by SAP PI and SAP CE infrastructures. Hence, the customer could install either SAP PI or SAP CE to get access to the SAP ESR and SAP SR instances.
- SAP ESR should be used to model and manage all SOA assets. We can use it to model SAP and nonSAP services. SAP ESR models can be used to directly implement the service implementation in SAP. With SAP ESR model, it is not possible to directly implement a .NET or J2EE service. However, the .NET or Java service signature can be made to conform to the Service definition described in SAP ESR.
- Enterprise Services Repository used to define re-useable services rather than classical interfaces
- SAP SR can be used to manage the publication of SAP and nonSAP services.
Usage Scenarios of SAP PI:
- All web services and enterprise services that are being exposed to the customer should go through SAP PI. This is to ensure scalability, security and availability, since going through a managed middleware ensures the quality of service (QoS) for the enterprise service. For example, we cannot expose an application web service directly to a customer in a B2B scenario since the security and load are unpredictable
- SAP PI is used to create abstraction between heterogeneous sender and receiver systems based on SOA standards to provide unified access to legacy systems.
- SAP PI 7.1 is for mainly leveraging functionalities for service enablement, and service and process orchestration
- Integration between non-SAP system and non-SAP system.
- Use SAP PI for both A2A, B2B integrations including EDI
- Use SAP PI for service enabling legacy applications that lack a framework for exposing web services.
- For SAP PI 7.1, many SOA enabling standards or WS standards are supported as part of this release making it the core technology enabler of Enterprise SOA. (e.g. WS Reliable Messaging, WS Security, SAML, WS Policy, WS PolicyAttachment etc.)
- For a predominantly SAP landscape, SAP PI should be the strategic integration platform and the enterprise wide service bus
When not to use SAP PI in enterprise SOA:
- Recent release of the SAP platform (SAP ECC6) has native capability to expose enterprise services. The service should be modeled in SAP ESR and implemented in SAP ECC6. This service is readily available for consumption across the enterprise without the intervention of SAP PI or any other middleware.
- SAP PI usage is not recommended for synchronous communication since it places a significant load on the infrastructure services for servicing a synchronous request. Also, SAP PI cannot guarantee the QoS and response time in processing a sync request.
- For User Interface scenarios (such as a WebDynpro UI), the UI can directly consume enterprise services. SAP PI should not be used in UI driven scenarios if the backend is exposed as enterprise services.
- If a nonSAP backend such as .NET or J2EE or any other platform is exposing business services in a UI scenario, SAP PI is not needed for intermediation. The UI such as SAP Portal based User Interface through various SAP NetWeaver technologies (SAP CAF, SAP BPM, WebDynpro etc.) can directly consume nonSAP services.
In conclusion, SAP PI should be the strategic integration platform in a SAP centric landscape. However, SAP PI should be used as an intermediary if it adds value between the sender and the receiver entities.
-- Manish Agarwal, SAP Program Manager, Nagarro, Inc.
http://www.nagarro.com/blog/architectural-principles-for-usage-of-sap-pi...