Workflow (Middleware)---a Technical Reference Guide for Designing Mission-Critical Middleware Solutions

  • Article

Want more guides like this one? Go to Technical Reference Guides for Designing Mission-Critical Solutions.

Workflow is a declarative software development paradigm involving the use of an IDE to create a sequence of steps or operations that is then executed by a workflow engine. Workflow can simplify development challenges, such as coordinating parallel work, tracking a program’s execution, scaling out long running processes and more. Microsoft provides a workflow engine focused on integration within enterprises and between external partners in BizTalk Server (called Orchestrations in BizTalk). Microsoft also has a workflow solution available for the Microsoft .NET Framework called Windows Workflow Foundation (WF).

Primary scenarios for workflow are:

  • Modeling a business process or workflow.

  • Updating multiple systems that cannot participate in atomic transactions and where compensation is required on rollback.

  • When an entity or process goes through various state changes and has rules and logic around the state transitions.

  • Service Composition: Multiple data sources are queried and a single view of the information is presented to clients.

  • Controlling the flow of a user interface.

Best Practices

Development

  • BizTalk was built for guaranteed messaging with built-in reliable delivery capabilities. The adapter model allows BizTalk to integrate with many different types of systems. If guaranteed messaging and integration with a variety of systems and protocols are needed, you might prefer using BizTalk.

  • Develop using WF 4.0 unless necessary to use WF 3.X. WF 3.X is supported but no longer being enhanced. This was required to improve performance and to create true codeless workflows. Road to WF 4.0

  • WF 4.0 and WF 3.X are not compatible. The options for migration from WF 3.X are to use the interoperability activity to invoke WF 3.X workflows and shapes, side by side execution, or the WF 3.X runtime and/or migration of code to WF 4.0. The only migration path for BizTalk orchestrations is code migration. Migrating Workflows, Migration Guidance, Migration Toolkit

  • Sequence Activities provides a procedural style of flow, Flowchart Activities provides the ability to flow to previous steps, and State Machine works well for controlling state transitions of an entity or process.

  • Prefer using code activity or composite activity (Activity) for business programming. Use Native Activity for advanced scenarios where access to the runtime engine or bookmarks is needed. Use Dynamic Activity for executing activities at runtime. Consider when asynchronous activities may be needed. Design and Implementing WF Activities, Activity Authoring Options, WF 4.0 Activity Model

  • The WF Data Model is important to understand how workflow properties and CLR properties behave in custom code activities. WF Data Model

  • Persistence protects against system failure, along with improving scalability of the application or service. WF Persistence, Persistence Best Practices

  • Prefer using built-in tracking infrastructure to log custom data from workflows versus building a custom solution. Workflow Tracking and Tracing

  • Prefer using workflows services and AppFabric for correlation using message context or message-content based correlation. If building a custom correlation solution, promote data from the workflow using the SqlWorkflowInstanceStore. Promotion Sample, Troubleshoot Correlation Issues

  • Prefer WCF communication in and out of workflows. Code activities can be used to wrap communication to an external system. Use Native Activities and Workflow Extensions in more advanced scenarios. Workflow Extensions

  • Unit test activities and custom activities using the WorkflowInvoker. Consider dependency injection or Workflow Extensions to decouple activities from dependent components.

  • The WF 4.0 designer can be re-hosted in any .NET process. Rehosting the Workflow Designer

  • Parallel activities do not mean the activities are multi-threaded. Asynchronous activities are needed for multi-threading. Async Activities

  • Consider activity composition in scenarios that require adding multiple decision shapes. Best Practices Video (Time: 22:58-23:25)

  • WF 4.0 supports F5 debugging typical of .NET code bases. Debugging Workflows

  • WF 4.0 can flow transactions to external WCF services in a messaging activity. Not directly supported in BizTalk. Flowing Transactions in WF 4.0

  • The state machine Workflow WF is not available in 4.0. A sample of how to do a similar concept with the flowchart activity is available in the migration guide download page. Another option is to use the WF 3.5 state machine.

  • There is no current C# support for expression editor in WF 4.0.

  • Contract-first WCF development is not currently supported for Workflow Services.

Deployment

  • WF 4.0 supports side-by-side execution of workflows or namespace versioning with declarative workflows. Dynamic activities and using the WCF Routing Service are specialized ways to allow for changes in the runtime execution of workflows. Dynamic Update (updating a running workflow to a new version) is not currently supported in WF 4.0.

  • Use declarative workflows for easy versioning, deployment, and maintenance.

  • Any .NET process can host the WF 4.0 runtime engine. Prefer AppFabric to host workflows and workflow services. If hosting outside of AppFabric, use WorkflowInvoker to execute an activity like a method with limited runtime services,and WorkflowApplication to host a single workflow instance or type with full runtime services. Hosting Workflows

  • Self-hosting workflows with WorkflowApplication class in a server farm introduces complexity, especially around rehydration of workflows. Workflows hosted in AppFabric Server Farms with SQL Persistence Store do not have this issue. Workflow Persistence in AppFabric

Management and Administration

  • AppFabric provides the best installation, configuration, monitoring, administration, and management experience for WF 4.0. Make sure a decision to self-host and not use AppFabric is really necessary. AppFabric Managing an Application

  • Similar to BizTalk, the WF 4.0 tracking and persistence databases size and content should be maintained. AppFabric Archive and Purge Database

  • Tracking affects database size requirements more than persistence. Consider how much tracking is needed in development versus production and adjust the tracking profile. Tracking Profiles

  • Understand persistence settings for given workflow scenarios. Persistence Best Practices

Performance

Case Studies and References

Examples of successful architectures are described in the following case studies and white papers:

Sample Architectures

Tailspin Travel Sample Architecture

Contoso Sample Application with Human Workflow

Case Study

Windows Server AppFabric Solution with Workflow Based Services

References

Developer Samples

Workflow Patterns

.Net Developer Center Beginners Guide to WF

.Net Developer Center Resources and Community

Questions and Considerations

This section provides questions and issues to consider when working with your customers.

Development

  • Are there various systems throughout the enterprise or external partners that the solution will need to connect with? Are there industry-specific protocols required, such as HL7, EDI, or RFID?

  • Is this workflow operating as a service?

  • What type of root workflow should be used?

  • What type of custom activity should be built to extend WF?

  • How should the workflow communicate with applications?

  • How should you solve correlation problems?

  • What level of guarantees do you need around transactions and compensation?

Deployment

  • Where will you host the workflow?

  • How will your host affect high availability?

  • Consider what type of workload (real-time messages, batch jobs, and UI processes) the workflow will be doing, and their effect on the hosting environment. Consider if differing workloads need BizTalk level of scalability options.

  • What kind of tracking and persistence is needed to support the workflow(s)?

  • How does tracking and persistence affect Microsoft SQL Server availability requirements?

Management and Administration

  • How sensitive is the persisted data in the workflows? How will the runtime connect to the tracking and persistence stores? (Security Considerations)

  • What level of tracking do you need for production and non-production environments?

  • How does the host decision affect your ability to track workflow states and tracking data?

Performance

What kinds of response times are needed and can workflow meet those requirements?

Appendix

< Full URLS for Hyperlinked Text>