I'm trying to figure out the best way to manage work flow for a purchase order object.....
I've been working on an application for handling our company's purchase orders. I've encapsulated the basic purchase order business logic inside of objects using CSLA 188.8.131.52.. The UI is Windows forms.
Currently, I'm trying to work out how to handle the multiple steps/statuses a purchase order follows as it gradually moves through our system ("work flow"???). My original idea was to use the "State" Design Pattern and have all of this logic encapsulated inside the business objects.
However, it was recently suggested that I should use Windows Workflow Foundation instead of the "State" Design Pattern. I am not very familiar with Workflow Foundation and I have some concerns.
At first glance Workflow Foundation appears to be something that I would use for writing scheduled nighttime processes that kick off and perform several tasks in a controlled sequence. And at first glance, I'm struggling to see how WF would work with an event-driven Windows application that starts and stops with no continuous flow. Would WF be appropriate for my purchase order Windows app I described above?
I'm also concerned about the encapsulation of rules and logic related to my purchase order object. It sounds like if I somehow use WF, some of the validation code and security code related to a purchase order would end up in the WF code instead of my purchase order object. I really like how the CSLA-based objects encapsulate everything. So the thought of breaking this encapsulation makes me very uncomfortable (maybe I've become too obsessed with my objects lately). Am I thinking correctly and is this bad?
Any other advise/experiences/links you can share related to this would be greatly appreciated.
I write PO and Invoice systems for a living and do not use Windows Workflow. (Nor would I want to.)
I have a large Web app that is CSLA based. It is in production at numerous Fortune 500 companies and has been for 4-5 years.
I try and "keep it simple" so I just use a Status field and switch the values as it moves into different states.
I totally agree with the K.I.S.S. (keep it simple...) ideology -- assuming you're operating in an environment that will allow it. Everything seems to gravitate towards getting way overcomplicated if you let it.
My purchase order object has a "Status" property, but that just tells us what the current status is. It doesn't provide any work flow management. How do you handle which status transitions are allowed and which are not? Also, how do you handle which functionality is allowed or not allowed in each status? These questions are why I'm looking at the State pattern and WF.
Our purchase orders have 23 different statuses all of which prevent/allow certain activities. So I'm trying to come up with a way to manage this. I think at our company, the K.I.S.S. train may have derailed and left behind a lot of carnage. :-)
23?? I won't ask.
I only have a handful for POs and Invoices.
Essentially a given step in the flow equates to a Screen (or offline task) which equates to a BO. So the BO in charge of that Use Case is the one that determines if everything is valid and then saves the data and changes the status to the next step.
So a user could enter something in a screen and it is status=1.
Then a task can pick it up and validate it and change it to status=2.
Then users who need to work with stuff at status=2 open their screens and see the list of fully validated items. They can pick one for processing which will change the status to 3.
Then an approval workflow could kick in (which is separate from status in my app.) As it goes through all levels of approval the status stays the same but the approval data changes to show who approved what when.
When the last approver gives the Ok - then the status changes to 4.
Or it could be rejected which may be status 5.
Or Cancelled - status 6.
Data could be exported by an offline task - change status to 7.
Status values of 1-7 are just figurative - you can call them anything.
Anyway - that's how I do it.
Thanks Joe! I really like your idea. I'm going to run that by our team as a new option to consider.
We decided to bring in a Magenic consultant to help us determine if/how Microsoft's WF would work for us. We've worked with Magenic on a couple other projects and all the consultants they've sent us have been outstanding.
It sounds like there are 2 kinds of WF workflows - Sequential and State Machine. I think in our situation we need State Machine. But unfortunately, the majority of the documentation and examples we've found focus on Sequential. So at this point we're waiting for the the Magenic guy to come next week and show us what we need to do.
Copyright (c) Marimer LLC