- SAP Managed Tags
As of release 2411 customers of SAP Digital Manufacturing can now create alerts for specific plants and ensure that only users who are assigned to these plants can access them. Besides, multiple processors can now be assigned to an alert. In this article we will walk you through these new features of the Alert Service and explain how customers running multiple plants can use them.
Introduction
The Alert Service in SAP Digital Manufacturing aims to notify production operators or supervisors about events or exceptions happening on the shop floor and intentionally introduce human decision making when responding to them. Alerts can either be created manually within Production Operator Dashboards (PODs) via the “Raise Alert” POD plugin or automatically by production processes. Alerts contain configurable data fields (in earlier releases known as alert properties) which include the context information that led to the creation of the alert. For example, they can contain information such as plant, work center, resource, operation, material, SFC, order, or readings from sensors connected via shopfloor systems or MQTT brokers. For more information about the alert service and some example end-to-end scenarios, please refer to my earlier blogs Create an Issue in SAP Quality Issue Resolution from an Alert in SAP Digital Manufacturing, Enriching Readings from MQTT Sensors with the Applicable Manufacturing Context, the Alerts section of the Application Help for Execution and the Enabling Alert Services section of the Operations Guide for SAP Digital Manufacturing in the SAP Help Portal.
In this article, I’d like to focus on the mentioned two new features which turn the Alert Service “organizationally” more scalable and more valuable to customers running multiple plants.
Before I start, let me briefly highlight a few changes in terminology coming with release 2411 to ease your reading: The terms “property” and “property set type” have been renamed to “field” and “alert data schema”, respectively, to better match the terminology used in the “Manage Service Registry” app. Consequently, the tile “Manage Property Set Types” has been renamed to “Manage Alert Data Schemas”.
Access to alerts created for the current plant
In earlier releases users with roles assigned as listed in the This was because, in earlier releases, the plant information could only be added via a field within alert data schema to an alert. Fields are defined at design time in the “Manage Alert Data Schemas” app and assigned to alert types in the “Manage Alert Types” app by the customer. Customers are given the degree of freedom to define whatever fields make sense for their specific use case and adding a “plant” field is not mandatory. Therefore, if a plant information is available as a field in an alert data schema, it has a purely informative nature – for example in SAP predefined alert types such as Supervisor Request, Material Request, Quality Request etc. all containing the “DME_Shopfloor” alert data schema including the field “DME_Plant”.
With the 2411 release a new optional field “Plant” of data type “String” has been added to the API payload of the Alert Service (not belonging to any alert data schema). If new alerts are created with a valid plant name assigned to the new “Plant” field, only users assigned to that plant can access the alert in the “Manage Alerts” app. If new alerts are created leaving the new “Plant” field empty, any user with the required roles mentioned above can access them no matter of their current plant, i.e. no change to the behavior in earlier releases.
This new behavior is reflected in the UI of the “Manage Alerts” app as it now automatically filters alerts by the current plant of the logged-on user. Using the UI’s Plant filter the user can then select whether to display alerts created for the current plant, alerts with no plant assigned, or both. Note that the “Plant” filter only filters based on the new “Plant” field in the API payload but intentionally ignores other payload fields relating to plant information that may come in via alert data schemas such as “DME_Plant” used in SAP predefined alert types.
Users with assignments to multiple plants need to change their current plant via the plant icon in the top bar of the Fiori Launchpad as shown in the screenshot below, if they want to display alerts created for other plants they are assigned to. User assignments to plants are managed in the “Manage User Assignments” app. User assignments not only control access to alerts but also access to other areas, for example (in combination with the “Manage POD Users” app) which PODs user have access to or which plants users can create or update data objects for; i.e. they are used across applications in SAP Digital Manufacturing.
We recommend customers to adopt the new “Plant” field in their alert generating scenarios as it introduces an additional layer of security to the Alert Service that becomes very relevant as soon as they create and manage alerts for more than just one plant.
What do customers need to do to enable the new “Plant” field in their alert generation scenarios? Alerts can be created in three different ways:
- Manually via the “Raise Alerts” POD plugin
- Automatically via production processes calling the API of the standard service “Create Alert” shipped as service registry content. This service is used to create alerts of the SAP defined alert types
- Automatically via production processes calling the API of a custom service creating alerts of custom type.
In the first case you don’t have to do anything. In the “Raise Alerts” plugin a production operator selects one of the SAP predefined alert types to create an alert for. The plugin assigns the current plant of the logged-on user (the production operator) as value to the “Plant” field of the new alert. Consequently, the new alert is only accessible in the “Manage Alerts” app to users with matching current plant.
In the second case you are running a production process that calls the standard service “Create Alert” in DMC_Cloud similar to the one in the screenshot below:
The script task “Current DateTime” contains the Java Script code snippet
var t = (new Date).toISOString().replace(/\.\d+/, "");
$output.Current_DateTime = t
to compute the current timestamp in the correct format or the “TriggeredOn” payload field.
The fields in the alert data schema “DME_Shopfloor” are mapped against the input parameters of the production process design:
With the delivery of release 2411 the API of the “Create Alert” service will be updated and you need to “sync” your production process design to pull in the new field “Plant”.
To do so, click edit to create a new version of your production process design. Then, click on “Sync” as shown in the screenshot below:
Next, you need to map the input parameter “in_Plant” to the new payload field “Plant”.
Then, click “Save All”, “Quick deploy”, and finally click “Run” to test. You only need to assign a valid plant name to the input parameter “in_Plant” while you can leave the other input parameters empty to run the test. Now, check in “Manage Alerts”, if the new Alert has been created and shows up with the previously assigned plant name. If you can’t find the alert, make sure that your user is logged on to the same plant 😉.
In the third case where you have created a custom service to create alerts of custom type, in a first step, you need to add the new “Plant” field to the main part of your CreateAlertRequest schema. Open the “Manage Service Registry” app, click on the “Schemas” tab and search for your “CreateAlertRequest” schema, which you may have chosen a different name for. Next, click “Edit” and “Add”. Scroll down to the last line highlighted with a red tag and place the cursor into the first field. A pane on the right side becomes visible. Enter “Plant” in the “Name” and “Description” field. Keep “String” as data type.
Then, click “Save”. In the following popup click “Check Where-Used” to identify all your custom services, which use the schema you are updating. Close the Where-Used popup and hit “Continue Anyway”. If you are unsure about which production processes are using the services listed in the Where-Used list of the updated schema, you can display each listed service in the “API Services” tab of the “Manage Service Registry” app and click there on “Check Where-Used”. You will need to sync each one of the listed production processes in the following way:
- Open the production process in its production process design in the “Design Production Processes” app. It will show a warning that the service is outdated.
- Click Edit, then on “Synchronize.
- This will pull in the new “Plant” field from the updated schema. Just for testing, we have entered the hard-coded value “1010” into the “Plant” field and some other values into the structure arrays for the two alert data schemas of this example alert type. In a real-world scenario, you’d rather map an input parameter to the “Plant” field as shown in above paragraph.
- Click “Save All” and “Quick Deploy” and then “Run” to test. Open the “Manage Alerts” app. You should see a new Alert with the value “1010” in the “Plant” column:
The previous alert hasn’t got a “Plant” assigned since it was generated prior to the schema and production process updates.
Assigning Multiple Processors to an Alert
In earlier releases it was only possible to assign a single processor to an alert or keep the processor field empty. A processor is a user in SAP Digital Manufacturing who is supposed to analyze the alert and drive the resolution of the situation that led to the alert. In a real-life shopfloor where supervisors and operators work in shifts, this could be more than just a single person per alert. Therefore, in release 2411, this limitation has been lifted. It is now possible to assign multiple processors to an alert either during alert generation using the “Raise Alerts” POD plugin or production processes, or through the “Manage Alerts” app as shown in the screenshot below.
Note that in “Manage Alerts” and in the “Raise Alerts” POD plugin you can only add users as processors to an alert that are assigned to the current plant.
If you generate alerts automatically via production processes and want to assign multiple processors to a new alert, you need to use the new structure array “Processors” that was added to the standard “Create Alert” service. You can ignore the legacy structure “Processor” that is only kept for backward compatibility:
If you are generating alerts via a custom service, you need to add the schema “AlertProcessor” with name “Processors” as structure array to your “CreateAlertRequest” schema and synchronize each consuming production process just as you did for the new “Plant” field in the section above.
Note that processors are entered as free text into the production process design. No validation takes place to check whether the processor is a valid user in SAP Digital Manufacturing. Consequently, it is possible that the “Plant” field value of a new alert generated by the production process at runtime may not match the current plant of the processor. When generating alerts for multiple plants from a single production process design it is possible to enter a list of processors whose users are assigned to different plants. Depending on the plant new alerts are generated for only those processors can access the alert in “Manage Alerts” whose current plant match the “Plant” field value of the alert.
Bluesky| User | Count |
|---|---|
| 11 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
