Skip to Content
Technical Articles
Author's profile photo Manoel Costa

Recover failed Production Processes within SAP Digital Manufacturing


We are all aware that SAP Digital Manufacturing’s standard capabilities can be easily extended and customized using Production Processes, leveraging Low Code / No Code capabilities. However, what should be our course of action when a Production Process fails?

In this blog post, I will demonstrate how to handle exceptions in Production Processes, recover failed Production Process instances, and recover / retry them.

To accomplish this, we will replace the standard Start plugin, which initiates SFCs (Shop Floor Control) operations in PODs (Production Operator Dashboards), with a custom Start flow built within a Production Process. This custom flow will be invoked asynchronously, and I will intentionally induce a failure by providing an empty mandatory Input Parameter.

While this example is quite simple and hypothetical, the same principles can be easily applied to any other service, logic, or workflow.

Production Process Setup

In Design Production Processes app, create a new Production Process and a new Cloud Process.

Drag and Drop a “Start” Control, and create required Input Parameters.

* Note that I left “inSfc” Input Parameter as “Not Required”, as we will use this parameter further down below to deliberately force an error by providing an empty SFC input value.

Create a POD Connection to your Plant, Resource and Work Center, so we can display an error message in POD during the exception handling flow as well.

Add “Start SFCs” service and link all Body Parameters to the respective Input Parameters accordingly.

Now, let’s create the exception handling flow.

To do that, Drag and Drop an “Error Catch” Control on top of the “Start SFCs” service, and configure it accordingly by selecting all the error codes that must be catched. In this case, I just selected all of them.

Drag and Drop a “POD Message” Control and configure it accordingly by defining the error message that will be displayed in POD when the exception handling flow is triggered.

Click “Additional Options” (“…”) at the top right corner of the Production Process and select “Manage Error Codes”.

Create some “Error Codes” including “Key” and “Message” details, which will be used later on in the exception handling flow.

Drag and Drop an “Error End” Control and configure it accordingly by defining an “Error Code”, switching “ON” the “Show Process in Recovery List” setting, adjusting “Termination Mode” and selecting “Parameter(s) Causing the Failure” details.

Don’t forget to publish your Cloud Process to Service Registry, so it can be mapped in POD Designer.

To do that, click “Additional Options” (“…”) at the top right corner of the Cloud Process and select “Edit Header”.

Switch ON “Publish to Service Registry” setting.

Save and deploy your Production Process.

POD Setup

Create or edit an existing POD and set your newly created Production Process behind the Start Action button, replacing the standard Start plugin.

Click “Configuration” for your Production Process mapping and change “Call Type” parameter to Asynchornous.

*** This step is very important, as only asynchronously called Production Processes are sent to Process Recovery List when they fail.

Map the Production Process Input Parameters but leave inSfc as “None” on purpose, which will force an error during the Start SFC service call.

Click “Configure Notifications” at the top right corner and enable Production Processes notifications as follows:

Save and publish your POD.


Now that all the needed setup is in place, you can go ahead and give it a try.

To do that, open your POD, select any SFC and click “Start” Action Button to trigger the custom Start flow defined in your newly created Production Process, which will always fail, as the Production Process inSfc Input Parameter was set to “None” in POD Designer on purpose, but it’s required by the Start SFCs service, triggeting the Production Process exception flow.

Once the exception flow is triggered, “POD Message” Control will show up with the pre-defined error message in POD.

As we enabled “Require Confirmation” setting in the “POD Message” Control configuration, you must press “OK” button before the Production Processes can carry on and continue the flow execution, otherwise the Production Process exection will keep hanging until “OK” button is pressed.

Now, go to Monitor Production Processes and check your Process Instance details, which will have the “Completed with Error” Status, caused by the “Error End” Control.


In the Process Instance details page, you should be able to see more details of the Production Process execution, including the error message defined in the “Error End” Control.

Recover Production Processes

If your Production Processes execution failed when being executed asynchronously and having “Show Process in Recovery List” enabled in “Error End” Control, it should land in Recover Production Processes.

In the Process Instance details page, you should be able to see more details of the Production Process failure, including Error Code and Description, and the Input Parameters (Variables) used to trigger this Production Process.

For a failed Process Instance, in the top right corner, you can choose to “Delete” it, if it’s no longer needed or valid, to “Retry” it right away with the very same Input Parameters (Variables) or to “Change Input and Retry” it, where you can change the Input Parameters (Variables) before retrying.

In this case, as inSfc value is empty, this Production Process will never work unless we use “Change Input and Retry” to update inSfc value before retrying.

So, in order to properly reprocess this Process Instance, click “Change Input and Retry” button at the top right corner and inform a SFC ID “In Queue” for that Plant, Operation and Resource combination and click “Change Input and Retry” button to retry it.

If all the Input Parameters are valid, this Process Instance should run smoothly this time.



SAP Digital Manufacturing Production Processes and Recover Production Processes capabilities used in combination offer a simple and intuitive way to effective handle and recover/retry failed Production Process.

While the example used here may be simplistic and hypothetical, the underlying principles are applicable to any other services, logic, and workflows.


Do you like this post? Please let me know in the comments section what you think. Any feedback is highly appreciated.

Or, if you have any questions, please checkĀ SAP Community Q&A Area, or comment down below.


Manoel Costa

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Dilahan Ciloglu
      Dilahan Ciloglu

      Hi Manoel,

      Thank you for the article. I tried the same scenario with exactly the same requirements but I didn't get any results. Firstly, I made the same design and got the error message which I attained at the pod, then I was able to view it at the Recover Production Processes app after that I select my process instance and clicked on Change Input and Retry button, gave the necessary input and retry but nothing happened I didn't get any messages. I checked my pod also nothing was changed, order was still in "in queue" status. However, when I run the design at Design Production Process app with the same inputs it works and order status changes. Is there any other rules or settings that I need to take in consideration ?

      Author's profile photo Manoel Costa
      Manoel Costa
      Blog Post Author

      Hello Dilahan,

      The exemple above is for educational purposes only and don't necessarily reflect a real world use case where SFC input is not marked as mandatory in a Production Process and is provided blank from POD.

      If you try the example above As Is, using an optional input parameter and not giving it an input value, Recover Production Process app will indeed fail to recover it. This is a known gap which should be addressed in DM upcoming releases.

      I suggest you use the example above as an input to build your own Use Cases, which should work just fine.

      Hope it helps,