2    Administration and Development Tools

Imagination is everything. It is the preview of life’s coming attractions.
                                                                                                   —Albert Einstein

SAP Process Orchestration (SAP PO) comes equipped with a broad collection of administrative and development tools that provide easy access to its internal functionality and that empower system administrators (SAP Basis) and developers to unleash SAP PO’s true potential.

In this chapter, we’ll talk about the main administration and development tools provided with SAP PO and provide guidance about when and how to use these tools for developing and administering your integration solutions.

2.1    SAP Process Orchestration Tools

SAP PO has a home page from which administrators and developers find their way to SAP PO’s most important components. All process integration tools are bundled together on that page, as shown in Figure 2.1. Those tools represent the start point of any integration solution built on top of SAP PO. From there, developers and administrators can find all important links (with the exception of SAP NetWeaver Development Studio and SAP NetWeaver Administrator) to the necessary tools and infrastructure to design, build, configure, monitor, and manage integration solutions implemented with SAP PO. Each of these tools can help you fulfill specific administration and development activities during design, configuration, and runtime.

Figure 2.1    Process Integration Tools Landing Page

For those of you who have been working with earlier versions of SAP Process Integration (SAP PI) or SAP Exchange Infrastructure (SAP XI) in the past, not too many differences will be noticeable at first sight. However, the major changes are found in the internal functionality of each tool, as you’ll discover in this chapter. A completely new generation of administration and development tools is represented by SAP NetWeaver Administrator and SAP NetWeaver Development Studio (often referred to as NWDS). Both tools fit perfectly into the new generation of Java-based product lines offered by SAP NetWeaver.

To access the Process Integration Tools page, go to http://<hostname>:<port>/dir, where <hostname> is the hostname of the SAP NetWeaver system, and <port> is the port number of the SAP NetWeaver system.

Table 2.1 provides an overview of the different tools and main areas and components that we’ll explain in more detail in the next sections.

Main Area	Component Name(s)
Enterprise Services Repository (ES Repository)	Enterprise Services Builder (ES Builder) Enterprise Services Registry (ES Registry) Web UI
Integration Directory	Integration Builder
	SAP Cloud Platform Integration content
System Landscape	System Landscape Directory (SLD)
Configuration and Monitoring	Monitoring Home (pimon) SAP NetWeaver Administrator

Table 2.1    Process Integration Tools Overview

2.1.1    Enterprise Services Repository

The role of the Enterprise Services Repository (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 service-oriented architecture (SOA)-style enterprise services.

The ES Repository (see Figure 2.2) 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 Services Description Language (WSDL) and Extensible Markup Language (XML) definitions (XSD).

Figure 2.2    ES Repository Architecture

The ES Repository is also used to import and maintain SAP standard content (ES Repository content), provided as part of different SAP industry solutions or by certified third-party software suppliers. The ES Repository content is also called business content and can be downloaded via the SAP Service Marketplace or via the ES Workplace. You’ll need proper SAP Service Marketplace credentials 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 Universal Discovery, Description, and Integration (UDDI) directories and Active Directory.

In the following subsections, we’ll help you better understand the role of the ES Repository and how to position it within the SAP PO architecture. After that, we’ll talk about the ES Builder and Service Registry.

Understanding the Enterprise Services Repository

One of the challenges we commonly encounter as SAP integration specialists is how to explain 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’ve 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 LEGO pieces, all of them in different colors, shapes, and sizes. Now, imagine that you’re building an airplane or any other object you would like to build with LEGO bricks. When you have that picture and the process of designing and assembling new objects using different building blocks clear in your mind, you’re more than halfway to understanding what the function and role of the ES Repository really is. The LEGO bricks in the bucket are similar to the ES Repository. When you start building your new LEGO creation by searching, selecting, and assembling different LEGO bricks, it’s similar to using the ES Repository Builder to build new service interfaces by creating or reusing repository objects stored in it.

Local or Central Enterprise Services Repository

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. These options are as follows:

• Local ES Repository per SAP PO instance
  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 (i.e., the Advanced Adapter Engine Extended [AEX]). The advantage of this setup is in its simplicity, as well as less initial installation effort required from the SAP Basis team.
• Central ES Repository for all SAP PI instances
  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.

Enterprise Services Builder

You 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 (see Figure 2.3). Object types created in the ES Builder are stored and maintained in the ES Repository.

Figure 2.3    Enterprise Services Builder: ES Repository

Note

The ES Builder is known by most SAP PI developers simply as the Integration Repository or just Repository.

ES Builder: Recommended System Requirements

The following recommendations apply for running the ES Builder on your development laptop or desktop:

• A minimum of 4GB of system internal memory (8GB is better)
• Java Development Kit (JDK) 6 or newer
• Java Web Start
• Web browser (Mozilla Firefox, Google Chrome, etc.)
• Windows administrator/developer rights

When you click on Enterprise Services Builder link from the Process Integration Tools home page (refer to Figure 2.1) and enter your SAP PO user credentials, a pop-up will appear, asking your permission to load the ES Builder’s required libraries and to run it as a Java Web Start application. After you’ve given permission, the application will start downloading all necessary libraries from the server hosting SAP PO (see Figure 2.4). This action might take a few minutes depending on the speed of your network connection.

Figure 2.4    Downloading ES Builder’s Required Java Client Libraries

Tip

If SAP Single Sign-On (SSO) is available in your SAP landscape, then some of the preceding steps could be skipped. This also depends on your firewall settings for Java programs and antivirus software installed on your local PC.

If you encounter problems launching the Java Web Start application, then you can try one of the following possible solutions:

• Make sure your users have the proper rights to run Java Web Start from their browsers.
• Verify the recommended system requirements for running ES Builder (see previous box).
• Check your settings for the Java Runtime Environment (JRE). In Windows, go to the Control Panel, and choose Java, then click on the Java tab and select View to check your user and system JRE settings. You should see the entry shown in Figure 2.5.

Figure 2.5    Windows Java Runtime Environment

A dialog box with different Available Profiles is presented to the user the first time the ES Builder is started. Within the context of this book (i.e., SAP PO), we’ll assume that you should choose the Unrestricted profile (see Figure 2.6).

Figure 2.6    ES Builder: Available Profiles

Tasks Performed from Enterprise Services Builder

The ES Builder is mainly used by SAP PO developers to perform different development activities at design time. The following is an overview of the typical activities performed by developers before and during the development of repository objects inside the ES Builder:

• Configure personal settings
  The behavior of the ES Builder user interface (UI) can be configured to meet diverse personal preferences (e.g., language or navigation options) and certain organizational requirements (e.g., automatic publishing to ES Repository) for different users. To access the personal settings from the main menu, choose Tools • Personal Settings (see Figure 2.7).

Figure 2.7    Configuring Personal Settings from ES Builder

• Edit authorizations
  By default, all objects in the ES Builder initially have unrestricted access for all ES Repository users. By editing the authorizations, specific permissions can be granted to groups, roles, and users to perform activities in the ES Repository.
• Define work areas
  This functionality gives you the opportunity to create new software component versions (SWCVs) (imported from SLD and as local SWCVs), folders, namespaces, and usage profiles on the fly. The same menu can also be opened by right-clicking on a SWCV, namespace, or folder, and then selecting New (or press (Ctrl)+(N)).
• Browse and search for object types
  Repository objects can be used in different integration scenarios and SWCVs throughout the repository. This advanced search function provides an extensive set of search parameters and operators to help you find all kinds of object types across the repository.
• Edit object types
  This is one of the main functionalities when it comes to the common actions executed from the ES Builder repository: creating, editing, copying, and deleting objects. Other useful functions in this category include, for example, the Where-Used list (which shows a list of where the object selected is currently used) and the Check Object function (which validates the overall consistency of the object).
• Manage object changes
  Change lists are created as soon as the user edits or creates new repository objects. A change list is automatically created per SWCV. The user can then accept and activate or reject the change list. Change lists can also be transferred from one user to another if necessary.
• Monitor and analyze cache notifications
  The cache status overview provides a total overview of all cache refresh notifications and their statuses after change list activations are performed by different users from the ES Repository. You can select filters based on period and SAP PI user.
• Clear SLD data cache
  This function allows the developer to clear the SLD data cache used by the ES Builder during design time. This type of cache is maintained by the ES Builder to improve performance while accessing information (metadata) such as SWCV and main instances from the SLD. The SLD data cache is updated automatically when you start the ES Builder.

Enterprise Services Registry

Services are small pieces of software and as such have a lifecycle like any other software: they are designed, created, published, consumed, changed, and, at some point, removed from the software landscape in which they operate. The more services you add to your landscape, the greater the need for a central place where service-related metadata and other related information is kept and managed. This is where the Enterprise Services Registry (ES Registry) comes into play (see Figure 2.8).

As mentioned in Chapter 1, you can think of the ES Registry as a virtual yellow pages directory that maintains a record for all (published) web services available in your landscape. In the ES Registry, you can maintain web services for SAP and non-SAP applications. Services are classified into different categories, depending on their lifecycle statuses. Developers can publish their services into the ES Registry directly from the ES Builder, Integration Builder, or from SAP NetWeaver Development Studio. After a service has been published, it can be queried and found by service consumers on the ES Registry.

Figure 2.8    Enterprise Services Registry

ES Registry: Fact Sheet

The following are a few miscellaneous details about the ES Registry that you should know:

• ES Registry isn’t a mandatory component for the SAP PO landscape. However, when positioned properly, it can add more control and structure to the way web services are managed (service provisioning and consumption) across an SOA landscape.
• Services created in SAP PI, SAP Composition Environment, SAP Business Process Management (SAP BPM), and an SAP (NetWeaver-enabled) backend can be automatically published in the ES Repository. In the same way, it’s also possible to search for and retrieve services by using the ES Repository from the SAP products mentioned previously.
• Third-party (non-SAP) services can be published into the ES Registry either by directly importing the service’s WDSL into the ES Registry or by integrating external UDDI-based registries with the ES Registry. For more information about how to integrate non-SAP service registries with the SAP ES Registry, see SAP Note 1277970.
• One central SAP ES Registry is sufficient to manage all web services and to be shared across an SOA landscape. However, it can coexist with other service registries if necessary.
• ES Registry is based on UDDI version 3 and runs on the SAP NetWeaver Application Server for Java (SAP NetWeaver AS Java).

Web User Interface

A quick and easy way of browsing, searching, and managing service interfaces and certain related repository objects is provided by the Web UI, also called ES Repository Web UI. This simple tool also enables you to generate a complete overview of all active service interfaces and their related repository object types, such as message types, data types, and external definitions. Furthermore, you can subscribe to specific object types and receive notifications when a change takes place (e.g., a deletion or other change). This functionality can be very useful for system administrators and managers responsible for a certain set of mission-critical interfaces. Figure 2.9 shows what the main page of the ES Repository Web UI looks like.

Figure 2.9    ES Repository Web UI

2.1.2    Integration Directory

So far, we’ve seen how the process of designing and creating integration building blocks takes place in different areas of SAP PO. This brings us now to another important process integration tool: the Integration Directory, in which everything comes together and new integration solutions are fabricated based on existing integration components available on the ES Repository and SLD. In the Integration Directory, the dots are connected, and the rules of engagement governing a particular integration scenario are set and activated to be executed at runtime. Here, we configure both application-to-application (A2A) and business-to-business (B2B) processes configuration scenarios. We’ll discuss this in detail in Chapter 5.

The Integration Directory uses the Integration Builder as the Integrated Development Environment (IDE) to create and maintain configuration objects. We explain that subcomponent in the next section.

Integration Builder

The Integration Builder serves as the UI of the Integration Directory. In the Integration Builder (also known as just the Directory), configuration time is performed. You configure new configuration scenarios based on a combination of configuration objects and repository objects previously created at design time (see Figure 2.10). A configuration scenario consists of one or more integrated configurations (ICOs), each representing a message interaction between two or more systems.

Figure 2.10    Integration Builder

A graphical representation of the message interaction between the business systems is also provided as part of the configuration scenario (see Figure 2.11). Additional configuration objects that are also part of a configuration scenario include, for instance, content-based routing rules, communication channels, alert rules, value mapping groups, and parties. That last object represents an external business party and is mostly encountered only in B2B scenarios.

In addition to the Integration Builder, you can also use an application programming interface (API) to access, edit, and activate configuration objects. This approach is particularly interesting when performing and activating a large amount of changes in the Integration Directory or when embedding Integration Directory functionality into another application.

Figure 2.11    Configuration Scenario: Graphical Representation

SAP Cloud Platform Integration Content

SAP Cloud Platform Integration is a cloud based (iPass) system that facilitates the integration of business processes and data across on-premise and cloud applications (cloud to cloud and cloud to on-premise integration). Since the introduction of SAP PO 7.5, SAP PO is also equipped with an SAP Cloud Platform Integration runtime, which means that you can deploy, run, and manage the cloud integration content artifacts (e.g., Integration Flows [iFlows], value mappings, and security artifacts) in SAP PO. These new features can be accessed via the Cloud Integration Content Management Cockpit. The Cloud Integration Content Management Cockpit can be accessed through the Cloud Integration Content link on SAP PO’s landing page as shown earlier in Figure 2.1. The Cloud Integration Content Management Cockpit can also be directly accessed via the http://<hostname>:<port>/IGWGBDeploy/Admin, where <hostname> is the hostname of the SAP NetWeaver system, and <port> is the port number of the SAP NetWeaver system.

As shown in Figure 2.12, from the Cloud Integration Content Management Cockpit, you can perform the following activities:

• Deploy
  After downloading SAP Cloud Platform Integration content as a file on your local file system from SAP Cloud Platform Integration, this button can be used to upload and deploy the content on your SAP PO system.
• Undeploy
  Use this functionality to undeploy and remove previously deployed content from SAP PO. You first need to select the content.
• Refresh
  Use this to refresh the page and get an update of the status of each deployed integration content.

Figure 2.12    Cloud Integration Content Management Cockpit

To learn more about SAP Cloud Platform Integration, please refer to the book SAP HANA Cloud Integration by Bilay, Gutsche, and Stiehl (SAP PRESS, 2016, www.sap-press.com/3979).

Note

After deploying the SAP Cloud Platform Integration content on SAP PO, the status of the deployed item is displayed in the Runtime Status column. Successful deployments are marked in green, whereas failed ones are in red. The root cause of the failed deployments can tracked via the Log Viewer in the SAP NetWeaver Administrator.

The deployed SAP Cloud Platform Integration content can also be monitored in the same way as SAP PO interfaces are monitored. To read more on the subject of monitoring SAP Cloud Platform Integration content, see Chapter 7, Section 7.2.3. It’s important to note that to be able to deploy, view, and use the Cloud Integration Content Management Cockpit, the roles presented in Table 2.2 needs to be added to the user.

Roles	Description
SAP_XI_ADMINISTRATOR	Provides display and modify authorization to view and deploy security artifacts in the Cloud Integration Content Management Cockpit
SAP_XI_CONFIGURATOR	Provides display and modify authorization to view and deploy cloud integration content in the Cloud Integration Content Management Cockpit
NWA_SUPERADMIN	Provides display and modify authorization to view and import trust certificates in SAP NetWeaver Administrator
NWA_READONLY	Provides display authorization to view monitoring data in SAP NetWeaver Administrator

Table 2.2    Roles Required to Access the Cloud Integration Content Management Cockpit

More details about the SAP Cloud Platform Integration content are provided in Chapter 17.

2.1.3    System Landscape Directory

The System Landscape Directory is a central information hub supplying the entire SAP NetWeaver ecosystem with system landscape information about its operating environment. Such an environment includes not only other SAP NetWeaver components (such as SAP Composition Environment and SAP Solution Manager) but also SAP backend systems. The SLD contains relevant information about installed software components (SCs) and their versions on the entire SAP landscape, the business systems running that software, and the underlying technical infrastructure supporting those business systems. The SLD supports different types of SAP systems, but in SAP landscapes, the most common are SAP NetWeaver Application Server for ABAP (SAP NetWeaver AS ABAP) and SAP NetWeaver Application Server for Java (SAP NetWeaver AS Java). These types of SAP systems will automatically register with the SLD and send regular updates (via SLD bridge) about their versions and the installed products and SCs they support. Note that previous configuration is needed on the application system (SAP NetWeaver AS ABAP or SAP NetWeaver AS Java) to connect and update the SLD. Configuring the SLD bridge between application systems and the SLD is normally a task for SAP Basis.

SAP’s standard recommendation is to use one SLD instance, but in complex and/or highly distributed SAP landscapes, you might have more than one SLD instance available. In such a case, you must take either automatic replication of metadata or transporting SLD objects over different SLDs into consideration. Both approaches will help you maintain your SLD metadata consistently and keep it updated across the landscape.

To access the SLD (see Figure 2.13), go to http://<hostname>:<port>/sld, where <hostname> is the hostname of the SAP NetWeaver system, and <port> is the port number of the SAP NetWeaver system.

Figure 2.13    System Landscape Directory

The SLD functionality spans three main functional areas: landscape, software catalog, and development. These areas are described in the next sections.

Landscape

The landscape area of the SLD deals with the creation and maintenance of technical and business systems installed in your system landscape. Technical systems are application systems installed and registered in your system landscape. Typical examples of technical systems include SAP Enterprise Central Component (SAP ECC) and SAP PI. As mentioned previously, they can be of different types, but the most important ones (and relevant for SAP PO) are SAP NetWeaver AS ABAP, SAP NetWeaver AS Java, SAP PI, and third party. A technical system can have one or more business systems assigned to it. For instance, a technical system representing a particular SAP system might contain multiple business systems for each client of that SAP system (see Figure 2.14).

Figure 2.14    System Landscape Directory: Technical Systems

Within the SLD, you can group different types of technical systems in landscapes and sublandscapes based on their logical or technical relationships, which are defined by an SLD administrator. You can create different types of landscapes for different purposes (e.g., administration, general, SAP NetWeaver development infrastructure [often referred to as NWDI] systems, scenarios, transports, and web services).

Business systems, on the other hand are logical systems that can act as senders or receivers within an integration scenario in SAP PO. Business systems are always linked to a technical system in the SLD and can be of the SAP NetWeaver AS ABAP, SAP NetWeaver AS Java, or third-party system types. Business systems are grouped in SLD business system groups and transport targets to facilitate the transport (e.g., from development to test) of integration scenarios created in the Integration Directory.

Software Catalog

The SLD has a software catalog of all available SAP products and SCs in your system landscape. That software catalog includes information (metadata) about support packages and dependencies between the products and SCs.

A product within the context of the SLD is a logical unit that corresponds to a collection of product versions, each with one or more SCs. In an SAP environment, a product represents an SAP technical component. Before you can start developing any integration solution in SAP PO, you first need to create a product and at least one associated SWCV in the SLD.

A SC is a logical unit representing a collection of SWCVs, each with one or more SC units. A software unit supports a specific functionality of a product and SWCV; it also embodies the logical link between the product and SWCV (see Figure 2.15).

Figure 2.15    System Landscape Directory: Products and Software Components

Development

To avoid naming conflicts between SCs, the SLD also provides a name reservation service (also known as a name server), which allows you to reserve names that are guaranteed to be unique. In this section, we discuss name reservations and Common Information Model (CIM) instances and classes.

The SLD offers a tool for managing namespace prefix reservations for both SAP and your own custom SAP NetWeaver software developments. Namespace prefix reservations can be made via the SAP Service Marketplace. Namespaces are unique identifiers for XML structures and particularly useful when working with external parties (i.e., in B2B integration scenarios).

You can manage all CIM instances and classes known in your SLD environment. CIM is a standard of the Distributed Management Task Force (DMTF) and is based on the object-oriented modeling approach. The SLD is currently based on CIM 2.9. You can read more about CIM and DMTF at www.dmtf.org.

2.1.4    Configuration and Monitoring

Prior to the latest releases of SAP PI and the introduction of SAP PO, most SAP PI system monitoring and administrative tasks were performed from either the ABAP stack (Transactions SXMB_MONI and SXMB_ADM) or via the Runtime Workbench (RWB).

The Monitoring Home screen (also known as “pimon”) is a new place in which you can monitor and manage different areas of your local AEX. It comes packed with different kinds of monitoring and administrative functions that ease the access to different administrative areas of SAP PO (see Figure 2.16).

Figure 2.16    Monitoring Home Screen for Your Local AEX (pimon)

To access the Monitoring Home screen, simply click on the Configuration and Monitoring Home link from the Process Integration Tools home page, or go directly to http://<hostname>:<port>/pimon, where <hostname> is the hostname of the SAP NetWeaver system, and <port> is the port number of the SAP NetWeaver system.

Note

For SAP PI dual-stack systems, the traditional monitoring and administration methods still can be used (i.e., RWB and ABAP stack Transactions SXMB_MONI and SXMB_ADMIN).

Two new features are also provided as part of the configuration and administration tools that deserve additional attention: the Migration tool and the integration visibility configuration.

Migration Tool

The Migration tool supports the migration and mass change functions for process integration scenarios and channels using directory content from your SAP PI landscape. It’s extremely interesting, especially if you’re planning to migrate your current integration scenarios from a dual-stack SAP PI to a new, Java-only SAP PO environment. You can run the tool, select the directory source objects you want to migrate, and obtain an overview of which objects can be migrated without changing them and which might require additional changes. You also can perform mass changes on communication channels between systems or rename multiple directory objects at once. The tool currently supports the following source systems: XI 3.0 and XI 7.0 or higher.

Integration Visibility Configuration

This tool facilitates the discovery of message flows and provisioning of events to subscribed applications (e.g., SAP Solution Manager or SAP Operational Process Intelligence) interested in consuming technical or business events for process integration visibility. It allows you to configure and schedule the way events are detected and propagated to the subscribed applications. Depending on the functional and technical requirements, it could be positioned as a way of feeding third-party applications that support Business Activity Monitoring (BAM).