Nov 21, 2011 at 8:08 PM
Edited Nov 22, 2011 at 12:18 AM
Im new to WF and State Machines. @CodeChief, where do i mark it as "Mapped". More to the point, i don't quite understand how you're are setting current state in the state entry. Can we get a sample app that shows this?
This is kind of a deal killer for me. I would like to use WF with our Silverlight app, but it seams it is not quite ready. Is there any labs on persistence and re-initializing workflow via Silverlight?
The "Mapped" setting is hidden in the properties window.
You will need to write a custom persistence participant to get it out. Don't get into writing your own store because that will end in a lot of pain I can tell you. More work is needed there! Hopefully WF5 will have nice CRUD base classes we can simply decide how
and where to store our data with.
A much simpler suggestion, considering the state machine does not even save the current state name (crazy but true), is to:
1) Don't use the platform update 1 because the state machine does not add any external value because of lack of state name. Less deployment issues then for same benefits.
2) You will have to write out the state of your workflows to use it for display during long running workflows, so just write out the other variables you are interested at the same time, e.g. a copy of the current order form or whatever the workflow is logically
processing from start to finish.
This way you avoid all the pain and get the simplest solution.
Silverlight has no workflow, but is a web service client. You communicate with workflows via web services too, like you are probably already doing (at least REST-fully) if your Silverlight app is exchanging any kind of state with it's web server (is
anything more than a flash animation or stand-alone game/demo).
Keep your Silverlight app calling a web service business tier (separate class with all your rules in straight flat coded) following the n-tier paradigm. You will save a lot of pain, get your solution to market quicker and MAYBE when WF5 is out can shift
your business tier logic into a workflow if there is any value of that.
The workflow designer is great and there is no problem with designing, saving or loading workflows as XAML. But the infrastructure behind it still puts brick walls in your way, at least fewer than WF3.5 but some pretty major ones, need I say the dreaded
"versioning" word! The workflow service host wants to persist the workflow "tree" inside an internal class, you have no chance of fixing up. So any change to the workflow hierarchy which affects a persist point means broken workflow again. And don't ask
where the rules engine has gone.
I see the benefit of workflow as it forces your logic to be visual like a diagram (customer design friendly) but mainly separate to the main gunk of code, so business rules are forced to be separate and not hidden away in various subroutines of different
parts of your code. That makes it dynamic and easy to edit (if it weren't for the versioning issue). Of course "code activities" are still there so it's sure in practice bad designs will just hack in loads of code again anyway. So there you go. Nice idea,
If you want to avoid workflow, perhaps you do this already; just make sure you have a clean SOA n-tier design and religiously separate anything which looks like a rule into this tier, even a silly little function if it is really a business rule. Make your
business tier a WCF service (like it would be if it were a workflow) then you have a migration path to switch the inside of this black box to workflow 5 or some other open source workflow engine perhaps. Wait for an indication that MS have
dealt with versioning and added a rules engine, then perhaps come back.
Sorry no time to write code samples. Don't want to gloat but I have my own SQL persistence store and XML based rules engine which works after a month of work under extreme pressure, so I know what I am talking about. That work belongs to a customer so
I can't share it but will get around to writing a different base class/sample anyone can use as a MSDN or Code Project article in the near future because I feel WF still has promise and I want to help.
In my case the customer has over 300 rules which change regularly and reference one another (hence the need for a rules engine) and a system in which many other workflows are foreseen, so workflow was the right choice in this case. I got it working
properly in WF3.5 and now 4, but it was not easy both times and never "did what it said on the tin". Surprisingly WF 4 was even harder which is really strange because it promised to solve all the issues of WF 3.5. The main reason for that was lack of documentation
(specifically behaviour and really complete samples, like you seek) and over complicated design of the WF infrastructure.