4    Working with the Enterprise Services Repository and Registry

Look up at the stars and not down at your feet. Try to make sense of what you see, and wonder about what makes the universe exist. Be curious.
                                                                                             —Stephen Hawking

The Enterprise Services Repository (which we’ll refer to as the ES Repository) is a one-stop shop for designing and developing integration solutions enabled for service-oriented architecture (SOA) and based on SAP Process Orchestration (SAP PO). The ES Repository is the central area in which you design, build, and maintain the logical building blocks that are used to create new integration scenarios during configuration time. It’s designed around a model-based architecture, which means that service interfaces are designed using the underlying information model and the business processes providing or consuming them. Because of this strategy, services created in the ES Repository can be maintained and extended in a flexible manner during the lifecycle of the systems and business processes that use them. This approach adheres to one basic principle of SAP PO, which is to decouple the business semantics from the technical aspects of the physical system landscape.

Note

Since the introduction of early versions of SAP Exchange Infrastructure (SAP XI) and SAP Process Integration (SAP PI), the term Integration Repository applied to most functions provided today by the ES Repository. To be consistent with the new terminology, we’ll only use the new terminology as used by SAP: Enterprise Services Repository (ES Repository) and Enterprise Services Builder (ES Builder).

In this chapter, we’ll first discuss the technical basics of the ES Repository. Then, we’ll dive into some of the most important components and explain how to use them. We’ll carry on with this journey through the ES Repository with the assumption that you’ve previously configured the System Landscape Directory (SLD) and that you’ve already created the necessary products and software component versions (SWCVs), as described in Chapter 3. If that isn’t the case, then you can still take a look at Chapter 3, in which the concepts and tools of the SLD are further explained. If you’re totally new to SAP PO, then we recommend that you gain that knowledge first because we’ll be applying some of those concepts during design time. This chapter ends with a practical exercise focused on the ES Repository online.

4.1    Basic ES Repository Technical Concepts

Before we discuss the specific components of the ES Repository, we’ll discuss the main functional blocks and then move on to the central role played by service interfaces in all phases of any SAP PO integration scenario.

4.1.1    Functional Blocks

The ES Repository is made up of two main functional blocks in SAP PO: the ES Builder, which is where you execute the majority of the design-time activities, and the Enterprise Services Registry (ES Registry), which (as mentioned in Chapter 2) can be seen as the yellow pages of services, a directory in which service interfaces are published by service providers and discovered by service consumers (see Figure 4.1).

Figure 4.1    ES Repository: Components Interaction

We already discussed the ES Builder in Chapter 2, Section 2.1.1, so we’ll focus on the ES Registry here. The ES Registry centrally stores information about services within an enterprise SOA landscape. The ES Registry contains vital details about the functionality offered by services available in a particular SOA landscape. You can query the ES Registry to retrieve the Web Services Description Language (WSDL) of registered services and their operations and endpoints. Furthermore, services published into the ES Registry can be classified using specific categories, such as their lifecycle status (Released, Configured, Deprecated, etc.), which makes it possible to label services with this information.

The ES Registry is also a central source for SAP PO developers to find available services in their system landscape that they can reuse in integration scenarios. Administrators can find available service endpoints and manage connections between consumer and provider systems. The ES Registry provides support for SAP and non-SAP applications as well as visibility and additional control over the available services in an SOA landscape, providing answers to questions such as the following:

• Which services are available and where?
• What does the WSDL of the available services look like?
• Which services have been modeled but not yet implemented?
• Which services have been configured and can be called?
• Which endpoints are available (secure or nonsecure) for the services?

Normally, after the development of a service interface has been completed, the developer will publish the (new) service interface into the ES Registry so that it can be discovered by service consumers. This procedure doesn’t necessarily apply to all organizations and varies depending on the enterprise integration architecture policies of each organization. However, it should be considered and applied whenever possible because it truly contributes to enhancing the level of service reusability and the SOA maturity level within most organizations. Figure 4.2 depicts the interaction between the individual components of the ES Repository.

From a general SOA point of view, the ES Repository also plays a critical role in providing the foundation of enterprise SOA. It’s a cornerstone component responsible for storing all relevant aspects of service interfaces consumed and provided by SOA applications. Common service details typically stored in the ES Repository include versioning, namespaces, data types, security policies, operations supported, release status, and so on. Within the context of SAP PO, the scope of the information stored in the ES Repository is much broader and richer, as we’ll discover in the next sections.

Figure 4.2    ES Repository: Service Provisioning and Discovery

4.1.2    First Steps in the Enterprise Services Repository

When you open the ES Repository, the first thing you need to do is import the software components (SCs) metadata from the SLD into the ES Repository. You also have the option to create repository objects for testing purposes under a local SWCV. Local SCs don’t depend on data from the SLD and so don’t need to import anything from the SLD. Regular and local SCs are the virtual containers in which you’ll store the repository objects you’ll be building during design time in SAP PO.

There are two main types of SWCVs: those delivered as part of SAP or by third parties as business content (i.e., prepackaged integration solutions) and those that are custom built and that you define in the SLD. In this book, we’ll mainly deal with the second type. However, the import procedure from SLD into the ES Repository is similar for both types. The only difference is that for custom-built SWCVs, we’ll have to create our own repository namespaces, whereas namespaces for business content SWCVs have already been defined by the software supplier. Typical examples of ready-to-use business content shipped by SAP include the ES bundles. An ES bundle offers a set of enterprise services that support a particular business process as part of the SAP enhancement packages for SAP core modules (e.g., SAP ERP Human Capital Management [SAP ERP HCM], SAP ERP Financials [SAP ERP FI], etc.) or for industry-specific solutions, such as Industry Solutions for Utilities (IS-U) or Industry Solutions for Insurance Companies, Claim Management (IS-CM) and Policy Management (IS‐PM).

4.1.3    Service Interface

A service interface in SAP PO is a platform- and programming language-independent interface definition that follows a model-driven approach to define service operations (methods) that will be implemented at a later stage by an SAP or non-SAP application system. A service interface has a one-to-many relationship with the operations it contains.

Depending on the business process and application functionality to be supported by your service interface, it will fall into one of the following categories: inbound, outbound, or abstract.

Service interfaces represent the principle deliverable as a result of the activities performed during design time in the ES Repository. After the service interface is ready, it can be released for proxy generation and further implementation on the application side (e.g., an SAP ABAP or Java backend system). During the process of proxy generation, the following development objects will automatically be created on the application side:

• Proxy development objects (i.e., classes, methods, and data types)
  A service definition for mediated or point-to-point communication using the web service runtime.
• Inbound (service provider)
  You want to expose specific application functionality available on the backend system to service consumers. The consumers of your services can be either other application systems or users. From an SAP PO perspective, the system receiving or processing the requests is the inbound or server (proxy) application.
• Outbound (service consumer)
  You need to consume information provided by an external system from your backend system. The invocation of an outbound service can be either automatically or manually triggered from the backend system. From an SAP PO perspective, the system sending the messages is the outbound or client (proxy) application (see Figure 4.3).

Figure 4.3    Outbound vs. Inbound Service Interfaces

• Abstract (only applicable for SAP PI dual-stack systems)
  A special type of interface used in integration processes, and part of the cross-component Business Process Management (ccBPM) framework. Abstract interfaces can’t be used to generate and implement service interfaces on the backend system. Furthermore, they can only run under dual-stack (ABAP) systems and therefore aren’t applicable for SAP PO Java-only systems.

4.1.4    Integration Patterns: Stateful and Stateless Communication

Each service interface created in SAP PO has an integration pattern assigned to it. This functionality enables developers to build different types of integration scenarios. Currently, four different types of integration patterns are supported in SAP PO, as discussed in the next sections.

Stateful

A service consumer sends a request to a service provider, and the service provider receives and processes the request. If required, the service provider will send an answer back to the service consumer. After the message exchange has completed successfully, the information (status) contained in the request and response messages remains available for the messaging runtime. This is known as stateful communication.

Stateless

Service consumers send their request to service providers, and service providers receive and process the information. If required, the service provider will send an answer back to the service consumer. After the delivery of messages involved in the message exchange has completed successfully, the information (status) contained in the request and response messages is no longer available for the messaging runtime. This is known as stateless communication and is integration pattern you’ll encounter in most integration scenarios.

Stateless (XI30-Compatible)

This integration pattern offers backward compatibility with all existing protocols (up to SAP NetWeaver 2004s) in backend systems that were generated and implemented based on message interfaces. Message interfaces are the predecessors of service interfaces. If you’re migrating message interfaces previously created with the Integration Repository of SAP NetWeaver 2004s into service interfaces in the ES Repository, then they will be assigned to this interface pattern. This particular interface pattern only allows one operation per service interface.

Tentative Update and Confirm or Compensate

This pattern is SAP’s own implementation of the widely known two-phase commit protocol. Its goal is to support atomic transactions executed across distributed systems. From an SAP PO point of view, it makes it possible to enhance the Best Effort (BE) Quality of Service (QoS) provided by synchronous messages to Exactly Once (EO). Technically speaking, this pattern allows you to synchronously distribute information across systems using both QoS BE and EO.

One good example of the application of this type of integration pattern is provided these days by many airline online booking websites. When making a new flight reservation, the customer gets the option to make a prereservation without having to confirm the ticket. That can be handy if you need more time before you decide to buy your ticket. Later on, you can come back to the airline’s website and make the final reservation or even cancel it.

4.1.5    Asynchronous versus Synchronous

From a system integration perspective, information interchanged between systems can be grouped into two main categories: unidirectional or bidirectional. When the information flows from one system to another, and the sender of that information doesn’t expect a direct answer from the receiver, this is asynchronous communication. With synchronous communication, the sender of the information (question or request) expects a direct answer and waits until the answer (also called a response) is sent back by the receiver. This might sound like a very trivial and logical subject, but it’s one of the most discussed topics in system integration architecture and system integration development decisions. Therefore, it’s very important that you’re able to identify whether your service interfaces should support asynchronous or synchronous operations, based on the business process functional and technical requirements. Let’s see how these two different types of communication can be compared with our daily lives in the following subsections.

Asynchronous

A good example of asynchronous communication from our daily lives is interaction in social media platforms, such as Facebook or Twitter (see Figure 4.4). When you send a tweet to your followers, you don’t necessarily expect an answer from your followers. However, if you do expect an answer, then it might take some time before you see the reactions in your lists of tweets.

Synchronous

The analogy we always use to explain synchronous communication is quite simple but very effective (also shown in Figure 4.4). When you call someone on the phone, you expect a direct answer from the person you’re calling on the other side. If the person doesn’t answer the phone, then you might try one more time, call at a later time, or maybe leave a message on his voicemail system. This last option, in turn, is a good example of buffering messages on the receiver side for later processing, as we’ll explain in the next section about QoS.

Figure 4.4    Examples of Asynchronous and Synchronous Communication

4.1.6    Quality of Service

Service interfaces can be configured to meet different types of processing requirements set by the sender of the messages into SAP PO. The sender uses the different types of QoS to specify how the messages should be delivered. SAP PO currently supports the following QoSs:

• Best Effort (BE)
  Messages are sent synchronously by the sender system. The sender waits for a response before it continues processing. This is the default QoS for synchronous interfaces, such as Remote Function Calls (RFCs), Business Application Programming Interfaces (BAPIs), synchronous ABAP proxies, and web services.
• Exactly Once (EO)
  The message is sent asynchronously. The sender doesn’t wait for a response. The Advanced Adapter Engine Extended (AEX) guarantees that the message is sent and processed exactly once. You normally select this QoS for most asynchronous interfaces, such as integration via Java Message Service (JMS), IDoc, asynchronous ABAP proxy, or file-based interfaces.
• Exactly Once in Order (EOIO)
  Similar to the EO QoS messages, EOIO QoS messages are sent asynchronously; however, in this case, messages are delivered in the same order as they were sent from the sender. Messages are delivered to a specific set of preconfigured queues as supplied by the application. Always use this QoS with caution and only apply it when no other alternative is provided by the sender or receiver system because it introduces more complexity and potential performance issues to your integration scenario. For instance, when one of the messages generates an error during processing, it will block all subsequent messages that arrive after that erroneous message. To restore the flow of messages, the message causing the error must be retried, saved, or deleted from the queue.

In this section, we’ve discussed the centerpiece of the design objects: the service interface. What else do you need to make information interchange between systems and business processes possible? We’ll discuss design objects next.