Here at PAT we are developing, among many other things , a new BPM solution that initially will work for our applications, but targeted to be adapted to others by standard means (SOAP) as well as through custom connectors.
We built is using the new Workflow Foundation 4.0 shipped along with the .NET Framework 4.0.
We rehosted both the designer and the workflow runtime.
On the designer side, we customized the way the property editor behaves on the rehosted environment.
In fact, for a Business Analyst is not easy to write flows using the out-of-the-box behavior. If you need better design time support “for free” (aka Intellisense) you should have the Visual Studio IDE.
We are going to implement our Intellisense support, but this sounds not enough.
On the left-down-side we provided a property editor, that allows for each Expression Editor provide a context-specific expression. This is very powerful yet simple to use.
Well, we basically provide many property-specific features there:
- List of compatible scoped variables and arguments
- List of possible “expression templates” (where implemented by the provider).
The coolest thing is the this last one… “expression templates”. This is useful when you need to choose from predefined values, –or- when you need to choose from pre-defined expression types.
For instance, let’s take a quick example. Let’s say you have an activity “Change Ticket Status”. This Activity obviously have the property where to store the “Target Status”, right? Now, … in order to take advantage of arguments, we should have an expression editor there. But what IF the Business Analyst (BA) already knows its status and just like to write a constant value there? The BA needs to know the status code… and write it there.
We did better. We provided a “designer feature” that allows our property editor to gather a list of expression templates from the “Ticket Status Property”.
We can also provide a variable-creation logic, which is more simple. By pressing Create New Variable button you come to a “new variable” form where you define the name and choose a compatible type (in this case the type does not have other compatible types so the list is locked):
The UI here is MUCH more simpler to use that the out-of-the-box one. Because we add also human-readable description for the types (provided by some designer attributes we apply to types), and filtering on both description and type name.
Workflow Execution Monitor
From the designer console, you can see the workflow queue updated in real time:
We also provided a debugger feature that allows the user to display from the designer, the status and the trace of all the execution along with parameters.
This was done adding a TrackingPartecipant that stores the history on our own table, that, in turn, is displayed on this page.
We host all our services on our own WCF services. We have one administration service that allows the designer to perform all the “designer/administration” stuff.
We also provide a “Client” service that allows external applications to connect to the “Events” where our Workflow Definitions are attached.
We track versions of the same definition – in order to maintain compatibility with workflows already started – and also we provide Persistence support to all our workflows.
We provided a metadata-driven set of clients that allows the user to provide data to flows at any stage required by the Business Analyst:
All this stuff is interfaced externally to the End-users through:
- A “traylet” Windows-application
- A multibrowser lightweight web application where the end-user could provide answer and make the flow continue with the results.
We are going to provide in the future, “Human Interaction Clients” for other platforms, such as WP7, IPhone, Android.
I’ll provide further details on the persistence and provider-independence of this solution in a next post!