How can I get the process instance errors and save it into any process variable?

Write to datastore also has an onError output that can be configured.

yes, you are right. but I use the write to data store entity node in the process, and webapi start this process, not use a!writeToDataStoreEntity() in the interface directly, and my problem is how can I capture the process instance error message and configure back in onError()/onSuccess() outputs?

thank you Sir for your response.

One school of thought is: this is already built for you! If, in your example, the database operation (Write to Datastore smart service) fails, an alert is raised to the relevant team (assuming you've configured this correctly on the process model) and members of that team can navigate to the Monitoring tab of Designer and see all of the failed instances, They can then open up an individual instance, conduct whatever remediation is required and reprocess the instance to a successful completion.

You appear to want to take this a step further and create a dedicated Application for error handling. I've seen this done elsewhere and it requires you to make an assumption that every instance may fail. So, in parallel to the business process, you'd start a thread that is designed to raise the Task you described (with a time delay to allow for a longer-than-usual processing time) and, if your main process succeeds, it kills this process. 

This comes with the obvious issue in that if your main process is failing for a systemic reason then your monitoring/error handling process will also fail so now you have an even larger mess to clean up!

You might be better of putting your efforts into building something that prevents "failure demand" That is: if your system is aware that there are failures occurring because, say, a WebService is unavailable, you might want to prevent new transactions from being started that will be guaranteed to fail.

thanks Stewart Burchell for taking the time and responding back to my query.

Looks like your are from Appian Product team . Let me take this opportunity to learn from Appian Expert like you.

Couple of points which i do not understand from your response :

1. Monitoring tab of Designer and see all of the failed instances -- is this the recommended way to handle and reprocess failed instances' steps in Production ?

2. You appear to want to take this a step further and create a dedicated Application for error handling : I do not want to create a separate Application to handle exceptions. i want to include exception handling step inside the same application .. adding  a screenshot below for your reference

 3. if your system is aware that there are failures occurring because, say, a WebService is unavailable, you might want to prevent new transactions from being started that will be guaranteed to fail. : I completely agree with this point

Additionally , is there any specific reason why System is not allowing us to capture Step error details in a process variable ? ( attaching screenshot for reference)

Thank you for helping me.

1. Yes

2. In your diagram I assume the Exception flow from 'Get Weather Details' to 'Weather Exception' is a timer-based exception? This will not work as the timer will only trigger whilst the node is NOT in an exception (red line) state. As I said, you need to think differently. Your flow in your Production Support should ALWAYS be initiated (held back  from processing by the use of a timer) and then killed off if your main flow is successful.

3. Different node types allow you, the Designer, to handle errors in different ways. Some allow you to continue processing and provide you access to the error details (as defined in the Data outputs tab) and others do not. For the former you can design to route to an exception flow as part of the main flow. For the latter you have to design as I've indicated in 2.

To add to what Stewart said. The noun "Exception" in Appian process models is not about a technical exception, but a business exception.

Thanks ...yes, configuring an Exception flow is about thinking about things like "What should happen next if a User doesn't doesn't act on their Task in a timely manner?" or "What should happen next if the Web Service I'm calling hangs and doesn't respond in a timely manner?".

At the same time I'm conflicted because the very same questions should apply if any given step has a "Technical" error.

thanks Stewart Burchell for your response.

business exception can we easily handle programmatically but i am trying to find a better way to handle technical exception.

I my attached screenshot Weather API is throwing business exception i.e. -- city not found , or server down

and add leave details( A database call) is more about technical exception (red line).

Anyway thanks & Stewart Burchell for guiding me.

OK. Then let's dive in. As long as you get some response, even if it's a HTTP 500 code, you can easily react on it.

In my experience the only "real" issues come up when a timeout occurs. Then the node just stops. We can build crazy things around it, but I am quite successful with just ignoring that. If this does not happen too often, the Ops team can manage this easily.

Yes Sir , anything other than HTTP 200 code is considered as exception and save that response in db for reprocess in future again if required.

Yes Sir , anything other than HTTP 200 code is considered as exception and save that response in db for reprocess in future again if required.