How to call Workflow - Custom

An alternative to the "Managed" runtime events, meaning that the process of activating workflow process creates and updates runtime events and action sets, is to create your own runtime events and action sets. This allows you to create complex sequences of workflow process calls, perhaps setting several profile attributes that are needed in the workflow, calling different versions a workflow process based on mutually exclusive conditional expressions, and calling workflow in different calling modes. With great power comes great responsibility. Walking away from the simple management the activation process provides gives you a lot of flexibility but it also makes your system more complicated and deployment a bit trickier. I think I have said deployment is trick either way now, which when you are talking about complicated processes is probably true regardless. I tend to think the custom route is easier to understand because you control all the steps and the names are more logical because they are your names.

So let me start by defining what I mean by custom managed events. You can achieve the same affect as the managed architecture by creating your own runtime event in the GUI (Administration - Runtime Events) with the same parameters used in the tools workflow pallet, start branch step attributes.

Then you create a custom Action Set with as many custom Actions as necessary. Conditional expressions can be used to prevent the instantiation of a workflow process manager component unnecessarily.The step that needs to actually calls the workflow will have an Action Type of 'BusService'. The Business Service Name will depend on what mode you want the workflow to run in. To simply replicate what the managed process does, just set the Business Process Name to 'Workflow Process Manager', the Method to 'RunProcess', and the Context to "ProcessName", "workflow name" where workflow name is. . . you know. This is a Name, Value pair format for properties accepted by the business service.
It is important to recognize that dynamic process properties cannot be passed to the WF through the business service context. This is because process properties are expected as a child property set. Plus the business service context cannot resolve expressions. If you need to pass dynamic process properties to the workflow, you have two options. You can either set a profile attribute that can be referenced in the workflow or you can create a shell service which I will get into in my next post.