Tell us what you think

We want to create the best possible experience for our learners. Your feedback helps us to improve the experience for everyone.

Understanding the Service Registry and Manage Web Servers App

Objective

After completing this lesson, you will be able to understand how to leverage the Service Registry.

Service Registry 101

In the last units, you have learned about building production processes in SAP DM. In this unit, we will have a deeper look at the foundation of the Production Process Designer, which is the Service Registry. The Service Registry is the central place in SAP DM to manage all services that are used within SAP DM, and it also provides external endpoints to the published production processes. The graphic below visualizes its use cases, and we will walk through them one by one.

The image depicts the SAP Business Technology Platform (BTP) and its components. At the center is the SAP Digital Manufacturing (DM) platform, which is based on a SaaS account. The SAP DM platform consists of SAP DM services and SAP DM production processes. These services and processes interact with the SAP DM Service Registry, which connects to various external services. These include SAP Kyma PaaS extension services, Customer PaaS Account services, and Partner PaaS Account services. The SAP DM platform also integrates with other SAP systems such as SAP S/4, SAP S/4 / ERP, SAP ME/MII, SAP EWM, and other systems. Additionally, it connects with customer applications, customer systems, 3rd party systems, and shop floor systems. This architecture enables the SAP Digital Manufacturing platform to provide a comprehensive set of services and capabilities for managing and optimizing manufacturing processes within the SAP ecosystem.

Let's now break down the above graphic. In the center, you see the SAP BTP; within that, there is the SAP DM, and within that, there is the Service Registry.

SAP Digital Manufacturing Services and Production Processes

Let’s start with the SAP DM services and production processes which are available in the Service Registry. The SAP DM services, meaning the public APIs and some additional built-in services, for example APIs for Indicator Interaction, are added to the Service Registry by default. This makes all of those APIs available to be used in the Production Process Designer without any additional work.

The production processes themselves are not part of the Service Registry by default. They become available upon publishing. So, what is the difference between a published and an unpublished production process?, you might ask. The unpublished one is only visible/callable within the same production process design. This is comparable to a private method in object-oriented programming which is only visible/callable within the same class.

As soon as the production process is published to the Service Registry, it becomes visible to other callers from within SAP DM, such as automatic triggers or the POD, and also to external callers (for sure, it is protected by authentication via OAuth). Publishing a production process will be one of the exercises in this unit.

Third-Party APIs

When you move to the right, you can register all kinds of third-party APIs to the Service Registry that you want to use in your production processes. To be able to do so, the APIs need to be available on the public internet and you can use authentication to protect the endpoints you want to offer to SAP DM. Examples could be custom applications you want to integrate or shop floor systems that offer REST-APIs.

In one of the following exercises, we will register some additional SAP DM services manually. This will show you how to add third-party services as well.

Registration of Additional Endpoints to SAP System

Next to the third-party applications, you can also register additional endpoints to SAP systems. This is if the standard integrations don’t cover your scenario, or you want to integrate additional modules, and you can also use the Service Registry and the Production Process Designer to achieve this. One example might be to create an equipment structure when you have finished producing the SFC.

Integration of Extensions Built on SAP BTP

Lastly, you see, under the Service Registry block, that it is also used to integrate extensions built on SAP BTP. These might be custom POD plugins or functional extensions like a next numbering logic. Some of the options will be explained on a high level in Unit 12.

Parts of the Service Registry and its Connection to the Manage Web Server App

The Service Registry has three parts. The Schema Library manages the structures of all API inputs and outputs, so the hierarchy, names, descriptions, and data types of all parameters. These structures are the basis for the value help in the Production Process Designer. Then, there is a section for UI extensions, which we will not look at in this course. There is also the section for the APIs. The APIs, in turn, use the Web server object. The Web servers are managed in the Manage Web Server app and have the host URL of a service, while the entry in the Service Registry has the exact path to the endpoint. That way, the Web server can be reused for multiple endpoints. The Web server also references the SAP BTP destinations for authentication. You will get a better grasp of this in the second demo, where we will add an additional service.

Important Information on Public APIs – Check Where-Used, Compatibility of Changes, and Status Information

The Service Registry offers the following three functions to help customers if SAP DM APIs should change:

The image shows an activity confirmation screen within the SAP Manage Service Registry tool. It displays configuration details for a HTTP web service. The screen has three key sections, labeled in the image as 1, 2 and 3: 1. The left navigation pane which lists various configuration categories such as API Services, Schemas, UI Extensions, etc. 2. The main central area showing the Activity Confirmation heading and an overview stating Confirms activities. Confirms activities in a phase of an order. 3. A Check Where-Used pop-up window on the right side of the screen. This window contains fields to define the Service Definition, including Type (HTTP), Method (POST), URL Path (ts/Extension), Protocol (REST), and Web Server. It also has fields for Request Body content type and data type, with a description stating Request object to confirm activities. The user interface follows a typical SAP application layout with a blue color scheme and clearly organized sections for navigation, main content, and additional settings

1. Marked in the Service Registry

If an API is changed, it will be marked in the Service Registry. There are four different statuses that could be visible for a standard API. If there is no remark at the marked position in the screenshot, this means the API is current. In this status, you can just use the API without any issue.

Then, there is Changed (compatible). This status shows that with the last release, the signature of the API changed, but in a way that does not break any implementations of the API. Examples could be an additional output or an optional parameter that was added.

Changed (Incompatible) refers to modifications in the API that may impact the calling logic. For example, an optional parameter might be changed to a mandatory parameter. In such cases, it's essential to review what has changed and adjust your implementations accordingly. Typically, when there are incompatible changes in a public DM API, versioning is applied, allowing implementing projects time to adapt and update their production processes. However, the status is still accessible because the same logic also responds to alterations made in your published production processes. This feature aids you in identifying changes and reviewing the calls to the production process from within SAP DM.

The Deprecated status describes that the API should not be used in production processes anymore and will be decommissioned in a future release. When incompatible changes are needed for public APIs, typically the old version is set to deprecated and a new service registry entry is done for the new version.

2. Software Version Field

The software version field will become a dropdown as soon as the API is available for more than one SAP DM release. When you select a different release, you can see the details on the previous definition of the service.

3. Check Where-Used Function

Lastly, the Check Where-Used function shows you the service's usage within SAP DM. This allows you to evaluate the impact of API changes and helps you determine whether you use a certain API.

Next lesson