We often hear about customising business rules and logic. A lot of people have trouble with figuring out how to do this. Often, when software is developed, we rush the software out the door for one customer, but then realise that when we attempt to give the next customer the same software, the logic doesn't quite fit. Perhaps Customer A has a mandatory field while Customer B doesn't always want to fill that value in.
Perhaps your customer wants to see a list of sales on screen that are about $100. This could be done with an SQL query but what about a case where the customer wants to recursively search through a list of sales related to other sales?
These are scenarios that come up time and time again. Logic that might change can't be hard coded.
Windows Workflow (WF) is a good solution to this problem. What is WF?
Forget all the hype about WF. People talk about using it to map business processes, people use buzz words and so on. Ignore all that rubbish. WF is simply a way of programming without writing code (or at least very little code). Basically you pass arguments in to a WF activity, it does some processing and then spits out the result. Sound familiar? It does and that it is because it is no different to executing normal code.
Except, WF allows you to store logic in a Xaml file rather than a DLL. This means that you don't need to compile the logic and even better Microsoft supplies an editor control to edit the logic. So, you can create hooks in your code when leverage various WF workflows. It's very simple.
Sample App - WorkflowEditor
This is a very simple WPF app. It leverages the WF editing control. It simply allows you to open a WF Xaml file, edit it and then save it. To see how this works, simply run the app and open the file Add.xaml in the bin\debug folder.
The Add.xaml workflow simply assigns the output variable by adding the two input variables together. Trying adding some if statements and so on.
The toolbox you get in this editor is very simple. You can add all kinds of Workflow Objects (google this stuff). The toolboox editor is editable after app compilation so if you're onsite you can even customise your own toolkit.
Sample App - ExecuteWorkflow
This app simply passes the input argumets on screen, passes them in to a workflow and then displays the result on screen. Try running the Add.xaml workflow which is in the WorkflowEditor project. Try editing it using the Workflow editor, and then re-running this sample.
Conclusion & Thoughts
WF is still not the answer to all kinds of logic customisation. It's still slower than code. Also, it's much more awkward coding with diagrams instead of code. However, it does open up opportunities. In some cases, you might be able to confirm logic with customers, hire configuration people to set up your instances, perhaps even write the logic in to the contract. Of course you could just compile the logic in to a DLL and maintain it, but this has always been a headache in the past and if you want to pursue this path, you're going to need to create a code editor and leverage a compile inside your app with takes time. WF is a good answer in a lot of situations.