GVersion 1.0

Authors: Amar Nemalikanti, Keerti Nayak,

Sreedhar Kanchanapalli, Yashu Vyas

SAP NetWeaverProcess Integration Playbook

Contents

Planning and assessment 1Introduction 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 26Interface/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 29Design — 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 98Interface 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

Continues Evolution

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 today’s 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

Continues Evolution

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.

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.

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

Application A Application BCoversion Program A - B

Continues Evolution

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 individual’s 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

Application A Application B

Application C Application D

Application EEAI

Continues Evolution

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 ESB’s 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 organization’s 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

Continues Evolution

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 ESB’s proprietary XML-based programming language, a task that requires both tedious hand coding of XML and in-depth knowledge of the ESB’s 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

Continues Evolution

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 client–server 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

Continues Evolution

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 vendor’s 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 ESB’s 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 community’s 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 ESB’s 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

Continues Evolution

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

EAI Playbook 8

Continues Evolution

production. This in 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. Today’s 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 today’s 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 client’s 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

Continues Evolution

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 sender’s 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

Continues Evolution

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 company’s 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 modification on the company’s 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, SAP’s 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 SAP’s 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

Continues Evolution

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 organization’s 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.

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

EAI Playbook 12

Continues Evolution

ESB layer ESB component SAP NetWeaver PI features

payloads to providing rich aggregation or decomposition of service semantics so that each side of the conversation is unaware of the other side’s 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.

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

EAI Playbook 13

Continues Evolution

ESB layer ESB component SAP NetWeaver PI features

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 fulfill 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 consistent and valid. Each component in the VETO pattern is typically implemented as a separate service and can be configured and modified 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 modifications of it. Moreover, implementing validation as a separate component would ensure that every

EAI Playbook 14

Continues Evolution

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.

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.

EAI Playbook 15

Continues Evolution

Figure 1: Example hybrid architecture

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

EAI Playbook 16

Integration Services Layer

App

lication

C

onn

ectivity

PK

MS Hub

STAR

Kronos

Application Connectivity

Application Connectivity

App

lica

tion

C

onn

ectiv

ity

SA

P

Hub

Integration Services LayerApplication

Connectivity

PkM

S HUBSAP PI S

AP

Hyperion

Kronos

Application Connectivity

Application Connectivity

Continues Evolution

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

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

Integration Service Layer

SAP PI(Process Rules)

IntegrationC

omponent

PK

MS S

AP

Hyperion

Kronos

IntegrationComponent

IntegrationComponent

Network

Continues Evolution

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

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

IntegrationServices

Layer

ServiceRegistry

SAP

Hyperion

Application Connectivity

Application Connectivity

Register

Request Loca

tion

Bin

d a

nd

Re

qu

est

Continues Evolution

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

Continues Evolution

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

Continues Evolution

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

Continues Evolution

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

Continues Evolution

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

Continues Evolution

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.

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

SAP Project Initiation Estimation hours v11_LATEST.xlsx

Continues Evolution

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

Continues Evolution

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

Continues Evolution

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.

Type of high-volume interfaces

EAI Playbook 27

Continues Evolution

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

Continues Evolution

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

Continues Evolution

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 integration platform integrating SAP and Non-SAP Systems using various message and transport protocols. Based on quality of service, interfaces can be broadly divided into synchronous and asynchronous ones. PI has got setup adapters, which help us integrate our systems in various message formats based on the business requirement.

Synchronous calls, are made from SAP system to an outside world, can be established using Business Application Programming Interface (BAPI)/RFC, Proxy, Plain HTTP, and Web services. Similarly asynchronous calls are made using File, Proxy, and JDBC.

Asynchronous interfaces

When two systems interact with each other and are not really interested in a quick response, this is referred as asynchronous communication. IDoc, JDBC, JMS, Proxy, and File-based approaches are commonly used. Persistene, Error handling and reprocessing, performance…, etc., are discussed to decide the best integration approach for asynchronous interfaces.

File-based integration

File-based interfaces are tightly coupled with application. File formats are fixed and the reading application can read the file. Some SAP-standard transactions/programs create file or expect file as input. In these cases, we need to create file on SAP application server in case of inbound interfaces and pick files from application

EAI Playbook 30

Synchronous

BAPI/RFC Proxy Web Services

Asynchronous

File Proxy IDocs

Continues Evolution

server in case of outbound interfaces. This can be a solution for standard SAP interfaces. But this integration approach may not be the preferred for custom developments.

IDoc-based integration

This is a very standard approach to post SAP-standard documents and to send messages to third-party systems. Application Link Enabling (ALE) layer provides standard error-handling, persistence, and reprocessing mechanism for IDocs. Standard IDocs can be used directly in most of the interfaces. If the existing IDoc does not meet the business requirement, it can be extended to add extra fields. Custom IDocs can also be created, if required. All the IDocs are persisted in the system and can be reprocessed, if required.

ABAP proxies

This is an outside-in development approach with adapter-less out-of-the-box integration. The proxy framework acts as a layer over the actual functionality and hides technical details from application developer. Transforms language-specific data structures into XML and vice versa. Ensures technical connectivity with the integration engine and guaranteed delivery. The Proxy model is an important element of the Enterprise Services Architecture.

SAP’s latest integration approach, using XI SOAP (extended XML document format), is a very common integration approach for custom developments. These can be synchronous and asynchronous. Asynch messages are persisted in SAP by default, whereas option to persist synchronous messages is available. Asynchronous proxy error messages can be reprocessed in target SAP system for inbound interfaces. In case the middleware is not available, and the outbound messages fail, they can be resent from SAP.

In case of inbound interfaces, custom code can be written to call a BAPI to poststandard documents like Sales Order or Delivery Document. Multiple documents can also be posted, if required.

For custom asynchronous scenarios, we can go for IDoc or Proxy approach. IDoc and Proxy approach details are explained below.

JDBC

SAP PI can help us integrate SAP with variety of data bases like oracle, DB2, etc. This needs the driver program from JDBC.

JMS

JMS adapters can be used to integrate SAP with queue-based tools. This helps us in integrating JMS-based communication.

IDoc Proxy Comments

Middleware Dependency

× Proxy-based interfaces can be developed using SAP PI, where as IDocs can be used with other middlewares (with SAP adapter).

Performance in ECC Message Processing

× Posting data in ECC using proxy awards better performance.

Performance in ECC — Message Transmission

We can create separate IDocs in PI and still bundle them in PI, while sending them to ECC limiting number of tRFC calls to ECC. Proxy and IDoc messages can also be bundled together for better performance in PI.

Performance in PI/Middleware

× Message processing will be easier in PI when we use proxies as:

“XML to IDoc XML” transformation is not involved

“IDoc XML to IDoc” transformation is not involved

Message Tracking at transaction level

× If we create multiple IDocs, one for each transaction, it is easier to pinpoint the failed IDoc and the data inside.

EAI Playbook 31

Continues Evolution

IDoc Proxy Comments

If we send everything to ECC using proxy and create custom IDocs for failed messages (using BAPI/ALE), we need to correlate the proxy message and IDoc in ECC.

Message Reprocessing Failed IDocs and proxy messages can be reprocessed in ECC.

Maintenance × It is easier when we use IDocs. We may not be creating a proxy message and then a ZIDOC using BAPI/ALE or some other method for error handling.

Persistence Considerations

× In case we create 1000 IDocs from a file containing details about 1000 documents, we may need more disc space. Sending them using single proxy call and creating IDocs for failed transactions can be considered.

Message Persistence IDocs as well as proxy messages are persisted in ECC.

Recommended approach for asynchronous inbound interfaces

1. SAP-standard programs expecting file input — In cases where SAP-standard program is expecting file input, definitely the file-based approach should be preferred.

2. SAP-standard document posting (e.g., Sales Order and Delivery) — SAP has provided standard IDocs for master as well as transactional data. So, for example, we are getting a message to create a material in the system or to create a sales order, etc., standard IDocs should be used and can be extended to add extra fields, if required.

3. Single custom transaction in SAP per source message — In cases, we need to execute custom logic and post any document in SAP or to create an entry in a table proxy should be preferred over other mechanisms. Asynchronous proxy messages are persisted in ECC as well as PI, and can be reprocessed in case of errors.

4. Multiple custom transaction in SAP per source message — Custom IDocs should be created to post the IDocs in SAP. ALE layer takes care of persistence and reprocessing. We can set custom IDoc status after each logical step and messages can be reprocessed, if needed. We can execute only the relevant steps while reprocessing by using IDoc status in our logic to post the document.

5. Sender system is EDI based — Most of the EDI standard documents can be readily mapped to IDocs using translation tools or adapter available in the market. Hence, IDocs should be used to post data in SAP for EDI interfaces. We might need to involve third-party EDI providers, since PI cannot handle EDI maps and transmission.

6. Very large source payload, creating thousands of documents in SAP per source file (very rare scenario) — Very large payloads should be sent to SAP using proxy and posted in loop. PI provides high-volume support for proxy messages using SOAP adapter bypassing integration engine. In case of errors, IDocs should be created for failed transactions using BAPI-ALE in SAP to keep track of the failed messages and reprocessing, if possible. We can also persist them in custom tables if the message format is simple.

Recommended approach for asynchronous outbound interfaces

1. SAP-standard programs creating file — Many FI transactions create files in SAP. In case we need to send them to a partner or system, file-based interface should be preferred. So, in all such cases where files are generated by standard programs, we should use file-based interface instead of translating the message to a different format.

2. SAP-standard document posting (e.g., Sales Order and Delivery) — Most of the transactions like Purchase Order Creation, Sales Order Creation, and IDocs are created without any custom development. These can be sent to vendors, customers, and banks or any other system in IDoc format. IDocs are widely used and we have many translators available in the market to translate them from IDoc to native message

EAI Playbook 32

Continues Evolution

format. Using PI, we can translate IDoc to SOAP, File, or any other industry-standard format. It may involve use of third-party adapters in some cases.

3. Messages sent from SAP system in custom format — Custom interfaces can be built using proxy approach. Any custom message format can be created and any custom output can be sent out using proxy. This helps us in creating simple and robust solution in very less time.

4. Target system is EDI based — IDocs should be used to send the data out of ECC. We might need to involve third-party EDI providers, since PI cannot handle EDI maps and transmission.

Synchronous interfaces

Synchronous interfaces with ECC system can be developed using BAPI/RFC; Web services; and Proxy. Platform independence, open standards, and persistence are discussed to decide the best integration approach for synchronous interfaces.

BAPI/RFC

BAPI- or RFC-enabled function module can be invoked from external systems or middleware’s with SAP adapter. These are not persisted by default. In case we need to persist these messages, we should use BAPI-ALE to create IDocs for failed messages or some other logging mechanism.

PI or any other middleware with SAP adapter can communicate with ECC synchronously my making RFC calls.

Web service

This is not based on open standards and, hence, SAP has provided the flexibility to expose them as Web services. These services can either be predelivered content from SAP or custom created. BAPI/RFC-enabled function modules can be exposed as Web services. Request/Response payloads are not persisted in SAP by default. Middleware may not be needed to invoke a Web service as soap runtime lies on ABAP stack of SAP systems and can be invoked directly. If routed directly (bypassing middleware), there can be significant amount of gain in terms of performance.

Synchronous proxies

These are SAP-centric solution. Easy to create and maintain using PI. These can be persisted in ECC. Business scenarios where we need to send messages and expect a real-time response, synchronous proxies should be preferred.

Recommended approach for synchronous inbound interfaces

1. Web service is available — In case we have predelivered integration contetnt available, we can download the same from SAP marketplace and use the same. These can be used directly and can be enhanced, if needed.

2. BAPI/RFC available to be exposed as Web service — In case we have a BAPI- or RFC-enabled function module, they should be exposed as Web services. Web services award platform independence.

3. SAP-delivered proxy classes (Ex FSCM) — For SCM or FSCM integration, SAP provided predelivered content as proxy and can be readily used.

4. Custom synchronous requirement — For custom synchronous interfaces, Proxy can be a preferred solution. Proxy messages can be persisted in SAP, if needed.

EAI Playbook 33

Continues Evolution

Recommended approach for synchronous outbound interfaces

1. Web service provided by the target system — WSDL can be imported in PI, so that services can be called directly from PI. Proxy can be generated using the same interface definition, and can be used between ECC and PI.

2. Custom synchronous requirement with persistence in SAP — Proxy should be used as we can easily enable persistence of synchronous proxy messages in SAP systems.

Design — Error handling strategy

Purpose

Every interface design must include mechanisms to identify and correct the errors that could occur at runtime. Instead of each interface having its own individual design for handling such error conditions, a common strategy used by all the interfaces is used. This common design for handling errors encountered during interface execution is called the Error Handling Framework.

Scope

This document only covers the handling of errors that occur in interfaces in which the PI System is involved. This document does not apply to errors that occur in interfaces that do not make use of the PI Server.

Executive summary

Every interface design must include mechanisms to identify and act upon error conditions that could occur at runtime. Instead of each interface having its own individual design for handling such error conditions, a common strategy used by all the interfaces is used. This common design for handling errors encountered during interface execution is called the Error Handling Framework.

This strategy would involve using out-of-the-box SAP error handling features like alerts, workflow email notifications, CCMS, etc. Custom components need to be built in order to achieve error handling functionality, which is not standard.

The Error Handling Framework for the interfaces consists of two parts:

Error notification

System errors in SAP PI would automatically trigger the CCMS alerts, which can be monitored through the SAP solution manager.

Custom alerts from SAP would be raised to notify the error in the interface in the following scenarios:

1. Any custom validation/lookup error in SAP PI

2. Mapping errors due to missing values for mandatory fields in SAP PI

3. Any functional error occurring while data processing in a target SAP system

Specific basis configuration would be required to integrate the custom SAP PI alerts with CCMS and solution manager.

EAI Playbook 34

Continues Evolution

Message reprocessing

Though the best approach for resolving the error caused due to the incorrect data would be to resend the correct data from the source system, but in addition to it, the error handling framework would have the option for reprocessing the erroneous message. The erroneous message can be reprocessed by the following mechanism:

1. Reprocessing the message in SAP PI by using the standard SAP PI tools — SAP PI stores all the messages being passed through it. Standard tools are available in SAP PI to resend the message to the target system, in case of an error in SAP PI.

2. Reprocessing the erroneous data in SAP ECC — The message to SAP ECC from SAP PI would be passed either in the form of an IDoc or a proxy. In case of an error in IDoc, the data can be reprocessed by using the standard transactions available for reprocessing the IDocs. If the data integration is being done by using a proxy, custom mechanisms have to be used to reprocess the errors.

Definitions

Terms Explanations

Functional Errors Errors that occur as a result of incorrect business data or configuration

Technical Errors Errors that occur as a result of technical capability not operating as anticipated

Trigger An event that will kick off a business process in SAP/Legacy System

Connectivity Moving data from the source system to PI or moving data from PI to the target system

Process Logic used within the SAP/Legacy system to process the data

Transformation Mapping data from source to destination formats

POF Point of Failure

Error classification

Errors can be classified based on the combination of POF, such as Trigger, Connectivity, Transformation, Process, and error types Functional or Technical. The table below shows the various classifications based on the above parameters.

1 Trigger Functional Failure in an Outbound proxy/Function module/Report Program while collecting back-end information

2, 4 Connectivity Technical Failure in the connectivity between PI and SAP/Legacy System

3 Transformation Functional Transformation of data from Source to Target format in PI

5 Process Functional Business Validation Errors in SAP once data is loaded into SAP via an IDoc or Proxy and same on Legacy side

An error handling strategy should basically contain mechanisms for notification of errors and, if required, mechanisms to reprocess the errors. The following sections brief about both of the above mechanisms with respect to the various error classes:

EAI Playbook 35

Continues Evolution

It should be noted that SAP provides many mechanisms to support error handling. Custom components need to be built in order to achieve error handling functionality, which are not standard.

POF trigger

The error type here would be functional.

These errors would occur while data is being collected for sending to a middleware. Typical points of occurrence would be:

A class, report, and function module calling an outbound proxy

A function module behind the creation of an outbound IDoc

A standard SAP program generating a file

These issues would be related to the business processing of information on the sender side. The following sections detail the various mechanisms for error notification and error reprocessing:

Error notification

Examples of a few reasons for these errors on the outbound side would be:

Invalid input to an outbound program, e.g., invalid material, invalid plant, and invalid customer

Invalid correlations, e.g., invalid material for a plant, etc.

Out-of-the-box features can be used for error notification in such a case.

Out-of-the-box features like ABAP messages can be displayed both in an online and batch mode.

Error reprocessing

Error reprocessing will be done manually, due to data input issues.

POF connectivity

Error type here would be technical.

These errors occur during the sending of information to the middleware. These can occur as follows:

At the source, SAP system occurring as a result of incorrect proxy connectivity for proxy-based communication.

At the source, SAP system occurring as a result of incorrect partner profile for IDoc-based communication.

At the middleware, e.g., SAP PI occurring as a result of adapter-specific errors.

Error notification

For the adapter-specific errors, which occur at the middleware, out-of-the-box features like alert category definition, agent assignment, and alert rules configuration (via the RWB) need to be used.

In case of outbound IDocs, we would have the following error use cases:

Partner profile is incorrect, hence, the IDoc could not be posted. In such a case, standard task TS00007989 would be triggered. The notification would go to the IDoc administration maintained via the transaction OYEA.

EAI Playbook 36

Continues Evolution

Case where an outbound IDoc goes into a syntax error. In such a case, Standard Task TS00008070 is triggered. The agent to receive the notification can either be maintained in the specific partner profile or in general view specific to the partner number. In case the above agents are not maintained, the error is propagated to the IDoc administrator maintained via OYEA.

Error reprocessing

Error reprocessing would be required in case of failed outbound IDocs.

SAP provides out-of-the-box features for error reprocessing in case of failures in case of outbound IDocs. This can happen through the transaction BD87.

In case of proxy-based communication, error reprocessing can happen via the transaction SXMB_MONI.

On the legacy side connectivity, all PI adapters have their own retry mechanism. SAP PI attempts to resend the message, which resulted in error due to connectivity or adapter-related issues for a preconfigured number of times.

Once all such attempts fail, the message is set to an error state.

POF transformation

The error type here would be functional.

These errors would occur during the mapping or the transformation step within PI. The errors would result as a consequence of business validation of check performed in PI as well as incorrect data formats.

Error notification

Some examples of such errors can be:

Errors in data formats occurring due to missing values for mandatory fields, incorrect field lengths, etc.

Errors that occur due to specific business rules, which are applied on the incoming data.

Out-of-the-box and custom features would be used for error notification.

Out-of-the-box features

SAP provides out-of-the-box error notification mechanisms called alerts. The steps to use them includes definition of alert categories, assignment of agent responsibilities, and definition of alert rules.

The first step to use the feature would be to configure alert categories. The category is used to classify different kinds of alerts. This is done via the transaction ALRTCATDEF.

The definition involves configuring the recipients or the responsible agents who should receive a notification based on the alerts.

It also involves definition of container variables. These variables would be used to construct the alert message. A standard set of such containers are provided by SAP.

SXMS_MSG_GUID SXMSMGUIDC Message ID

SXMS_RULE_NAME SXMSDESCR Description of the alert rule

SXMS_ERROR_CAT SXMSERRCAT Error category

EAI Playbook 37

Continues Evolution

SXMS_MSG_GUID SXMSMGUIDC Message ID

SXMS_ERROR_CODE CHAR70 Error code

SXMS_FROM_PARTY SXI_FROM_PARTY Sender party

SXMS_FROM_SERVICE SXI_FROM_SERVICE Sender service

SXMS_FROM_NAMESPACE SXI_FROM_ACTION_NS Sender namespace

SXMS_FROM_INTERFACE SXI_FROM_ACTION Sender interface

SXMS_TO_PARTY SXI_TO_PARTY Receiver party

SXMS_TO_SERVICE SXI_TO_SERVICE Receiver service

SXMS_TO_NAMESPACE SXI_TO_ACTION_NS Receiver namespace

SXMS_TO_INTERFACE SXI_TO_ACTION Receiver interface

These are configured in the alert category definitions as follows:

The containers are used to construct the alert message. To be able to relay the alert messages to a centralized alert monitoring tool like Remedy, some containers like SXMS_MSG_GUID, SXMS_FROM_INTERFACE, and SXMS_TO_INTERFACE should mandatorily be used.

The final step would be to define alert rules for the above alert category in the RWB under Alert configuration.

When an error occurs, the alert rule determines the corresponding category and further the corresponding recipient resulting in an alert message in the alert inbox.

EAI Playbook 38

Continues Evolution

More details from SAP Help.

These errors can be relayed onto CCMS and then seamlessly to the solution manager via the following steps:

Scheduling a job via the RWB to transfer alerts from the alert inbox to CCMS

Setting up a CCMS template for PI errors using the transaction RZ20 in PI

EAI Playbook 39

Continues Evolution

The alerts can then be seen via the RZ20 transaction, the description is similar to that of the alert category.

Custom alerts

Custom features would have to be implemented to support rule base business validation errors from PI.

All such alerts can be raised from a consolidated system. A consolidated system would have two major advantages: one proper governance of alert categories and the other being a generic framework available to support such errors.

A generic framework would include a wrapper class ZCL_CUSTOM_ALERT_HANDLER having a public method RAISE_ALERT implemented over the standard alert function module SALERT_CREATE_API.

EAI Playbook 40

Continues Evolution

The following shows the method signature:

Parameters Description

P_INTERFACEID This is the Interface ID, which uniquely identifies the interface. This correlates to the alert category.

ID This is an optional importing field. Message ID corresponding to error message should be passed, if needed.

LANG This is an importing field and should have value for Error Message Language. If ID field is populated, populate this field, if needed.

V1 This is an importing field and should have value for SAP Error Variables. If ID field is populated, populate this field, if needed.

V2 This is an importing field and should have value for SAP Error Variables. If ID field is populated, populate this field, if needed.

V3 This is an importing field and should have value for SAP Error Variables. If ID field is populated, populate this field, if needed.

V4 This is an importing field and should have value for SAP Error Variables. If ID field is populated, populate this field, if needed.

MESSAGE_STRING_TAB This is an optional importing field. Populate the field with error message, if needed. The messages as a part of the container should be exactly similar to the messages that are desired to be displayed in a centralized error monitoring tool like Remedy.

A precondition to use the framework would be to define alert categories as specified in Section 8.1.1 in addition to it a generic alert category container needs to be defined.

EAI Playbook 41

Continues Evolution

It should have a generic message string table along with a placeholder for the title of the alert message. This is done to accommodate any error message text, which needs to be displayed.

The alert category defined here needs to be mapped to the interface ID. This is done by means of a simple configuration table.

To facilitate a call from PI, in form of an RFC lookup, a wrapper RFC is coded over the method RAISE_ALERTS.

EAI Playbook 42

Continues Evolution

The following is the detail about the parameters:

INTERFACEID Unique Identifier of an Interface

MESSAGETYPE Type of message Error, Information

MESSAGETEXT Message Text as STRING

MESSAGEID Message ID

ALERTTITLE Title of the Alert Message

SYSTEMOFORIGIN Source system where the message is generated

The RFC can be called from the PI map in the following ways:

Via the RFC lookup standard function in the message map (graphical mapping).

Via a custom Java wrapper API for XSLT- and Java-based transformations.

The JAVA WRAPPER API has a method EXECUTE with the following parameters:

HashMap MessageParam This is a collection of all the above-mentioned parameters of the RFC ZPI_RAISE_ALERTS.

String PIService Service for RFC Lookup Channel.

String PIRFCChannelName Channel for RFC Lookup.

Abstract Trace trace Trace object.

The calling application can terminate the mapping after calling the RFC, by failing the generation of the target nodes.

The RFC channel name for the lookup can be passed to the map by means of parameterized mapping technique.

Error reprocessing

Error reprocessing here is not in scope and should not be allowed, as the errors in this step arise because of errors in incoming data.

A rerun of the interface should be the possible reprocessing option.

Error reprocessing can be done from PI itself by using transactions like SXMB_MONI or Message Monitor. This should normally be avoided and done only in exceptional cases with approvals.

POF process

The error type here would be functional.

These errors would occur while the data is being processed for posting into the target SAP system. These errors are mainly business processing errors and are due to incorrect data, missing configuration, etc.

As a precondition, the functional specification will need to clearly define what constitutes a transaction. That can be a complete input file/message, a single record in the input file/message, or a group of records (based on some grouping criteria). By default, it is assumed that a record constitutes a transaction, unless otherwise specified.

Data can be posted into SAP by means of IDocs or Inbound Proxies or files.

EAI Playbook 43

Continues Evolution

The following sections define the error notifications and reprocessing options based on the above three use cases:

Use case A: Inbound IDocs

Error notification

A few examples of such errors can be:

Incorrect records in the incoming data.

Missing configuration in the incoming data.

A custom framework needs to be built with pluggable components for error notification.

As discussed in Section 8.1.2, a wrapper class ZCL_CUSTOM_ALERT_HANDLER is built with a public method HANDLE_IDOC_ALERTS.

The method has just one input parameter DOCNUM.

The method is based on a simple configuration table. This table determines the corresponding Interface ID for the IDoc message based on the IDoc control record.

EAI Playbook 44

Continues Evolution

The following is the structure of such a configuration table:

After the determination of the Interface ID, the method HANDLE_IDOC_ALERTS calls the method RAISE_ALERTS with the parameters as described in Section 8.1.2.

The alert category definition is a precondition for this mechanism, along with the configurations as suggested in Section 8.1.2.

The call to HANDLE_IDOC_ALERTS is made from a workflow task. The sequence of events is shown in the diagram below.

SAP trigger event ‘IDOCAPPL.INPUTERROROCCURRED’ for the IDoc parent event IDOCAPPL in case of IDoc error. A method is called within a workflow task, configured for the error event. The workflow task passes the IDoc number to the method.

Error reprocessing

Reprocessing of IDoc errors can be done from the transactions like BD87. Reprocessing should only happen in case of transient errors, e.g., errors due locks or missing configuration on the target side.

EAI Playbook 45

Continues Evolution

Use case B: Inbound proxies

Error notification

A few examples of such errors can be:

Incorrect records in the incoming data.

Missing configuration in the incoming data.

The custom framework as described in Section 8.1.2 can be used for error notifications. The method RAISE_ALERTS has to be called from the inbound proxy code.

Error reprocessing

Successful transactions will be posted and custom IDocs will be generated for failed transactions to allow for future reprocessing of those failed records. We will generate one IDoc per failed transaction.

Error reprocessing could be used in the following use cases:

In case of transient issues like locks.

In case of missing configuration.

In an exceptional case when the source cannot resent the message.

It should be noted that error reprocessing should not be done in case of data-related issues, as this would not meet the auditing requirement for integration.

Custom feature needs to be implemented for error reprocessing.

The proxy interfaces do not have any standard mechanism for capturing the data in case of an error.

In such scenarios, the data can be captured in a custom IDoc.

The procedure for creating the custom IDocs in such scenarios is described below.

The first task is to identify the interface header details (Receiver, Sender, Message ID, etc.) before starting to process the data. This is achieved by using the method of class CL_PROXY_ACCESS.

Once message header details are obtained, the corresponding IDoc type and message type are to be used for this interface and can be obtained from a control table as shown below.

Then using function module SWO_GET_FUNCTION_FROM_METHOD and table TBDBA, we can obtain the underlying BAPI function module that is used for posting the IDoc data. Using function module RFC_GET_FUNCTION_INTERFACE_P, we can obtain the import, export, and table signatures of the BAPI function module. Lastly, using function module IDOC_TYPE_COMPLETE_READ, we can obtain the segment information of the IDoc type that is being used.

EAI Playbook 46

Continues Evolution

Forward error handling

Forward Error Handling (FEH) is a concept of monitoring and solving errors in asynchronous message processing on the receiver’s endpoint. SAP application systems use Error and Conflict Handler (ECH) to implement FEH with the use of Postprocessing Office.

Inbound proxy in ECC system normally used to throw an exception in case something went wrong. We will try to change this behavior, and whenever an exception should be thrown, we will pass the message to the ECH service in order to be able to process it in Postprocessing Office.

Configuration steps:

Active FEH in ECC client using SPRO menu

Create an ECH business process that you need to assign to your proxy class and set up its persistence with CL_FEH_MESSAGE_PERSISTENCY.

Now you also need to create a business process in the Postprocessing Office — via a view — /SAPPO/VS_BPROC. Then, you need to assign ECH business process to PPO business process.

Assign proxy method to the FEH process and you can do this using a view — FEHV_PROXY2CMPR.

Implementation:

We need to add a new interface IF_ECH_ACTION to the proxy class and once you add this you should see a few new methods in your class.

Need to add an attribute — GO_ECH_ACTION, which is a static attribute assigned to your class.

We need to insert the code to call ECH into the proxy’s method and will be executed once the proxy’s exception is thrown. You need to populate at least ls_bapiret structure in order to send an error description to the ECH.

Once you run the message and the error should happen, you should be able to see the message with a new status in local PI monitor (transferred to external application) and also from the Postprocessing Office — /SAPPO/PPO2 transaction. In PPO, once you select the message, you should be able to see the details (like all errors) and also be able to view the content of the message.

EAI Playbook 47

Continues Evolution

Once you open a message in the Postprocessing Office, you can see that there are a few possible ways to handle en error. You can either repeat (in case the error should not happen anymore), confirm (complete the message in case of an authorization issue the message was processed manually), or discard (fail message in case the processing should not be repeated at all).

Retry method:

Within this method, you can call the proxy’s method one more time with the same data. The best idea is to copy the standard method into a new one and add the same importing parameter and exception, but also add bapiret exporting parameters, which will indicate if the retry was successful or not this time. If the call was not successful again, you just need to invoke the exception and call collect method.

Confirm method:

Within this method, you can do multiple things like sending an email message to a correct user that he needs to reprocess the transaction manually, etc., and as the end thing you need to call the finish method. When you confirm the message in the Postprocessing Office, the status should get updated accordingly.

Fail method:

The last method should be used when you cannot do anything with the message and just want to delete its status, so it will no longer be reprocessed by anyone. You can also send emails and other alerts from it prior to calling the s_fail method. Again, using this method should update the status of the message in ECH.

Using any of the buttons/methods described should update the global message status.

Use case C: Inbound files

Error notification

A few examples of such errors can be:

Incorrect records in the incoming data.

Missing configuration or master data in the incoming data.

Capture the error records in a separate file in “error” directory in the original source file format and send email notification to the respective support team.

Application logs:

A set of reusable custom function modules packaged as “includes” handle file-based interfaces. One of the custom function modules provides a means of logging actions performed by file interface programs. The main purpose of this function is to write a message to the interface application log. Application logs can be viewed using transaction SLG1.

Error reprocessing

For missing configuration or missing master data, the required configuration or update will be done in ECC, and the error file can be reprocessed.

EAI Playbook 48

Continues Evolution

Design — Archiving strategy

Purpose

The purpose of this document is to define, for the SAP ERP PI Team, a message archiving process and deletion process.

A high volume and a large amount of data are transferred through the PI system to other parties.

All the incoming or the outgoing messages are persisted as they enter the PI database and stored there to be used for error analysis.

To avoid the PI database from growing too fast, it is advisable to archive and delete the unneeded information. According to the volume of messages processed by the PI system, the archiving may not be needed immediately, but not actively archiving will reduce the PI performance in the long run. Most customers will not retain all their archives; there are specific cases where some data is archived and stored.

SAP has implemented specific data management functions to stop PI database overflow. These functions can be used in the following components:

PI engine

PI adapter framework

PI BPE

This document is expected to be actively maintained on an ongoing basis as and when new interfaces are developed that adopt architectural or infrastructural components (or variants thereof) not already contained in this document.

Scope

The scope of this document is to outline the process and steps involved around PI message archiving and deletion processes. This document can be extended to define the strategy of archival process.

Audience

This document is primarily intended for use by PI BASIS Team members and those people interested in knowing the message archiving process of PI.

PI engine archiving

Master table information

SXMSPMAST is the master table that holds the key information about each of the messages going through the integration engine. The data is persisted in this table based on the retention period defined for asynchronous and synchronous messages. 

If a message enters the Integration Server (IS), the field ITFACTION of SXMSPMAST table is set to INIT. Then the interface is checked for the action to take; if it is listed as an interface for archiving, the field ITFACTION is changed to ARCH. Otherwise, it changes to DEL. 

*Note: ITFACTION filed value in SXMBPMAST table that describes what action applies to the messages, but does not mean that the action has already took place. So it is only action status info, not that action already done.

EAI Playbook 49

Continues Evolution

Hence, the interfaces that should be archived are mentioned in archiving list before scheduling the archiving and deletion jobs.

Procedure to schedule the jobs

1. Log into the client of the IS and call transaction ‘sm37’ — Simple Job Selection.

2. Enter “*” in the job name field and enter the ABAP programs.

3. “RSXMB_ARCHIVE_MESSAGES, RSXMB_DELETE_MESSAGES” in the “Job step -> ABAP program name” field.

4. Push the execute button; you may see the jobs that execute the archiving/deletion programs. If you find some jobs with the status that are other than finished, you may double-click that line to find out more information.

System maintenance action plan

ABAP programs responsible Frequency

RSXMB_ARCHIVE_MESSAGES Period of the archiving cycle

RSXMB_DELETE_MESSAGES Period of the deletion cycle

Defining interfaces and retention periods for archiving

We also specify for how long XML messages are retained in the database before they are deleted or archived, and how long history entries for deleted XML messages are retained in the database.

Before defining interfaces in integration engine, we have to decide retention period. It varies from company to company based on the decision.

To define retention periods for messages and history entries for messages in the database, proceed as follows:

On the Define Interfaces for Archiving screen,

Choose retention periods and enter in the corresponding fields the number of days that history entries marked for deletion or XML messages marked for deletion or archiving are to be retained in the database.

If we want processed synchronous XML messages without errors to be deleted immediately, enter 0.

Save your changes.

The above settings are to be done in the Integration Engine Configuration. Use Transaction SXMB_ADM -> Specific Configuration.

EAI Playbook 50

Continues Evolution

Defining retention periods

The system navigates to a screen where the retention periods you specified are represented by the corresponding configuration data according to the following table:

Figure 4-5: Retention period

Below is an example of defining retention period.

Figure 4-6: Categories of retention period

XML messages that do not have the status processed successfully remain in the database.

Defining interfaces

This is where you define interfaces so that you can archive their XML messages.

SXMB_ADM -> The system differentiates between sender and receiver interfaces at this point.

Figure 4-7: Defining interface for archiving

To include an interface in the list of interfaces displayed, enter the interface in the Name and Namespace fields, and choose Flag Interface for Archiving.

When we choose Flag Interface for Archiving, you can see your interface.

Figure 4-8: Choosing the interface

EAI Playbook 51

Continues Evolution

Choose the interface and press retention period.

Figure 4-9: Defining retention period for an interface

We can specify retention period for the integration engine.

Figure 4-10: Define retention period

The configuration pertaining to archiving is done and now we have to schedule the archiving job and then read, write, and monitor the archived messages.

Setting up the physical path for archived messages

This can be set up through SPRO.

Figure 4-7: Physical path

Schedule archiving

To schedule archiving, follow this path:

SXMB_ADM -> Schedule Archiving -> Integration Engine — Archiving.

EAI Playbook 52

Continues Evolution

Figure 4-8: Integration engine archiving

Start Date: The start time of the archiving action. We define the start time and maintain the parameters in the corresponding fields. If jobs are to be executed periodically, choose period values to enter the start values.

Figure 4-9: Integration engine archiving — Define

Displays a dialog box like below in which you maintain the general parameters like Output Device, Number of copies, and Number of pages. We can choose Properties to maintain additional properties of the spool request. You do not generally change these properties for each spool request. If you have not configured any printer, Enter LP01 or LOCL. These output types come with the system and just create spool, and the spool will be deleted based on the basis configuration.

Figure 4-10: Background print parameters

Schedule Archiving: Once we are done with scheduling and defining printer, we can Schedule Archiving or F8.

Job Overview: To display the scheduled job in the job overview, choose Job Overview.

EAI Playbook 53

Continues Evolution

Archive Administration

The Archive Administration is used for reading, writing, deleting, and management of archived messages. There are a few ways to execute this transaction.

Transaction SXMB_ADM -> Schedule Archiving Job ->.

Enter transaction XMS_SARA will go directly.

Transaction SXMB_ADMIN -> Schedule Archiving Job ->.

Reading of archived messages

From Archive Administration -> Read -> Archive Administration:

Run Read Program.

Figure 4-11: Archiving administration

EAI Playbook 54

Continues Evolution

When we execute, you will get a screen like below.

Figure 4-12: Select file to read — Achieved

Expand any one of the above Sessions and Files and press Enter. We will see the messages that were archived and deleted on that particular date.

Figure 4-13: View message

EAI Playbook 55

Continues Evolution

To see the messages, follow the steps below:

Select messages

And press. It will take XML message versions.

Management

From Archive Administration ->

When we explore management, we can see Sessions, Files Archiving Objects, Job Details, Physical File Name, Logical Path, and File Name, Size and the Status.

Example of archived messages:

Figure 4-14: Al11 View of archived messages

Statistics

From Archive Administration ->

When we press statistics, then we can find statistics about space saved in MB.

Figure 4-15: Display statistics for archiving

And also, we can see the covered database space in DB12.

EAI Playbook 56

Continues Evolution

History entries

History entries are spots for observing message processing. They are generated by persisting at the end of a processing step for a message and contain the current status and the execution date.

History entries remain in the database for an unspecified length of time and must be deleted at some stage so that the database table does not overflow. The deletion process only deletes history entries for messages that have already been archived or deleted. The history entry is kept in the database for at least seven days after a message has been deleted. This is necessary since history entries are also required for the quality of service Exactly Once. Deleting these history entries are taken care by standard housekeeping job SAP_BC_XMB_HIST_DELETE_<client>.

This job can be scheduled through SXMB_ADM->Schedule Deletion jobs.

Figure 4-16: Schedule delete jobs

Figure 4-17: Delete jobs for XML messages and history entries

EAI Playbook 57

Continues Evolution

Archiving

Adapter framework

The adapter framework automatically deletes the correctly processed XML messages. Asynchronous messages are persisted in database and are automatically flushed out after their storage time has expired.

For monitoring purpose, synchronous messages are persisted in the message store for a specified time. Since these messages are held in memory, we should not set this value too high. If there is a high load of synchronous messages, it can result into OutOfMemory errors.

The default settings are:

Successfully processed synchronous message are set to five minutes.

Successfully processed asynchronous messages are set to 30 days by default.

The delete job is started with the message store and is triggered periodically. It is triggered once a day by default (1,440 minutes).

There are two kinds of archiving adapter messages:

Signed messages

Unsigned/normal messages

Signed message contains additional information like nonrepudiation signatures from the parties. Other than this, signed and normal messages are the same.

Signed messages may need to be archived for legal reasons. Both types of messages reside in the same local database of adapter framework. Thus, separate archiving process is needed for signed messages.

Procedure

Log into the client of the IS and call transaction SXMB_IFR. This will bring up a browser window with a link to the RWB.

Once logged in, go to the ‘Component Monitoring,’ choose ‘All’ from the dropdown menu of the field “Component with Status,” and hit the “Display” button.

Figure 5-11: Adapter archiving

EAI Playbook 58

Continues Evolution

In the list of components, mark the radio button of the Adapter Engine <hostname>.

Figure 5-12: Background processing

In the tool bar below, click the Background Processing button (SP 14).

Here, you will find a list of background processing running in your system.

Check the status of the jobs and, if necessary, the logs (on the Log Tab); in this context, jobs of job type archiving and deletion are important.

Figure 5-13: Create adapter archiving

Repeat the checks also for every noncentral adapter engine.

EAI Playbook 59

Continues Evolution

Remarks

Messages with S/MIME security settings can be archived by using:

Runtime Workbench -> Component monitoring

Display all components.

Choose an Adapter Framework -> Security Archiving.

PI BPE Archiving.

Procedure:

Log into the client of the IS and call transaction SE16.

Enter the table name SWWWIHEAD/SWW_CONT in the “Table Name” field.

Push the “Table Contents (F7)” button, then the “Data browser: Table <table name>: Selection Screen” page will appear.

Click the “Number of Entries” button, then you will get the entry numbers. If this number is too large, you need to delete the completed WORKITEMS.

In transaction SE38, you may execute the Report RSWWWIDE_TOPLEVEL, which allows you to delete the completed BPE WORKITEMS manually.

System maintenance action plan

TABLE responsible Frequency

SWWWIHEAD Daily (if you have heavy BPE load)

SWW_CONT Daily (if you have heavy BPE load)

Different archiving/delete-related reports at a glance

RSXMB_ARCHIVE_MESSAGES archive XML messages.

RSXMB_CANCEL_NOT_REST_MESSAGES cancel XI messages with errors that cannot be restarted.

RSXMB_DELETE_ARCHIVED_MESSAGES delete archived XML messages.

RSXMB_DELETE_MESSAGES delete XML messages from the persistency layer marked for DEL.

RSXMB_CANCEL_MESSAGES helps in mass cancellation of error messages — XI.

RSXMB_SHOW_REORG_STATUS and RSXMB_SHOW_STATUS provide an overview for all XML messages in XI persistency layer.

RSXMB_MESSAGE_STATISTICS2 provides the processing statistics. This report is basically analyzed in the history table.

RXWF_XI_UNSED_MSGS report helps in converting message states other than 003 to final state, i.e., 003.

SXMB_REFRESH_ADAPTER_STATUS report helps in converting message states like 001/008 into final state.

RSXMB_DEL_TO_ARCHIVE changes the flag values from DEL to ARCHIVE in master table.

EAI Playbook 60

Continues Evolution

Design — PI application transport strategy

Purpose

This document provides the guidelines to handle the PI transports. It also drives the consultants to adhere to specific naming convention while creating transport requests.

Scope

The scope of this document is to provide the strategy for PI transports.

Audience

This document is written for all personnel directly involved with the design, configuration, and ongoing activities of interfaces developed within the SAP PI environment.

Transport method used: CTS+

SAP NetWeaver PI contains enhanced functionality that enables close coupling between the PI development tools (ESR and ID) and CTS (Change and Transport System), and enhanced administration support during configuration phase of TMS supporting the system maintenance of combined Java and ABAP systems.

The following graphic describes the important CTS+ components and their distribution to the PI systems for a typical three-system landscape:

Advantages:

1. Simplified transport management to avoid inconsistent system states.

2. Connect Java Systems to standard CTS.

3. Combined transport requests for mixed sets of objects (ABAP, Java, PI objects…, etc.).

4. Central administration of all transports (ABAP, Java, PI objects, EP Objects…, etc.) in one user interface.

5. Logs clearly show the state of each request for developers and administrators.

6. Imports are shown in the CTS+ system with all other requests.

7. Imports can be triggered, scheduled, and monitored centrally.

EAI Playbook 61

Continues Evolution

Prerequisites:

CTS+ has been configured to route the transports to the required target system.

All the PI-related development for the interface is freezed in DEV.

Unused ESR and ID components of the interface are deleted.

The interface is Functional Unit test (FUT) passed.

All the required UNIX OS level directories and user IDs and passwords are created in the target system.

Transport methodology

System Landscape Directory (SLD):

Software catalog:

– Using the ‘Export’ option of SLD, create the transport request and assign the required custom

products and software component versions to the request.

– The transport requests can be released from the Transport Organizer of ABAP stack or from

Transport Organizer Web User Inteface (UI).

System catalog:

– Using the ‘Export’ option of SLD, create the transport request and assign the required technical and

business systems to the request.

– The transport requests can be released from the Transport Organizer of ABAP stack or from

Transport Organizer Web UI.

– In the target system SLD, create source and target business system groups and assign

corresponding business systems to the group.

– For each source business system, add the corresponding target business system.

Points to remember:

1. The ownership of the above tasks will be with the BASIS team.

2. In the target system, all the technical systems should exist prior to transporting business systems.

3. Similarly, all the product versions should exist in the target system prior to transporting software component versions.

4. First, export the software catalog components and then the system catalog components.

5. Make sure to add the different export components to the transport request in the correct sequence. First, add the components that are a prerequisite for the import of the other.

6. In the target system, the import is triggered manually or automatically by the system administrator.

ESR and ID:

Every interface scenario will have only one request created with all the ESR components and the corresponding ID components.

EAI Playbook 62

Continues Evolution

Creating the transports:

The transport requests for the components can be created using the following steps:

1. Select the components that need to be transported and choose menu option, Tools -> Export Design/Configuration Objects.

2. Select ‘Transport Using CTS’ as the transport mode, enter a description, and choose ‘Continue.’

3. The system now displays a proposed transport request (either a newly created one or an existing standard request for your user).

4. If a different request needs to be used, click on the link to access the Transport Organizer Web UI to create a new transport. Refresh the transport selection in your PI transport wizard to show the new transport request.

5. Choose ‘Finish’ to create the request and assign the selected components.

Releasing the transports:

1. The transport requests can be released from the Transport Organizer of ABAP stack or from the Transport Organizer Web UI.

2. After releasing the transports, wait for some time and refresh the status and switch to your released transport to check the export log.

Searching the transports created:

1. From ‘Tools’ menu, choose ‘Find Transports.’

2. Choose ‘Advanced’ in the search screen and select ‘CTS Transport’ as the transport type and search for transports.

3. Select one transport line to display its status information. To display details (Attributes tab page) and the contained objects (Transported Objects tab page), double-click an entry.

4. From the transport display, the Transport Organizer Web UI can be opened to check the transport status.

Checking the transports in target system:

After the CTS import of the transport to the target system has been executed either automatically or manually by the transport administrator, check the result of the import in the target system.

1. From ‘Tools’ menu, choose ‘Find Transports.’

2. Choose ‘Advanced’ in the search screen and select ‘CTS Transport’ as the transport type and search for transports.

3. Select one transport line to display its status information. To display details (Attributes tab page) and the contained objects (Transported Objects tab page), double-click an entry.

EAI Playbook 63

Continues Evolution

Points to remember:

1. The ownership of the above tasks will be with the PI development team.

2. All design and configuration objects in the respective change lists required for a particular interface scenario should be activated.

3. The unused objects in the scenario should be deleted.

4. In ESR, while creating transport request for a scenario, make sure to include the required ‘Imported Objects’ if any used in the scenario.

5. The different export components to the transport request should be added in the correct sequence. First, add the components that are a prerequisite for the import of the other.

Transport naming convention

Please provide the transport request description as below:

For SLD components:

Description of components: SLD

Example:

DEV Business Systems: SLD

For ESR and ID Components:

FRICEW Object ID: <CR# XX>: <Description of the object/CR>: <ESR&ID/ESR/ID>

Example 1:

Object ID: Prepaid Freight: ESR&ID

Example 2:

Object ID: CR# XX: Sales Report Extract–Mail Subject Change: ESR

Design — Middleware/system sizing process

The sizing can be done using the Quick Sizer tool. Quick Sizer is a Web-based tool designed to make the sizing of SAP business suite easier and faster. It has been developed by SAP in close cooperation with all platform partners and is free of cost.

Quick Sizer calculates Central Processing Unit (CPU), disk, memory, and Input/Output (I/O) resource categories based on throughput numbers and the number of users working with the different SAP solutions in a hardware- and database-independent format.

The Quick Sizer tool can be accessed at:

http://service.sap.com/quicksizing

Development — Development standards and naming convention

Purpose

This document describes the naming standards for the SAP PI implementation. This document is categorized into three parts —SLD, ESR, and ID.

EAI Playbook 64

Continues Evolution

SLD provides the overview and naming standards of its components like Software Catalog, Technical Systems, and Business Systems.

ESR provides the overview and naming standards of its components like Namespaces, Business Scenarios, Interface Objects, Mapping Objects…, etc.

ID provides the overview and naming standards of its components like Logical Routing, Collaboration Profiles, Collaboration Agreements…, etc.

The collection of naming standards presented here is a combination of best practices derived from other PI implementations and SAP naming standards recommendations.

Scope

The scope of this document is to provide naming standards for the PI objects.

Audience

This document is written for all personnel directly involved with the design, implementation, and ongoing operation of interfaces developed within the SAP PI environment.

Guiding principles and best practices

All objects will have functional/technical specifications. No object will be worked on without a specification.

Please use the naming standards in this document for all development requirements.

All objects that do not conform to the naming standards in this document will not be transported into production.

Support for shorter redeployment cycles and reconfiguration via loose coupling of interface components.

Minimize design and development time, and maximize reuse.

Must have centralized control and monitoring of end-to-end transaction progress.

Wherever possible, utilize common services during the design and development of the interface components.

SLD

The computing environment consists of a number of hardware and software components that depend on each other with regard to installation, software updates, and demands on interfaces. The SAP SLD simplifies the administration of the system landscape.

The SLD contains component information, a landscape description, and a name reservation, which are based on the standard Common Information Model (CIM). The CIM standard is a general schema for describing the elements in a system landscape. This standard is independent of any implementation.

The component information provides information about all available SAP software modules. This includes version numbers, current patch level, and dependencies between landscape components. It is also possible to add instances for third-party components to the component description.

The system landscape description represents the exact model of an actual system landscape. Together with the current component information, the system description provides information for various processes (the system administration and implementation, for example).

EAI Playbook 65

Continues Evolution

The major components of SLD are:

Software catalog

Component information regarding SAP solutions and their possible combinations and dependencies is already delivered by SAP. The software catalog can be enhanced with non-SAP products by the customer. Information on installed landscape elements, including software packages installed on the various application systems in the landscape, is contained within the SLD. This information is utilized during the design and configuration of integration scenarios with PI.

Naming standards

Product

Custom products to be defined for PI development.

Vendor: While creating the product, the vendor (owner) of the product should be specified. Usually, it will be the Uniform Resource Locator (URL) of the company.

E.g., abc.com.

Product name: Name of the product to be created. Usually, the product will be defined corresponding to the functional area.

E.g., ORDER_MANAGEMENT, FINANCE…, etc.

For example, all finance-related interface scenarios should be placed under the product name FINANCE.

Version: Version of the product.

E.g., 1.0, 1.1..., etc.

Software component

Custom software components to be defined for PI development. Each software component will be associated with a product.

Vendor: While creating the software component, the vendor (owner) of the product should be specified. Usually, it will be the URL of the company.

E.g., abc.com.

Name: Name of the software component to be created. Usually, the software component will be defined corresponding to the subprocess of the functional area.

E.g., ACCOUNTS_RECEIVABLE, GENERAL_LEDGER…, etc.

For example, the FINANCE product contains the software components ACCOUNTS_RECEIVABLE and GENERAL_LEDGER.

Version: Version of the software component.

E.g., 1.0, 1.1..., etc.

Technical systems

If the automatic registration of SAP systems is set up (data supplier bridge within SLD and data supplier within connected SAP systems), only technical systems of third-party products will need to be physically maintained by the SLD organizers; otherwise, all technical systems information need to be maintained manually. Our

EAI Playbook 66

Continues Evolution

recommendation is to always set up automatic registration of SAP systems since it minimizes the errors and work effort.

Naming standards

For SAP instances:

<SAP SID>

For technical systems defined for a SAP instance, utilize the SAP SID as the naming standard.

E.g., DE1 and DX1

For non-SAP instances:

<System Name>[<Description>]

<System Name>:

Application name of the system (E.g., ORACLE).

Recommended not to use hostname.

[_Description] (Optional).

An additional free-form description can be used if the system name does not guarantee uniqueness for the definition of technical system.

E.g., ORACLE_National.

Business systems

Business systems are logical systems used in scenario configurations in which they act as senders or receivers of messages. Every business system is associated with a technical system.

For example, every client of SAP system will be represented as a business system. There will be no difference between technical and business systems in case of non-SAP systems.

Naming standards

For SAP instances:

<Technical System Name>CLNT<Client>

<Technical System Name>:

Name of the technical system.

<Client>:

Client number.

E.g., DE1CLNT100.

For non-SAP instances:

<Technical System Name>[_Description].

<Technical System Name>:

Name of the technical system (E.g., ORACLE).

EAI Playbook 67

Continues Evolution

[_Description] (Optional):

An additional free-form description can be used if the system name does not guarantee uniqueness for the definition of technical system.

E.g., ORACLE_National.

ESR

In the ESR, we define namespaces, business scenarios and processes, messages, and interfaces (interface objects) and mapping programs (mapping objects).

These objects are created using the editors provided by PI and these objects internally generate Web standard languages and protocols, such as BPEL, WSDL, and XML Schema Definition Language (XSD).

The different components of ESR are:

Namespaces of software component versions

A namespace uniquely identifies a set of names so that there is no ambiguity when objects have different origins, but the same names are mixed together. Within the ESR, we can group PI development objects from one software component version into logical units using namespaces. A software component version can have multiple namespaces. These namespaces provide additional grouping and organization logic for the interface components.

Naming standards:

http://<company>/<functional area>/<scenario description>

Note: The elements in the namespace should be in lowercase, except for <scenario description>.

<company>: URL of company.

E.g., abc.com.

<functional area>: Functional area of the interface.

E.g., Purchasing.

<scenario description>: Description of interface.

E.g., PurchaseOrderCreate.

Namespace Ex: http://abc.com/Purchasing/PurchaseOrderCreate.

Business scenarios and business processes

The use of business scenarios enables us to define the message exchange and process flow (actions) for collaborative processes.

A business process is an executable, cross-system process that is implemented by BPM.

Naming standards:

Business scenarios (PI scenarios):

PIScen_<AaaaBbbbCccc>

EAI Playbook 68

Continues Evolution

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., PIScen_Procure_to_Pay .

Actions

AC_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: AC_CreatePurchaseOrder.

Business process (integration process)

IP_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., IP_CololectPOIDOC.

Interface objects

Interface objects combine the following:

Service interface (message interface) is used to describe a platform-independent or programming language-independent interface, which is used to exchange messages between application components within PI.

Service operations are entities that perform specific tasks on a business object, e.g., creating, updating, or deleting a business object. The operation is related to an action applied to an object (or a method), or an event triggered or received.

Message type comprises of a data type that describes the structure of a message.

Data type is a basic unit for defining the structure of the data for a message type. A data type can be created in a nested way by referencing data types from a complex data type. A data type enhancement can be defined on the basis of the corresponding standard SAP data type.

External definitions are not a specific type of an interface object. The structure of these objects is not created manually, but is loaded into the integration builder by uploading a file.

Context objects are pointers to a specific element (field) within the message, for future reference. They help encapsulate access to data that is contained in the payload or in the header of a message.

Naming standards:

Service interface

SI_<AaaaBbbbCccc>_<interface type>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

EAI Playbook 69

Continues Evolution

<interface type>: Should be one of the following:

IB for inbound.

OB for outbound.

AB for abstract.

E.g., SI_PurchaseOrder_IB.

Service operation

<AaaaBbbbCccc>_<comm. type>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

<comm. type>: Should be one of the following:

Async for asynchronous.

Sync for synchronous.

E.g., SalesOrderCreate_Async.

Note: For stateless XI 3.0 compatible interface pattern, the name of the service interface and operation must be identical.

Message type

MT_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., MT_PurchaseOrder.

Data type

DT_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., DT_PurchaseOrderData.

Data type enhancement

DTE_<Original Data Type Name>_<Enhancement Description>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., DTE_PurchaseOrderData_Plant1000Extn.

External definitions

ED_<AaaaBbbbCccc>

EAI Playbook 70

Continues Evolution

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., ED_SalesOrderXSD.

Context objects

CO_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., CO_PONumber.

Mapping objects

Mapping objects are the ones used in the creation of data translation maps. This includes the various mapping technologies that can potentially be utilized within the PI landscape. These contain the following:

Message mappings used to define mapping rules between source and target message types. These can be graphical, Java, or eXtensible Stylesheet Language (XSLT). Mapping templates can be created, which can be reused (for creating mappings) across the interface scenarios having similar message type structures.

Operation mappings (interface mappings) are used to assign mapping program(s) between source and target message types. Different mapping programs can be combined in sequence. For synchronous interfaces, a request and response mapping can be provided.

Imported archives are for importing externally defined programs into the ESR. These can be of type XSLT or Java. All files to be imported should be in Java Archive (JAR) format.

Naming standards:

Operation mappings

OM_<Source Msg Int. Name>_to_<Target Msg Int. Name>

<Source Msg Int. Name>: Message interface defined for source system.

<Target Msg Int. Name>: Message interface defined for target system.

E.g.,: OM_ORDERS_ORDERS05_to_SI_PurchaseOrder_IB_Async.

Message mappings

MM_<source message type>_to_<target message type>

<source message type>: Message type defined for source system.

<target message type>: Message type defined for target system.

E.g., MM_ORDERS_ORDERS05_to_MT_PurchaseOrder.

Mapping template

MTMP_<source message type>_to_<target message type>

EAI Playbook 71

Continues Evolution

<source message type>: Message type defined for source system.

<target message type>: Message type defined for target system.

E.g., MTMP_ ORDERS_ORDERS05_to_MT_PurchaseOrder.

Imported archives

IA_<source msg type>_to_<target msg type>_<Map Type>

<source message type>: Message type defined for source system.

<target message type>: Message type defined for target system.

<Map Type>: Should be one of the following:

XSLT

Java

E.g., IA_ ORDERS_ORDERS05_to_MT_PurchaseOrder_XSLT.

Miscellaneous

Function library

Function library groups a set of user-defined functions created that can be reused across the mappings of the same software component versions.

Naming standard:

FL_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., FL_Orders.

Parameters

Parameters are placeholders to provide any value dynamically.

Naming standard:

P_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., P_CommChannelName.

Graphical variables

Store intermediate mapping results and reuse in multiple target field mappings.

Naming standard:

GV_<AaaaBbbbCccc>

EAI Playbook 72

Continues Evolution

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., GV_PONumber.

Business objects

To define the business objects used in the interface scenarios.

Naming standard:

BO_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., BO_SalesOrder.

Alert category

To define the categories for the alerts used in the interface scenarios.

Naming standard:

ACAT_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., ACAT_CommunicationAlerts.

ID

The goal of the ID is to configure the sender-receiver relationships, transport mechanisms, and security requirements that will be used at runtime.

The prerequisites for configuring an interface scenario in the ID are that the internal system landscape is implemented in the SLD and the relevant design objects are defined in the ESR.

In simple terms, interface scenarios are developed in ESR, configured in the ID, and executed in runtime by the IS.

The different components of ID are:

Logical routing

Logical routing relates the message interfaces defined in the repository to potential senders/receivers. The primary building blocks are interface determination and receiver determination.

Naming standard:

No naming standards are required for logical routing objects since these are automatically generated by PI server.

EAI Playbook 73

Continues Evolution

Collaboration agreements

Collaboration agreements define the technical details for message processing. The primary building blocks are sender agreements and receiver agreements.

Naming standard:

No naming standards are required for collaboration agreement objects since these are automatically generated by PI server.

Collaboration profiles (parties and communication components)

In the collaboration profile, the technical options available to the communication parties for exchanging messages are documented. Here, the potential senders/receivers of messages and technical communication paths are specified. The primary building blocks are parties, services, and communication channels.

Party

This will be used if a larger unit (e.g., Company) is involved in a cross-system process.

Naming standard:

Party_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., Party_ABC.

Business component (business service)

If the parties involved have published only their interfaces and not their system landscape, using a business component, we can define the technical or business subunits of the companies involved and then assign them to relevant interfaces.

Naming standard:

BusComp_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., BusComp_ManuFileServer.

Business process (integration process)

A business process defined in the ESR is recipients of messages (for process step triggering) or can send messages. They are considered as a service and modeled here.

Naming standard:

BPM_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., BPM_CollectPOIDOC.

EAI Playbook 74

Continues Evolution

Business systems

Business systems defined in the SLD are imported to the directory and used as sender/receiver systems.

Naming standard:

Since these are defined in SLD and imported in ID, no naming standards are required.

Miscellaneous

Configuration scenario

All configuration objects related to an interface scenario are grouped together by configuration scenario. While creating the configuration objects, each of them should be assigned to a configuration scenario.

Naming standard:

CS_<Interface Name>

<Interface Name>: Interface name taken from FRICEW specification. Recommended to use FRICEW Interface Specification File Name.

E.g., CS_SalesOrderCreate.

Communication channel

A communication channel specifies the transport mechanism for a message — the adapter type and adapter configuration parameters. A communication channel should be assigned to a business system or business component. Depending on whether the business system or business component is addressed as a sender or receiver of messages, the assigned communication channel has the role of either a sender or a receiver channel, and must be configured accordingly.

Naming standard:

CC_<direction>_<adapter type>_<AaaaBbbbCccc>

<direction>: Should be one of the following:

In — for receiver.

Out — for sender.

<adapter type>: Type of the adapter used.

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., CC_In_File_PurchOrd.

Folders

Folders provide an additional option for the logical grouping of objects.

Naming standard:

<Interface Name>

EAI Playbook 75

Continues Evolution

<Interface Name>: Interface name taken from FRICEW specification. Recommended to use FRICEW Interface Specification File Name.

E.g., SalesOrderCreate.

Value mapping group

This defines the groups used in value mapping for interface scenarios.

Naming standard:

VMG_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

E.g., VMG_ReceiverList.

Summary

SLD

Vendor E.g., abc.com

Product name Ex: ORDER_MANAGEMENT, FINANCE…, etc.

Software component Ex: ACCOUNTS_RECEIVABLE, GENERAL_LEDGER…, etc.

Technical systems For SAP instances:

<SAP SID>

For technical systems defined for a SAP instance, utilize the SAP SID as the naming standard.

Ex: DE1, DX1…, etc.

For non-SAP instances:

<System Name>[_<Description>]

<System Name>:

Application name of the system (E.g., ORACLE).

Recommended not to use hostname.

[_Description] (Optional):

An additional free-form description can be used if the system name does not guarantee uniqueness for the definition of technical system.

Ex: ORACLE_National.

Business systems For SAP instances:

<Technical System Name>CLNT<Client>

<Technical System Name>:

Name of the technical system.

<Client>:

Client Number

Ex: DE1CLNT100.

For non-SAP instances:

<Technical System Name> [_Description]

<Technical System Name>:

EAI Playbook 76

Continues Evolution

SLD

Name of the technical system (E.g., ORACLE).

[_Description] (Optional):

An additional free-form description can be used if the system name does not guarantee uniqueness for the definition of technical system.

Ex: ORACLE_National.

ESR

Namespace of software component versions

http://<company>/<functional area>/<scenario description>

Note: The elements in the namespace should be in lowercase, except for <scenario description>.

<company>: URL of company.

E.g., abc.com.

<functional area>: Functional area of the interface.

Ex: Purchasing.

<scenario description>: Description of interface.

Ex: PurchaseOrderCreate.

Namespace:

Ex: http://abc.com/Purchasing/PurchaseOrderCreate.

Business scenarios Business scenarios (PI scenarios)

PIScen_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: PIScen_Procure_to_Pay.

Actions Actions

AC_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: AC_CreatePurchaseOrder.

Business process Business process (integration process)

IP_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: IP_CololectPOIDOC.

Service interface SI_<AaaaBbbbCccc>_<interface type>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

<interface type>: Should be one of the following:

IB for inbound.

OB for outbound.

AB for abstract.

Ex: SI_PurchaseOrder_IB.

Service operation <AaaaBbbbCccc>_<comm. type>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching

EAI Playbook 77

Continues Evolution

SLD

between uppercase and lowercase characters.

<comm. type>: Should be one of the following:

Async forasynchronous.

Sync for synchronous.

Ex: SalesOrderCreate_Async.

Note: For stateless XI 3.0 compatible interface pattern, the name of the service interface and operation must be identical.

Message type MT_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: MT_PurchaseOrder.

Data type DT_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: DT_PurchaseOrderData.

Data type enhancement DTE_<Original Data Type Name>_<Enhancement Description>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: DTE_PurchaseOrderData_Plant1000Extn.

External definitions ED_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: ED_SalesOrderXSD.

Context objects CO_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: CO_PONumber.

Operation mappings OM_<Source Msg Int. Name>_to_<Target Msg Int. Name>

<Source Msg Int. Name>: Message interface defined for source system.

<Target Msg Int. Name>: Message interface defined for target system.

Ex: OM_ORDERS_ORDERS05_to_SI_PurchaseOrder_IB_Async.

Message mappings MM_<source message type>_to_<target message type>

<source message type>: Message type defined for source system.

<target message type>: Message type defined for target system.

Ex: MM_ORDERS_ORDERS05_to_MT_PurchaseOrder.

EAI Playbook 78

Continues Evolution

SLD

Mapping template MTMP_<source message type>_to_<target message type>

<source message type>: Message type defined for source system.

<target message type>: Message type defined for target system.

Ex: MTMP_ ORDERS_ORDERS05_to_MT_PurchaseOrder.

Imported archives IA_<source msg type>_to_<target msg type>_<Map Type>

<source message type>: Message type defined for source system.

<target message type>: Message type defined for target system.

<Map Type>: Should be one of the following:

XSLT

Java

Ex: IA_ORDERS_ORDERS05_to_MT_PurchaseOrder_XSLT.

Function library FL_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: FL_Orders.

Parameters P_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: P_CommChannelName.

Graphical variables GV_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: GV_PONumber.

Business objects BO_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: BO_SalesOrder.

Alert category ACAT_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: ACAT_CommunicationAlerts.

ID

Party Party_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: Party_ABC.

EAI Playbook 79

Continues Evolution

SLD

Business component BusComp_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: BusComp_ManuFileServer.

Business process (integration process)

BPM_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: BPM_CollectPOIDOC.

Business system Since these are defined in SLD and imported in ID, no naming standards are required.

Configuration scenario CS_<Interface Name>

<Interface Name>: Interface name taken from FRICEW specification. Recommended to use FRICEW Interface Specification File Name.

Ex: CS_SalesOrderCreate.

Communication channel CC_<direction>_<adapter type>_<AaaaBbbbCccc>

<direction>: Should be one of the following:

In — for receiver.

Out — for sender.

<adapter type>: Type of the adapter used.

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: CC_In_File_PurchOrd.

Folders <Interface Name>

<Interface Name>: Interface name taken from FRICEW specification. Recommended to use FRICEW Interface Specification File Name.

Ex: SalesOrderCreate.

Value mapping group VMG_<AaaaBbbbCccc>

<AaaaBbbbCccc>: Self-explanatory name with separate individual words by switching between uppercase and lowercase characters.

Ex: VMG_ReceiverList.

Development — Templates

EAI Playbook 80

Continues Evolution

Development — Checklist

Code review checklist

Type of development (i.e., data conversion):

Object ID:

Code reviewer:

Date reviewed:

Date approved by development management/name of development manager:

All programs

Administrative data

Printout of program code attached .

Development class attached .

Authorization group assigned.

Version management .

Documentation

Header section of program contains CR number/development request number.

Header section of program contains name of the programmer .

Date on which program was created.

Name of the technical specification.

Author of the technical specification.

Program title specified.

Input file name specified, if used.

Name of the output file name, if being created.

A brief description of what the program is going to do.

Restrictions/assumptions, if any.

Data declarations adequately documented .

Variables and parameters adequately documented.

Function modules identified and described .

Called transactions/subroutines identified and described.

Use of ABAP template.

Changes history present .

Subroutine comment blocks present .

General points removal of ‘dead code’

Use of text elements.

Authorization object implemented .

Messages successfully issued to SLG1.

EAI Playbook 81

Continues Evolution

Dequeue and Enqueue Function Modules used before making any changes to custom tables.

Locking when calling transactions handle multiple-user runs, i.e., interactive reports that call transactions at some point within the run should lock data at the beginning of the run.

List any outstanding optimization improvements that may be used to improve the performance of the program .

Data declaration

Data declarations follow standard naming convention.

Constant declared instead of hardcoding values.

Variables based on dictionary object.

No redundant data declarations.

All variables have read/write references (cross-reference).

Data validation Data entered by the user must be validated and handled properly if invalid. Note that when select options

or parameters are based on dictionary objects link to a check table, no extra validation needs to be done .

Database accesses

SELECT only the fields required.

Do not use SELECT/ENDSELECT.

Use of SELECT… INTO TABLE where appropriate.

Where clause used rather than CHECK.

SELECT… WHERE matching primary key or secondary index.

Use views or join selects instead of nested select statements.

SELECT SINGLE with fully qualified key.

SY-SUBRC check performed for all selects/reads.

Database updates

No direct database updates (unless custom-built tables).

Whenever possible, use array operations instead of single row — INSERT/UPDATE/DELETE… FROM TABLE…

CALL TRANSACTION return codes checked.

CALL TRANSACTION process mode and update mode as variables.

Backup Domain Controller (BDC) Session Report (number of transactions, sessions, etc.) .

Modular programming

No unnecessary duplication of code .

Sensible use of subroutines (single-purpose FORMs).

FORM parameters assigned a data type where possible.

Reusable code placed in function modules and documented.

SY-SUBRC checks and error handling on function module exceptions.

EAI Playbook 82

Continues Evolution

Use of standard function modules for date manipulation, pop-ups, etc.

Processing data

On change is not used for processing control breaks in loops on internal tables; ON CHANGE OF is unsuitable for recognizing control levels in loops of this type because it always creates a global auxiliary field that is used to check for changes. This global auxiliary field is only changed in the relevant ON CHANGE OF statement. It is not reset when the processing enters loops or subroutines, so unwanted effects can occur if the loop or subroutine is executed again. Also, since it is set to its initial value when created (like any other field), any ON CHANGE OF processing will be executed after the first test, unless the contents of the field concerned happen to be identical to the initial value.

Use case statement instead of IF/ELSEIF/ELSEIF Make sure Case statement includes “when others.”

Sensible use of move corresponding statement .

Use loop at... where or read table with key instead of unnecesary complete loops .

BDC program

Input file validation done and error message displayed accordingly.

F4 help given in case user is not entering any file name.

Call transaction/BDC_SESSION method used as per the specification.

After a call transaction, are the error messages captured in an internal table?

Is SY-SUBRC EQ. 0 checked after a call transaction?

Refresh/clear BDCDATA done after a call transaction.

If BDC_SESSION method is used and if unable to open session using BDC_OPEN, appropriate message is given.

If BDC_SESSION method is used and if unable to insert using BDC_INSERT, appropriate message is given.

If BDC_SESSION method is used and if unable to close session using BDC_CLOSE, appropriate message is given.

Audit report displaying the records, which have been posted or not shown.

Dynpro program

Screen numbers created as per ABAP programming standards.

Validations on input screen elements done using chain/endchain.

PF status created as per the specification.

Help functionality exists for all screen fields.

SAP scripts

“NAST_PROTOCOL_UPDATE” function module used to display all messages .

All long texts are displayed on the SAP script using the Layout Include command.

PI

PI naming standards are followed. The naming conventions for PI are followed in the object.

Objects should be with status active. This will check for errors as well . The object is active with no errors.

EAI Playbook 83

Continues Evolution

Namespace should be created for every object with correct naming standards.

IDocs and RFCs should be loaded into SAP Component SAP APPL.

Message interfaces, message types, data types, message mappings, and interface mappings should be created with the correct naming standards and under the appropriate Software Component Version (SWCV).

Message mappings should comply with rules given in the mapping sheet.

A test case should be maintained for the mapping program created.

For any User Defined Functions (UDFs) created, in-line documentation is maintained.

All the ID steps should be added to relevant configuration scenario.

Sender system, sender interface, and receivers are given as per the requirement for receiver determination.

In the interface determination, the receiver interface and the corresponding interface mapping are to be given.

All the required configuration parameters are to be maintained for the adapters created (both sender and receiver).

In case of IDocs, check if ports are maintained in IDX1 and the metadata is loaded into IDX2.

Error handling as per functional requirements are implemented.

Run procedure

General information

Program:

Transaction code:

Brief description of object (in R/3):

Selection criteria (in R/3):

On the screen, selection options appear for the following:

Execute .

System information.

R/3 system:

Client:

Outbound system.

Inbound system.

Selection screen.

Using the variant

Click the icon to use the variant.

The variant screen is displayed.

EAI Playbook 84

Continues Evolution

Select the variant.

The selection screen is as follows:

Execute .

The output is as follows:

Development checklist

Type of development (i.e., data conversion):

Object ID:

Author of specification:

Reviewer of specification:

Date reviewed:

Date approved by development management/name of development manager:

Task More information

All programs

Authorization object(s) are specified

Program technical details are entered in development summary

Revised development estimate.

Standard SAP program usage Standard SAP program will be used.

BAPI will be used.

ALE will be used.

SAP function(s) will be used.

Specify reason for custom program.

Is a copy of an existing program required for modification? (specify reasons)

Name

Program Zskeleton has been copied as the template for the program (including standard report header) (relevant to all, except module pools and SAP script)

No data is changed/deleted from SAP tables using custom code

Conversion

Legacy System Migration Workbench (LSMW) will be used

LSMW naming conventions are used.

Translation tables Custom table will be created in data dictionary. First two columns are: ‘Site’ and ‘Application’ to ensure global design.

Global function will be created/used for the translation.

Use standard program to upload delimited file into SAP custom table.

Create and change mode for uploaded data will be implemented

Program runs in background mode using files

Directory paths for conversions are used.

Error-handling tools designed System failure during upload.

It is possible to correct failed transactions in bulk by a user (i.e., BDC sessions).

Audit report defined Clear audit of all errors.

Clear audit of all successfully uploaded data.

EAI Playbook 85

Continues Evolution

Task More information

Interfaces

Legacy programming Is legacy programming required?

Legacy file formats and program requirements have been specified.

Legacy specification section is complete.

Development summary has been updated with legacy program name and developer name.

File transfer method Legacy to SAP automatic data transfer is required. (If not, how will data be transferred to and from SAP?)

External application file will appear in appropriate system directory.

SAP output files are output on appropriate system directory.

What file transfer tool is used? (Network File System/FTP/Direct Pick by ABAP Prog., etc.)

Data frequency and volume information is detailed

Volumes have been confirmed and development summary has been updated.

Translation tables Custom table will be created in data dictionary.

Global function will be created/used for the translation.

Audit/error monitoring SLG1 is used for all major audit milestones and error messages. (If not, why?)

SLG1 objects have been designed according to the functional specification.

Enhancements

Audit and error messages SLG1 is used for all major audit milestones and error messages. (If not, why?)

SLG1 objects have been designed according to the functional specification.

PI

Naming standards Check if the naming standards are being followed for all the PI objects. Refer to PI Naming Standards Document.

ESR Interfaces should be created only when required. All ths IDocs and RFCs should be underimported objects.

Technical Details section should list all the steps used for developing ESR objects.

Message interfaces should be specified along with the relevant message types (inbound and outbound). Message types should list the data types being used.

Interface mapping and message mapping should be checked with respect to interfaces being used and the mapping programs as well.

Mapping sheet with the rules mentioned in the spec is attached.

ID Technical Details section should list all the steps used for developing ID objects.

Check if the systems mentioned are maintained in SLD.

Key combinations and requirements should be maintained for receiver determination, interface determination, receiver agreement, and sender agreement.

All the configuration parameters are specified for the adapters.

Others Recovery strategy/restart strategies to be specified.

Error-handling and notification scenarios to be mentioned in the spec

test cases.

Workflow

Business flow diagram (flowchart) with all technical details

List of all tasks, including workflow template/standard task/custom task

List of business objects — Methods — Events

EAI Playbook 86

Continues Evolution

Task More information

Role resolution for each dialog task

If function modules used for role resolution, then details of function modules

If configuration is required to do in SPRO transaction, then configuration details (class, release procedure, workflow triggering..., etc.)

Pseudo code giving complete details of relevant programs, transactions, event triggering, workflow handling, SAP documents posting, and any integration from workflow like (email to outlook)

HR Organization object: If used, then details regarding org. objects (org. unit, position…, etc.) along with usage

Error-handling scenarios

Development readiness checks

1. The following document details the steps to be carried out to perform system development readiness and connectivity checks:

2. Roles, responsibilities (authorizations), and skill sets in a PI environment:

Development status and templates

Usually the object development status will be tracked based on the FRICEW tracker. If the projects are proposed to use any proprietary tools the status can be downloaded directly. Sample FRICEW Tracker attached and Monthly Project Report attached. Some templates also can be accessed through Quest.

Production cutover

Plan

EAI Playbook 87

Continues Evolution

Strategy

Introduction

The final phase of any SAP implementation is known as the Cutover Phase. Any organization implementing SAP or SAP PI would need to plan, prepare, and execute the cutover. This is done by means of finalizing a cutover strategy and a cutover plan. The execution of the cutover phase should be based on the cutover strategy and the plan.

Scope

A typical SAP PI cutover execution is realized with the coordination of various teams. These teams would typically be SAP security/SAP BASIS and SAP development and legacy system teams. The activities by all these teams need to happen in a defined/approved chronological pattern. This document details the roles and responsibilities of all such teams during the cutover phase.

Executive summary

The following is a bird’s-eye view of the responsibilities of the various teams:

SAP security — The SAP security team would be responsible to set up users on PI for the IT support roles and business support roles along with SAP basis/infrastructure users. They are also responsible for setting up service user accounts used in RFC destinations.

SAP basis/infrastructure — The SAP basis/infrastructure team is responsible for installing SAP PI software, create RFC destinations, configure integration engines and IS, transport management, CCMS setup/integration with central CCMS, setup housekeeping jobs, and configuration for high availability/disaster recovery. They are also responsible for setting tuning parameters along with loading of metadata.

SAP development — The role of SAP development during a cutover is to import/activate transports, validate transported objects, smoke testing, and configuring communication parameters for integrating applications along with the activation of communication channels as outlined in the cutover plan. The details on the tasks for each of the following teams are detailed in sections below.

Legacy teams — Following would be a few examples of the legacy-related tasks:

a. Promote interface-specific changes to the legacy environment, if necessary.

b. Perform data conversions, if any.

c. Perform business activities like repointing file destinations, renaming folders, etc.

SAP security tasks

The following are the core tasks performed by SAP security teams during a cutover or system build:

Create and transport support roles

EAI Playbook 88

Continues Evolution

The following are the types of support roles tha security would need to create to support PI cutover:

Role type Teams using the role DescriptionABAP/Java key transactions

Infrastructure support role

Basis/infrastructure This is a super admin role; enables users to install PI components, monitor PI components, and configure IS.

SXMB_ADM (ABAP)

NWA (NetWeaver Administrator)

IT support role IT support/development This role enables the IT support/development team to edit communication channels. This is required to set up connectivity details like FTP server address/Web service destination.

SXMB_MONI

ID

RWB

Business support Business users [should this be PI support team]

This role enables business users to monitor PI messages.

RWB

Service/system user role

RFC users This is to set up RFC destinations. This role should enable system user to process messages through the PI pipeline.

These roles need to be transported to the production environment.

Assign users to roles

Once the role is transported into the production box, the respective users need to be assigned to the respective roles. These users need to be identified before the cutover process is kicked off.

SAP basis tasks

The following are the core tasks that need to be performed by SAP basis during the PI cutover phase:

Validate SLD content

The following validations need to be done in PI SLD by SAP basis:

Validate technical system

Technical systems are application systems that are installed in your system landscape. Example of an application system is a CRM server. In the SLD, there are four types of technical systems: SLD Web AS ABAP, Web AS Java, stand-alone Java, and third party.

All SAP systems that form the part of the PI integration landscape get automatically registered to the PI SLD. Examples of these technical systems are SAP ECC, SAP CRM, SAP SRM, etc. Basis needs to validate these technical systems.

Business systems

Business systems are logical systems that function as senders or receivers within PI. Business systems can be SAP systems or third-party systems.

Depending on the associated technical system, the following are the types of business systems that are defined in the SLD Web AS ABAP, Web AS Java, stand-alone Java, and third party:

These should be created based on the production clients in SAP PI SLD. Basis need to create and validate the business systems.

Validate transport groups and business system mapping.

Since the business system name in DEV, QA, and PRD are different in the landscape; the ID configuration defined in DEV will be invalid for QA or PRD. To avoid this situation, transport targets are

EAI Playbook 89

Continues Evolution

used. By defining transport targets, the referred business systems are changed automatically and the configuration will remain valid.

To achieve the same, mappings and transport groups need to be defined in the SAP PI SLD. These mappings map the DEV and QA business systems to the PRD business systems.

Basis/Infrastructure validations

The following set of infrastructure validations needs to be performed by SAP basis:

Validate RZ10 Profile parameters of connecting SAP business systems

Validate Java VM parameters in Config tool

Validate exchange Profile parameters

Execute SLDCHECK in all Integration engines of connecting SAP business systems

Validate all JCO providers in PI System

Validate all RFC connections in SM59

Verify if all the required SSL certificates are installed and are valid through STRUST/NWA

Validate CCMS and Process Monitoring Infrastructure (PMI) monitoring are enabled

Validate Alert Configuration settings, and verify if CCMS and RWB Alert rules are properly configured

Validate the connections to TREX system if used and also with any scheduling software like Redwood

Validate if Web dispatcher and all dialog instances are up and running

Verify to see if the trace levels are set to minimum/required on ABAP and Java stacks

Mount shared file directories

Driver installation for JDBC/JMS or SOAP adapters

Basis/Infrastructure background jobs

The following set of background jobs need to be activated or scheduled:

SAP_BC_XMB_DELETE_<client> (deletion of XML messages, if not archived)

SAP_BC_XMB_HIST_DELETE_<client> (deletion of history entries)

ARV_BC_XMB_WRP<date> (archiving of XML messages, if not deleted)

ARV_BC_XMB_DEL<date> (deletion of archived XML messages, if not deleted)

SXMS_DELAYED_MSG_PROC<client> (job for delayed message processing, only if is used)

ARV_WORKITEM_WRP<date> (archiving of work items, only if ccBPM is used)

ARV_WORKITEM_DEL<date> (deletion of archived work items, only if ccBPM is used)

SWWERRE (restart of erroneous ccBPM process, only if ccBPM is used)

SWWDHEX (monitors deadlines of ccBPM processes, only if ccBPM is used)

SWWCLEAR (deletion of job logs, only if ccBPM is used)

RSXMB_RESTART_MESSAGES (automatic restart of erroneous, asynchronous messages)

RSWWWIDE (deletion of work items, if not archived, only for ccBPM)

RSWF_XI_INSTANCES_DELETE (deletion of archived work items, only if ccBPM is used)

SXMS_PF_REORG (reorganizes performance data)

EAI Playbook 90

Continues Evolution

SXMS_PF_AGGREGATE (aggregates performance data)

SXMS_REFRESH_ADAPTER_STATUS (refresh of outbound adapter status, only if the IDoc adapter and BPE are used)

RSALERTPROC (deletion of alert and alert logs from database)

RSALERTPROC

SXMS_PF_REORG

RSXMB_DELETE_MESSAGES

SXMB_DELETE_HISTORY

XMS_PF_AGGREGATE

SAP PI instance/profile parameters

The following instance parameters can be set by the Basis/Infrastructure team:

Parameter Value Description

abap/arfcrstate_col_delete X Activates deletion of ARFCRSTATE records in background. Forces report RSTRFCEU to run in batch periodically every five minutes (see SAP Note 539917)

gw/max_conn 2000 Sets maximum number of active connections (Gateway)

gw/max_overflow_size 10000000 Sets size of local memory area for Gateway

icm/HTTP/max_request_size_KB 2097152 Maximum size of HTTP request accepted by ICM

rdisp/appc_ca_blk_no 2000 Sets TCP/IP communication buffer size

rdisp/force_sched_after_commit no Disables automatic rollout of context after commit work

rdisp/max_arq 2000 Maximum number of internal asynchronous messages

rdisp/max_comm._entries 2000 Sets maximum number of communication entries

rdisp/rfc_max_own_login 90 Sets RFC quota for own logins

rdisp/rfc_max_own_used_wp 90 Sets RFC quota for own-used work processes

Simple Mail Transfer Protocol (SMTP) and SCOT configurations

The SAP Office emails are configured through SMTP. The transactions used to configure the same are SOST and SCOT. SAP basis needs to configure and validate these settings.

Purge messages in PI

Before a PI box is handed over by BASIS for data loads or Interface execution, a validation needs to be performed by BASIS on the available messages on the PI box.

In case messages already exist on the PI database, the database needs to be purged and cleaned up.

Apply Archiving and Deletion settings

SAP basis needs to apply the message archiving and deletion setting on the both the PI ABAP and Java stacks.

The archiving parameters (e.g., duration to archive) is governed by business needs.

EAI Playbook 91

Continues Evolution

Configure Integration Engine/Server

The Integration Engine is a runtime environment of SAP NetWeaver PI. The integration processes involved can take place between heterogeneous system components within a company as well as between business partners outside company boundaries.

As a PI runtime component, the Integration Engine has the task of receiving, processing, and forwarding XML messages. During message processing, collaboration agreements are evaluated, the receivers are determined, and mapping activities are executed.

The individual processing steps are called pipeline services and are defined in pipelines. It is the task of the Integration Engine to process these pipelines correctly and consistently.

To guarantee this, the Integration engines on various SAP systems, like SAP ECC, SAP CRM, and SAP SRM, need to be configured accordingly.

This is done via the transaction SXMB_ADM. The core parameters that need to be configured are:

Maintain ‘Role of Business System’ as Integration Engine.

Maintain Integration Engine URL.

Check Specific Configuration for categories ‘DELETION’/’MONITOR’/’PERF’/’RUNTIME’/’TUNING’/ - LOOK NOTE.

All custom software component versions are available in SLD.

Configure SXMB_ADMIN for Payload accessibility in SXMB_MONI.

Set up logging and trace levels.

Set up receiver/sender IDs via SXMSIF.

Set up parameterized IS URLs.

Maintain archiving and deletion Jobs.

Register queues in PI as well as satellite systems, like ECC, SRM, and CRM. Also, verify the queue priority settings, if used.

EAI Playbook 92

Continues Evolution

Import transports

The final step to be executed by basis is to import transports into the PI builder or the ESRs.

Various mechanism used for the transports are CTS+, file based, etc.

Development team tasks

Activate Transports

Unlike ABAP transports, which get automatically activated when they are imported into a target system, PI transports specifically ID transports need to be activated manually as the communication details do not get transported. This is due to the reason that the communication details are different on each environment.

The ESR transports are similar to ABAP transports and do not need any manual activation.

Lets us take an example where CTS+ is used to manage transports.

To activate an ID transport, go to the target system Integration directoryToolsFind Transports. All the transports imported into the system would be displayed on to the right side.

EAI Playbook 93

Continues Evolution

All the transports imported into the system would be under the transport user NWDI_CTSADM. To activate the transports, the required work list under user NWDI_CTSADM needs to be transferred on to the user activating them.

Configure communication details

The details that need to be maintained in the communication channels need to be collected prior to the cutover. This task is part of the system build activity. The following examples show the type of information required to be determined for common integration patterns:

EAI Playbook 94

Continues Evolution

Examples:

Communication channel using a file adapter:

Details that are required would be the FTP folder/directory, FTP server/port details and the user name/password, system dependent OS commands, etc.

Communication channel using a JDBC adapter:

Details that are required would be the connection parameters, the user name/password, SQL statements, etc.

Deactivate and activate communication channels

To avoid any accidental transfer of data from/in to SAP prior to Go-live, all the channels are to be deactivated. This should be done as part of the configuring the communication details task under Section 6.2.

EAI Playbook 95

Continues Evolution

The channels (interfaces) should remain inactive, unless a go-ahead is given as per the deployment plan.

This could be either done at the integration director level as shown below or the RWB.

ID setting: Most of the Java-based adapters have a setting within the communication channel configuration for activation or deactivation. This setting should be marked as inactive after the initial system build.

The RWB components provide the following options for channel deactivation:

Deactivation via manual control

Deactivation via External control

Validate partner profiles

Validate all the partner profiles in the source and the target systems of SAP using WE20 transaction. The inbound/outbound parameters along with message controls should be validated.

EAI Playbook 96

Continues Evolution

Smoke/Connectivity testing

A Smoke test is a basic connectivity test that can be conducted in a newly build PI environment. This test is done without posting any data from SAP or into a SAP system and certifies connectivity configurations in PI.

The following are a set of sample patterns that can be used for smoke testing:

Connectivity Test Patterns Testing Process

SAP to PI using Proxy 1) Through validation of RFC connections.

2) Send out dummy message from ECC using transaction SPROXY and stopping the queue on target. The message needs to be archived/purged after the tests.

PI to SAP using Proxy Through validation of RFC connections.

SAP IDoc to PI Generate a dummy IDoc in ECC via transaction WE19. The message and IDoc needs to be archived after the test is successful. The queues/communication channels on PI should remain as inactive during the tests.

Third party to PI Java-based adapters like SOAP, JDBC, JMS, and FILE can be tested via the communication channel status on the RWB.

These tests are typically conducted by the development teams. It should also be noted that the smoke testing needs to be done in a very controlled environment. This is to avoid posting of any data in SAP or non-SAP system before the designated date.

EAI Playbook 97

Continues Evolution

Continues Evolution

Interface monitoring approach and strategy

The capabilities for central monitoring with SAP NetWeaver PI are offered through the specific PI WorkCentre in SAP solution manager. Going forward, SAP solution manager will be the recommended platform and tooling for central monitoring of complex, distributed multidomain PI landscapes. The main central monitoring capabilities include overview monitor, message monitor, component monitor, channel monitor, all integrated with SAP solution manager E2E monitoring and alerting framework, and Information Technology Infrastructure Library (ITIL)-based processes for incident management and notification.

All these along with increased connectivity options, improved local monitoring, and fault tolerance lead to considerable reduction of total cost of operations for SAP NetWeaver PI 7.3.

Introduction

SAP is continuously introducing latest innovation on each and every product. As we already know that from SAP PI 7.3, we have the option to install stand-alone Java-only component for PI. Last week, SAP released SAP PI 7.4, which optimized for dealing with HANA DB. SAP already released the solution manager 7.1 on HANA, which is similar to SM 7.1 SP08.

As customer, we have been learning the new features added to PI 7.3 Monitoring and also identifying how those new features are getting impacted on solution manager 7.1 SP7. Through this blog, I could like to share what are the possibilities available on Central PI monitoring in solution manager.

Available from

Central PI monitoring (PIMON) is one of the new features from SM 7.1 SP 0 onwards (applicable for SAP PI 7.1 SP6). It is like other functionality in Technical monitoring WorkCentre, but from SAP PI SP 7.3, it has some more improvements. Entire enhancement in PI monitoring part of solution manager goes along with PI NW version. With PI 7.3, the entire PI monitoring in solution manager highly integrated with integration engine process monitoring. From PI 7.3, you can directly view the PI monitoring dashboards available in Technical WorkCentre of solution manager 7.1. You can get the details here monitoring — What’s New in SAP NetWeaver 7.3 (Release Notes) — SAP Library.

Time... is now!!

We are currently using PI monitoring from Runtime Workbench (RWB) and very few interface monitoring with respect to solution manager, but we felt it is the perfect time to get with central PI monitoring solutions available in SM 7.1 SP7.

RWB is one of the local monitor (other local monitors for PI are SXMB_MONI), which have been used in decades, its only help to monitor the individual PI domain or we can go ahead with typical NWA as CEN system based on Computing Center Management System (CCMS)/RFC-based monitors. These local monitors also have been enhanced from time to time for each release of PI. Can be reviewed some of the enhancement with screen shots here SAP PI 7.3 New Local Monitoring Tools

Though you can get lots of enhanced features in local monitors, but using RWB, we cannot monitor the message processed in new AEX (Java-only stand-alone installation option for SAP NetWeaver PI 7.3). In such

EAI Playbook 98

Continues Evolution

systems, monitoring can be done via Central PIMON Solman, local NWA for PI. JAVA alone PI is very light application and moreover cost-saving approach instead of installing the entire NW PI, which is compatible with solution manager PIMON in SM 7.1., since Technical monitoring is purely based on Solution Manager Diagnostic (SMD) agents.

We do use BPMon Interface monitoring PI-related key figures. But again this is not covering other features like component and message monitoring.

Another reason we could go for Central PIMON in solution manager, instead of typical monitoring approach, it is monitored centrally in one place, can be direct to the root-level cause of the problem, or reporting by integration of other solution manager cabalists like RCA and ITSM.

If we look into the configuration perspective also, PIMON setup can be done via self-guided wizards, which is a better approach than NWA or BPMon, where we need to go for some steps manually.

And I could say all the issues that we faced with respect to the PI monitoring are already identified and corrected. Delivered in Wiki, PiMon_Home — Technical Operations — SCN Wiki. Couple of weeks before we successfully completed our PIMON monitoring setup with minimal effort.

Customers’ view

After the implementation, our customers are also delighted, and they commented that two things they liked with PIMON in solution manager, they are central dashboards and easy navigation approach.

 

Central PI monitoring available in solution manager helps to monitor components, channel, message, and in addition we can also have the message search scenarios. Using central user-defined message search — Technical Operations — SCN Wiki

EAI Playbook 99

Continues Evolution

Pleasant Dashboard view of PI monitoring

Detail navigation for each nodes

EAI Playbook 100

Continues Evolution

Channel monitoring navigation

Defect and change management

Change management is a vital process to control development life cycle of software, starting from product design and development to production deployment.

During product development phase and even after production go live, product has to undergo changes, enhancements, and bug fixes. Tracking of these changes is very important and crucial task for organizations. Correct, authorized, and properly documented changes needs to be implemented.

SAP ChaRM (CR Management) provides change management capabilities and enforces standardized approach to achieve these activities. SAP ChaRMis SAP solution manager-based tool, which provides tracking and documentation of all CR and transports for business solution development in an organization.

In this post, we will focus on different ChaRM approaches in SDLC.

A typical CR process is initiated by a business user via service help desk. Help desk assigns CR to respective manager where manager validates request to take further action.

Manager validates if request is valid.

Manager assures, CR is approved by business logically and financially.

Manager assigns CR to developer and tracks all changes from DEV to PRD system.

EAI Playbook 101

Continues Evolution

Standard CR process for development/enhancements

New requirement/correction request by the business user

This requirement is validated by the change manager

– The change manager provides information on effort, duration, and cost for this CR

After approval of the CR, the CR is accepted by the SAP development team

– SAP Functional team provides the functional specifications and test cases

– SAP customizing is conducted (if needed)

– SAP ABAP development is conducted by the ABAP development team

– Unit testing is performed by the SAP team

The CR is created as a SAP Transport, and moved to SAP Quality system

– Testing is performed by the SAP testing team.

If defects found by SAP testing team, the CR is moved back to SAP development team.

Testing is performed by the business user

– If new change or additional requirement is requested by the business user, the CR is moved to the

SAP development team

After testing, the CR is approved by the change manager for production.

– The transport is moved to SAP Production system

The CR is closed.

EAI Playbook 102

Continues Evolution

Handling bug fixing, issues, and user changes

This type of CR is also handled in same way as mentioned in above section.

EAI Playbook 103

Continues Evolution

Urgent changes

These types of changes are directly conducted on the SAP Production system for the following cases:

Example

Screen text translation

SM59: System connectivity configurations

Functional configurations, such as number range configurations, etc.

EAI Playbook 104

Continues Evolution

Outage processes

Planned outage processes

EAI Playbook 105

Continues Evolution

Unplanned Outage Processes

EAI Playbook 106

Continues Evolution

Best practices to avoid unplanned downtime

EAI Playbook 107

Continues Evolution

Possibilities to secure a SPOF

Possible high-availability setups for SAP NetWeaver 7.0

EAI Playbook 108

Continues Evolution

General recommendation

Release management

Purpose

You can use release management to summarize functionally related change states for components of a release order product. You can use workflow management to assign the release order to several employees, so that these employees check the completeness and consistency of the change states, and then release these change states for further processing. The release can involve several stages.

SAP workflow management is used in release management.

Introductory notes

Implement release management if your products consist of many components, and you use the SAP change management to document changes.

In the SAP-standard system, you can use release management for change states of item variants and color variants in Integrated Product and Process Engineering (iPPE).

Integration

You use iPPE. Release management was realized for the release object type Change State of Item Variant or Color Variant in iPPE. However, you can also program your own release object types.

For more information, see the section “Notes for Implementing Your Own Release Object Types.”

EAI Playbook 109

Continues Evolution

Features

You can configure release management variably. Your release process can involve one or more levels. Every level can be assigned to one or several users that are responsible for the release.

The change states that the users are to check and release are collected for release orders.

In a release order, you create change states that are functionally related.

You can issue a release order as well as cancel it.

EAI SW upgrade/update processes

Decision factors

This unit lists important decision factors, including background description and rating support. The three most important — exclusive decision factors — are listed at the beginning. If your environment allows an upgrade in principle, the following subsections listing IT/operations-related and interface/scenario-related decision factors provide more insights into what needs to be considered:

Alongside these factors, your customer-specific environment and project and IT setup might dictate other critical points that should also be listed and rated for your project decisions. The following diagrams show our ratings in orange for each decision factor related to the questions that have to be answered. This can, but must not necessarily, be correct for your project. We recommend that you discuss these factors during the initial project phase within your team of experienced XI/PI consultants.

EAI Playbook 110

Continues Evolution

Below is a checklist that you may use for reference once you have read the details of each factor. Note, that most of these questions do not have a simple yes or no answer and other factors (such as your current release version) might influence the conclusion drawn from the answers, so please read through the details first before you go through the checklist.

Exclusive decision factors

If one of the following three exclusive factors points your environment toward a new installation and phase-out option, you can stop here in the document and start with preparing your project for the only available option: In your case, the installation of SAP NetWeaver PI 7.3.

EAI Playbook 111

Continues Evolution

Usage type

If you are running usage types like Business Intelligence (BI), Composite Environment (CE), Portal (EP), or Development Infrastructure (DI) in addition to PI in your productive system, then an upgrade can only be executed if the other usage types are upgraded at the same time. Note, however, that running multiple usage types with PI 7.3 is not recommended.

In this case, you must ensure that the other usage types are available, that they have an upgrade path to NetWeaver 7.3, and that your team is ready to upgrade them. This means that if you are running BI or CE with custom development that these applications have been vetted in the new version and are ready to be upgraded. As described above in Section 3.2, if you have a lot of custom development you should isolate the migration of the development to the new version from the upgrade.

SAP does not currently support a staggered approach to upgrading SAP NetWeaver when multiple usage types are in use, so you will have to upgrade all usage types at the same time. For this reason, SAP recommends that you perform a new installation with phaseout as opposed to an upgrade in most circumstances.

This current release restriction might be eliminated with future availability of the complete SAP NetWeaver stack, therefore, you should check for an updated version of the SAP Note 1407530 “Release Restrictions for SAP NetWeaver 7.3 — PI.”

PAM compliance

Check the Product Availability Matrix (PAM) for the supported operating systems and database releases running SAP NetWeaver PI 7.3 by first going to http://service.sap.com/pam and then searching for “SAP NetWeaver 7.3.”

Starting with SAP NetWeaver PI 7.1, only 64-bit operating systems are supported. If your productive system is currently still running on a 32-bit operating system, you will have to do an OS migration of your productive environment before you can technically perform an upgrade. As this additional step has to be considered for your project as an additional downtime phase of your productive system, you might be better off with a new installation on newer (faster) hardware instead.

However, you can first perform the OS migration of your productive systems by system copy mechanisms followed by an upgrade, if the additional downtime is acceptable for your business. The same argument is valid where your underlying database release is no longer supported with SAP NetWeaver PI 7.3.

EAI Playbook 112

Continues Evolution

Downtime requirements

For planned downtimes requirements to your productive XI/PI system, you will certainly have to set up a SLA with your business departments relying on the middleware.

Depending on the maximum-allowed planned downtime (in hours), you might not have the option to go for an upgrade at all. Based on our experience, a well-prepared technical upgrade can be achieved with a downtime of up to four hours. The downtime of a PI system depends greatly on the existing runtime data, such as the number of active messages in the DB tables. Additional downtime, independent of SAP software, could include taking care of the OS, including Network/FTP and DB patches. We calculate for up to eight hours of manual rework after the technical upgrade, which includes changes to integration.

Directory objects, such as communication channel adjustments or required maintenance to activate newer features like message packaging. The technical upgrade procedure itself is already divided into an online preparation phase, where a parallel system environment with a new SAP JVM and more is created for your running system, followed by an minimal offline upgrade phase, which is used to reduce the actual upgrade downtime to a minimum — but you still need to execute manual steps afterwards to get everything up and running again.

If during an upgrade you suspect that it will exceed the maximum downtime allowed, you might have to decide at a predetermined moment in time whether to finish the upgrade, even if it is running longer than expected, or to restore the system and schedule another time for the technical upgrade of your system. During the preparation phase of the upgrade, you should have been able to calculate an estimated downtime for your productive system and, depending on the calculated downtime and the downtime requirement, you would have been able to work out if they fit or not.

If your business does not allow for more than one business day downtime (eight hours), our recommendation is that you consider installing a new PI 7.3 system and keep your old productive system running whilst all interfaces are manually redirected. In this situation, it would even be possible for you to switch interface scenarios back from PI 7.3 to the old environment if you were to encounter a critical showstopper situation with the new interfaces on PI 7.3, which you had been unable to detect during the validation phase.

Note, if you are performing an update from PI 7.1 or EHP1 for PI 7.1, then the downtime is normally less than the estimates given above, so keep this in mind when evaluating your maximum allowable downtime.

EAI Playbook 113

Continues Evolution

IT/operations-related decision factors

High-availability setup

We assume that you have already configured a reliable high-availability setup for your mission-critical middleware system. Starting with SAP NetWeaver 7.0, SAP introduced a new option for configuring SAP NetWeaver systems using the ABAP Central Services, which can now be separated from the central instance in parallel to the SCS for Java. Each stack (ABAP and Java) has its own Message Service and Enqueue Service. For ABAP systems, the Central Services are referred to as ASCS and for Java systems the Central Services are referred to as SCS. The ASCS and the SCS are leveled as SPOF and, therefore, require a high-availability setup.

Previously, the only supported configuration was the ASCS that was integrated within the ABAP central instance — and, therefore, the ABAP system central instance also needed a HA setup. In the graphic above, this setup is represented with SCS/CI on the right side.

For PI 7.3, we recommend that you setup the system using the ASCS/SCS only. If you have already made the configuration changes to your productive XI/PI landscape, an upgrade will cover the features to PI 7.3. If your old system is still running on SCS/CI, you might want to start with a new PI 7.3 installation using the new configuration option for the ASCS/SCS HA setup from the very beginning.

Auditing requirement

Do you communicate business relevant data directly from your productive XI/PI system to external customers and partners? Is your business using payload modification on XI/PI? Do you create completely new messages in XI that cannot be reproduced outside of the original sending systems, due to temporary data retrieval?

If you answer ‘yes’ to any of these questions, we assume that you have a high level of demand for storing and making sure the messages processed and transferred via the XI/PI system are available to your business teams, and even to external auditors. In this case, you have a high requirement for storing historical message and message processing data of your productive system. Therefore, you should consider upgrading your environment, as this will best enable you to retain this historic data.

Alternatively, you have to keep the latest backup of your productive XI/PI system on hand and ensure that, if business needs require access later on, the system could be rebuilt and access to the message relevant data could be provided.

EAI Playbook 114

Continues Evolution

If you have mostly internal communication going through your XI/PI system, or you use an additional EDI adapter for external communication that takes care of archiving and access issues, you might not be interested in historical data at all. In this case, you do not require audit-relevant information, but your business might still need to know about messages processed weeks ago. In this case, you have to rate how important the history data of messages processed in your productive XI/PI system is to you and your business.

Basic and operations customizing

“How intensively have you already built an operational backbone around your productive XI/PI system?” That question is the target of this criterion. Have you already integrated your XI/PI system tightly into your monitoring landscape? For example, does it consists of solution manager, Central Monitoring systems, and Firewall/DMZ settings? In this case, you might not want to invest again into the necessary configuration steps to set up a parallel new PI 7.3 system. Instead you want to use the existing configuration and simply upgrade your existing XI/PI system. Nevertheless, if you are planning on migrating to the new Solution Manager Central Monitoring, then much of the customization will be replaced by, or have to be modified for, the new monitoring. In this case, even if you do have a lot of customization, you might still be better off with a new installation. However, if you did not yet invest too much into the configuration, you might consider the effort acceptable to start from scratch and integrate, or start building, a new monitoring environment around your new PI 7.3.

Basis objects, such as alert configuration (alert categories and alert rules), interface archiving settings, and so on, can be transported to ease the transfer efforts. Other configuration changes, such as changes to the instance profiles and JEE properties, have to be reconfigured manually in the new PI 7.3 system.

Third-party adapters and content

SAP and software partners are taking efforts to ensure that the third-party adapters certified with older releases are also certified for PI 7.3 (this includes the Java-only Advances Adapter Engine Extended, also known as the AEX). SAP offers the solution catalog to check for software that has already been certified (http://www.sap.com/ecosystem/customers/directories/SearchSolution.epx). Additionally, you can contact the software provider to see how far they are with the PI 7.3 certification of theirs adapters.

One possible option for overcoming the nonavailability of these solutions for PI 7.3 would be to install a noncentral Adapter Engine (or Advanced Adapter Engine if you are currently using PI 7.1) in the productive XI/PI system that would contain the third-party adapters. You would then change the communication channel

EAI Playbook 115

Continues Evolution

configuration and have them point to the noncentral Adapter Engine for execution, instead of the central Adapter Engine used previously. Next, you would upgrade the XI/PI system and keep the noncentral Adapter Engine on the old release for the time being, before the third-party adapters are available for PI 7.3, as well. More information about this intermediate solution using a noncentral Adapter Engine can be found in the release notes of SAP NetWeaver PI 7.3: What’s New in SAP NetWeaver 7.3 (Release Notes)>Process_Integration>Advanced_Adapter_Engine

Alternatively, you could decide to keep the scenarios using the third-party adapters running on the productive XI/PI system, and plan to investigate later into time and resources for redirecting the relevant interfaces completely to the newly installed PI 7.3 systems. Our recommendation, as listed above, is for a new installation of PI 7.3 whilst keeping the scenarios running in the productive system for now.

The same facts apply for delivered and certified XI content.

EAI Playbook 116

About DeloitteDeloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee, and its network of member firms, each of which is a legally separate and independent entity. Please see www.deloitte.com/about for a detailed description of the legal structure of Deloitte Touche Tohmatsu Limited and its member firms. Please see www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte LLP and its subsidiaries. Certain services may not be available to attest clients under the rules and regulations of public accounting.

Copyright © 2014 Deloitte Development LLC. All rights reserved.Member of Deloitte Touche Tohmatsu Limited