With the current functionality of Forms, with a Workflow task you can tell it to wait until the Workflow has completed. This is great except for those times when a workflow instance terminates and then the Forms instance is stuck. It would be nice if the Workflow instance could tell the Forms instance that it terminated and then be able to set a routing condition for that in Forms. This way a user could be assigned a task to resubmit it, or a timer event could be placed in the process diagram to wait x amount of minutes and try again.
Question
Question
Feature Request: Ability to Detect if Workflow Terminated and Route
Replies
The current implementation is done on the presumption that workflow termination is a bad thing and you might want to retry it after fixing the workflow definition. Which is why the Forms task suspends.
But sure, we can look into giving people more options.
Sometimes workflows terminate due to external factors though, rather than due to problems with the workflow definition. Sure, some of those can be handled with try-catch, but it's not possible to foresee every single exception scenario.
For instance, we had a workflow terminate the other day because its email activity failed. We looked into it and noticed that there was a very brief (under 2 minutes) outage of their email server during that time. This outage in their email server cascaded all the way to the Forms instance, which got suspended.
We retried that instance later and it worked, but Forms doesn't have the option to "retry tasks automatically if they get suspended", and it also can't notify an administrator like Workflow can, so the only reason we found out about the issue is that the end-user complained... which is never a good thing.
I think if it could communicate back to the Forms instance that it terminated, that would be the best scenario so that the Process Admin can decide what they want to do within the process modeler. That way we are not assuming what everyone would want to do.
A nice feature would be to make Workflow more robust in how it deals with bad connections to email servers. Our PEs have used multiple try-catches with time delays after each one when trying to send mail when the mail server isn't reliable as a way of working around unreliable email servers.
Maybe a 'retry x times every y minutes' setting in Email Server Properties in the Workflow Administration console for the email external object.
That and something built into Workflow that would fire off an error or message when workflow loses connectivity to the email server. Workflow sending a Warning to the event viewer about being unable to connect to a mail server would be pretty handy.
Yes, this would be good. We have run into it several times as well, and it's always annoying.
I feel like this could be easily handled by adding a timeout sub-option to the "wait for workflow to complete" option. Most of the time, you tend to have a pretty good idea of how long the workflow is supposed to take (especially since workflow provides those statistics!), which you can use as the timeout value. Then you can have a gateway immediately following the workflow task that checks the value of a dataset that workflow was supposed to set, to see if it finished successfully or terminated.
The other option would be for Workflow to communicate the termination to the Forms instance that started it. The framework for that type of thing already exists (i.e. Workflow can email someone if an instance terminates) so it may be possible to latch this on to that too.