4.2    Design Objects

Design objects come in different shapes, categories, and names—each covering specific tasks within the ES Repository spectrum. However, they all share the same common goal, which is to make integration between systems and business processes possible. In this section, we’ll uncover the other design objects needed to support several types of integration scenarios.

4.2.1    Software Component Versions

A SWCV is a virtual logical container that stores all relevant design objects created during design time in the ES Repository. It’s also used to define a shipment unit as part of an integration solution. This shipment unit can be then delivered and installed on the customer side (i.e., in a different SAP PO system). A SWCV is always linked to its parent product (as defined in the SLD), and there can be one or more versions of the same SWCV available.

As explained before, you can also create local SWCVs for test purposes in your development environment. When working with local SWCVs, keep in mind that they can’t be transported or used to configure integration scenarios in the Integration Directory. However, you can decide later on to transfer local objects to a transportable SWCV via release transfer.

4.2.2    Folders

With repository folders, you can add more structure to the design objects created under a particular namespace. Each folder can contain any number of subfolders, just like in Finder for Macs or in Windows Explorer. For instance, you can create folders based on the design object category, such as service interfaces, mappings, and so on. Another option is to introduce folders as a way to separate certain design objects that belong to specific business processes or functionalities.

4.2.3    Namespaces

When working with XML documents, you normally assign one or more namespaces to the XML documents’ elements and attributes to differentiate them from other elements and attributes with the same names that might also exist in other XML documents. The purpose of namespaces in the ES Repository isn’t much different—namely, it’s to guarantee the uniqueness and differentiation of object types within an SWCV. Namespaces are created at the SWCV level. You need to create a namespace within an SWCV before you can start adding new design objects to that SWCV. You can share the same repository namespaces in different versions of the same SC, but you must use different repository namespaces for different SCs.

When defining ES Repository namespaces, consider the following best practices:

• Introduce and stick to naming conventions. If possible, use existing naming conventions available in the SAP PI developer’s community as a foundation, and extend them with your own conventions if necessary.
• Try to define namespaces based on the following criteria:
  • The business processes they support (e.g., HR, legal, logistics, etc.)
  • The business domains or geographical areas of the organization (e.g., consumer products or Business-to-Business [B2B], or US, EU, APJ [Asia Pacific Japan], etc.)
  • A combination of the preceding criteria (e.g., US:HR, EU:HR, etc.)
• Give preference to Uniform Resource Name (URN)-style instead of URL-style namespaces to avoid confusion with callable URLs.
• Use only lowercase when defining namespaces.
• Namespaces must be unique across different SCs in the same ES Repository.
• Keep the length of namespaces as short as possible.

Let’s go over a few examples of possible namespace syntax:

• Based on business processes
  urn:[company urn]:[process]:[sub process*]:[application*]
  Example: urn:rojoconsultancy.com:hr:recruitment:peoplesoft
• Based on geographical area
  urn:[company urn]:[geographical_area]:[application*]
  Example: urn:rojoconsultancy.com:eu:peoplesoft
• Based on a combination of both
  urn:[company urn]:[geographical_area]:[process]:[application*]
  Example: urn:rojoconsultancy.com:eu:hr:recruitment:peoplesoft

Optional

Depending on the size and complexity of your system landscape, you’ll have to choose the appropriate namespace approach to accommodate not only your current but also your future design objects in the ES Repository. By doing so, you’re paving the way to an extendable and logical way of organizing and managing content in the ES Repository.

Predefined ES Repository Namespaces

When IDocs, BAPIs, or RFCs are imported into an SWCV, you’ll notice that these types of objects already have their own predefined namespaces. Table 4.1 shows an overview of how these namespaces look in the ES Repository.

Namespace	Area of Application
urn:sap-com:document:sap:idoc: messages	Imported IDoc interfaces
urn:sap-com:document:sap:rfc: functions	Imported BAPI or RFC interfaces
http://sap.com/xi/XI/System/ Patterns http://sap.com/xi/XI/SFTP	Imported business content provided by SAP or a third party

Table 4.1    Predefined ES Repository Namespaces

We’ll now talk about operation mappings and message mappings, which are both absolutely crucial repository objects in most SAP PO or SAP Business Process Management (SAP BPM) integration solutions.

4.2.4    Mappings

Common mediation services offered by an ESB such as SAP PO include, for example, the transformation and mapping of multiple message protocols. Thanks to this feature, you can create integration solutions that can support any-to-any interaction between services from almost any type of system (SAP and non-SAP). It doesn’t matter which service initiates (sends a request) or answers (sends a response) the message interaction—SAP PO can support the mapping or transformation logic needed to generate the required target message protocol.

Operation Mapping

An operation mapping is used to map and/or translate the message structure from one service interface operation into another. The message structures define the actual contents of a service interface operation, as declared in its WSDL. It’s important to emphasize here that an operation mapping is configured to map web service-styled operations. The messages mapped don’t always necessarily represent a real web service operation as such, but they can be almost anything (a text file, a binary file, a database query, a mainframe message, etc.) as long as they can be represented as XML documents while being processed by SAP PO. For instance, you might want to map a flat file or a database query outbound message into an IDoc or ABAP proxy structure (see Figure 4.5).

Figure 4.5    Operation Mapping

Define the assignment of the operations linked to each other in an operation mapping. The number and type (message mapping, Extensible Stylesheet Language Transformations [XSLT], Java, etc.) of mapping programs or transformation rules you need to configure for an operation mapping depends, among other elements, on the communication mode and the complexity of the mapping to be performed:

• Synchronous communication
  Synchronous operations always have a request, a response, and an optional fault message. In that case, you have to define separate message mapping programs for request, response, and fault messages.
• Asynchronous communication
  For 1:1 mappings, you only need one mapping program. Only in some special situations, you’ll need to declare more than one mapping program as we’ll explain in the next section.

More than One Mapping Program

Depending on the complexity of the mapping requirements or type of transformation you have to support, it might be necessary to apply more than one mapping program to a single input before you can get the required message structure as the output of the operation mapping. The operation mapping offers standard functionality to execute multiple mappings in a sequence. You do that in the operation mapping editor, in which you can configure the necessary mapping programs in the correct order of execution. You can combine different types (graphical, XSLT, Java, etc.) of mapping programs in the operation mapping editor.

No Operation Mapping between Outbound and Inbound Service Interfaces

When both the outbound and inbound service interface have the exact same XML structure (i.e., both interfaces use the same message type to describe their web service operations, and there’s no mapping rules to be applied to those messages), you don’t need to create an operation mapping program. In such a scenario, the AEX only plays the role as the “pass-through” integration layer between sender and receiver without changing the internal structure of the message.

Message Mapping

In message mapping, you realize the actual message mappings between two XML structures as configured in operation mapping. You build the mapping with the graphical mapping editor. In the editor, you select the messages to be mapped, the source structure, and the target structure. The graphical mapping editor offers different standard tooling and out-of-the-box functions to realize simple and complex mappings. You also have the choice to build your own custom-built Java functions using user-defined functions (UDFs) and function libraries or even to import your own Java classes (for the more adventurous).

Overview of Mapping Objects

Table 4.2 provides an overview of the mapping objects you can create in the ES Builder.

Mapping Object	Description
Operation mapping	Associates one or more mapping programs for a pair of service interface operations. An operation mapping encapsulates the mapping programs to be executed at runtime.
Message mapping	Created using the graphical mapping editor. A message mapping has to be referred to by an operation mapping.
Function library	Enables you to use UDFs across message mappings. You can use UDFs from a function library in message mappings and in mapping templates. UDFs are custom-built Java functions created at the message mapping level to enhance the mapping program or add specific mapping functionality not available in the default mapping functions.
Imported archive	Contains an externally developed Java or XSLT (Java) mapping program. They are imported as archives (ZIP files) and are configured using an operation mapping.
Mapping template	Contains specific, reusable parts of a message mapping that can be used to create new message mappings.

Table 4.2    Mapping Objects

4.2.5    Process Integration Scenario

Process integration scenarios and actions bundle and represent all relevant design objects that you use at configuration time, such as service interfaces, mappings, and communication channel templates.

A process integration scenario is a graphical representation of the process flow, showing the different interactions between the involved components in your integration scenario (called the collaborative process). It gives you a high-level overview of the integration scenario, its participants, the exchange moments, mode of communication (i.e., synchronous or asynchronous), type of communication (inbound or outbound), message types used for information exchange, and any applicable mappings. Furthermore, you can use a process integration scenario as a template for later use during configuration time from the Integration Directory. Another advantage of using process integration scenarios is that they provide a quick view from a repository perspective into the integration solution for developers and technical administrators. Figure 4.6 shows a simple example of synchronous interaction between two service interfaces modeled as a process integration scenario in ES Builder.

Figure 4.6    Process Integration Scenario in ES Builder

4.2.6    Actions

Actions represent specific functions executed by a component within the process integration scenario. When creating an action, you bind an existing outbound or inbound service interface with the action. Typically, you’ll encounter the following types of actions defined in a process integration scenario:

• Send
• Receive
• Create, read, update, and delete (CRUD)

Actions are design objects that are independent of the process integration scenario so they can be reused in different process integration scenarios.

Note

Neither integration scenarios nor actions are required when creating design objects as part of an integration scenario. Their use is always optional, but is best practice.

In the next section, we discuss data types, external definitions, message types, and fault message types, which are design objects that give structure and context to the inner part of service interfaces created in ES Builder.