We are currently building an application that makes use of a non-simple approval process, which involves multiple levels of approval, returning, reviewing, notifications etc..
Because of the said requirement, we were asked to make use of a workflow framework also to facilitate process transparency.
On the prototype we have succesfully incorporated the workflow and it works fine. however, we cannot determine the actions that should be available to the user. For example, I have the following recieve operations: create(), managerApprove(), RAApprove(), ORMApprove().. now if I call them in order, using the correct user name then they will work. Obviously, if I don't call them in order, then it will throw a FaultException because its not in the correct state. Question is, how will I know which functions are available to expose in the UI - say, if its currently waiting for manager approval then just show an approval button for the manager...
As a workaround, I've created another WCF service that retrieves the same data from the database and then determines the correct UI state (which actions can be performed by the user). I think this is a duplication of logic, since that's supposed in the WF already.
Also, if the WF changes then it my seperate WCF service may potentially break. For example, if I switch the approval order in the workflow then I need to update the logic in the WCF service as well. Otherwise, it would show an invalid page state and clicking approve will invoke the wrong method and cause a FaultException.
Any help will be much appreciated... I'm really new to WF4.
UPDATE:
My colleague put my question this way:
What's the best design for a web app that adopts WF?
The main reasons why WF is being considered - The workflows involved are long running - Workflows are human workflows - they need to coordinate actions of real people - Process Transparency
Also, how should the workflow integrate with the UI? - how will the UI know what state in should be in and what pages to show which users?
The workflow itself doesn't expose the information directly. It is there as each pending Receive is a named bookmark and the bookmark name contains the SOAP action it supports as well as the service contract and namespace. The easiest way of getting at this into is by adding the SqlWorkflowInstanceStore to the WorkflowServiceHost and checking the column with the pending bookmarks. It isn't perfect as this will give you the information as it was last persisted which is not necessarily the current state but it has worked for me in a number of applications. Just make sure to set the TimeToPersist to a pretty low value and add some Persist activities in strategic places.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With