Hi,
Is there any way to handle exception and continue process execution? In other words if error occurs i need to go to different route (route 2 on print screen). It is not possible to query db to check if error will occur or not.
Simplifies process model. In real case there are much more nodes after writing to db.
Discussion posts and replies are publicly visible
The term "exception" does not mean a technical exception, like in Java, in this case. This is about a functional or business exception which results in a different flow in process.
One common example of this - suppose you have a process that sends out a survey, where each user receives a task. However, the task deadline is 7 days after the survey is started. A good use for an exception is to trigger the exception after 7 days to skip the task if the user did not complete it. This will ensure the process does not wait indefinitely for the user to complete their task.
I would just like to add a note here on the older Query DB's functionality for the "Continue on Error" parameter. This was an extremely convenient setting for us in similar situations in the past, before switching primarily to the Write to Data Store service for design convenience. It would be HUGE to see the Write to DS service upgraded with a similar setting for "Continue on Error" (I can see this beneficial for other services as well), where we can decide to throw the exception and pause, or, record the error and create custom error handling.
Agree that the Write to DS node is very sound, however the error is typically with the underlying database. For example, we have many processes that interact with our Oracle Financials environment for retrieving, and writing data. We do not control that environment, and they have standard maintenance periods and the occasional unplanned outage. Say we have 1000 process instances running which hit the Oracle DB during the outage. With Write to DS, they all fail and require manual restarts. When we used Query DB, we would have each failed call continue on error, log it, and wait at a Receive Message event. Once the DB was back online, we could resume all processes with one click, sending messages to the waiting nodes.
There is one solution that I have tested and might be useful. Everything depends on your needs but you can have separate process that will only have one node 'write to database' and then from main process you will call this sub process but Asynchronously so even if there is error on sub process your main process will continue. To check results of your sub process in main process you can use query db to check whether db is updated or not. Drawback of such solution is that you will have multiple nodes with error on app monitoring
Asynchronous Subprocesses
Yes you are right Peter Lewis I tried to use Pessimistic locking and I tried to use separate table for storing locks but it did not worked as expected.
Solution that finally worked for me was to setup Process Display Name to variable so I can then use Process Report to get list of active process models. Based on Process Display Name queryProcessAnalytics function returns me this name in c0 which I can use to identify how many people are trying to run same process for same record. Based on that I can wait 2-3 seconds and recheck and write to db if there is only me who run this process.