<p>about your learning experience to help us improve.</p>

You've completed

cleanFiles/bookmap_Exploring_Extensibility_in_SAP_Digital_Man_en-US_learning-sap-com_lsc-prod.zip (MMCP-DROPZONE) - 2025-04-17T09:33:58.000Z

Building Production Processes Including a Loop

Develop a Complex Production Process

Exploring Customization in SAP Digital Manufacturing

Setting Up a Complex Production Process

In the next three videos, we will step-by-step develop a complex production process, which includes loops and error handling. The production process should be later used in the pod to assemble all components assigned to the operation in one single. For this second process of this course, we will reuse the same production process design. In a real live scenario, give some thoughts about how you want to structure the processes into designs as designs. All processes from a design are deployed together and are also moved. between systems together. Like for the simple process, we will give the new process a speaking name. In this case, we have skipped the API research. As I already know, the behavior and parameters of the relevant APIs. I will just start modeling right away. If you want to challenge yourself, you may stop the video at this point and try by yourself to build a process which assembles all components assigned to a given operation. As a first step, the start element is added with all parameters. Don't worry if you don't know all parameters now. You may also add them. The Retrieve Plan component service will provide us a structure array with all the components assigned to the operation handed over. We will iterate over this list to assemble all components. With adding the condition, we added the first part of your loop. To be able to model the logical expressions, we need to add the process variable next. For this, I select the local variables option and create a variable called V-assembly counter. Always keep in mind to use speaking names. The default value was selected to be zero. That way the variable can be used without assigning it a value first. The Assemble Component's API will be the action to be repeated within the loop. Before configuring the API input, the loop condition should be modeled. In the Expression Editor, you can either type in the expression right away, where you may use the UI to assemble a correct expression. Unfortunately, there is no function to test run expressions. Therefore, for very complex expressions it might make sense to move them into a script task for better testing. Still you will see the condition results at runtime. In this case, we will test if the planned component structure has an element at the position V assembly counter, which was our loop variable. As soon as the loop variable is equal to the array, length the condition will become false. I rearranged the services a bit that you can still read the full condition and we have more space to continue modeling. The process also works if the condition is not readable in the modeling pane, but just if you select the element. Still, I would recommend that you define a modeling direction in your project, EG from left to right, and then from top to bottom. For sure, loops will always break this direction, but this will also make them easier to spot if you model from left to right in all other cases. With some new space available, we can add the rest of the elements and finish modeling the condition. Each condition at least needs two exits. I also recommend to think about if the outgoing flows cover all possible cases, especially if you decide not to use the else option. Here we use the else option, so it is easy to say that all possible outcomes of the previous code are covered. Like for the Retrieve Plan Components API, we again fill the inputs of the Assemble Components API. For some of the parameters, we also use the counter to access dedicated fields from the Retrieve Plan Components Outputs Output Structure Array. Here, I replaced the index from plain component's array manual. With the mapping of the service finished, we can add the last connections and configure the last element. For script tasks, we not only need to map inputs and outputs, but we also need to define which data should be handed over and which data we want to return. For supporting the loop, it is quite easy. We want to retrieve the current countervalue as an input and give the increased countervalue back out, so we can continue working with the increased value back out. So we can continue working with the increased value. It is important that you do not forget to. assign inputs and outputs. It is especially easy to not map the output again to the process variable and wonder why the value of the process variable is not changing. Now we can start writing the JavaScript code to increase the counter. It is fairly easy the output counter equals to the input counter plus one. You can either just start typing and leverage the autocomplete function where you may use the insert parameter button to get some help with the input and output parameters. The button with the magic stick offers a printing function to help with formatting. Please also note the hint over the text box of script tasks, which explains that local variables within the script task should not be a duplicate of input or process variables. In this very simple script task, we didn't need more variables at all, but if you start increasing the complexity of script tasks, pay attention to this point. This is also the reason why we use prefixes for input, output, and process variables. For simple functions like this one, you don't need to test run the function. function, but it is still highly recommended as it is way faster to correct mistakes before deploying the new version. To test the script task, you can manually hand over some input values, and you will get the outputs returned. Similar as for running the entire process from PPD. If you have if statements slash more complex constructs within your script task consider handing over different inputs, so all lines of code are reached reached and the special cases are covered. Finally, we will rename the script task to a description of its purpose. This is not really needed, but it will later help with readability and maintainability. The deployment was successful and the process will be tested as part of the next video. I can already give the hint that the hazard design gap right now, which needs to be discovered and addressed.