I have a specific use-case for an application under development that I am struggling to solve. The application is designed to be deployed either stand-alone (with its own back-end data store), integrated with a third-party package (like an ERP system) or both. So, when a user posts a transaction to the system, the steps required will vary based on the deployment scenario. I'm looking to leverage Windows Workflow Foundation (WF) for the processing side, especially since it will allow us to develop different workflows for each deployment scenario that we can "plug" into the application. My problem is figuring out how to properly integrate WF with my CSLA business objects. Oh, and the application uses a web service interface.
So, using a simple inventory scenario as an example, let's say that the customer has to record receipt of a particular item into two different data stores: one used by accounting to record the receipt of the item for payment and another that tracks the inventory for shipping and receiving purposes.
When the client application posts that it received an item, it calls my web service and passes the item information. Here's where the question is. Should the web service start the workflow process or should there be an intermediary (business?) object that is used by the service?
For example, the service could start the PostReceiptActivity (workflow) which would instantiate my PostReceipt CSLA business object, populate it with the values provided by the client, validate the object then Save it. But who handles the fact that it has to be stored in two places? Do I create two BO's - one for each data store? This seems logical and my workflow can be designed to handle what happens if one write fails, etc. But wouldn't each of these steps actually be activities within the workflow? Then, if I deployed the solution in a stand-along environment, the workflow could be changed to only include the one activity.
Am I making sense? I'm sure someone else has had to implement something similar, can you share some insights how you did it?
Thanks in advance!
So am I heading down the wrong path? I would certainly appreciate your take.
I don’t know about the _wrong_ path – just one
that is not well charted :)
There’ve been a couple threads on WF here before, and my
views haven’t changed.
I think it is good when you want power users to edit your
workflows (and you actually believe that makes any sense). Or at least low-end
developers (which might make more sense).
I think it is good (potentially) when you have long-running
processes that you want to suspend/resume over a period of
hours/days/weeks/months. While you can do that yourself with state tracking
tables, it might be the case that WF is easier – but only way to
know is to try it.
I think it is good when using the WCF/WF integration in VS 2008.
Microsoft is making it pretty darn easy to create/consume services with
workflows. So there’s something to be said for creating a WCF service
where the service implementation is a workflow – just to take advantage
of the tooling in VS.
Rocky
From: SonOfPirate
[mailto:cslanet@lhotka.net]
Sent: Tuesday, July 29, 2008 4:42 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Where does WF fit in?
So am I heading down the wrong path? I would certainly appreciate your
take.
Yea, I've noticed that support and had considered exposing the workflow directly as a service; however, we allow the actual workflow to be swapped in the application's configuration file as a way to further customize the application (eg, when the logic is so different that we create a new, compiled workflow for the user).
In addition, something I failed to mention earlier, is that we support both Web (for public use) and WCF (for internal client applications) services. So, there is a common service class that both service implementations delegate to. This class is where we resolve which workflow activity to use based on the configuration settings.
It seems after giving this more thought that the proper point of integration for WF and CSLA is the individual WF activity. In other words, my business objects are there to support what each activity is supposed to accomplish. For instance, if the workflow activity is used to persist data, then I would use a business object to do this.
However, when the service call is first made, it makes sense to perform authorization to make sure the user can perform the operation. This would require a business object up-front. Or maybe authorization should be an activity in the workflow???
And then I should validate the BO before going too far into a workflow. Another activity?
I'm still uneasy about how to put it all together (obviously). Like you said, uncharted territory. I would certainly feel better if I had an example to reference.
The Using CSLA .NET 3.0 ebook has a chapter specifically
covering WF, including the idea of using a Command object and the
Csla.Workflow.WorkflowManager to easily launch a workflow. You could consider putting
the authorization code into the Command object, so only an authorized user was
allowed to execute the command. If authorized, the command would use the
WorkflowManager to launch the workflow based on the workflow type name from
your config file.
Rocky
Copyright (c) Marimer LLC