In the last unit, we learned that publishing production processes makes them callable from third-party applications and from within SAP DM. For the third-party calls, every SAP DM customer needs to know for themselves which possibilities there are in their application to call REST APIs. This lesson will take a deeper look at the possibilities of calling production processes from within SAP DM. One option is to call them from the Production Process Designer you have already seen in the last units. Still, that option is more a special case as you don’t want to ask production operators to choose the run button in the designer and put in all the data fields. Ideally, you want to react to certain events which happen on the shop floor or actions happening in the PODs. Let’s take a look at the options available. The graphic below shows you all the options, and we will go through them one by one.
- Automatic Triggers
The Manage Automatic Triggers app offers the possibility to react to three kinds of events, which are events happening on the shop floor, time events, and business events. Let's discover more about these triggers.
1A. Subscriptions
Let’s look at the shop floor events. There, you have the indicator changes. This is the classic way to react to changes from your machines, for example, when you want to trigger a production process to finish the SFC when the status tag of the machine changes to a certain value. You will learn more about this when you study the machine integration course DM3000. For this training, it is enough that you know that SAP DM can react to tag changes. The second use case of the subscriptions is to react to MQTT Messages. This is a rather new feature that allows you to subscribe to MQTT topics and to react to the messages published on that topic. The use case is fairly like the indicator subscriptions, just that you react to messages.
1B. Timers
Timers allow you to trigger production processes based on time events, for example, every hour or every weekday at 9:00 am. An example use case could be if you integrated SAP DM with EWM and you may want to automatically replenish the materials for the next orders for a given production supply area. In the preceding graphic, a sample timer has been configured for this. The timer needs a name (1), a Cron expression, the production process, and the mapping of the inputs. For the Cron expression (2), it is easiest to just use the Cron Expression Builder. It will help you to create the timers you need. In case you have a lot of processes you want to trigger periodically, you might want to coordinate the different triggers a bit so that not all of them trigger at the same point in time. Next, you select the published production processes that you want to trigger (3) and hand over the parameters the process requires (4). The timer event does not have any data itself, so all inputs of the production process need to be defined in the timer itself. When we look at the business events, that will be different.
Let's now return to the figure, Calling Production Processes within SAP DM.
1C. Business Rules
Business rules allow you to react to certain business events, for example when an order has been released, an SFC has been completed, a data collection has been logged, and so on. There are two types of business rules: events and business services. Events are the simpler form of the two. Events just allow you to trigger the production process without any interaction with the business event itself (asynchronous execution). In other words, you can just react to them. You can find the complete list of events on this SAP Help Page.
On the other hand, the business services are a bit more complex because they offer three different trigger points. For the business service, a pre-service, a post-service execution, and an error-during-execution trigger are available (see the graphic below). At the same time, it is possible to select between synchronous and asynchronous execution of the production process in the pre- and post-events. This is the list of business services and their specifications.
Key to this figure:
a) The async pre-service allows you to trigger a production process before the business service itself is executed, but the business service does not wait for the triggered production process to finish. It is just started. The production process will be executed to the end, even if the business service itself fails.
b) The sync pre-service is fully executed before the business service itself. Therefore, you could use it to execute tests or to manipulate data flowing into the business service. Let me give you an example: The Start SFC service is called out of a machine integration, and before the start is executed, you want to check if enough material is available for the operation and otherwise reject the start. It is important that your production process doing the check takes less than 10 seconds, otherwise you will run into a timeout. You will also find this hint in the UI itself.
c) The Error During Service execution allows you to react to issues that you may anticipate coming from certain services.
d) The async Post-Business Service allows you to react to the business service, very similar to the events.
e) Lastly, the sync Post-Business Service allows you to manipulate what the service returns to the caller.
Hint
For both business services and events, perform some testing of your use case. Some events and business services only react to the public API calls and not the UI, and vice versa. An example use case configuration will follow in the next lesson.
- Calls from POD
For certain plugins in your POD, you can also configure a sequence of actions to occur when specific events happen in your POD. In this lesson, we want to emphasize once again that it is possible to call production processes from the POD, which enables further automation. For example, you can decide that when a button is pressed by a production operator, you could call the production process (as an action) to assemble all the components assigned to the operation we developed in one of the previous units. When making the call, you can pass information from the POD to the production process, providing necessary context such as the selected SFC, work center, and operation. You can also store the output variables of the production process as POD variables so that you can use them alongside the POD variables that come with your POD.
- Alerts
Alerts enable you to initiate production processes and utilize the data from the alerts. For example, if a resource is down, you may want to notify the maintenance staff, mark the resource as unscheduled down, and trigger the rescheduling of any orders planned for that resource. To implement this, you can configure a custom alert type that activates a production process. Within that production process, you would update the resource's status and reschedule any affected orders. Additionally, the alert can notify maintenance personnel via email to inform them of the situation.
- Special Cases
When we introduced error handling, you may have noticed the toggle button labeled "Show Process in Recovery List" at the error end element. This toggle allows you to add the production process to the Recover Production Process list for re-execution. When you select a process for re-execution, you can run it with the same parameters or modify them to different values and run it. As you design your processes, consider this feature. However, keep in mind that if the original process reaches the error end, all services executed prior to that point are not rolled back. Therefore, simply re-executing processes that have already written to or changed some data may not always be beneficial.
For the sake of completeness, I would like to mention the last option for triggering production processes: Just executing them from the Production Process Designer, as you have already done. While this method is primarily useful for developing production processes, it is less relevant for the actual productive use of the system.