Configuring Scenarios in the ESR Browser

In order to develop a Java proxy, we will need to use SAP NetWeaver Developer Studio (NWDS) as the IDE.

While implementing a Java proxy, you will need to switch SAP NWDS to the Development Infrastructure perspective. In this perspective, you will need to create a number of development components (DCs).

The role of the Enterprise Services Repository (which we refer to as the ES Repository) within the context of an enterprise service bus (ESB) such as SAP PO, is to maintain specific operational metadata about the services that SAP PO provides and consumes. The ES Repository provides developers with a complete modeling environment for creating SOA style enterprise services.

The ES Repository supports the design time in SAP PO and stores metadata related to the services’ versions, namespaces, deployment status, access and security rules, mapping and transformations, service operations, data and message types, and external message definitions, such as Web service (WSDL) and XML definitions (XSD).

The ES Repository is also used to import and maintain SAP standard content (ESR content), provided as part of different SAP (industry) solutions or by certified third-party software suppliers. The ESR content is also called business content and can be downloaded via the SAP Support Portal. You will need proper SAP Support Portal credentials in order to download any content. The business content imported into the ES Repository normally contains repository objects, such as service interfaces and messages types, but it can also offer additional content, such as mappings, integration processes, and so on. The ES Repository may also use external sources from other third-party repositories (Services Registry needed), such as existing UDDI directories and Active Directory.

One of the challenges we commonly encounter as SAP integration specialists is how to explain what the roles and functions of the different products contained within the SAP NetWeaver suite to nontechnical and business folks. After many years of dealing with this challenge, we have found a simple yet effective way of achieving that goal by using analogies from our daily lives. Explaining the Enterprise Services Builder (ES Builder) is no exception.

Here’s how it works: Try to picture a large, blue, plastic bucket filled with lots of building pieces, all of them in different colors, shapes, and sizes. Now, imagine that you are building an airplane or any other object you would like to build with building bricks. When you have that picture and the process of designing and assembling new objects using different building blocks clear in your mind, you are more than halfway to understanding what the function and role of the ES Repository really is. The building bricks in the bucket are similar to the ES Repository. When you start building your new creation by searching, selecting, and assembling different building bricks, it is similar to using the ES Repository Builder to build new service interfaces by creating or reusing repository objects stored in it.

In SAP PO, you have the option to configure one local ES Repository per SAP PI instance (which is the default setup) or to have a central ES Repository connected to all SAP PI systems that are available in your system landscape. We discuss these options in the following subsections.

With this option, each SAP PI instance within the system landscape has its own dedicated ES Repository directly connected to the "local" Integration Directory and runtime engine (AEX). The advantage of this setup is in its simplicity and that there is less initial installation effort required from SAP Basis team.

In this setup, a single ES Repository is hosted on the central SAP PO instance. The Integration Directory and the runtime engine (AEX) of the local SAP PO instance are directly connected to the central ES Repository. The advantage of this architecture is that you can minimize total cost of ownership (TCO), because the number of ES Repositories is reduced. At the same time, you save time by removing the need for transport scenarios and administration tasks.

We use the ES Builder to access and create content for the ES Repository. It can also be seen as the implementation of the ES Repository and a core component of SAP PO. The ES Builder is a development tool with which you design and develop logical building blocks to support integration applications that follow SOA principles. Object types created in the ES Builder are stored and maintained in the ES Repository.

Enterprise Integration Patterns (EIP) help in solving recurring problems faced in the integration of enterprise applications.

Most patterns consist of a mix of SAP PI Integration Flow (iFlow) configurations and SAP Business Process Management (BPM) process implementations. That is, they rely on the power of SAP Process Orchestration, which combines both of these technologies.

The figure, Patterns by Category, shows all the patterns offered by SAP BPM.

Patterns can be differentiated between stateful and stateless patterns, as shown in the figure, Pattern States and Availability.

Stateless patterns can be implemented either as Integration Flows on PI (AEX) or as processes in BPM. As a general guideline, stateless patterns are best implemented as Integration Flows on AEX. This applies especially if the integration process consists of a single pattern only and no additional business logic is executed in the Process Orchestration system (that is, a pure ESB scenario). In such cases, the overhead of starting, executing, and completing a BPM process instance is typically very prohibitive. If the pattern is part of a larger business process involving multiple integration or workflow patterns, it could be implemented within SAP BPM, as the overhead costs become less relevant in the overall scenario.

Connectivity PI and SAP BPM

SAP BPM now supports the XI 3.0 protocol for service endpoints (configurable on the service reference). This means that messages can be sent reliably between PI to BPM.

The message received by PI will be processed by the Java Proxy Runtime (JPR), which delivers it via the Web Service Runtime (WSRT) to BPM. The message could start new process instances or trigger intermediate message events in BPM. The message will be discarded if it does not match either a process start interface or an intermediate trigger.

Outbound communication (automated activity triggering a message) happens in a similar way. Here the sender component name can be specified in the service configuration in BPM.

A process uses the Conditional Start feature if the same message trigger is used in the start event and in at least one intermediate message event of the process. In BPM, a Web service endpoint is represented by a reusable message trigger. The start condition and the correlation condition can be independently defined. Usually, the correlation condition is a more specific variant of the start condition.

In the conditional start use case, a new process is started only if there are no running processes that match the correlation condition of the incoming message. The start event is not directly triggered by the message. First, the matching evaluation is done and if there is no running process, the process start for the active version is initiated. That means, all messages that come in at any point in time will then be received by exactly one process instance.

For a running instance of a conditional start process, messages with matching correlation criteria will be received by the intermediate message event. If there is no running process instance with matching correlation criteria, the message will be received by the start event, given the start condition is satisfied, thereby spawning a new process instance.

A content enricher pattern is a message transformation pattern. It is a stateless pattern and is available with NetWeaver 7.3, SP4.

Enterprise Integration Patterns (EIP) are design patterns that help in solving recurring problems faced in the integration of enterprise applications. One of the message transformation patterns is needed if the target system requires data fields that the originating system cannot supply. In numerous integration scenarios, for instance, System B needs additional data that System A has not provided. Such instances are tailor made for the Content Enricher pattern. It has the ability to look up missing information or compute it from the available data. The Content Enricher allows you to communicate with another system if the message originator does not have all the required data items available.

As a service technician, Kevin's daily job is to visit customers for servicing and repairs of appliances. His supervisor Emil wants a summary of the tasks each of his technicians worked on during the day. For each of his technicians, Emil gets a daily report of customers visited and tasks undertaken. He would like to get better insights into the kinds of service calls conducted by his technicians than that, what is already provided in the daily report.

Emil wants a list of all visited customers (including name, address, phone number, issue or regular service, and service date and time) served by Kevin on that particular day. Emil will input Kevin’s employee ID to the process and the requisite details would be retrieved from the system.

The figure illustrates the architecture of the content enricher pattern.

The Content Enricher helps gather additional information from a system using the available information. In this example, Kevin enters his direct report's ID into Business System S1. A generated message in SAP Process Integration (PI) (AEX) is delivered to SAP BPM (Inbound).

Web service calls in SAP BPM aid in looking up additional information based on the ID and the enriched message from SAP BPM (Outbound) is relayed through Integration Configuration 2, eventually providing Business System S1 with the requested information.

As shown in the figure, An Integration Scenario for the Content Enricher Pattern, the following integration scenarios exist:

• Integration Configuration1 (ICO1) – A message flow can be triggered in Business System S1 that flows through SAP PI (AEX) to SAP NetWeaver BPM.

• Integration Configuration2 (ICO2) - To send the enriched content back to SAP PI (AEX) from SAP BPM and store it as a file in your specified folder using File adapter.

For creating the Content Enricher pattern in NetWeaver Developer Studio, the following prerequisites apply:

1. The service interfaces to be used in the process model–starting interface and automated activity–should be created first and then imported from the SAP PI ES Repository.

2. For testing the BPM Process from the BPM Process repository, the UME action SAP_BPM_TRIGGER_EVENT should be assigned to the specific user role.

The steps for modeling the process are enumerated as follows:

1. The pattern starts with a service interface.

2. An Employee ID is provided as input to the system.

3. A Web service call retrieves the order list (List of Order IDs).

4. The order details are then retrieved for each Order ID using Web service calls.

5. These details are consolidated and a summary (the enriched content) is returned to the sender system.

The aggregator pattern is a stateful filter that is used to analyze and store input messages until a complete set of (related) messages are received. It can then produce a single refined message from the messages that were received. It is used in cases where subsequent message processing is contingent upon the successful processing of multiple input messages.

Dealing with asynchronous messaging systems presents challenges like correlating the messages, particularly since the incoming messages may arrive in any order. While some of the other routing patterns can be stateless, the aggregator needs to store each incoming message until the set of messages is complete for further processing. The aggregation is limited to a completion condition, either time bound or quantity bound.

One division of the company manufactures stationery supplies like colored pencils and graphite writing pencils. Graphite pencils are manufactured and placed into bins on a conveyor belt so that they can be packed by a machine. Each package contains 10 graphite writing pencils. The company would like to increase throughput without compromising on quality.

The aggregation is not dependent on the order of messages received, which means the Aggregator may receive related messages at any time (within a reasonable limit) and in any order. Each time the Aggregator receives a new message, it should check if the message is part of an existing aggregate and create a new aggregate if a related aggregate doesn't exist, and then add the message to the appropriate aggregate.

In our example for the graphite writing pencils, we need to aggregate a set of 10 pencils. The pencils are collected into the next bin and once the count reaches 10, the bin is conveyed to the machine that packages them.

This example deals with these three integration configurations:

• Integration Configuration1 (ICO1) – A message flow can be triggered in Business System S1 that flows through SAP PI (AEX) to SAP BPM.

• Integration Configuration2 (ICO2) – For triggering intermediate message(s) that flow to SAP BPM via SAP PI.

• Integration Configuration3 (ICO3) – For sending the aggregation to SAP PI (AEX) from SAP BPM using a File Adapter.

The steps for modeling the process are enumerated as follows:

The figure shows the iFlow of example 3. This is the description of the process flow:

1. The pattern starts with a service interface with the message counter reset to zero.

2. As long as the counter is within defined bounds, incoming message(s) that match the correlation key are collected.

3. The message counter is incremented for each collected message (matched correlation key).

4. Once the counter has met the completion condition, all the collected messages are processed (aggregated) and this aggregation is sent to the receiver.