<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 a Production Process

Business Scenario and API Testing

Exploring Customization in SAP Digital Manufacturing

Building a Production Process (Part 1)

Welcome to the first video demonstration of this course. This demonstration has three parts. It was cut into small pieces to allow you to perform the same steps in our own DM tenant and practice. With these introductory words, let's dive right into the scenario. Before we start designing the production process, we should understand the business scenario and check if we have the proper APIs to realize it. In this scenario, we want to build a simple production process that can collect some torque values. Later on, the production process can be used for the integration of the torque wrench. When we look at it from the UI and process side, we are at the assembly step of the bicycle. At this step, both wheels are assembled, and the torque from both bolts should be collected. In the UI, you would select the SFC and operation, and afterwards manually collect the data. For the automation of this, we will first look for the proper API and try it out. I always recommend testing the API with the use case you have in mind to check if it behaves as you anticipated. You may also check how it handles missing data or special values. In this case, you might have noticed in the UI that we expect torque values between 25 Newton meters and 30 Newton meters, so I would be advised to check how the API behaves for a value outside this range, for example, 32 Newton meters. SAPDM offers ODATA and Rest APIs. You can use both types in the production process designer. At the moment, there are more Rest APIs available, And the API we are looking for is also a Rest API. The APIs are grouped into packages. The package and also the API itself have a status. On the package, you find the status in the lower right corner. It is important to pay attention to only implementing active APIs. Don't implement, deprecated, or decommission APIs as they will stop working in the near future, which will then break your business process. I will now search for the package by the name of the function I am looking for. You will mostly find it by the name of the function. If you don't find it right away, try some similar terms or search manually right now. There are over 60 packages available, and the number is increasing. So, for most of the functions, you will find some APIs. With the correct package identified, we can now check the API reference to find the details on the endpoint. Relating back to earlier here, you can also see that the second API in the list was deprecated. It is grayed out and should not be used anymore. The first one seems to be fitting to the business scenario at hand. Let's have a look at the details. In the details, we do see the request structure and the expected responses. The required values are marked with an asterisk. We will need to hand over the data collection group details, the operation, the parameter values, the plant, the resource, and the SFC. When the API call was successful and returns at HTTP 200, we can then expect to get four structures in return, which we could check out more detailed here or check with an example. We will now use the tryout function of the SAP Business Accelerator Hub to test the API. You may also use your favorite API test tool for this. In my case, I have already set up the environment on the page and can directly go ahead to testing. With the environment ready, I can start filling the input parameters. To make the video a bit shorter, I already prepared the JSON structure and just pasted it in here. It contains all the information required by the API. The front torque value is 27 nanometers and the back value is 29 nanometers. The API reports that the collection was successful. The response code is HTTP 200 and the additional structures are all empty in this case. Next, we can check if we also find the value in the UI now. Back in the Work Center pod, we need to first refresh the data. For this, we navigate back to the SFC selection and re-select the SFC. You can also set up the pod in a way that the data is refreshed in the background using pod notifications. However, as we just use the default pod here and need to perform the refresh manual, After the reselection, you now see both values are collected and also visible within the system. This now gives us a good understanding what we want to achieve and how the required API for this works. For sure, we have skipped the part on checking the behavior of the API with wrong data, but we will come back to that in a later lesson on error handling.

Building a Production Process (Part 2)

In this part of the demonstration, we will build the production process to perform the data collection. Therefore, we will navigate to the production process designer. On the entry page, you can see that we already have one design under my name, which we use to test the content for this training beforehand. Nonetheless, we will create a new design together to show you all the steps. Each design needs a name, an ID, and has a version. The needs to be unique, but will be automatically said according to the name you'd, give to the design. The version number will increase with every new version of the design you develop. In this case, we use the course name as the design's name. In the projects, you should try to give the designs telling names and use them to group production processes with a common context. After clicking the create button, you will enter the design environment. However, there is no process in the design. To add a new process, can use the plus icon on the top right side or the create button. We will name our process log data collection. This will automatically give it the same ID. For the process, we select the cloud runtime and don't check the visible -to-production connector, prodcon, or plant connectivity, PCO, runtime. The cloud runtime is selected as we only use cloud services and also want to execute the process in the cloud later on. The visibility to external systems like prodcon or PCO can be changed later if needed. This gives us a blank modeling canvas, and we can start dragging into services. For this, we switch to the Editor tab to find the controls and services as explained in the last session. To model the process, we will need to start, an end control, and the API itself. You can find the services by navigating through the packages, like in the SAP Business Accelerator Hub, where you can use the search bar. The basic controls can not only be found in the control section, but all elements also offer a context menu to find possible next elements. You need to use this menu to connect elements with logic flows. See how we connect the start element to the service. All changes we have done so far are only stored in the browser. If we would reload the session new or the internet connection would get lost, all unsaved changes will be lost. Therefore, it is advisable to save from time to time. This initial design is so small that you may model it in one go without saving it in between, But for larger changes you're working on, make it a habit to save regularly, definitely before fetching a new coffee. The logic flow is already done. However, there are no inputs and outputs to the process yet. For our use case, we at least need the two torque values as an input. From a design point of view, you can now decide on how many values you want to get as input and which values you either hard code or determine within the design. In this case, we decided to ask for all. the parameters from the caller of the process. To add input parameters to the production process, select the start element and add the parameters in the object details. On a second screen, we had the API signature open so we could look up all the values needed. Each parameter has a name, the data type, and if it is required or not. If the APIs you use in the process also have the parameters as required, we would recommend to also mark them as required here. This will help callers of your process to know exactly which data you need. Next to the flat data types, you may also use complex data types like arrays or structures. The structures need to be defined beforehand in the schema library, which we will use in a later lesson. In this case, we don't need to create a new structure, but we can just reuse an existing one. We first needed to check which one is fitting the API structure and then selected the desired structure. When all parameters are added, select the save button. Now on the service itself, we can start mapping the process inputs to the service inputs. The selection help will offer all process input variables, process variables, and outputs of possible services that were called before the current one. If you want to hard code the value of a flat data type, you can use double quotation marks around the value. When you select a variable like a parameter of the designer, we'll use a single quotation mark around the name. When filling in the inputs of the API, I noticed that we forgot to add some parameters and went back to adding them. As you see, it is easily corrected. So don't worry if you miss something in your first attempt, you can always go back and correct things. The first two structures we filled out on the lowest level. However, if you already got a matching structure, you can also perform the mapping on a higher level of the structure like you see for the parameter value structure. After completing the mapping of the inputs of the log data collection service, we are done with designing our first production process. You could also select the end element and forward the outputs of the API to the caller, but didn't do so for now. With the completed design, we are ready to deploy. Remember to save first and then deploy the design. Depending on the size of the design, the deployment can take some minutes, but simple designs like this are much faster. When the deployment is done, you will get some message that the design was successfully deployed and the status on the top left side of the design will change. Congratulations. You develop your first design.

Building a Production Process (Part 3)

In this last video of the lesson, we will test the production process we built previously. In this case, we will just use the design environment for this later on you will learn about more ways to trigger production processes. In the business scenario, we would trigger the production process based on the sensor data the prod con receives from the torque wrench. To start the production process from the production process designer, we already navigated back into the design and process and can now execute the process. Therefore, we just select the run button and put in all the required data inputs. For the flat data types, this is fairly simple. You just type in the data you want to pass. The DC parameter JSON is a bit more complex. You can either just type in the structure you want to pass over, or use the value help which will assist you with the information from the schema library. With all the data filled and we can run the process. The message tells you that the production process was executed without any errors, but But to check whether the data was correctly recorded, we will navigate back to the pod to check the values once more. As you can see, the collection was successful. This concludes the first demonstration on how to build production processes. Now you should be able to create your own first production process. In a later demonstration, we will extend the example by adding error handling in case the parameters are out of range.