Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Introduction to Long Running Workflows 3.7
Similar to Introduction to Long Running Workflows 3.7 (20)
More from StephenKardian
More from StephenKardian (14)
Recently uploaded
Recently uploaded (20)
Introduction to Long Running Workflows 3.7
- 1. Introduction to Long Running Workflows
- 2. Introduction to Long Running Workflows • Provide an understanding of Workflows features and tools Goals
- 3. Introduction to Long Running Workflows • Workflow Designer • Workflow activities • Workflow types • Persistence • Workflow endpoints Lesson Plan
- 4. Introduction to Long Running Workflows • Workflows are based on Windows Workflow Foundations (WF), is a runtime environment that hosts a Workflow Engine as well as a designer. • A Workflow is a series of distinct programming steps or phases. Each step is modeled in WF as an Activity. • A Workflow is a group of connected business activities that can take minutes, hours, days, weeks, months or longer to complete. Workflow
- 5. Introduction to Long Running Workflows Workflows can be leveraged in a number of different scenarios • Where long-running processes are needed • When state is required • When asynchronous processing is required • When message correlation needs to occur • When the business process needs to act as an endpoint • When Fault Tolerance is required • When tracking is required Workflow
- 6. Introduction to Long Running Workflows Implementing Workflows Implementing workflows in Neuron ESB requires: • ESB Service Management Objects • Neuron database assigned to the active deployment group • A workflow definition • A workflow endpoint • An endpoint host
- 7. Introduction to Long Running Workflows Workflow Designer Like the Business Process Designer, the Neuron ESB Explorer provides a Designer dedicated to building Workflow definitions. • Toolbar • Toolbox • Outline • Property Grid • Error Window • Output Window
- 8. Introduction to Long Running Workflows Workflow Activities
- 9. Introduction to Long Running Workflows Workflow Activities
- 10. Workflow Designer : Demo Purpose: To familiarize users with Workflow Designer in the Neuron ESB Explorer Objectives: To acquaint users with the following areas Neuron ESB Explorer: • The Workflow Designer • Workflow Activity Library
- 11. Introduction to Long Running Workflows Control Flow Activities For • Iterates through a collection until the condition evaluates to false. • 3 Conditions • Initialization • Condition • Iteration Retry • Retries all workflow activities contained within based on the following properties • Retry Count • Retry Delay Timeout • Times out if the activities contained within do not complete their execution within the time period allotted. • Can throw an exception if necessary when the timeout occurs.
- 12. Control Flow Activities : Demo Purpose: To familiarize users with the workflow activities specific to Neuron ESB Objectives: To acquaint users with the following workflow activities: • For • Retry • Timeout
- 13. Introduction to Long Running Workflows Language Activities C# • Implements a C# code block for an Execute method • ESBMessage is passed in differently based on Workflow type • message in Normal Workflows • request in Request/Reply Workflows • message in Correlated Workflows C# Class • Implements a code block for a C# class • Has an Execute method • ESBMessage is passed in differently based on Workflow type • message in Normal Workflows • request in Request/Reply Workflows • message in Correlated Workflows • Can add using statements for namespaces Visual Basic .NET • Implements a Visual Basic .NET code block for an Execute method. • ESBMessage is passed in differently based on Workflow type • message in Normal Workflows • request in Request/Reply Workflows • message in Correlated Workflows
- 14. Language Activities : Demo Purpose: To familiarize users with the workflow activities specific to Neuron ESB Objectives: To acquaint users with the following workflow activities: • C# • C# Class • Visual Basic .NET
- 15. Introduction to Long Running Workflows Custom Activities Execute Process • Allows the workflow definition to execute business processes designed in the Business Process Designer
- 16. Custom Activities : Demo Purpose: To familiarize users with the workflow activities specific to Neuron ESB Objectives: To acquaint users with the following workflow activities: • Execute Process
- 17. Introduction to Long Running Workflows Messaging Activities Audit Message • Audits the specified message to the Neuron ESB database • Audited messages appear in either the message history or failed message history report Clone Message • Clones the specified message into the given result variable. Create Binary Body • Creates an ESB message object with a binary body • Data is of type Bytes[] Message Correlation Scope • Creates a scope for receiving messages intended for handling by the current workflow
- 18. Introduction to Long Running Workflows Messaging Activities Create Reply Message • Uses the specified request message to create a reply message. • Automatically sets the semantic to Reply Create Text Message • Creates an ESB Message object with a text body • Data is of type String Publish Request Message • Publishes the specified message on the topic indicated using the request/reply semantic, and waits for a reply Publish Message • Publishes the specified message on the topic indicated, using the semantic selected.
- 19. Introduction to Long Running Workflows Messaging Activities Receive Message • Waits for a message to be received for the workflow, and passes the message to the workflow Split XML Message • Splits a single ESB message object into a collection of ESB message objects • Uses an XPath statement to split the message Join XML Message • Joins a collection of ESB message objects with a text body, into a single ESB message object
- 20. Messaging Activities : Demo Purpose: To familiarize users with the workflow activities specific to Neuron ESB Objectives: To acquaint users with the following workflow activities: • Audit Message • Create Reply Message • Publish Message
- 21. Introduction to Long Running Workflows Web Services Service Endpoint • Implements a service endpoint to which the specified message is sent • Supports pool management for high concurrency • Bypasses the pub / sub infrastructure • Policy controlled Http Utility • Allows REST calls to be made through a configurable interface. • Supports environmental variables • Returns a reply from the REST call as a message Adapter Endpoint • Implements an adapter endpoint to which the specified message is sent • Supports pool management for high concurrency • Bypasses the pub / sub infrastructure • Policy controlled
- 22. Web Services : Demo Purpose: To familiarize users with the workflow activities specific to Neuron ESB Objectives: To acquaint users with the following workflow activities: • Adapter Endpoint • Service Endpoint • HTTP Client Utility
- 23. Delay • Pauses workflow execution for the time period indicated. • Persists the workflow upon encountering the activity, as long as the delay is greater than 1 minute in duration. • Unloads the workflow immediately upon encountering the activity. Introduction to Long Running Workflows Primitive Activities
- 24. Primitive Activities : Demo Purpose: To familiarize users with the workflow activities specific to Neuron ESB Objectives: To acquaint users with the following workflow activities: • Delay
- 25. Introduction to Long Running Workflows Error Activities Throw with Message • Throws a .NET exception • Attaches an ESB message to the error
- 26. Error Activities : Demo Purpose: To familiarize users with the workflow activities specific to Neuron ESB. Objectives: To acquaint users with the following workflow activities: • Throw with Message
- 27. Introduction to Long Running Workflows XML Transform Message • Transforms the body of the message based on an XSLT • Takes an ESB message as an argument • Returns an ESB message as a result • Allows XSLT parameters • Enable or Disable scripts Validate XML • Validates an XML document based on an XML schema • Takes in either an XML string or an XML document • Throws an error if the validation fails Transform XML • Transforms an XML document based on an XSLT • Takes in an XML string or an XML document • Returns an XML string • Allows XSLT parameters • Enable or Disable scripts
- 28. Error Activities : Demo Purpose: To familiarize users with the workflow activities specific to Neuron ESB. Objectives: To acquaint users with the following workflow activities: • Throw with Message • Transform XML • Validate XML
- 29. Introduction to Long Running Workflows Workflow Types • Normal Workflow • One way • Each message means a separate workflow instance • Request-Reply • Implements the request reply semantic and returns the reply when the workflow is completed • Each message means a separate workflow instance • Correlated • Filters and groups messages based on conditions of the messages as they are received by the workflow host. • Multiple messages are handled by the same workflow instance • Essentially a singleton pattern
- 30. Introduction to Long Running Workflows Workflow Persistence • The Persist activity pushes the workflow state (messages, variables etc.…) to the database. • If a workflow stops or fails for any reason it can be resumed from the last persist activity it encountered rather than from the beginning. • Persist is commonly used after expensive functionality is executed, service calls are made, or other message processing activities are performed, in order to prevent these actions from having to be taken again should the workflow need to be re-started.
- 31. Introduction to Long Running Workflows Workflow Endpoint • Workflow endpoints host the workflow definition in Neuron ESB. • As a workflow endpoint is itself a subscriber, in much the same way an application would be, the endpoint hosts the definition and processes messages through it. • In relation to the Pub/Sub pattern this means that workflow endpoints act as a subscriber and uses the definition much like a business process.
- 32. Introduction to Long Running Workflows Review • Workflows should be used in long running scenarios where normal timeouts would expire • Neuron ESB Management Objects need to be installed in order to use workflows • A database is required for workflows • Neuron ESB provides three types of workflows • Normal • Request / Reply • Correlated • Persistence allows workflow to restart from its last successful operation
Editor's Notes
- The goals of this lesson are to provide the user with an understanding about workflows, their features and tools.
- The lesson has been broken into five sections to make the information provided easier to understand. The sections we will be covering are Workflow Designer Workflow activities Workflow types Persistence Workflow endpoints
- A workflow is a series of distinct programming steps or phases, designed to process long running transactions. In Neuron ESB Workflows are based on Windows Workflow Foundations (WF), is a runtime environment that hosts a Workflow Engine as well as a designer. Workflows are comprised of group of connected business activities that can take minutes, hours, days, weeks, months or longer to complete.
- Workflows are used in lieu of business processes in a number of different scenarios. While business process are good for quick stateless processing, workflows excel in long-running processing or that which requires state. Workflows are also asynchronous in their execution, unlike business processes, so they aid in situations where this is required. Another scenario in which workflows excel are with message correlation. A business process is designed so that only one message can be passed into the business process. This makes correlating messages that are part of a set impossible. However, workflows have the ability (using a correlated workflow) to invoke a singleton pattern in which one workflow can handle multiple messages. Because workflows contain state, and not run in-memory, workflows have an extensive tracking system behind them (this is discussed in the Workflow Hosting and Tracking presentation) which provides a much more in depth way of examining their execution.
- In order to use workflows in Neuron ESB it is important that the ESB service management objects are installed, which is selected by default when installing Neuron ESB. Workflows also require a workflow definition, a workflow endpoint and an endpoint host. Creating a workflow endpoint and host it in an endpoint host is discussed in the Workflow Hosting and Tracking presentation.
- Neuron ESB provides a workflow designer to create workflow definitions, very similar to the business process designer discussed in the Introduction to Business Processes presentation. The Workflow designer is comprised of 6 parts. The toolbar, which provides you standard options such as cut, copy and paste, as well as save and print in order to save or print an image of the workflow definition. The toolbox which is where you will find all the workflow activities used to build workflow definitions The outline, which is the design canvas where the actual building of the workflow definitions takes place by dragging and dropping workflow activities into this location to mirror the business flow. Property Grid, where the properties for each workflow activity can be set. Error window, where errors that occur in a workflow will appear. Output window, this is where activities such as WriteLine and Language editors will write informational messages during workflow definition testing.
- As workflows in Neuron ESB are built on top of Microsoft workflow foundation, many of the more than 80 activities available to build workflow definitions, are provided by Microsoft, and thus the documentation surrounding them can be found at https://docs.microsoft.com/en-us/dotnet/framework/windows-workflow-foundation/net-framework-4-5-built-in-activity-library.
- However, some of the activities available for building workflow definitions are designed, built and provided by the Neuron ESB team. These activities, highlighted in red, are the ones for which the Neuron ESB team will provide the information in this presentation.
- For – The For activity operates in the same manner as a for loop in .NET. The user provides an initializer (a variable with a set value such as x = 0), a condition (something that when met indicates the loop is complete such as x < 10) and an iterator (a value by which to increment the initializer such as x += 1). All activities contained with in the For activity will execute every time that the loop repeats. Retry – The retry activity provides users a way to retry all activities, contained within, a set number of times should an error be encountered during the course of processing. For example if you are trying to connect to a service, that is often known to be busy or down for short periods of time, you may want to encapsulate that service call in a retry step and allow the workflow to retry attempting to call the service every 30 second for 5 tries before concluding the service has an issue and throwing an error. Timeout – The Timeout activity allows users to set a timeout around the execution of other activities. In certain circumstances it may be necessary to limit certain interactions to a set time to ensure the speed of the overall workflow. For example a call to an external system may take 60 seconds to timeout. However, it may be necessary to move on with the workflow if the call has not returned a result in 30 seconds. Encapsulating the call to the external system in a timeout will allow you to instruct the workflow to continue execution even if the call to the external system has not completed.
- C# - Exposes a C# method name OnExecute to the activity, allowing users to develop code directly inside of the method declaration. The context variable exposes the Neuron ESB client context to the method and allows users to access the Configuration, Environmental Variables, Repository Documents, Message and a variety of other aspects of the Neuron ESB solution. C# Class – Exposes a full C# class to the activity instead of just a single method. While this class still contains a definition for the OnExecute method, as that is what the workflow definition will call to begin the execution of the code in the class, users can add their own methods and develop within the class as they would in any other .NET class. VB.NET - Exposes a VB.NET method name OnExecute to the activity, allowing users to develop code directly inside of the method declaration. The context variable exposes the Neuron ESB client context to the method and allows users to access the Configuration, Environmental Variables, Repository Documents, Message and a variety of other aspects of the Neuron ESB solution.
- Execute Process – This activity allows users to call a business process, from inside a workflow definition, much like a method is called by another method in .NET. This can be configured using a process that exists inside the current solution or by referencing a process from an external solution. The message is passed from the calling process to the child process and back using a reference passing, meaning the message is not copied but rather passed exactly as is. Whatever is done to the message in the child process is reflected in the parent process when the child process returns the message.
- Audit – The audit activity instructs the Neuron ESB explorer to audit the message to the Neuron ESB database with the associated action that you selected. Clone Message – The clone message activity clones the specified message into a given result variable. This is activity uses the clone(false) method and so the message Id for the new message will be different from the original. Message Correlation Scope – This activity creates a scope for receiving messages intended for handling by the current workflow Create Binary Body – Creates an ESB message object with a binary body (sets the data type of the body to Bytes[])
- Create Reply Message – Uses the specified request message to create a reply message. Automatically sets the semantic to Reply Create Text Message – Creates an ESB Message object with a text body. This sets the data type to type String Publish Message – Publishes the specified message on the topic indicated, using the semantic selected. Publish Request Message – Publishes the specified message on the topic indicated using the request semantic, and waits for a reply
- Receive Message – Listens for Neuron ESB to receive a message intended for the workflow, based on a correlation Id (discussed in detail in the Workflow Patterns and Correlation presentation, and assigns the message value to the variable indicated. Split XML Message – Splits a single ESB message object into a collection of ESB message objects, based on the provide XPath. Join XML Message – Joins a collection of ESB message objects with a text body, into a single ESB message object.
- Service Endpoint – Provides the workflow definition a way to access services endpoints defined in the Neuron ESB solution. Using this activity bypasses the pub / sub infrastructure, so there is no publisher and subscriber considerations to worry about. Adapter Endpoint – The adapter endpoint activity by passes the pub / sub infrastructure, allowing a message to be handed directly from the business process to the adapter endpoint. HTTP Client Utility – The HTTP client utility allows the users to dynamically adjust the properties of the next REST service endpoint call in a workflow definition. This activity works similar to Google’s Postman plugin, so being familiar with that will make understanding this activity incredibly easy. Users can add headers, adjust the body or include URL parameters to be passed along to the service endpoint. The HTTP client utility supports dynamic configuration using environmental variables, message body and context properties, as well as .NET objects.
- Delay – The delay activity pauses workflow execution for the time period indicated. It will persist the workflow upon encountering the activity, as long as the delay is greater than 1 minute in duration. It also unloads the workflow immediately upon encountering the activity.
- Throw with Message – The Throw with Message activity throws a .NET exception with the ESB message attached.
- Transform Message – The Transform Message activity transforms the body of a messages based on an XSLT. The XSLT must be present in the Neuron ESB repository. This activity takes in a message and returns the results as an ESB message. Transform XML – Transforms an XML document based on an XSLT. The XSLT must be present in the Neuron ESB repository. This activity takes in a message and returns the results as an ESB message. Validate XML – Validates an XML document based on an XML schema. The schema must be present in the Neuron ESB repository. This activity takes in an XML string or an XML document.
- There are three types of workflows that can be created in Neuron ESB, each with its own particular function. Normal Workflow – The normal workflow is a general purpose workflow and the one used in most cases. It is a one way workflow, meaning that messages flow into the workflow but no response is sent out of it. Each normal workflow receives a single message argument and a new instance of the workflow is created for each and every message. Request-Reply – The request-reply workflow implements the request reply MEP and returns the reply when the workflow has completed. Each request-reply workflow receives a single message argument and a new instance of the workflow is created for each and every message. It is not recommended to use the request-reply workflow in most cases as workflows are for long running transactions and replies normally have to occur in short periods of time. Consider using a business process for all request reply MEPs.
- As workflows have state and are captured in the Neuron ESB database it is possible to persist a workflow (capture a copy of it as it is at the point of persistence) using the persist activity, which pushes the workflow state, to include message, variables etc, to the Neuron ESB database. If a workflow stops or fails for any reason it can be resumed from the last persist activity it encountered rather than from the beginning. The persist activity is commonly used after expensive functionality is executed, service calls are made, or other message processing activities are performed, in order to prevent these actions from having to be taken again should the workflow need to be re-started.
- Workflow endpoints host a workflow definition. As a workflow endpoint is itself a subscriber, in much the same way an application would be, the endpoint hosts the definition and processes messages through it. In relation to the Pub/Sub pattern this means that workflow endpoints act as a subscriber and uses the definition much like a business process. We discuss how to host a workflow definition in a workflow endpoint more in the Workflow Hosting and Tracking presentation.