Understanding Further Production Process Elements

Objective

After completing this lesson, you will be able to understand further production process elements.

Lesson Introduction

After we have built the first production process, the basic understanding of the environment should be there. In this lesson, we will go one step deeper and explain some concepts you will need to build more complex production processes. In this lesson and the demonstration following it, we will build a production process which automatically assembles all elements to the shop floor control (SFC) that are assigned to the current operation. This production process can later be called from the POD to save the operator some clicking effort and therefore improve the user experience. The following concepts will be explained without further references to the case, but it should already be mentioned here as the screenshots will use the example.

Loops

When you start building your own production processes, you will eventually reach a point where you want to perform certain steps multiple times, in other words, use a loop. As you might have noticed in the first lesson of this unit, the Production Process Designer does not offer a control for this. Therefore, we need to build the loop ourselves, which will show you some more controls in detail. To build a loop in the Production Process Designer, we need three elements: a local variable (1), at least one script task (2), and a condition (3).

The image depicts a high-level process flow diagram. The overall flow shows a job (Type: Job) with an ID of 444 feeding into the main Runtime Planned As process. This triggers the assembly of components, starting with a single task defined by local variables. The single task is executed in the Runtime Task block, with the Assemble Components block indicating the continuation or hierarchical breakdown of the component assembly process.

1. Local/Process Variable

The local/process variable allows you to store data during the production process runtime. (We will later discuss global variables that allow you to store data independent of the process.) Most of the time, this is the index of the array you are looping over. So, it is advisable to start counting at 0 instead of 1, as the first element of an array has the index 0 in JavaScript.

2. Script Task

You will at least need a simple script task that increases the index variable in each iteration of the loop. In some cases, when you want to build more complex conditions, you might need a script task for the condition as well.

3. Condition

The condition will be used to decide when your loop should terminate or the following code will be executed.

In the screenshot, you already see a simple example, which we will build in the next demonstration to ensure that each element is understood correctly. The example shows a whole loop. If you rearrange the elements, placing the condition at the end of the loop content, you can also create a do-while loop.

Note

As we now come to the more complex modeling aspects, please make sure that you keep production processes fairly simple. To get some sense of the complexity of the processes, you may read the table under Restrictions for Cloud Processes under this note. For example, there is a max loop count of around 200 iterations or a max call stack depth of 10.

Error Handling

When you run and test your production processes extensively, you will eventually encounter exception scenarios that need to be handled. The Production Process Designer offers multiple functions to address this situation.

The image shows a screenshot of the SAP Data Intelligence user interface for designing data processing pipelines. Overall, the interface provides a visual, drag-and-drop style for designing data pipelines, allowing users to connect various components to extract, transform, and load data between different systems.

1. Error Catch

The Error Catch is placed directly on the service. It catches issues returned by the service. For the services from the service registry, like the SAP DM APIs, these are the HTTP error codes (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Client Error, 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, and 504 Gateway Timeout). If you call a subprocess (a different production process from the same design), you may also catch custom error codes that you defined as part of the subprocess.

2. Error End

The Error End allows you to let your production process end with an error. The error will appear in the Monitor Production Processes application. The process will be marked as "Completed with Error". For the Error End to work, you need to first define custom error codes. The option can be found on the three dots in the design header. This is also marked with the number 2 in the screenshot.

3. Automatic Retries

Lastly, it may happen that services you call from the Production Process Designer are temporarily unavailable due to whatever reason. These degradations are rare but could happen. To make your production processes more robust to this, you can activate automatic retries for most services. In the details menu, you can set the number of retries, the interval, and the error codes that should be retried. If you specify the same error codes in the automatic retry and the error catch, the retries are executed before the error catch. In the demonstration, you will see how to activate the feature, but you won't see an example as we cannot provoke a service unavailability.

Global Variables

Next to the local variables, which store information within the runtime of the production process, there are also global variables, which can be used to store data independent of the runtime of a single process. They may be used to hand over information like counter values from one process instance to the next. However, they should be used with great care. As soon as you start using global variables, the process is not a stateless function anymore.

Let’s say you have developed a machine integration with increasing material counters per order and you use a global variable to store which bookings have been made already so you can perform a delta calculation to perform work-in-progress bookings. In the Happy case in the graphic below, you see how it is supposed to work. There is an automatic trigger on the machine counter change (T1), the WIP process compares the current global variable to the machine counter, and books the difference. Afterward, the global variable is updated (T2). When an order is completed, the global variable is rested (see T3a and T4a). In T5a, the next counter increase arrives, and the order WIP logic can work again. This is all the Happy case, but now imagine that, for whatever reason, the order complete booking does not work between T3b and T4b in a way that the global variable is not updated. In this case, not only is the order complete impacted, but also the following processes like the order WIP between T5b and T6b.

The image shows a table comparing a Happy case and Failure case scenario for some process. The table allows comparing how the external counter and global variable change through a multi-step process, contrasting the outcomes in a successful Happy path versus a Failure scenario where an order does not complete as expected partway through.

As you see in the above example, stateful production processes can lead to complex manual cleanup activities after errors. For this reason, you should only introduce states if you are sure to gain other benefits which justify possible cleanup trouble. Still, there are cases where it makes sense to set up production processes like this, but, as they are quite complex, this would be beyond the scope of this course. To find out more on global variables, read the SAP Help Page on this topic, which also offers a simple demo example.

Log in to track your progress & complete quizzes