Dear community,
I have a start process web api, the process is updating the metadata table.
My facing issue is that API response success even when write to data store entity error.
The expected result should be when process executing error, we can expose the process instance error in web api response body.
Therefore, how can I get the process instance error? then I can save it into process variable, and in the api, we can get it through ProcessInfo.
Thanks in advance for your answers.
Discussion posts and replies are publicly visible
a!startProcess() has two parameters which help, onSuccess and onError. onError happens when a node in the process model runs into an execution error and onSuccess happens when the activity chaining for you process completes and none of those nodes hit an error. For your use case, it seems like you need to add an a!httpResponse() in the onError parameter.
Write to datastore also has an onError output that can be configured.
In my case, when write to data store entity node encounter error, a!startProcess still response success code 200, it didn't flow into onError condition, that's why I have this asking.
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?
Did you enable chaining at least up to that node?
BTW, why does this node fail in the first place?
Yes, I have enabled activity chaining for the whole process paths.
Why the node failed? it's because the request data passed the incorrect date format, when insert into DB, process instance show below error:
" com.mysql.jdbc.MysqlDataTruncation: Data truncation: Incorrect datetime value: '292269055-12-02 16:47:04.194' for column 'DUE_DATE' at row ....."
OK. The first rule when implementing APIs is: Do not trust incoming data! I recommend to check and validate the data before trying to write it to DB. This allows you to return any error messages you like. A failed process is no proper error handling.
If there is no way to capture this kind of data for failed process, I will go into this way that validate data and give customized response before start process. Many thanks Stefan~
You can write your own error handling around this. It's not great if you want to surface the details of an error but you can at least handle this gracefully.
Your process model needs to be chained. You can add one or more Boolean flags and default them all to false e.g. isDataValid, isDataWrittenToDatabase, Then as the process proceeds you can toggle these to 'true' e.g. if you have a validation step then you can update the 'isDataValid' to true. The same for the Write To Datastore. If this is successful the next thing you would do would be to update the 'isDataWrittenToDatabase' flag to true.
These pv!s will then be available to your WebAPI and you can then customise your HttpReponse according to what those flags are set to. As I said this will at least handle failures gracefully. Getting the specifics of the failure of a Write To Datastore node would be a lot more complicated (probably as an asynchronous process that trawls the logs in some fashion).
I also echo - never trust the data being sent to your WebAPI. Always conduct the necessary validations on it before attempting to write to the database (or write to a staging table with no validation, and then conduct an off-line validation exercise before committing to your operational tables).
An afterword: please consider raising a request to Appian Engineering to allow developers to conduct their own error handling so that you can do exactly what I think you're looking to do (the equivalent of a 'try'/'throw'/'catch' pattern).