Custom Workflow Activity
Overview
Another approach for exposing a .NET library to Workflow is to create one or more custom workflow activities to wrap the library. This should only be done if the library must be invoked in the same process as the workflow engine. Some reasons for this may be if the API works with large objects that would be slow to send/receive via service methods, or if it works with objects that cannot be represented by service data contracts.
For more information, see the MSDN documentation on the Windows WF 3.5 framework (the System.Workflow namespaces) for details on creating a custom activity.
Note: Workflow does not currently support activities created with the Windows WF 4.0 framework (the System.Activities namespaces).
For information on registering custom activities with Workflow, see Third-Party Activities.
Note: The Proficy Server service must be restarted to detect changes in the ActivityExtensions.ditafile.
- Workflow activities are directly executed by the workflow engine and do not require the extra communication overhead of a service method call.
- Custom activities appear directly in the activity toolbox.
- Custom types that are returned by custom activities can be used by other activities by binding to properties on those objects.
- Writing a set of custom activities is more complex than writing a custom service.
- The reusability of custom activities is limited because they can only be executed by workflows. They cannot, for example, be used by a form created with the display editor.
- The workflow debugger does not support custom types that are returned from activities.
- A workflow instance waits for an activity’s Execute method to complete before executing other activities in the workflow instance, even in parallel branches. Therefore, care must be taken to spend a minimal amount of time in the Execute method. Note that the currently executing activity in one workflow instance will not block the execution of other workflow instances.