The approach to the workflow execution has been changed. Now, the process is executed using a run loop. Therefore, you can create an endless workflow. One iteration of the loop is equivalent to one Activity. By default, the maximum number of iterations is limited by Int64.MaxValue. However, you can change it as follows:
Workflow Engine.NET V3.5
IMPORTANT! If in your project the Action Provider has changed (after the first initialization) using the method workflowRuntime.WithActionProvider(...) replace this code with the following call workflowRuntime.ClearActionProvider().WithActionProvider(...)
IMPORTANT! If in your project the Rule Provider has changed (after the first initialization) using the method workflowRuntime.WithRuleProvider(...) replace this code with the following call workflowRuntime.ClearRuleProvider().WithRuleProvider(...)
IMPORTANT! If in your project the Designer Autocomplete Provider has changed (after the first initialization) using the method workflowRuntime.WithDesignerAutocompleteProvider(...) replace this code with the following call workflowRuntime.ClearDesignerAutocompleteProvider().WithDesignerAutocompleteProvider(...)
IMPORTANT! If in your project the Designer Parameter Format Provider has changed (after the first initialization) using the method workflowRuntime.WithDesignerParameterFormatProvider(...) replace this code with the following call workflowRuntime.ClearDesignerParameterFormatProvider().WithDesignerParameterFormatProvider(...)
Overall, I prefer Stateless because it's simpler for more things that WF. Sure, it's nice to be able to design your workflow graphically, but when you need to implement something more difficult than a sequential workflow (like the state machine workflow), you'll need to work with ExternalDataExchange just to make the right state transitions. It's probably not hard, but considering that and the fact that you need to implement a persistence service to pause a workflow just seemed unappealing to me. I don't have a need to persist a workflow to disk for later execution anyway... so I will be using regular events to deal with this in Stateless. Error handling is easily doable in Stateless (I've been successful with it), but the implementation I've taken is questionable, and is the topic of another discussion (which I'm searching for now on SO!). I might be posting a question regarding this very soon.
Late to the party. We've used Stateless in production now for over a year and a half, no issues. It is a very elegant solution for processing workflows and you quickly integrate the states with your data model. We represent our states with and int in SQL, so you can run the state machine in ASP.Net in process. This is true for long running workflows as well.
Workflow Engine is an open source workflow engine for .NET and .NET Core that enables you to add custom executable .NET and Java workflows of any complexity to any software, be it your own creation or a third-party solution, with minimal changes to existing code.
Its core features are:
- HTML5 visual designer. Design, model, edit and visualize your custom workflows.
- Workflow version control. Keep track of your workflow changes and easily revert them.
- Parallel workflow support. Split workflows into branches that execute tasks concurrently.
- XML import/export. Export your workflows for further reuse and sharing.
- Localization support. Translate user interface to multiple languages of your choice.
- In-built workflow timers. Set intervals or specify time to run custom actions and workflow tasks.
Workflow Engine build for .NET core includes a set of pre-built providers for the following databases:
- MS SQL Server
- PostgreSQL
- Oracle
- MySQL
Windows Workflow Foundation (WF) in .NET Framework 4.5 introduces many new features, such as new activities, designer capabilities, and workflow development models. Many, but not all, of the new workflow features introduced in .NET Framework 4.5 are supported in the re-hosted workflow designer. For more information about the new features that are supported, see Support for New Workflow Foundation 4.5 Features in the Rehosted Workflow Designer. For more information about migrating .NET Framework 3.0 and .NET Framework 3.5 workflow applications to use the latest version, see Migration Guidance. This article provides an overview of the new workflow features introduced in .NET Framework 4.5.
.NET Framework 4.5 introduced several new versioning features based around the new WorkflowIdentity class. WorkflowIdentity provides workflow application authors a mechanism for mapping a persisted workflow instance with its definition.
Developers using WorkflowApplication hosting can use WorkflowIdentity to enable hosting multiple versions of a workflow side-by-side. Persisted workflow instances can be loaded using the new WorkflowApplicationInstance class, and then the DefinitionIdentity can be used by the host to provide the correct version of the workflow definition when instantiating the WorkflowApplication. For more information, see Using WorkflowIdentity and Versioning and How to: Host Multiple Versions of a Workflow Side-by-Side.
WorkflowServiceHost is now a multi-version host. When a new version of a workflow service is deployed, new instances are created using the new service, but existing instances complete using the previous version. For more information, see Side by Side Versioning in WorkflowServiceHost.
Dynamic update is introduced which provides a mechanism for updating the definition of a persisted workflow instance. For more information, see Dynamic Update and How to: Update the Definition of a Running Workflow Instance.
A SqlWorkflowInstanceStoreSchemaUpgrade.sql database script is provided to upgrade persistence databases created using the .NET Framework 4 database scripts. This script updates .NET Framework 4 persistence databases to support the new versioning capabilities introduced in .NET Framework 4.5. The persisted workflow instances in the database are given default versioning values, and can participate in side-by-side execution and dynamic update. For more information, see Upgrading .NET Framework 4 Persistence Databases to Support Workflow Versioning.
NoPersistScope is a new container activity that prevents a workflow from being persisted when the NoPersistScope's child activities are executing. This is useful in scenarios where it is not appropriate for the workflow to be persisted, such as when the workflow is using machine-specific resources such as file handles, or during database transactions. Previously, to prevent persistence from occurring during an activity's execution, a custom NativeActivity that used a NoPersistHandle was required.
Workflows in .NET Framework 4 required a fully trusted application domain. In .NET Framework 4.5, workflows can operate in a partial trust environment. In a partial trust environment, third-party components can be used without granting them full access to the resources of the host. Some concerns about running workflows in partial trust are as follows:
Activity authors should override CacheMetadata to avoid having the workflow runtime automatically execute reflection against the type. Arguments and child activities must be non-null, and Bind must be called explicitly. For more information on overriding CacheMetadata, see Exposing data with CacheMetadata. Also, instances of arguments that are of a type that is internal or private must be explicitly created in CacheMetadata to avoid being created by reflection.
To make larger workflows more manageable, workflows can now be searched by keyword. This feature is only available in Visual Studio; this feature is not available in a rehosted designer. There are two kinds of searches available:
Keywords searched in workflows will match the actual content of the workflow files. The search results will be shown in Visual Studio Find Results view pane. Double-clicking the result item will navigate to the activity which contains the match in workflow designer.
Since a workflow or certain container activities (such as NoPersistScope) can only contain a single body activity, adding a second activity required the developer to delete the first activity, add a Sequence activity, and then add both activities to the sequence activity. Starting with .NET Framework 4.5, when adding a second activity to the designer surface, a Sequence activity will be automatically created to wrap both activities.
To more easily navigate a large workflow in the designer, pan mode can be enabled, allowing the developer to click and drag to move the visible portion of the workflow, rather than needing to use the scroll bars. The button to activate pan mode is in the lower right corner of the designer.
In order to make hierarchical workflows easier to navigate, components of a workflow are shown in a tree-style outline view. The outline view is displayed in the Document Outline view. To open this view, from the top menu, select View, Other Windows, Document Outline, or press Ctrl W,U. Clicking on a node in outline view will navigate to the corresponding activity in the workflow designer, and the outline view will be updated to show activities that are selected in the designer.
Prior to .NET Framework 4.5, all expressions in workflows could only be written in Visual Basic. In .NET Framework 4.5, Visual Basic expressions are only used for projects created using Visual Basic. Visual C# projects now use C# for expressions. A fully functional C# expression editor is provided which capabilities such as grammar highlighting and intellisense. C# workflow projects created in previous versions that use Visual Basic expressions will continue to work.
In a rehosted designer, some of the standard UI controls may not have meaning for a given workflow, and may be turned off. In .NET Framework 4, this customization is only supported by the shell bar at the bottom of the designer. In .NET Framework 4.5, the visibility of shell header items at the top of the designer can be adjusted by setting WorkflowShellHeaderItemsVisibility with the appropriate ShellHeaderItemsVisibility value.
d0d94e66b7