Purchase Order Object - Managing Work Flow

Purchase Order Object - Managing Work Flow

Old forum URL: forums.lhotka.net/forums/t/5093.aspx


xxxJasonxxx posted on Monday, July 14, 2008

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 3.0.4.0..  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. 

Thanks!

Jason

JoeFallon1 replied on Tuesday, July 15, 2008

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.

YMMV.

Joe

 

xxxJasonxxx replied on Tuesday, July 15, 2008

Joe:

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.  :-)

Jason

JoeFallon1 replied on Tuesday, July 15, 2008

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.

KISS.

Joe

 

xxxJasonxxx replied on Tuesday, July 15, 2008

Thanks Joe!  I really like your idea.  I'm going to run that by our team as a new option to consider.

jeff replied on Tuesday, July 15, 2008

One app I did a while back had a table that defined what status choices were valid to transition to from a given status. And there was a visual designer so the end users could change around the "workflow" which really was just this simple transition flow diagram. So some managers could kick something back to a previous step or whatever, and ultimately with the right approvals the entity would get to the "closed" or final stage. Each transition was stored in a history table so users could add comments about why they were changing to whatever status.







xxxJasonxxx replied on Friday, July 25, 2008

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