GVersion 1.0 Authors: Amar Nemalikanti, Keerti Nayak, Sreedhar Kanchanapalli, Yashu Vyas

SAP NetWeaver Process Integration Playbook

Contents

Planning and assessment 1 Introduction 1

Integration history 2

Integration challenges 3

What is an Enterprise Service Bus (ESB)? 4

ESB key features/characteristics 4

The case for an ESB 6

Selecting an ESB 7

Understanding ESB functionality is an essential step in selection 7

Positioning SAP NetWeaver Process Integration (PI) as the ESB 8

How can SAP NetWeaver PI as ESB help address the above integration challenge? 9

Integration strategy 15

Integration architecture strategy 15

Communications middleware 18

Application and technical connectivity 22

Application connectivity options 22

Integration technologies options 23

Effort estimation and staffing plan 24

Project estimation tool 24

Staffing/resource planning model 24

Staffing plan 24

Envisioning 26 Interface/scenario-related decision factors 26

New PI 7.3 feature and function usage 26

Number of connected business systems 27

Number of live interfaces 27

Type of high-volume interfaces 28

Long-running ccBPM processes 28

Implementation 29 Design Best practices (Interface Strategy, Error Handling Strategy, etc.) 29

Purpose 29

EAI Playbook

Audience 29

Assumptions and risks 29

Scope 29

Executive summary 29

Integration platform 29

Integration patterns and key considerations 30

Integration strategy for SAP systems 30

Design Error handling strategy 34

Purpose 34

Scope 34

Executive summary 34

Error notification 34

Message reprocessing 34

Definitions 35

Error classification 35

POF trigger 36

POF connectivity 36

POF transformation 37

POF process 43

Design Archiving strategy 49

Purpose 49

Scope 49

Audience 49

PI engine archiving 49

Archiving 58

Different archiving/delete-related reports at a glance 60

Design PI application transport strategy 61

Purpose 61

Scope 61

Audience 61

Transport method used: CTS+ 61

Transport naming convention 64

Design Middleware/system sizing process 64

Development Development standards and naming convention 64

Purpose 64

Scope 65

Audience 65

Guiding principles and best practices 65

EAI Playbook

SLD 65

ESR 68

ID 73

Summary 76

Development Templates 81

Development Checklist 81

Code review checklist 81

Run procedure 84

Development checklist 85

Development readiness checks 87

Development status and templates 87

Production cutover 87

Plan 87

Strategy 88

Continues Evolution 98 Interface monitoring approach and strategy 98

Introduction 98

Available from 98

Time... is now!! 98

Customers view 99

Defect and change management 101

Standard CR process for development/enhancements 102

Handling bug fixing, issues, and user changes 103

Urgent changes 104

Outage processes 105

Planned outage processes 105

Unplanned Outage Processes 106

Best practices to avoid unplanned downtime 107

Release management 109

Purpose 109

Introductory notes 109

Integration 109

Features 110

EAI SW upgrade/update processes 110

Decision factors 110

Usage type 112

PAM compliance 112

EAI Playbook

Downtime requirements 113

IT/operations-related decision factors 114

High-availability setup 114

Auditing requirement 114

Basic and operations customizing 115

Third-party adapters and content 115

EAI Playbook

! "" Heading 1 , .

Planning and assessment

Introduction

Most enterprises run and maintain hundreds of applications supporting their business needs. The applications can be in the form of packaged applications or custom-built solutions. These could be built in house or acquired from third parties, or have been part of the original legacy systems or come in due to mergers and acquisitions or a combination of these.

It is sometimes surprising how organizations get these landscapes into a state of disarray as far as their information technology (IT) systems are concerned. Further analysis makes us believe that there are reasons why such varied systems grew and prospered.

Most solutions available today came up because they were the best-of-the-breed solutions available at a point in time for a business function when they were really wanted. When decisions were made to buy or make these legacy solutions (be it in COBOL or other ancient languages), it was still considered advanced.

Also, some solutions are specialized in a particular area, such as billing, human resources (HR), supply chain, manufacturing, retail, distribution, hospital, etc. More often than not, they provided solutions at minimum Total Cost of Ownership and required very little customization.

Many heavyweight applications of today like SAP and Oracle do provide a lot of functionality required to run todays business. However, these only cater to a fraction of the clients requirements. Even in the complex business environment that we see today, many enterprises still use applications that are above and beyond the scope of these heavyweights.

With the world coming closer, users no longer want to limit their business to smaller silos within the organization. Enterprises have started realizing that the potential of an organization can only be optimally realized when all the divisions within the organization are accessible without boundaries. Limiting such an interaction due to technology-related limitations is unacceptable to the business. Technology is there to grow business and not to limit them. Just to give an example of business processes that span multiple organizations, an assembly unit may want to check inventory, compare the inventory to forecasted demand, request quotation, order parts, receive shipment, verify quality, and fulfill an invoice. All these functions may be carried out by more than one system and may involve interactions between them. In order to support these business processes across heterogeneous landscape, the applications need to be integrated. Application integration needs to provide efficient, reliable, and secure data exchange between multiple enterprise applications.

EAI Playbook 1

! "" Heading 1 , .

Integration history

A vanilla integration, which provides integration between two applications, is very easy to conceptualize. A hardwired program in one of the applications that convert data from Point A to Point B using the custom proprietary application format will do the work. The only challenge here is that someone needs to be aware of the application A and application B. Finding such people is difficult, yet not impossible.

Application A Application BCoversion

Program A - B

However, this challenge extrapolates itself as we have more and more applications within the integration landscape. Gradually organizations end up having what is called as spiderweb epitome. This is difficult to maintain and extremely expensive too.

Application A Application BCoversion

Program A - B

Application C Application D

Application E

Coversion Program A - C

Coversion Program A - D

Coversion Program A - E

Coversion Program B - C Coversion

Program B - D

Coversion Program B - E

Coversion Program C - D

Coversion Program C - E

Coversion Program D - E

An alternate and highly effective solution to meet the integration challenges and yet avoid this spiderweb is to use an Enterprise Application Integrator (EAI), such as SAP process integration (PI), Tibco, WebMethods, SeeBeyond, Cordys, etc. These EAI tools have the capability to communicate to any systems and also within themselves. Thus was earlier a spiderweb is now a hub and spoke. All the applications talk to each other via the EAI tool. EAI does the translation necessary from any two specific applications within the network. This leads to simplification of the landscape and also a robust integration between heterogonous applications running on different platforms without the need for replacing any existing system.

EAI Playbook 2

! "" Heading 1 , .

Application A Application B

Application C Application D

Application EEAI

Integration challenges

However simplified enterprise integration can be, it still has its own set of challenges.

1. Lot of businesses use EAI solutions for their day-to-day operation. Once these processes are set up, they are expected to be up and running 24x7x365 days. Any downtime or misrouting can cause the business to virtually stop.

2. The skills required to maintain an EAI solution are quite daunting. Troubleshooting complex problems requires a combination of skill sets, which are generally spread across individuals. Hence, when staffing a development or maintenance project, the individuals needs are to be shortlisted based on various parameters and expect a strong collaboration.

3. Lack of standards is another major challenge. Though many standards have evolved and adapted across multiple EAI tools, not all EAI tools agree or work on the same standards. Some tools claim on adapting the standards, but are not 100% compliant. Added to this, the extensions to the standards provide means of creeping up customization into standards.

4. Most of the EAI tools use eXtensible Markup Language XML for exchanging information. XML is a free-flowing language where the tags can be marked up as and when needed. XML is a standard that has no standard. Hence, when we talk about interoperability, one still needs to resolve the semantic differences between these XML standards. This is a time-consuming task that requires significant technical and business decisions.

5. EAI requires a shift from the tradition of working in silos. Once a department has agreed to be part of a process flow spanning multiple departments, the business function that belongs to one department now becomes a shared responsibility. This removes the exclusivity of the department on the functionality. Any upgrades or changes in the functionality now need to be done with consultation from other departments.

EAI Playbook 3

! "" Heading 1 , .

What is an Enterprise Service Bus (ESB)?

An ESB is a communication and mediation layer that connects service consumers and service providers in service-oriented architecture (SOA) scenarios and in situations that mix SOA and other architecture styles. In other words, an ESB is an intermediary layer of middleware through which a set of reusable business services are made widely available. It typically is designed to be the backbone of a modern SOA, routing requests between service consumers and service providers, both synchronously and asynchronously, and may be configured to perform a variety of actions, such as routing, translation, protocol conversion, or authentication in between.

Essentially, it accepts service consumer requests, forwards them to the appropriate service providers, and returns whatever response may be generated to the requestor. To do this in an enterprise environment, an ESB includes availability and scalability features, as well as the ability to locate all of the connected service providers. An ESB also handles multiple protocols, with Web services being the most discussed. An ESB can support both synchronous and asynchronous requests, typically including or using store-and-forward messaging as part of the solution.

The real power of an ESB, though, is what it can do in between the consumer and provider, including data-dependent routing, data translation, protocol conversion, security features, and support for many protocols and interfaces.

ESB key features/characteristics

The core functions, which provide the basic operational capabilities of the ESB, are as follows:

Support of multiple protocols. An ESB typically supports a wide range of Web services, Representational state transfer (REST) and other protocols, both to provide a range of capabilities for newly developed business needs and to support integration with a wide range of third-party legacy systems and services.

Protocol conversion. Just as important as an ESBs support of multiple protocols is its ability to accept a request in one protocol and forward it as a request using a different protocol, a capability that simplifies using the ESB with multiple new legacy systems.

Data transformation and data-based routing. ESBs typically have the ability to translate data from one format to another, possibly using that data to enrich data streams and make routing decisions along the way.

Support of multiple connectivity options. ESBs provide the means to connect to the databases, messaging systems, management tools, and other infrastructure components that are part of an organizations existing infrastructure.

Support of composite services through lightweight orchestration. Lightweight orchestration, commonly called flows or itineraries by ESB vendors, is generally stateless and short-lived, though neither is a requirement. It means connecting multiple services together into a larger composite service, with the ESB managing the flow of control and information among the component services. The term lightweight stands in contrast to Business Programming Execution Language- (BPEL-) based process orchestration.

Support of multiple standard business file formats. Many vertical industries have defined file formats, the most recent being XML based. ESBs typically provide the ability to work directly with these formats.

Integrated security features. ESBs provide integration with security directories and Operating System (OS) security features to support authentication and authorization, simplifying the challenge of making services available to multiple user communities (for example, employees, customers, and agents).

EAI Playbook 4

! "" Heading 1 , .

A comprehensive error-handling mechanism. ESBs provide uniform mechanisms for identifying, managing, and monitoring both technical and business errors, with the ability to customize specific error behavior as needed.

Support of both synchronous and asynchronous operations. ESBs must support requests and operations of both the synchronous and asynchronous variety, making it easy to use each where appropriate, since all modern organizations will have business activities that fall into both categories.

Highly available and scalable infrastructure. ESBs can use software and/or hardware clustering and other mechanisms to provide high availability. Every ESB has the ability to support horizontal scalability and to span a large infrastructure; some also provide facilities to support vertical scalability of individual services.

Extensibility. While it is important for ESBs to support a broad range of individual capabilities in each area, it is perhaps even more important for an ESB to make it possible for customers to add capabilities themselves. Your ESB does not support a particular Web services protocol? Add it. You need to talk to an aging legacy system using a homegrown messaging system? Add support for that too. The good news is that all of the ESBs provide some means to make these kinds of extensions, indistinguishable from the out-of-the-box options.

Graphical editing tools. Graphical editors for ESB flows (itineraries or lightweight orchestrations) make it much easier for architects and developers to work with ESB activities over time, especially in the case of maintenance activities that occur long after flows original development. Without graphical editing tools, developers must work directly with the ESBs proprietary XML-based programming language, a task that requires both tedious hand coding of XML and in-depth knowledge of the ESBs operation.

Service level agreement (SLA) monitoring and management. Most ESBs have some provision for controlling throttling and load balancing to meet defined SLAs on a per-endpoint basis. ESBs cannot yet replace SOA service management products that provide endpoint security and management, though the trend is moving toward ESBs providing more and more of these capabilities. Most ESBs have some provision for controlling throttling and load balancing to meet defined SLAs on a per-endpoint basis.

BPEL and other business process support. Design, simulation, and execution of business processes using BPEL and its cousins remain primarily the domain of business process management (BPM) suites, but ESBs are supporting a growing range of these capabilities. Most products have the ability to create, execute, and manage BPEL orchestrations; some also offer process-simulation capabilities.

Business activity monitoring (BAM). BAM allows customers to define business-centric metrics called key performance indicators (KPIs) and to present those KPIs in near real time using dashboards. BAM also generates alerts to notify businesspeople of potential operational problems when these KPIs cross specified thresholds. Some ESBs provide comprehensive BAM capabilities; others rely on third-party BAM products.

Service life cycle management. Most ESBs include at least some life cycle management features. ESB vendors that have independent application life cycle management solutions (IBM, Oracle, and Software AG) naturally promote use of these products with their ESBs.

Dynamic service provisioning. Most ESBs can have the ability to dynamically provision new ESB operations, which means that users can add or modify flows without having to restart ESB components. ESBs that can host services themselves can also have the ability to dynamically provision those services. Innovations in this space include the ability to dynamically control the number of service instances running to meet SLA targets.

Complex event processing (CEP). CEP is growing, and as ESBs are both conduits for and sources of events, they are natural components of CEP applications. Vendors are adding prebuilt integrations for their own and third-party CEP engines.

EAI Playbook 5

! "" Heading 1 , .

A business rules engine (BRE). None of the ESBs include an embedded BRE, but several offer prepackaged integration with a third-party product. Some provide a plug-in BRE themselves; others require separate licensing of a third-party product.

The case for an ESB

An ESB is a core component of a mature SOA platform. It is also a sophisticated set of middleware components, which means it will include hardware costs, software licensing and support costs, training costs, and the time it takes to do the necessary design work. An ESB begins to make sense when the benefits exceed the complexity of implementing it. If the customer has straightforward needs with a limited number of services, a simple Hypertext Transfer Protocol (HTTP) infrastructure and matching SOA governance processes might be sufficient, and going for an ESB may not be justifiable, considering the implementation effort and cost associated with it. An ESB really starts to make sense, though, when customers need:

More robust service management than a simple infrastructure provides. Customers have large numbers of services, a need for extensive versioning, and a need for robust reporting on service utilization statistics.

Complex security policies applied to services. ESBs provide request authentication and authorization features, and also provide the means to integrate with a variety of security subsystems directly.

Both synchronous and asynchronous service invocation. If customers have a lot of messaging or electronic events, there is a need to have asynchronous services alongside the synchronous services. Asynchronous service invocation can be used for simple notification or other interaction models, such as publish and subscribe.

Routing of service requests to specific service provider instances. If customers have multiple special-purpose instances of a service, they will likely want an ESB to perform routing of individual requests to the appropriate instance. Customers may, for example, have specific clients whose data is hosted on specific hardware.

Different protocols for requestors and providers. Customers may have services available through messaging or other mechanisms, but want to make these services available to consumers via Web services. This could be because customers have legacy systems.

Transformation of data in some of your requests and responses. Customers may have services that need only specific data or that require data to be represented slightly differently.

A variety of different service infrastructure components. Customers may have security, XML acceleration, or other appliances that need to work in concert with their services, or customers may have Web services infrastructure components from multiple vendors that you need to integrate.

A growing number of composite services. Commercial ESB products include some level of Business Programming Execution Language (BPEL) or other orchestration, making it possible to create composite services within the ESB itself. Such composite services can also be used for process automation, in which several existing services are invoked to create a larger process.

Publish/subscribe. Customers may have expectations of implementing a loosely coupled messaging pattern like publish/subscribe where publishers and subscribers are allowed to remain ignorant of system topology and can continue to operate normally regardless of the other as compared to a traditional tightly coupled clientserver paradigm. An ESB allows publishers post messages to an intermediary message broker and subscribers register subscriptions with that broker, letting the broker perform the filtering. The broker normally performs a store-and-forward function to route messages from publishers to subscribers.

Any one of the above needs may not necessarily demand an ESB in most cases, there are other approaches that are viable as well. From a practical standpoint, though, customers will likely have more than one of these needs and that will tip the scales in favor of an ESB.

EAI Playbook 6

! "" Heading 1 , .

Selecting an ESB

Understanding the function of an ESB and its role and fit in your particular environment is essential to making a sound selection. Before making a decision to go with a particular ESB, it is good to look at the below points:

A Java 2 Enterprise Edition (J2EE) application server. Some ESBs are themselves JEE applications that, therefore, run on top of an application server. Some such ESBs require a specific application server, while others will work with any vendors application server. Most of these ESBs use the high-availability, scalability, and Java Message Service (JMS) features that the application server provides. Organizations with significant JEE installations will find this to be a benefit since they are accustomed to this administration and value the consistency in the underlying software infrastructure. Other organizations will see this application server as an additional layer to understand and manage.

Clustered hardware. Some ESBs achieve high availability through hardware clustering. If this is the case for your ESB, you will have fewer choices in hardware as well as the additional cost of clustering hardware, software, and administration. These solutions will make more sense in environments where there is already a lot of hardware clustering in place for other solutions.

Database or clustered database. For any operation requiring the maintenance of state or configuration information, some kind of persistent data store is required. Some ESBs do this using their own file formats, some use features of an underlying JEE application server, and others require a relational database to fill this need. Cases requiring a relational database may need to use hardware clustering to achieve high availability. In some environments, this is no big deal; in others, it adds significant cost and complexity.

Development tooling. Your integration and composite service developers will spend much of their time working with an ESBs developer tooling. The user experience varies widely, ranging from working directly with XML files and command-line scripts to working in integrated development environments, very often based on Eclipse, which let developers work with graphical models of event flows. You will need to evaluate your integration communitys skills and preferences to determine the best fit for your environment.

Monitoring and support. Some ESBs provide extensive support for monitoring and support, including the ability to view and manage in-progress business activities within the ESB (both BPEL and shorter-running message flows). Other vendors take a different approach, either providing these capabilities in separate BAM and system management environments or expecting that customers will already have those capabilities in house. Organizations without extensive support infrastructure in place must give more serious consideration to solutions that include these features.

Out-of-the-box features. Some ESBs provide extensive out-of-the-box features, including a services registry, and ships with an extensive set of technology and application adapters. Few provide an alert management system for error reporting and Application Programming Interfaces (APIs) for customer adapter development and configuration. It is good to choose an ESB that has better out-of-the-box features.

Understanding ESB functionality is an essential step in selection

An ESBs job is to give service consumers access to services, regardless of location, protocol, transport, interface technology, security domains, syntactical mismatches, and semantic differences. This means that ESBs must support many interface and transport protocols and data formats, and it also means they must provide conversions between interface protocols, between transport protocols, and between data formats. ESBs also route requests based on data; support request/response, notification, publish and subscribe, and other interaction styles; and integrate with a range of commercial directories and security models.

The real power of an ESB comes from its ability to chain operations together to create individual message flows (sometimes called itineraries, lightweight orchestration, or just flows). Developers can string

EAI Playbook 7

! "" Heading 1 , .

services together, the results of one service providing the input to the next, without having to build the flow logic into the services themselves.

Positioning SAP NetWeaver Process Integration (PI) as the ESB

What are the typical integration challenges in an enterprise? Integration challenges are often the foremost obstacle to getting the full value from packaged enterprise resource planning (ERP) solutions. Integration with these systems has frequently led to significant complications because core ERP applications are often better at collecting information than at making it available in all the places it is required. Typically, we see the below integration challenges in most of the customer IT landscape.

Limited interoperability: In most cases, ERP applications can handle integration with other packaged applications, such as customer relationship management (CRM) or human resource management (HRM), from the same vendor, but reaching out beyond the suite is often problematic. Connections to applications from other vendors, homegrown applications, and other legacy assets typically require the use or creation of custom interfaces.

Evolution of application platforms and infrastructure: With the evolution of application platforms, the application suites built on them, and the integration infrastructure designed to bind them SOA, followed by BPM, events, the cloud, and now elastic application platforms along with adding capability and flexibility to the enterprise, also drives up integration complexity.

Processes that run across value chains: In some highly collaborative value chains, such as pharmaceuticals or consumer-packaged goods, shared processes are the norm. Enterprises in these and other sectors with similar needs have to contend with the fact that an increasing number of critical processes are not contained in the four walls of a single enterprise; they must be able to cope with standards-based exchanges Electronic data interchange (EDI) and other business-to-business (B2B) data exchanges and standards, such as RosettaNet, Chemical Industry Data Exchange(CIDX), Petroleum Industry Data Exchange (PIDX), and Association for Cooperative Operations Research and Development (ACORD.

New realities: There are a growing number of newer, ad hoc exchanges that enterprises must accommodate. These range from custom XML formats between two or more partners, to Microsoft Excel spreadsheets, to a wide range of flat files. Enterprises must be able to easily move this information into and out of their ERP systems while maintaining adequate levels of control.

Interoperability with the cloud: There is a growing availability of software as a service- (SaaS-) based integration software in the market, rapidly expanding alternatives for customers. SaaS-based integration has significantly different implementation and operational attributes compared with on-premise integration, but when the economics are right, its greater flexibility and speed of implementation make it a good choice for meeting enterprise integration needs. Also, many enterprises could benefit from the flexible acquisition of additional resources that cloud-based computing enables.

Business expectation of application flexibility: The business will no longer put up with rigid applications that are too slow to respond to business change. Most major application vendors, such as Oracle and SAP, have spent the past several years updating their application platforms and application architecture to enable much greater flexibility, using approaches such as SOA, BPM, and event technology. Implementing and integrating these dynamic business applications often requires IT to configure many more aspects of application behavior, business process flow, and user experience, which further increases the complexity of the integration challenge.

Much closer business involvement: Application architectures of the past provided little or no opportunity for the business to control applications behavior; even trivial changes required a Change Request (CR) and developer involvement. Developers are still involved, but they now share responsibility with the business for modeling processes and business rules, and in some cases, these application elements remain under the control of business super users even after the application goes into production. This in

EAI Playbook 8

! "" Heading 1 , .

turn adds risk and complexity that IT must manage while giving the business the greater level of control it wants.

Much broader application access: During the earlier days of ERP integration, the range of choices within the context of user experience was limited, often including only Microsoft Windows clients and Web browsers. Todays applications are exposed through a much wider range of interaction channels, including not only desktops and Web, but also employee- and consumer-facing mobile apps, retail point of sale, fully instrumented real-time supply chains and warehouses, and Web services interfaces that expose application capabilities to the extended enterprise. Delivering application capabilities through all these channels requires a cohesive approach to multichannel and cross-channel support, which generates a completely new range of integration requirements.

ERP app integration with other apps from the same vendor: In todays enterprise, there is a need to connect ERP system with complementary apps, such as CRM, SAP Supplier Relationship Management (SRM), SAP Supply Chain Management (SCM), or HRM solutions and these complementary apps could be from the same vendor.

ERP app integration with legacy apps or apps from another vendor: This is often more challenging, as ERP-vendor-supplied integration tools vary widely in their ability to support integration outside their own application suite.

ERP app integration with the outside world: This is another area with a gap between some ERP vendors capabilities and their customers growing need for B2B integration. SAP provides effective EDI-based interactions using third-party integration vendors (with a strong focus on Seeburger) for years. SAP has also recently formed a partnership with Crossgate to provide enhanced B2B integration features.

How can SAP NetWeaver PI as ESB help address the above integration challenge?

When the clients overall IT application strategy is based on SAP (i.e., when SAP provides a substantial proportion of the overall application portfolio in the client landscape), this already means that the client has chosen SAP to be the strategic vendor for running its CORE business processes. In such cases, it is definitely worthwhile to consider the integration middleware/ESB solution from SAP as the core integration platform for the client landscape.

EAI Playbook 9

! "" Heading 1 , .

A major and unique advantage to having both the ESB and ERP software from SAP is the availability of SAP PI content. SAP provides PI content for SAP business suite applications, for SAP industry solutions like Retail, Oil and Gas, and Consumer Products, and for SAP NetWeaver applications like Master Data Management (MDM). This PI content reduces the development time considerably and avoids building interfaces from scratch, which will be the case if the client decides to go with third-party ESB vendors.

SAP NetWeaver PI has been in the market since 2004 and has accumulated a good installed base comparable to that of the leading integration middleware vendors. Most customers deployed the product to integrate SAP applications with other vendors packages or custom applications and few also used the product for B2B integration by combining NetWeaver PI with third-party technology (from Seeburger) or on-demand services (SAP Information Interchange from Crossgate) that are both resold by SAP. From Q2-2012, SAP is providing native add-ons for B2B support with additional licensing.

SAP NetWeaver PI has proven that despite its SAP-centric design and technology foundation, it can be utilized to support SAP-to-non-SAP integration scenarios. Most clients use NetWeaver PI to support batch-oriented requirements, but the product has also been successfully deployed to support real-time or near-real-time integration requirements.

SAP NetWeaver PI as a Message Oriented Middleware (MOM) provides reliable transport and assumes responsibility for delivering the message to the proper application. The sender application just puts the message into the queue and leaves the responsibility of delivering it to the MOM. If the receiver application is not running, the message is left in the queue until the receiver will be up again and will fetch it. PI quality of service describes mechanisms relating to the message transport. These include:

Guaranteed delivery of messages within PI

Check for duplicate messages

Delivery in the correct sequence (serialization)

SAP PI quality of services available are:

Best Effort: The message is sent to the receiver without guaranteed delivery, check for duplicate messages, or serialization mechanisms.

Exactly Once: The message is sent to the receiver exactly once. There is no serialization. All components that are involved in the message processing (including modules and the Java Connectivity Architecture (JCA) adapter) must guarantee delivery of the message exactly once by the correct transactional procedure.

Exactly Once in Order: This mode is an extension of the Exactly Once mode. In addition to the above-specified characteristics, serialization takes place on the senders side. All components must guarantee that messages are delivered exactly once and in the same sequence that they were sent. Serialization is achieved using a queue that is identified in the serialization context.

SAP PI enables loose coupling, meaning, it decouples the client (application needing an access to the service) from the service provider. It relieves the client from the need to know who is providing the service, because SAP PI is now responsible for creating a communication channel between the client and the service providers. The application does not need to have the integration code, because it will no longer be responsible for creating the connections/reconnecting in case of a communication error/knowing connection information of the service provider. Thus, introducing SAP PI into the landscape will simplify the design of the client.

SAP PI provides service location transparency. In a tightly coupled system, any change of the connection data in one of the service providers also requires a change in all of the clients that are using this service provider. This is no longer true when you use PI, because it is PI now that is responsible for storing that information. To sum it up, SAP PI provides service location transparency, as the client no longer has to know the exact location of the service provider it now becomes the responsibility of SAP PI.

EAI Playbook 10

! "" Heading 1 , .

SAP PI enables sharing of services. Once implemented, a service might be used in many projects or by clients (applications) from various departments. For example, a service providing information about the employee might be used by the systems from the HR, Finance, or IT departments.

SAP PI provides a clear separation of responsibilities in the customer landscape. Companies typically are run by business rules and the responsibility of the business is to know how to run a company what the companys input and output are and what services to provide. On the other hand, the responsibility of an ESB is to know what the Internet protocol (IP) address and Transmission Control Protocol (TCP) port of the application server are, what the protocol used by particular system is, what the signature of a particular method is, etc. If one day, one particular implementation service will be replaced by a new one, the way the company does business will not change, and we cannot expect or enforce any modication on the companys business partner or customer side, only the ESB will have to be updated. This enables to decouple the business model the way the company works from the implementation.

B2B integration needs. Enterprises have a choice of maintaining their own B2B infrastructure or relying on private exchanges for B2B integration needs. Larger enterprises typically tend to maintain their own B2B integration capability as an alternative for high-volume transactions that would be more expensive using the subscription pricing that private exchange models employ, and so enterprises today need products that typically support a wide range of B2B transport protocols such as File Transfer Protocol (FTP), Secure File Transfer Protocol (SFTP), Application Transport 1 (AS1), Application Transport 2 (AS2), RosettaNet Implementation Framework (RNIF), X.25, and others as well as a variety of B2B data formats such as X12, EDIFACT, ODETTE, TRADACOMS, PIDX, CIDX, and RosettaNet. SAP NetWeaver PI with its strong B2B integration capability could be a natural fit for enterprises with B2B needs.

When formulating ERP integration strategy, larger organizations may find it necessary to employ more than one type of integration solution in combination; however, it is better to solve all the problems with one solution wherever possible. SAP customers with obsolete or close-to-end-of-life integration platforms (e.g., Oracle-Sun Microsystems eGate or IBM/CrossWorlds WebSphere InterChange Server) should consider SAP NetWeaver PI as a potential candidate for replacing the incumbent technology.

For SAP-to-SAP integration, PI license comes included with the NetWeaver suite license and MySAP license. Customers have to pay separately for SAP-to-Non-SAP integration only, and pricing is based on the overall processed message volume in Gigabytes per month with special discounts available for large SAP customers, SAPs pricing model typically is more you use, less you pay.

SAP PI can easily replace Business Connector (BC) and can be a perfect fit for SAP customers using BC to make a staggered move for PI deployment. SAP PI is the central point for all NetWeaver components and is the integral part of SAPs Enterprise Service Oriented Architecture (ESOA) strategy, so customers who heavily invested on NetWeaver and ESOA gained a lot by having PI as the ONE integration platform

in their landscape.

When we compare SAP NetWeaver PI against a classic ESB reference architecture model, we could see that PI definitely has evolved to provide support for all layers of ESB reference architecture.

EAI Playbook 11

! "" Heading 1 , .

The ESB Reference Architecture Model

ESB layer ESB component SAP NetWeaver PI features

Architecture Availability SAP PI provides the ability to use clustering to support high availability and scalability across environments that scale horizontally and/or vertically.

Federation SAP PI supports federated deployments. Customers may choose to go for a distributed (federated) PI landscape due to several reasons, including: Separation of A2A and B2B processes Separated company divisions with majority communication/integration needs

residing within the same division Network constraints/downtime constraints Geographically distributed organization with majority communication

concentrated locally One central PI for global processes (HR, Finance, and master data) and

decentral PIs for divisions

Topology ESBs can be distributed or brokered. SAP PI is a brokered ESB that relies on a hub-and-spoke topology. Both options, either distributed or brokered, provide an adequate level of ESB functionality.

Extensibility SAP PI makes it possible for customers to add infrastructure capabilities themselves, a means to extend core functionality provided by PI.

Connection Messaging SAP PI provides support for both synchronous and asynchronous messaging, a wide variety of communication protocols including Web services, Simple Object Access Protocol (SOAP), and JMS. It also provides protocol conversion capabilities to enable the exchange of information between incompatible protocols.

Routing SAP PI provides the ability to support both predefined and dynamic routing (based on interpretation of message content).

Connectivity SAP PI provides the means to connect to the databases, messaging systems, management tools, and other infrastructure components that are part of an organizations existing infrastructure.

Mediation Dynamic provisioning

SAP PI can dynamically provision new ESB operations, enabling users to add or modify flows without having to restart PI components.

Policy meta model SAP PI supports policies to govern not only routing but also filtering or augmentation of messages.

Registry SAP PI provides an Universal Description, Discovery, and Integration- (UDDI-) compliant registry to locate available enterprise services/SOA assets.

EAI Playbook 12

! "" Heading 1 , .

ESB layer ESB component SAP NetWeaver PI features

Transformation and mapping

Transformation capabilities for SAP PI have improved significantly over the past several years. Capabilities range from simply mapping data formats of message payloads to providing rich aggregation or decomposition of service semantics so that each side of the conversation is unaware of the other sides details.

Transaction management

SAP PI adapters can be configured to ensure transaction handling in the applications they interface to. E.g., SAP PI Java Database Connectivity (JDBC) adapter can be configured to do a ROLLBACK of all the STATEMENTs executed against a database, if one of the STATEMENT nodes failed to execute.

SLA management SAP PI provides some basic capability to monitor adherence to SLAs, e.g., ccBPM process control steps can be configured to raise exceptions or alerts when expected interface execution flow is NOT met. Also, for interfaces that require priority processing to adhere to SLAs.

Orchestration Lightweight orchestration

Lightweight orchestration means connecting multiple services together into a larger composite service, with the ESB (PI) managing the flow of control and information among the component services.

BPEL support PI has the capability to create, execute, and manage BPEL orchestrations.

Change and control

Design tooling SAP PI provides for easy administration of the product, graphical editing capability, and the ability to support service creation and deployment.

Life cycle management

SAP PI supports unified life cycle management capabilities, which are further enhanced in the upcoming 7.3 release. Few are listed below: Centralized monitoring environment PI monitoring Good Morning page in SAP solution manager PI scenarios visible within SAP solution manager (for documentation) Optional additional message persistence on Advanced Adapter Engine (AAE) Enhanced logging on AS Java Flexible upgrade paths provided for all releases, including: SAP eXchange Infrastructure (XI) 3.0 SAP NetWeaver PI 7.0 incl. Enhancement Pack (EHP) 1 and EHP 2 SAP NetWeaver PI 7.1 incl. EHP 1 SAP NetWeaver PI 7.3 incl. EHP 1 Enhanced transport management features, including CTS+ apart from file-based export-import option.

Security SAP PI provides security mechanisms, including: Message-level security (digitally signed or encrypted documents

exchanged between systems or business partners): SAP NetWeaver PI offers message-level security for the XI protocol, for the RosettaNet protocol, for the CIDX protocol, and for the SOAP and Mail adapters. Message-level security relies on public and private X.509 certificates maintained in the AS Java keystore, where each certificate is identified by its alias name and the keystore view where it is stored. The message security settings are available in the corresponding collaboration agreement.

Transport-level security: PI supports transport security for HTTP, RFC, and FTP protocols. HTTP connections can be secured using SSL, RFC connections can be secured using Secure Network Communication (SNC), and FTP connections can be secured using FTPS. The various authentication methods supported include user/password, client certificate, SAP assertion ticket, SAML assertion, X.509 authentication token, etc.

Role-based authorization: SAP PI supports defining detailed authorization that can restrict access to Enterprise Service Repository (ESR) and Integration Directory (ID) objects according to a role-based authorization model. The access authorization can be defined at the object-type level where we can specify each access action, either individually as create, modify, or delete for each object type, or as an overall access granting all three access actions.

Access control list- (ACL-) based authorization: SAP PI supports defining authorizations based on ACLs to 1) ESR and ID objects, 2) service users, and 3) SNCs.

EAI Playbook 13

! "" Heading 1 , .

ESB layer ESB component SAP NetWeaver PI features

Technical monitoring SAP PI provides tools to investigate problems, find root causes, and take action to correct the issues that are discovered. The various tools include: SAP solution manager for total IT landscape management: Allows for central, IT role-based administration and monitoring across the whole SAP landscape using work centers. SAP NetWeaver Administrator for PI-landscaped monitoring: Allows for central monitoring of multiple PI domains, and provides a message status overview for all messages processed in all PI domains in aggregated view and with drilldown capability. User-defined message search capability: Allows searching for messages using business-relevant message payload content as search criteria (a separate Text Retrieval and Information Extraction (TREX) installation is NOT needed).

SAP NetWeaver PI provides a broad range of capabilities to address enterprise integration challenges. Few capabilities are below:

Message transformation ability to transform structure and format of business request to a service provider. PI as an ESB has the capability to change the message format to the format accepted by the service provider.

Message routing ability to send a request to a particular service provider basing on some criteria. PI as an ESB has the capability to decide to which service providers a particular message should be delivered.

Security ability to protect an ESB from unauthorized access. PI as an ESB assures that only selected clients have access to particular services.

Message enhancement ability to modify and add information as required by the service provider. PI as an ESB has the capability to add some additional information into the message before it will be delivered to the service provider. That information might come from a database or some other system.

Protocol transformation ability to accept messages sent using divergent protocols, i.e., Internet Inter-Orb Protocol (IIOP), SOAP, HTTP, JMS, JDBC, etc. This capability consists of two aspects: logical an ESB must understand the protocol (its semantic and syntax) and physical an ESB must have a component suited for operating using that protocol, i.e., HTTP server, SOAP server, JMS client, etc.

Service mapping ability to translate a business service into the corresponding service implementation and provide binding and location information. It is a mapping performed by an ESB between abstract business service and implementation service (IP address, port, name of the method, etc.).

Message processing ability to monitor the state of the received request. For the client, sending a message to the ESB (SAP PI), the most important thing is that a sent message should never be lost. In order to achieve that, the ESB has to monitor the state of the message is it already processed by the service provider, was the processing successful, is the service provider available, etc.

Process choreography ability to manage complex business processes that require the coordination of multiple business services to fulll a single business service request. This functionality enables the client to perceive business requests as one single request, while in fact its execution may trigger the execution of multiple business services. It is usually implemented as a BPEL, which is a language enabling business process modeling.

Service orchestration ability to manage the coordination of multiple implementation services. The difference between previously described process choreography and service orchestration is the type of service being managed in case of service orchestration it is an implementation service and in case of process choreography it is a business service.

PI support for established ESB integration patterns: SAP PI as an ESB supports established ESB patterns, including VETO and VETRO. VETO stands for validate, enrich, transform, and operate. It is a widely used integration pattern in ESB solutions. The VETO pattern ensures that data exchanged in an ESB will be

EAI Playbook 14

! "" Heading 1 , .

consistent and valid. Each component in the VETO pattern is typically implemented as a separate service and can be congured and modied independently of any other component.

Validate: The aim of the validate step is to ensure that messages received by the service provider will have proper syntax and semantics. This step should be performed independently not inside the service provider because that solution would limit the reusability of validation and complicate any further modications of it. Moreover, implementing validation as a separate component would ensure that every message that gets to the service will be in a proper format, thus would simplify the design of service provider and enable the operate step to focus on business logic. The simplest way of validating an incoming message is to check whether the message is a well-formed XML document and conforms to the XML schema or Web Services Description Language (WSDL).

Enrich: The aim of the enrich step is to add some additional data to the message content that would be needed by the service provider, for example, information about the customer, who has placed order. That information might be fetched from the database or might be the result of invoking another service.

Transform: The aim of the transform step is to change the message format to the one accepted by the service provider. This step might transform the message into an internal message format of the service provider, releasing the operate step from the need to perform this task and, therefore, increasing its efficiency.

Operate: The aim of the operate step is to invoke target service or to interact in some way with the target application.

VETOR/VETRO pattern: The VETOR pattern is a VETO pattern, which introduces a new component placed right before the operate step the Router. The aim of this step is to decide whether a message should be delivered to the service or not. The router is typically implemented as a part of the transform component or as a separate service.

Integration strategy

In order to define the integration strategy, the integration components will first be discussed. The integration components identify various functions and architecture recommendations based upon integration requirements identified by the Business Advisory (BA) teams. Specifically, the following integration components will be addressed:

Integration architecture strategy

Communications middleware

Data transformation and formatting

Application and technical connectivity

BPM

Integration architecture strategy

The Integration Architecture describes the strategies and techniques for the physical implementation of the technical components that make up the execution (production) architecture.

ESB integration architecture

The ESB is a hybrid architecture approach that includes the integration patterns described in the following sections. It combines characteristics from these patterns to fulfill the documented integration requirements. This architecture reduces the risk of outages to the entire integration infrastructure. Scaling or expanding hybrid architecture is also easier since changing a component will not affect all other components in the infrastructure. It also allows for the EAI solution to evolve into the ESB component of the SOA implementation.

EAI Playbook 15

! "" Heading 1 , .

Also note: With this hybrid architecture, there may be multiple instances of patterns introduced for various reasons. For example, there may be clusters of applications with their own hub. In this situation, there may be high traffic within a hub and some lower level of traffic between hubs. Multiple hubs may also be employed for different types of messages.

Figure 1: Example hybrid architecture

Integration Services Layer

Application

Connectivity

PK

MS Hub

STAR

Kronos

Application Connectivity

Application Connectivity

App

licat

ion

Con

nect

ivity

SA

PHub

Hub-and-spoke integration

In this pattern, applications/systems communicate directly to a middleware hub, which is responsible for routing the message to the appropriate target application or system. For publish/subscribe messaging, subscribers register with the hub. For request/reply messaging, the hub acts as a broker between the requesting application and the servicing application. In either case, applications are loosely coupled and have no data dependency with each other.

Figure 2: Example hub-and-spoke architecture

Integration Services LayerApplication C

onnectivity

PkMS HUBSAP PI S

AP

Hyperion

Kronos

Application Connectivity

Application Connectivity

EAI Playbook 16

! "" Heading 1 , .

Key points:

A hub provides a single control point where other features can be added (e.g., data transformations and routing).

The hub-and-spoke architecture provides the ability to quickly respond to new or changing environments, and it provides greater control of transaction monitoring and role-based access control (security).

A hub-and-spoke architecture makes monitoring and problem diagnosis less complex. There are fewer physical components, a less complex environment, and a well-defined path that all messages follow.

A logical point-to-point communication channel can be implemented over a physical hub-and-spoke architecture.

Scalability, load balancing, and availability are considerable implementation issues in a hub-and-spoke architecture.

Distributed (federated) integration

A distributed pattern is conceptually similar to the hub-and-spoke pattern, but distributes integration components at the source or target systems to perform message translation, routing, etc., which are governed by the centralized rules. This pattern reduces load on the hub, provides support for geographically dispersed regions, load balancing, disaster recovery, and fault tolerance.

Figure 3: Example distributed/federated architecture

Integration Service Layer

SAP PI(Process Rules)

IntegrationC

omponent

PKMS SA

P

Hyperion

Kronos

IntegrationComponent

IntegrationComponent

Network

Key points:

Provides flexible scheduling and transport of high-volume traffic between distributed components without requiring the network traffic to flow through the hub.

Through appropriate deployment, can maintain guaranteed delivery of events, even if network is unreliable (through existing phase-commit pub/subsolution).

Operational requirements, such as system monitoring, message monitoring, and end-to-end message tracing, are more difficult to provide in this environment.

EAI Playbook 17

! "" Heading 1 , .

Service locator integration

A service locator architecture pattern provides a requestor application with the information needed to connect to the appropriate service provider (source application). This typically is a three-step process:

1. Services register with the service locator.

2. Requesting applications request information about the required service.

3. The requesting application and the service bind and then communicate.

While this does involve point-to-point communication, awareness or knowledge of other applications is not built into any application. Note that an application can act as a requestor and as a service. Most often, this architecture model is associated with Web services.

Figure 4: Example service locator pattern

IntegrationServices

Layer

ServiceRegistry

SAP

Hyperion

Application Connectivity

Application Connectivity

Register

Requ

est L

ocati

on

Bin

d an

d R

eque

st

Key points:

This can be a very simple, easy-to-use, synchronous messaging paradigm with less moving parts.

This pattern has not been proven in high-volume, mission-critical transactions.

As described above, the service locator architecture model behaves in a request/reply synchronous paradigm although this does not have to be the case. The application connectivity component can be extended to include store-and-forward capabilities, guaranteed delivery, etc. When these features are added to the service locator model, this solution can look exactly like the distributed architecture described above (with the service locator facilitating communication between the client middleware components).

Communications middleware

Communications middleware/messaging capabilities were identified and recommendations regarding each capability have been made, including:

Message prioritization

Asynchronous communication

Synchronous communication

EAI Playbook 18

! "" Heading 1 , .

Publish/subscribe

Persistent delivery

Transaction management

Message prioritization

Prioritization of messages can be performed based upon time stamp (when messages were placed in a queue), message type, class, sending application, or message data contents. Message prioritization can impact efficiency and performance.

Key points:

Message priorities can be individually assigned by applications for each message, or the integration architecture can assign all messages of a single type to a selected priority.

Allows for the processing of higher-priority messages prior to lower-priority messages.

Allows the technical infrastructure to adapt to application requirements and SLAs.

Message prioritization will be achieved through message routing (EAI tool) or queue prioritization (messaging tool).

The level of message interrogation to support message routing can impact efficiency and performance.

Asynchronous communication

Asynchronous messaging allows an application to transfer a message to the integration services layer and continue processing. The integration services layer is responsible for queuing the message, locating the destination application, and delivering the message to the destination. Asynchronous messaging enables decoupled, near-real-time communication.

Key points:

Asynchronous messaging should be used whenever an application does not need a message reply or acknowledgement to continue processing.

Asynchronous messaging is typically implemented through a message queuing architecture using message-oriented middleware or the messaging components of an EAI tool (e.g., SAP PI and WebSphere MQ).

Asynchronous messaging provides eventual guaranteed messaging; however, there is no guarantee of response or reply time. The messaging architecture not the application is responsible for ensuring delivery.

Because asynchronous messaging enables send-and-forget communication, this is a less complex form of application communication.

Errors are logged and associated messages are sent to an error queue for processing.

Asynchronous communications can send and reply to transactions in near real time.

Does not build in architecture dependencies during design and development activities.

Synchronous communication

Synchronous communication establishes a direct connection (session) between two applications. Unlike asynchronous communication, synchronous communication allows an application to receive an immediate reply and/or ensure that a transaction is processed immediately.

EAI Playbook 19

! "" Heading 1 , .

Key points:

Introduces dependencies/wait states into the architecture design.

Excessive time delay in message delivery is considered to be an error condition.

Synchronous messaging is typically used when the application requires immediate delivery of a message to a cooperating application before processing can continue.

The use of a transaction processor to provide synchronous messaging results in guaranteed message delivery.

Publish/subscribe

Publish/subscribe is a special data delivery capability that allows processes to register an interest in (i.e., subscribe to) certain messages. An application then sends (publishes) a message to the integration architecture, which forwards it to all processes that have subscribed to it. An example of a publish/subscribe scenario is item catalogs distribution. There are several consumers of catalog files, such as Echo, EDI (832s), and third-party applications that require copies of the catalog file. In this instance, SAP generates a generalized catalog that is exposed to the subscribers by the integration services layer at various end points each published in a customized catalog format.

Key points:

Publish/subscribe is a coordination capability that matches and links a message initiator (publisher) with receivers (subscribers) in a dynamic fashion.

Requires the integration infrastructure to establish and maintain the relationship between publishers and subscribers. Enables routing data messages to a destination, only if the destination has requested to receive the data type.

Enables messages to be sent to multiple target applications simultaneously reducing the need for point-to-point interfaces within the EAI state architecture.

Persistent delivery

Persistent delivery ensures that messages are not lost as they pass through the integration architecture. Mechanisms are in place to track and restore messages as well as confirm messages have been received.

Key points:

Ensures transport persistence and data transfer between the integration components, despite any failures that may occur.

Ensures messages are delivered regardless of receiving application availability at the time the message is initially sent.

Ensures messages are sent once and only once. Reduces duplicate messages and potential errors.

Can be accomplished through configuration of message queues or through implementation of a transaction management infrastructure (example Order acknowledgement).

Transaction management

Transaction management ensures integrity of message delivery as they move within the integration architecture. It supports capabilities, such as two-phase commit, guaranteed delivery, rollbacks, and the ability to provide the appearance of synchronous communications via a queue-based (asynchronous) technical infrastructure.

EAI Playbook 20

! "" Heading 1 , .

Key points:

Ensures that multiple applications/data remain coordinated.

Avoids changing data within one database if related changes cannot be made within other databases.

May be managed by applications, not the integration architecture, since an application needs to be able to select its partners in a two-phase commit and respond to any errors.

Tightly couples applications.

Data transformation and formatting

The data transformation and formatting layer of the integration services architecture is responsible for the conversion of data, message content, and syntax to reconcile the differences between data from multiple heterogeneous systems and data sources. This layer is responsible for maintaining the information structure of the messages passed between systems and their meaning in a format that can be understood by other applications. Data transformation and formatting considerations include:

Message layout

Distributed data transformation and formatting

Centralized data transformation and formatting

Message layout

Information passed into and within the integration architecture is formatted as a message. A vendor-neutral format, such as XML, for messages going in and out of the integration service layer is highly desirable. The message layout must also support tracking, e.g., through the header information, for ease of maintenance and debugging. The primary message type for interacting with SAP is the iDoc.

Key points:

A standard structure (format and layout) of the header, metadata, and data sections will be defined and consistent for all messages.

The specific contents of header and metadata (example: routing information) needs to be defined and consistent for all messages.

The data section contents must be defined explicitly for each required message sent to the integration services layer.

Distributed data transformation and formatting

The data transformation and formatting can take place within the sending/receiving application or within a distributed integration component located with the application, rather than at the centralized integration services layer. A distributed integration component is an adapter, custom program, or integration tool specific to the application (example: Hyperion Integration Services).

Key points:

A standard format is exchanged between applications and each application transforms the data into the required format.

Reduces the number of required transformations and data formatting within the integration services layer thus reducing complexity.

EAI Playbook 21

! "" Heading 1 , .

Centralized data transformation and formatting

The data transformation and formatting can take place at a centralized location, such as within the integration services layer.

Key points:

There is the potential for a single point of failure (SPOF) for a major part of the enterprise because the transformation and formatting is no longer distributed. Awareness is required to identify and incorporate the appropriate failover scenarios into the architecture design.

Less resource intensive than in a distribution environment if the same transformations are taking place for multiple applications.

Application and technical connectivity

The application and technical connectivity layer provides reusable, noninvasive connectivity between packaged software (e.g., SAP, Hyperion, and Kronos) and custom legacy systems. This layer is enabled by reliable, event-driven messaging. A number of connectivity options exist to interface with the integration services layer.

Application connectivity options

The table below provides a definition for each of the application connectivity options listed above with a summary of key points.

Application connectivity options

Connectivity option Key points

APIs Specific methods or functions made available by an application through which another program can make requests of this application.

Provides a level of abstraction between the integration architecture and the application.

May have platform dependencies.

Database access Direct access to the database of the program through the invocation of embedded SQL command or by call store procedures to create, read, update, or delete information relevant to the communication between the applications.

System-level issues, such as connection pooling.

Tight coupling between database and integration architecture unless a data access layer is used.

Message queue Message queues provide for the transport and routing of messages between applications and systems.

Relatively easy to implement. Inherently point-to-point communications.

Remote procedure call/remote method innovation Modeled on remote object/component invocation where business services and data encapsulated in one application are requested directly through a synchronous call by another application.

Tight coupling. Primarily used for internal enterprise

integration. Requires object serialization.

Web service A software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a standards-based format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

Suitable for heavy traffic in terms of cost. Web service technology and standards are

maturing. Synchronous and asynchronous

communication. Based on open standards.

EAI Playbook 22

! "" Heading 1 , .

Using the connectivity options discussed above, the following interfaces to the integration architecture are discussed:

Existing business systems

Internet/portal applications

Third-party application packages

Communication with SAP

Integration technologies options

The integration strategy leverages technology assets, standards, and resources to fulfill integration requirements and create effective solutions. It is a systematic approach to integrate SAP, packaged applications, legacy applications, and data. Specific classes of products, including EAI, Web services, and Extract Transform and Load (ETL) tools, offer specific solutions as part of an overall integration strategy approach. An integration services layer is most successful when it uses the correct combination of the technologies employed within these different classes of products.

A summary listing of the key technology options is provided in the table below. Below table provides a recommended usage matrix for these technologies.

Key technology options

Technology option Description

EAI EAI is a set of tools and technologies that enables standards-based integration of disparate applications within and outside an enterprise. EAI tools can be used in conjunction with Web services implementations or independent of them.

Web services Web services are a collection of technologies (including WSDL, UDDI, XML, and SOAP), which enable the creation of programming solutions to specific messaging and integration problems.

ETL ETL technologies enable the extraction of large volumes of data from disparate source systems, the transformation of that data, and the loading of that data into target systems. The process is typically performed through batch loads, although several solutions now offer near-real-time data integration.

Recommended usage matrix

Requirement EAI Web services

ETL

Small message file size/discrete amounts of data High frequency of transmission of small amounts of data Asynchronous (near-real-time or batch) message or file-based communication High number of connections to disparate applications BPM across multiple systems or applications Bidirectional flow of data between applications Message-based integration with guaranteed message delivery Additional instances for load balancing Redundant configurations for automated failover Medium-to-high complexity of data transformations Processes driven through batch processing and scheduling Desire to leverage Web technologies and the Internet Capabilities need to be implemented in a proprietary manner (security, transactions, workflow, and reliable messaging)

EAI Playbook 23

! "" Heading 1 , .

Recommended usage matrix

Connectivity from disparate database components to a single database architecture Need to perform aggregate operations against batch data Accessible from external applications or systems (possibly running on different platforms) Need for a metadata repository

Effort estimation and staffing plan

Project estimation tool

One can leverage the Project Estimator and Planning Suite (PEPS) to help arrive at the estimates for the interface objects using PI. The same tool can be used for estimating the entire scope of Reports, Interfaces, Conversions, Enhancements, Forms and Workflows (RICEFW) objects and not just interfaces. The below attached excel sheet can be used as a starter to feed into the PEPS. It includes the end-to-end estimations of interfaces. This tool gives the detailed as well as summary of estimations across all the phases of the project.

It also helps arrive at a resource breakup based on the estimated hours. This estimation tool also details all the assumptions made while deriving the estimations. The complexity levels are also described so as to categorize the objects across different complexity levels.

It is recommended to directly use the PEPS to help arrive at the estimates, given the scope of the objects.

SAP Project Initiation Estimation hours v11_

Staffing/resource planning model

The estimates arrived at using the PEPS tool helps drive the staffing plan. It helps arrive upon the minimum number of Advanecd Business Application Programming (ABAP)/PI resources needed from RICEFW perspective. However, there are some additional PI resources/roles that would be required irrespective of the scope of the PI objects. The same has been outlined in the staffing plan below.

The sample resource plan can look like as below.

Note: The numbers included in this plan are just for illustration purpose. Every project will be in need of a development/integration lead and basis support for PI; however, the number and level of other resources like programmers, analysts, and their commitment are best identified based on the scope of the work and estimations derived out of the estimation tool.

Staffing plan

(Fill in grid to whatever level of detail is required, starting with most immediate time frame and moving toward most distant time frame.)

Project Name:

Project Manager:

Proposed Project Begin Date:

Proposed Project End Date:

EAI Playbook 24

! "" Heading 1 , .

Staffing manager:

Resource (personnel category) Likely source level

Level of commitment (utilization rate) Location Number

Interface development lead/integration lead

Manager and above Full time On-site 1

PI senior programmer Senior consultant Full time On-site 1

PI programmer Consultant Full time 1 on-site/2 offshore 3

BASIS support Senior consultant Full time On-site 1

Quality assurance Consultant Part time Offshore 1

Business analyst Business Technology Analyst (BTA)

Part time Offshore 2

EAI Playbook 25

! "" Heading 1 , .

Envisioning

This section will help envision the future state of the architecture and landscape. Once the middleware tool of choice is picked, this section will help formulate the strategy for the integration implementation and plan the transformation.

After analyzing the current landscape, scope of improvement in the business process and scope of improvement in the IT landscape, the best possible enterprise landscape is envisioned. This step should be executed considering the basic principles like:

Governance

Security

Scalability

Performance

Standards

Interface/scenario-related decision factors

New PI 7.3 feature and function usage

What are your business reasons for looking into PI 7.3? Does your business require the new SOA-related features, such as ESR with enhanced modeling capabilities, the Services Registry, and Web Service standards? Or do you want to go to PI 7.3 because your XI 3.0 system is going to run out of SAP-standard maintenance sooner or later and you would like to invest in the latest product version with enhanced high-volume support for EO/EOIO messages?

As you can see from the above diagram, the main recommendation is to check out the new features and function based on a new PI 7.3 installation, instead of doing this all in one step with the upgrade of the existing system at the same time to get new features and functions up and running.

EAI Playbook 26

! "" Heading 1 , .

Number of connected business systems

How many business systems are currently connected to your productive XI/PI system? How many types of business systems are connected, that is, how many different technologies can be distinguished on the business systems side?

In the graphic above, we recommend that you go for an upgrade if you have many business systems. The question now remains, what does many actually mean? This rating and number has to be provided on a customer-specific basis, unfortunately. For example, a customer has 20 plant systems and they are all connected by the same interface scenario and the same adapter type. In this case, the transfer of such identical systems might be easier to achieve than by moving 20 completely individual systems with individual interfaces and many types of adapters.

Our rule of thumb would be to say less than 25 different business system types could still be managed with a new installation and phaseout in a well-organized project. More than 25 different business system types might be not possible to handle with separated milestones; here a big bang approach for the whole company would be the better decision to make. Again, this value of 25 different business system types is not a fixed number it is simply a recommended value. You should decide in your own project whether the effort of manually redirecting systems from a running XI/PI system to a new PI 7.3 system can be achieved in your environment and how much you would rate this effort.

Number of live interfaces

Nearly, the same arguments provided under 4.3.2 can be applied to this criterion. We already consider more than 100 productive interfaces as many interfaces and, based on this number, the rating would favor moving toward an upgrade rather than a new installation.

EAI Playbook 27

! "" Heading 1 , .

Type of high-volume interfaces

Message packing for EO/EOIO messages is activated by default in the new installation of PI 7.3. This functionality is already available in PI 7.0, and, therefore, the upgrade should be easy as the functionality itself does not require any interface design changes.

There are two separate exceptions to this which might favor you choosing a new installation instead. The first is if you are planning on using the new ccBPM packaging functionality. Message packaging in Business Process Engine (BPE) helps improve performance by delivering multiple messages to BPE process instances in one transaction. This can lead to an increased message throughput. In some cases, it can lead to an increase in the runtime for specific messages, for example, the time the message must wait whilst an appropriate message package is created. To be able to take advantage of message packaging for (ccBPM) integration processes, you must activate it globally for the BPE and individually for the process types that message packaging could be useful for.

Since this configuration will affect the runtime of all your current ccBPM processes, it is recommended that you choose a new installation where you can perform this configuration independently of your current landscape if you have many ccBPM integration processes.

The second exception is if you are planning on moving scenarios to the AEX that you currently have running on the AAE. This will require a new installation of the AEX (as stated earlier, the AAE cannot be upgraded to an AEX) and a change to the configuration of the AAE scenarios. For this reason, it is recommended that you first get more familiar with PI 7.3 by using a new installation as opposed to an upgrade.

Long-running ccBPM processes

This criterion follows the same path as the auditing criteria for the IT/operations-relevant decision factors. If, for example, you have long-running ccBPM processes that collect daily messages for a whole month and start the real business-relevant processing at the end of the month, we consider these to be long-running scenarios. To keep them running and open, an upgrade has to be the first choice, otherwise, you have to define and describe handling decisions regarding what is to be done for final transfer of these scenarios from the old product XI/PI system to the new PI 7.3 system. If you only have processes that run for less than 24 hours, we do not consider them to be long running.

EAI Playbook 28

! "" Heading 1 , .

Implementation

Design Best practices (Interface Strategy, Error Handling Strategy, etc.)

Purpose

This document aims at explaining the integration options and strategy using SAP PI. Several business scenarios are explained in this document, and the best integration approaches have been suggested for given scenarios. It can be used as a reference document for any PI implementation project and can act as a base for integration strategy document for our clients.

Audience

This document can be used by Project Managers and interface architects.

Assumptions and risks

This document has been created based on the latest version of PI, i.e., PI7.3 and the newer releases may have some changes, which will obviously be not present in this document. Performance, version upgrade, change in the product architecture could be some of the possible risks, but SAP has always been very diligent in addressing this kind of issues.

Scope

PI is normally used in landscapes having at least one SAP system, like SAP ECC. PI can seamlessly integrate two SAP systems, an SAP, and a third-party system or two third-party systems. PI can be used for synchronous as well as asynchronous communication. This document describes various integration patterns, integration options provided by SAP PI. It also includes the integration guidelines for various integration scenarios.

Executive summary

One of the primary benefits of a packaged product, like SAP is to provide an out-of-the box solution for executing various business processes. However, it is practically impossible for one application to provide all the functionality required. It is always important to choose best of breed applications to execute these complex processes. This raises a need for integrating these best of breed applications through a common integration platform.

To that point, this document aims at providing a strategy for development of interfaces between SAP ECC, CRM, and third-party applications using SAP PI as the middleware tool. The strategy presented in this document combines industry best practices. The architecture and methodologies presented are designed to minimize both short-term development costs and long-term maintenance costs simultaneously.

Integration platform

PI is a product offering from SAP for cross-system application integration involving both SAP and non-SAP systems. It also acts as a SOA middleware, capable of integrating disparate systems using services. Built on the SAP NetWeaver platform, it uses a combination of both ABAP and Java stacks to provide a reliable, high-performance, standards-based, and service-oriented platform for integrating SAP with non-SAP solutions.

EAI Playbook 29

! "" Heading 1 , .

Integration patterns and key considerations

Integration scenario Key considerations

Synchronous

Inbound to SAP Performance High availability Reprocessing Logging

Outbound from SAP Performance High availability Reprocessing Change in schema

Asynchronous

Inbound/Outbound to/from SA Reprocessing Guaranteed delivery

B2B

Reprocessing Guaranteed delivery Use of third-party adapters Mapping complexity

Inbound Batch to SAP Performance Message split/bundling based on payload size Reprocessing

Outbound Batch from SAP Performance Message split/bundling based on payload size

Integration strategy for SAP systems

SAP PI is a very mature and robust integra