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?

Hello ,

I am new to Appian and facing same problem, I am trying to find a way to capture the Process Instance error to a process variable.

Are you able to achieve this task?

Same problem in terms of "Web API starting a process and want to return meaningful error message"?

Catching errors in processes is automatically done. The process stops and a notification goes to alert receivers. They can resolve the error and restart the nodes. In my experience this is good enough most of the time.

Thank you for your guidance.

Please can you take some time and read the below business scenario and guide me if possible :

Consider we have a Vehicle Maintenance Process A which get initiated based on number of request received by End User.

Suppose today system received 1000 requests so 1000 instances will get initiated for Vehicle Maintenance Process A.

In this process we have a database operation steps and due to some reason for all 1000 request this step throw an exception.

As you mentioned " Catching errors in processes is automatically done. The process steps and a notification goes to alert receivers." -- this is working fine , i just tested it.

But if we want to catch this exception and create an Exception task for Production support team and display the error message and give them an ability to reprocess this step , then how can we achieve this ?

In a nutshell -- i want to capture step.error data and save it to process variable and then show it to User.

Additionally in one of the similar discussion i found one user mentioned something "AppianException class from Appian Java APIs " , is there a way to use this ? if so can you please provide me a reference page.

I am from IBM BPM background and there we have a JS API tw.system.step.error and Catch Exception control which we use to handle these kind of scenarios.

Thank You Sir in advance!

There is multiple answers on different levels.

If these system failures happens more often than "almost never", then you might want to think about a different integration pattern. Like a message bus which queues writes and retries.

Now, about Appian. This is not Java and there is no "Exception Throwing" in Appian. That node paused and will not move until restarted.

This could be solved by adding a "Receive Message" event which starts that node. With a high number of processes, I would not recommend it.

Why no make sure that status is tracked in DB and this process can be restarted at any time. Then you would just cancel all paused instances and restart them. This can be done on a nice Ops dashboard using a process report and some utility processes.

This is just my thoughts, maybe others have better ideas.

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.

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.

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.