Skip to content

Overview

Business Processes and Workflow are two features within Neuron ESB used to design custom mediation or business logic to enhance integration scenarios or automate processes. Although both provide a graphical, drag and drop designers for composing complex business logic, they have very different runtime and management capabilities and target different scenarios. Where Workflow provides for state management, supports long running processes, compensated transactions, failover, restart capabilities, event correlation, tracking and fault tolerance; Business Processes do not. Business Processes on the other hand provide low latency execution and hence do not manage state. They are ideal for mediation and request/response type messaging scenarios (soap/rest services) where latency and scale are paramount. Business Processes are used to implement common integration patterns.

The Business Process designer and its respective runtime engine is used to achieve near real-time requirements where performance, agility and time to market are driving factors. Uses can develop custom business logic using the Business Process Designer for execution in low latency environments such as request/response type of messaging to provide either simple VETO or, more complex ScatterGather and Service Composition/Orchestration capabilities. Service Composition and Orchestration can be used to expose a discrete set of services within an organization as higher-level business services. A Business Process can be exposed as a SOAP or REST API within Neuron ESB.

The Neuron ESB Business Process Designer ships with over 40 configurable Process Steps; that do everything from calling a service and updating a database or queue, to parsing Flat files and Excel file (as depicted below within the Neuron ESB Explorer). Developers can extend its capabilities by building custom reusable Process Steps that can be registered in the Process Steps library and added to any custom Business Process. Process Steps can be graphically composed to build larger more complex Business Processes, significantly reduces the amount of custom code, as well as the time it takes to build and manage Business Processes.

For example, when a user or system submits a message to the bus, specific steps may first need to happen. These steps may include validating and transforming the message before it is published to other subscribers. VETO is a common integration pattern that stands for Validate, Enrich, Transform and Operate (see Figure 1). The VETO pattern and its variations can ensure that consistent, validated data will be routed throughout the ESB.

VETO pattern Validate, Enrich, Transform, Operate
Figure 1: VETO pattern – Validate, Enrich, Transform, Operate.

Neuron ESB provides a unique Business Process implementation that goes beyond the industry standard. Many patterns, like VETO, can be developed using the Neuron ESB Business Process designer. For example, Figure 2 displays a VETO pattern using the Neuron ESB Business Process Designer. When using Neuron ESB, this pattern can be implemented without any external custom code dependencies.

Business Process implementing VETO pattern
Figure 2: Neuron ESB Business Process implementing VETO pattern

The Neuron ESB Business Process Designer significantly extends the ability to develop more complex patterns and processes without introducing additional workflow technologies into a project. For example, a complex business process may involve the need for custom code execution, a decision based on external criteria, calling to a web service or data store, rerouting a message, but overall, being able to maintain transactions and deal with the exceptions as they occur. Figure 3 illustrates what such a process would look like when designed using the Neuron ESB Business Process Designer.

Neuron ESB Business Process implementing complex Order Process
Figure 3: Neuron ESB Business Process implementing complex Order Process

Once designed, Business Processes can be directly tested and debugged within the Business Process Designer before being deployed. The Business Process designer allows developers to do an end-to-end test that supports output tracing, or more controlled debugging as shown in Figure 4. Business Process debugging support at design time allows developers to quickly test, diagnose and fix the Business Processes AS they are developing them. The Business Process debugging experience within Neuron ESB is synonymous to the experience provided by Microsoft Visual Studio for debugging .NET applications. For example, developers can set Breakpoints, disable Process Steps, use F5/F10/F11 keys, view exceptions and view the context of the Business Process and Process Steps.

Neuron ESB Business Process Debugging Watch Window with Breakpoint
Figure 4: Neuron ESB Business Process Debugging Watch Window with Breakpoint

Once tested, Business Processes are executed at runtime either when a Party (Publisher/Subscriber) publishes or receives a message. When a Party is associated with Neuron ESB Endpoint (i.e. Workflow Endpoint, Adapter Endpoint or Service Endpoint), the Neuron ESB service or the Neuron ESB workflow host (depending on type of endpoint) provide the runtime execution environment. When the party is hosted in a third party .NET application using the Client API, that 3rd party .NET application serves as the runtime execution environment. Additionally, Business Processes support execution directly within a Workflow or a Business Process using the Execute Process Step or Workflow Activity.

The Neuron ESB Explorer can be used to associate one or more Business Processes to a Party as the final step required before deploying a Business Process to an active runtime environment. Business Processes can be effectively chained together, allowing developers to create more granular, componentized, reusable business logic. Figure 5 illustrates how multiple Business Processes can be added to a Party and, even given conditions to determine at runtime, when to execute.

Attaching Business Processes
Attaching Business Processes to a Party
Figure 5: Attaching Business Processes to a Party
Was this article helpful?
Dislike 0
Next: Working with Business Processes