The basic steps in the design process are:
| |  | Consider where and how the action may be used, including reuse outside the workflow. |
| | | Work out how the action will need to be customised by the user, and design the properties to support this. |
| | | Decide whether a web service or a custom .Net class is the most appropriate way of implementing the action. |
| | | Look at the characteristics of the action to determine how you will structure your class. |
| | | Determine the precise behaviour of your action, including handling unexpected results. |
Custom Actions vs. Web Services
There are two approaches to implementing a new action: writing the action as a web service, or as a custom .NET class.
Custom actions can provide richer functionality and have greater access to services within the workflow engine such as transaction control. They also have a lower communication overhead as they run within the process of the workflow service, but this also means that bugs in the action (such as resource hogging or infinite loops) can impact the whole of the workflow engine.
Web services are often much simpler to write as they do not require detailed knowledge of the workflow engine. They run in a separate process (possibly on a different machine) so cannot affect the rest of the workflow engine, and can also be reused by other applications. Similarly, it may be possible to make use of an already existing web service rather than creating a new one.
Action characteristics
If you have decided that authoring a custom action is the correct approach, the first step is to design what the action should do, how it can be configured and what transitions it supports.
Actions can be broadly divided by the following characteristics:
| | | Synchronous actions execute and complete immediately, whereas Asynchronous actions must be queued on another system for later execution or wait for a user to respond. |
| | | User actions require user interaction to complete (for example asking a question), whereas System actions perform processing without involving any users (probably involving some other system). |
| | | Branching actions make a decision about which of a number of transitions to trigger based on their processing, whereas Non-branching actions always trigger the same single transition when they complete. |
As examples, a Mail action would be Synchronous, System and Non-branching, and a Yes/No Question would be Asynchronous, User and Branching.
Conventions
The following behavioural conventions should be followed when implementing actions:
| | | Non-branching actions have a single transition called "Next". |
| | | Synchronous actions perform all their processing in the StartAction method, and take no further action in ProcessActionResults. |
| | | Synchronous actions should execute in a very short time as they are executed in the workflow engine's thread. |
