Would like to give an overview of PI 7.1 Components and its features over XI 2.0/XI 3.0/PI 7.0.

The SAP NetWeaver Process Integration (SAP NetWeaver PI) offering provides open integration technologies that enable process-centric collaboration among SAP and non-SAP business applications, both within and beyond the enterprise. By providing customers with seamless integration at sustainable costs, SAP NetWeaver PI removes the barriers associated with true integration.

Fig1- Components of Process Integration PI 7.1

The Various Components of Process Integration PI 7.1 are

a) SAP Solution Manager

SAP Solution Manager is used to manage the entire SAP solution landscape which seems to be a challenging task. Companies can minimize risk and increase the reliability of their IT solutions. SAP Solution Manager helps reduce TCO throughout the solution life cycle.

b) Enterprise Service Repository

ESR is a central repository of information that contains all the services. ESR is a container, stores all the underlying Meta data of application objects like service interfaces and descriptions. The global data types, interfaces and business processes maintained in Enterprise service repository which can be reuse where needed

c) Service Registry(SR)

Service Registry is a common pool available in SOA platform where the services of an enterprise are shared. Providers publish the services in the registry and Consumers discovers the services that need to be consumed. Service Registry is the UDDI part of the Enterprise Service Repository (ESR) which enables service consumers to find services.

d) Integration Directory(ID)

The Integration Directory is the central tool for configuring the processing of messages, such as the systems and external communication partners that are involved in the process, the routing rules that govern the message flow between these entities, as well as the settings for communication incl. security.
e) Integration Server

The Integration Server is the runtime environment to provide secure, standards-based, reliable, and scalable communication between provider and consumer applications

f) Advanced Adapter Engine (AAE)

The Advanced Adapter Engine AAE provides built-in mediation capabilities to reconcile incompatible protocols, structural maps, schema, and data formats between provider and consumer applications which eliminate the need for ABAP Stack during the process.

e)SAP NetWeaver Administrator (SAP NWA)

The SAP NWA safeguard the deployment and operations of the processes in order to ensure runtime governance, security with access control, authentication, auditing, enforcement of compliance to policies, and monitoring of the service execution.

It handles End to End Monitoring, Performance Monitoring, Message Monitoring, Component Monitoring, Alert Monitoring, Adapter Monitoring, Cache Monitoring, Sequence monitoring and Logging and tracing.

f) System Landscape Directory(SLD)

The System Landscape Directory of SAP NetWeaver (SLD) serves as a central information repository for your system landscape. A system landscape consists of a number of hardware and software components that depend on each other with regard to installation, software updates, and demands on interfaces.

SAP NetWeaver : SAP PI 7.1 Usage Scenarios: When NOT to use SAP PI

SAP PI is the middleware platform for integration purposes; however, we mention scenarios where SAP PI usage is not recommended from our project consulting experiences.

SAP PI is the middleware platform from SAP for enterprise wide integration scenarions. The majority of the backend integration scenarios can make use of SAP PI for integration pursposes.

However, there are several usage scenarios where SAP PI usage is not recommended.

Synchronous integration: This is a scenario where the request and the response messages are synchronous, such as an inventory check scenario from the web. A Synchronous request places tremendous resource demands on the SAP PI infrastructure; the request and response messages are persisted (based on configuration), and the thread is held open to receive the response from the target application. Hence, in this scenarion, usage of SAP PI is not recommended.
User Interface Integration scenario: This is a common scenario faced by the development team – the Webdynpro application is developed on the SAP J2EE application server integrated with the portal. The business data has to be fetched from the SAP ECC backend.

The User Interface would demand a quick response from the backend for fetching data and conducting the transaction. This is a synchronous scenario, and it would also be conducted with high usage every day. Hence, it is recommended to have a direct integration between the source application (WebDynpro application) and the target application (SAP ECC6) without using SAP PI. It is also recommended to expose the backend functionality as standard services.

For example, integration between SAP Portals (containing SAP BPM, SAP CAF, SAP WebDynpro) and SAP Suite (SAP ECC, SAP CRM, SAP SCM, SAP SRM etc.) should be conducted without the usage of SAP PI; the services should be exposed from the SAP suite as standards-compliant enterprise services.

Web Service interface of backend application: Many times, the target application in SAP/Microsoft/Java/Legacy is available as a standard web service. In such cases, the web service interface can be easily consumed in the source application. In such scenarios, SAP PI adds no value for transformation or backend integration.

In conclusion, SAP PI usage is usually not recommended for User facing applications where the backend application is available as a standard web service. SAP PI is almost always suitable for integration between backend applications not requiring human intervention.

Features of XI 3.0 over XI 2.0

Business process objects (CCBPM) are introduced to design a stateful cross component business process.
Context Objects are introduced to increase readability of routing rules instead of having XPATH expressions.
Channel Template is introduced that can be instantiated to Directory
WSDL,XSD,DTD can be imported to interface objects in External Definition & XSLT, Java are imported to Mapping Objects in Imported Archives
Message exchange between ABAP Proxies is introduced to improve performance by having no services of Integration Server.
Mapping Templates are introduced to have reuse of mappings, and to split and merge messages for BPM.
Support of packages of a Software component version can be used in versioning all Repository objects.
Data type enhancements can be introduced to for customer specific fields.
Party is introduced to facilitate B2B functions and Service generalizes business systems, Business service & business process.
Receiver determination rules are introduced to determine which receiver a certain message has to be sent to at runtime.
Sender agreement and receiver agreement are introduced for inbound and outbound processing.

Features of PI 7.0 over XI 3.0

Simple Overview of all messages is introduced in Message Monitoring with the help of Message status overview.
Mass restart of messages is possible
Critical alerts can be raised for all adapters. (e.g. - if JDBC adapter can't connect to database)
Adapter Modules are introduced in channel templates
Improved usability of adapters is possible by introduction of tabs (Information is classified and distributed across tabs)
Archived messages can be displayed in Message Monitoring
Maximum concurrency can be defined in receiver adapters (FILE, JDBC).
Optimizing thread usage is possible in JMS adapter by reusing the spare threads from SAP J2EE Engine
Extended SOAP adapter usage is possible by AXIS Framework and Encryption methods for SOAP 1.2
Maximum File size can be determined in File Adapter to limit the memory usage

Features of PI 7.1 over PI 7.0

a) Repository Objects

Integration Repository(IR) is renamed as Enterprise Service Repository (ESR)
Message Interface (MI) is renamed as Service Interface (SI).
Service Registry (SR) is to support publishing, classifying, discovering services.
Service Interfaces (SI) may contain several operations where each operation describes one communications (Synchronous / Asynchronous). The various attributes are Category (I/O/A), Mode(S/A), Interface Pattern & Operation Pattern
Interface patterns is a new attribute of a service interface that describes the type of communication that is to be executed on the message (Stateless/ Stateless Xi 3.0 Compatible / TU&C/C and Stateful)
Operation Patterns depends on Interface patterns (Normal / Commit/ Rollback / Confirm/Tentative Update/Compensate)
SAP Global Data type (GDT) is introduced to have business semantics in order to replace SAP Core DT
Interface Mapping is renamed as Operation Mapping.
Folders are introduced to organize projects and interfaces which have access authorizations
We can use either XML toolkit / JDK 1.5 toolkit for JAVA and XSLT Mapping.

b) Mapping Enhancements

We can set Failure Behavior in FIX values and value mapping (Return initial value/Default/Exception)
Output of fields and functions can be used for Multiple target fields for Reusable / Better Runtime Performance
Tool support to adjust the mappings after the structure changes to avoid structural inconsistencies.
Storing intermediate Results in a variable can be possible and can be reused.
Complete copy of XML sub trees is possible
Parameterized mapping is useful for Channel Lookup and Reuse of multiple mapping in Interface Determinations and to transfer content of Container in UDF.
Function Libraries is useful for Reuse of UDF and enhanced portability of UDF.
Graphical Support of RFC Lookup and JDBC Lookup is available.
Importing SQL Tables Meta Data is possible

c) CCBPM

Step Groups- Set of steps that can be reused by embedded in Integration Process across SWCV. Step Parameters can also be used in step groups.
Configurable Parameters- Defined in Integration process and the values can be used assigned in ID. Here Agents, Communication channel and simple data type can be used as parameters.
User Interaction - User Decision Step in IP with an agent configured in ID is used to get the workflow message to make a decision

d) Configuration Objects

Web Service Reliable Messaging WS-RM for Asynchronous messaging is configured in Sender Agreement and Communication Channel for a considerable level of reliability and security.
Principal Propagation based on Security Assertion Markup Language (SAML 1.1) can be configured in WS adapter. It means user is securely propagated from a sender system to receiver systems. An authorization check in receiving system based on original user.
Advanced Adapter Engine (AAE) is used to increase the performance of message processing by eliminating the need for ABAP stack during the process.
Reusable Receiver Rules for logical routing can be used in different Receiver Determination.
Cache Notification function is enhanced to analyze the possible error.
XML Payload validation is possible in sender and Receiver agreement.
Publish the sender agreement in Service Registry (SR) for WS Client and Provider connected to IS.
Centralized administration and monitoring is done by SAP NetWeaver Administrator.
Message Packing enables processing bulk messages in one service call and reduce context switches

SAP NetWeaver : SAP PI 7.1 - Usage Scenarios for Integrating Java, Microsoft, Mainframe and Legacy Applications

SAP PI 7.1 can be used for integration purposes across a wide variety of usage scenarios within and outside the organization. In this blog, we mention the major scenarios where SAP PI can be effectively used.

SAP PI can be used for enterprise integration across the organization landscape for integrating SAP and nonSAP systems. SAP PI can also be used for B2B integration to our trading partners.

Here are the major usage scenarios where SAP PI can be effectively deployed:

Integration between SAP systems such as SAP ECC6, SAP CRM, SAP SCM, SAP SRM etc.
Integration between SAP BW and nonSAP systems for bulk data transfer in absence of an ETL tool
Integration between SAP and nonSAP sytems such as Microsoft .NET applications, J2EE, Mainframe and Legacy applications. A typical scenario is: Product Data Management System posts HTTP request to SAP NW PI 7.1 and the data is transformed to the above IDOC based on business rules.
Integration between SAP PI and other middleware products such as TIBCO, webMethods, IBM Websphere, Microsoft Biztalk etc.
Integration between nonSAP and nonSAP applications
B2B Integration : Trading partner integration through EDI, XML document exchange, RosettaNet or other industry standard protocols
Service enablement of legacy applications; provide a webservice capability to legacy applications
Finally, SAP PI should be fully leveraged for service enablement and business process orchestration between applications across the enterprise

Many SOA enabling standards (WS standards) are implemented in SAP PI7.1 making it the core technology enabler of SAP Enterprise SOA. (e.g. WS Reliable Messaging, WS Security, SAML, WS Policy, WS PolicyAttachment etc.)

Creating Monitoring Process with PI 7.1

Purpose
We can monitor the processing of XML messages, the throughput and the processing of integration processes using monitoring functions. Monitoring functions are available for PI scenarios and integration processes.
Introduction
A monitoring process is a special kind of integration process that you use as part of Business Activity Monitoring (BAM). We use a monitoring process to monitor the milestones in a business process. The business process can be distributed across multiple applications. When a milestone is reached, the applications each publish events, to which a central monitoring process is subscribed.
We can define a monitoring process that can monitor events from different applications. A monitoring process can subscribe to events from SAP or non-SAP systems. The monitoring process can filter the events and then process them further.
Creating a Monitoring Process
First login into your Pi 7.1 system -> Enterprise Service Builder. Go to the namespace you want to create Monitoring Process. I assume that DT, MT and SI are created and everything is on place.
Right click on namespace and click on new. You will see this window.

Select Monitoring process and give desired name to it.
A monitoring process usually comprises the following elements:
●      One event message that starts the process
●      Further event messages that the process subscribes to by means of correlations.
●      Conditions that evaluate the events and create corresponding alerts
Procedure to Create a Monitoring Process
1.      Create a monitoring process.
2.      Define a starting receive step that waits for the event message that is to start the monitoring process. If various different event messages are able to start the monitoring process, define a starting receive step for each one.
3.      Define a correlation for the event messages that the monitoring process is to subscribe to.
4.      To receive the remaining event messages in the monitoring process, insert the relevant receive steps in the process definition. Each of these receive steps must use an activated correlation. A receive step can in turn activate a correlation.
5.      To query data from Business Intelligence, use a transformation step that calls a parameterized mapping. You can use the result in a condition and make further processing dependent on the result.
6.      Define conditions for filtering the events and for triggering alerts:
Insert a switch and for each branch define the relevant condition and the action that is to be executed when the condition is satisfied.

In monitoring processes you can define that alerts are triggered if particular events occur or deadlines are missed. Furthermore, you can define conditions for creating alerts. You can also include information shipped by Business Intelligence in the conditions, for example, whether a customer is an A customer.
Note
only use monitoring processes to monitor events from applications. Do not use a monitoring process to monitor events from other monitoring processes. These kinds of monitoring process hierarchies are not supported.
Business Scenario
We need to send some Non SAP PO, to the Composition Environment and which will be picked using Guided Procedure and then depending upon some validations it will be generated in CE. In some steps, Manager will need to check whether it is correct or not, if it is not then PI is supposed to raise an alert to the concerned person. For this kind of scenario we can use Monitoring Process to monitor business processes.
Using Transaction SWF_BAM, we can Business Activity Monitoring - Administration and here we can create Event Linkage to start our Monitoring Process.

This object type should be same as Business Object created in CE. A message proxy creates an event message from the event and the corresponding data; a monitoring process can then subscribe to this event. This is main aim of Create Event linkage. System filters events by means of a condition.
An application can trigger an event based on the change to the status of a business object. This can be an SAP or non-SAP application. The system creates an event message from the event and the corresponding data. An intermediate monitoring process can then subscribe to this event message. For this you require the local event infrastructure, which is provided by SAP Net Weaver Process Integration 7.1.

SAP NetWeaver - 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.