NETBPM Organizational structure (4)

Daniel's masterpiece, praise A

Turn from: netbpm design and implementation of workflow architecture

Read before: Because this article involves a lot of content, if there is a place to read not very clear, it is recommended to skip first, the overall understanding, and then back to understand. The author knows Limited, if has the mistake, welcome treatise:) The original address: NETBPM Workflow architecture design and Implementation analysis (reprint please retain)

NETBPM Component Interface

NETBPM consists of a series of components, each of which implements a core interface (using facade Pattern). The core functions of different components are responsible according to the WFMC specification.
NETBPM interface diagram:

2. interface (process Developer) provided for process developers: This interface is responsible for loading the process definition to the NETBPM engine. First, the process developer creates a process definition in accordance with NPDL and packages it into a process definition compression package that contains all the information for a business process, and then loads the process definition compressed package into the NETBPM engine via the NETBPM Web interface or otherwise. During the load process, the process definition compressed package will be parsed and saved to the NETBPM database.
4. interface (user) provided to the user: Here the user represents the person executing the process. The process runs with 2 main behaviors: Start a process and execute an activity. Starting a process creates a process instance of the process that corresponds to one execution of the process definition. A process instance contains one or more parallel flow-of-execution (see flow). For flow in Activity-state (active node, see NPDL), the system will definitely assign a specific person (or group) or third party to perform the activity. The execution activity is the second behavior of execution interface. Of course, the operating interface also implements some other methods such as getting a list of tasks, getting a list of valid process definitions, and so on.
6. interface between an external IT system (External IT systems) and the NETBPM engine: External IT systems can interact in 2 different ways and netbpm.
   • System initiates interaction: the system interacts directly with the external IT system. When the system wants to trigger an action in the process, it must use the execution Interface mentioned above.
   • Process Initiation Interaction: Interactors is required for this type of process initiation interaction. These interactors are part of the process definition, which is contained within the process definition package (actually interactors is a. NET assembly that has access to Flowcontext, which is the set of programs that we'll talk about later that contains the delegate class). Interactors establishes a communication channel between the Flowcontext (Flow runtime context) and the external IT system.
8. interface between organization structure data (organisational Datastore) and netbpm: think about it, netbpm is missing something, yes, that's the information of the organization structure: People, teams, departments, roles, etc. Because in the real world, for different organizational structures, the organization information may be stored in different types of databases, such as LDAP system, relational database, etc. To enable NETBPM to rapidly deploy in a real-world organization, NETBPM aggregates all of the organization's architectural information in one component (Organisation Component). This is what we usually say about the conversational façade pattern (session Façade pattern), which makes it easier for NETBPM to access organizational schema information from different data sources.

Here we step through the various components of NETBPM, the following is the NETBPM component structure diagram:

Defining components (definition Component)

This component implements the core interface idefinitionsessionlocal, which is used to parse, load, and save the process definition compressed package to the database. In addition, it provides methods for obtaining a process definition, obtaining a list of all valid process definitions, and so on, and related to the process definition.

Running components (execution Component)

The component implements the core interface iexecutionsessionlocal, which is the NETBPM engine push core, as described earlier, it mainly implements 2 methods: Start a Process instance (start ProcessInstance) and perform an activity (Perform Activity). In addition, it provides a way to get a list of user tasks and to cancel the operation of auxiliary processes such as process instances.

Organization Architecture components (Organization Component)

The component implements the interface Iorganisationsessionlocal, which brings together all of the Organization's architectural information, including users, groups, and memberships. Running components require information about user and group when assigning performers to activitie-state. This information is provided in read-only mode by the organization-schema component to the running component. The following is the NETBPM default organization structure data model. Based on this, we can easily implement customized organizational architecture components suitable for actual project requirements to be associated with our user database or LDAP system.

The note:netbpm source is just a simple organizational model, but it provides a way of thinking that we can easily extend to meet the needs of a custom organizational Architecture component:)

Logging Component (log Component)

This component implements the interface ilogsessionlocal, which is used to record the operation traces of the workflow engine, such as the update of the property value (if the user submits the form to be re-filled, the form data will appear multiple times, this is a property update), The invocation of the delegate class will be recorded and saved to the database.

Task Scheduler Component (Scheduler component)

This component implements the interface ischedulersessionlocal, in the real business process, we often encounter the need to trigger a task periodically, the task scheduling component is the role of this. The engine or third party encapsulates the task information (including the task execution environment, execution time, and so on) that needs to be performed at some point to save the job to the database. The Task Scheduler component will scan the task table at a specified time interval and perform the scheduled job based on the execution time comparison.

Management Monitoring Component (admin Component)

This component is used to monitor process definitions, process instance execution, and so on. (Source to be perfected) The following is the NETBPM core project in visual This component is used to monitor process definition, process instance execution, etc. (source code to be perfected)

Here is the source code diagram for the NETBPM core project in the Visual Studio solution, where all components are contained under the Workflow folder, each of which implements a core component.

A few important concepts in netbpm flow

Flow does not know why translation is good, in the jbpm called token, translated into tokens, here we call Flow bar. It represents a "thread of execution" for activity-states (the active node, see NPDL), which is equivalent to a token in the process definition template during the execution of a process instance (it is difficult to describe clearly, see below to understand:)). As I said earlier, a process instance represents one execution of a process definition. As shown, the state of the process instance can be seen as a flows tree.

When starting a process instance, at Start-state (the start node, see Npdl,start-state can actually be considered a special activity-state) the engine will automatically generate a flow named root. Flow contains information about the process instance, such as attribute values, process definition information, the performer of the activity-state where flow resides, and so on. Root flow updates its real-time information (such as performers, attribute values, and so on) before it encounters the fork (scatter node, see NPDL), which changes as the process runs. After the fork is encountered, root flow is dispersed into a number of (>1) forked flow (we can refer to root flow as the parent flow of these forked flow) according to the Forkhandler delegate class. If it is scattered in multiple, then forked flow will run in parallel, the parent flow is temporarily retired, only to join (aggregation node, see NPDL) aggregation, the engine will determine the mechanism of activating parent flow according to the Joinhandler delegate class defined by the join.

Note: For the fork and join mechanism, refer to NPDL Fork, join section for understanding.

Attributes (attributes)

attribute is used to represent variables in a process instance. A attribute-instance (attribute instance, or attribute value) represents an instance of the corresponding property during the execution of a process instance. There are generally several properties, one is activity-state (including start-state) need users or third-party to fill out (update) properties (generally corresponding to the user Web interface form to fill in the values), one is the role of the corresponding attributes, There are also some used as identity attributes (used to store certain information to facilitate subsequent nodes to use these information processing logic to judge).

1. Serializer (serialization of attributes):
   
   Both serializer and Htmlformatter are delegate classes, and serializer is responsible for converting attribute instances between. net-objects and text to facilitate the deposit and removal of attribute values into the database. The htmlformatter is mainly used to contact the property value and the http-text corresponding to the Web Forms display.
2. attribute range:attribute-instances (attribute instance) is related to flow. The attribute and Root-flow associations defined in the Process-definition (process definition root node, see NPDL) node, while in Concurrnet-block (parallel run block, see NPDL) The local attribute instances defined in are associated with forked flow. A flow can "see" all the properties associated with it and all the properties of the flow's parent flow.

Engine runtime contexts (execution context)

Because the picture is too large, see the interface diagram about inheriting Ihandlercontext click here

      ExecutionContext (object of type Executioncontextimpl, we translate to run-time context:)) Contains all the useful information about the engine at run time and the process instance (the Flowcontext mentioned above is a executioncontext), which establishes an interconnected channel between the delegate class (which includes the delegate class defined in the process definition compression package) and the process engine. This is very critical. as shown in the Exectutioncontext class diagram above, Executioncontextimpl implements the following interfaces: Iassignmentcontext, Idecisioncontext, Iforkcontext, Iactioncontext, Ijoincontext, Iprocessinvocationcontext, Itaskcontext, these interfaces are designed to match a specific delegate class, They regulate a specific context, such as Iactioncontext matching action type delegate class, Idecisioncontext matching Decisionhandler type delegate class, etc. And Exectutioncontext is a synthesis of all these special runtime contexts. When the engine transmits Exectutioncontext as a parameter to a specific type of delegate class (key: This is how the delegate class and the process engine establish a connection), the ExecutionContext object will "unboxing" into a special context, For example, when the ExecutionContext object is passed to the delegate class run () method of the action type, the ExecutionContext object is unboxing to the Actioncontext object to limit the methods it can invoke.

These interfaces inherit the same interface Ihandlercontext, as shown in the "interfaces inherited from Ihandlercontext" figure. Ihandlercontext is a specification of the most basic delegate class processing context of the interface, the implementation of the interface to inherit a few of the methods defined in the Ihandlercontext, of course, each inherited its specific interface can have its own specific methods. Let's look at the common interface Ihanldercontext class diagram: As shown in the Ihandlercontext interface diagram above, these interfaces inherit the same interface Ihandlercontext. Ihandlercontext is an interface that regulates the context of the most basic delegate class processing, and the class that implements the interface inherits the method defined in the Ihandlercontext. Of course, each of the specific interfaces that inherit it can have its own specific method. Let's look at the common interface Ihanldercontext class diagram:

Most of the methods, we can see its specific role from the method name, here is focused on the next getattribute () method and the GetConfiguration () method, which is we write the delegate class implementation, we often use the 2 methods. GetAttribute () is used to get the value of a property in the process instance, including the value of the property generated by the processor before the process (such as the value of the user filling out the form) and the value of the representation attribute set in the previous processing engine event (note: Iactionhandler has the setattribute () method, This method is often used to identify property values for later application logic) and so on. GetConfiguration () is used to get the parameter (parameters, Npdlparameter) set in the process definition.

Here's a look at several typical context-specific interfaces:

• Iassignmentcontext: Provides the engine context for the Iassignmenthandler delegate class, which defines the method for obtaining organization schema information, as described in the class diagram.
• Iactioncontext: Provides an engine context for the action, noting that it has a setattribute method that can assign a value to a property in a process instance, as described in the class diagram.
• Iforkcontext: Provides the engine context for the Iforkhandler delegate class, which defines how to scatter forked flow from the parent flow, as shown in the class diagram.
• Ijoincontext: Provides the engine context for the Ijoinhandler delegate class, which defines methods for obtaining other parallel flows, see class diagram.
• Iprocessinvocationcontext: Provides engine context for Iprocessinvocationhandler delegates, see class diagram for implementation methods.
• Other delegate type contexts in addition to implementing the basic Ihandlercontext method, there is no specific method, please refer to the Ihandlercontext method.

Delegate class

In the preceding we have been referring to the delegate class, then what is the delegate class exactly? The concept of delegation here refers not to the delegate in the. NET framework, which can be understood as the concept of "delegating, processing on behalf of".

NETBPM is designed as a generic process processing engine, and the NETBPM core execution engine handles only the most basic business process logic, and all uncertain logic is delegated to a series of interfaces called delegation Interfaces (delegated interfaces), The class that implements these interfaces is the delegate class. The process definition Convention uses what delegate type, and how the engine and delegate classes are associated are also done in the process definition.

To achieve maximum scalability, process developers can choose any of the following delegate class implementations in the process definition:

1. Use a valid delegate class that is already implemented in the NETBPM engine. (Delegates with generality are recommended to be defined in the engine in this way for reuse)
2. Use a custom delegate class to dynamically load in the form of a. NET assembly through the process definition compression package.

It is the way 2 this form gives NETBPM a great deal of flexibility in the application logic that is only appropriate for a particular process (which often accounts for the majority). NET assembly is defined in the process definition compression package, and NETBPM is parsed and saved to the database through the process definition component. When the engine running process needs to invoke the delegate class, the engine uses the reflection technique to instantiate the delegate class object, and then builds the interaction channel between the delegate class and the engine using the runtime context (ExecutionContext) described above, which is really an exciting design:)

The following are the delegate types in NETBPM (the recommendation and the ExecutionContext section are understood together):

• Assignmenthandler:
  Implements interface Iassignmenthandler, which can communicate with It-system in an organization's schema to specify the performer for Activty-state. Iassignmenthandler has the only method Selectactor (Iassignmentcontextassignercontext), wherein the ASSIGNERCONTEXT is its connection with the engine channel;
• Actionhandler: Implements interface Iactionhandler, which is used to execute a program logic that is done outside the process engine, where the action is executed, when execution is defined in the process definition. Actions can be seen as a listening interface for a sequence of process execution events, with a method run (Iactioncontext actioncontext), and Actioncontext is the channel it contacts with the engine.
• Decisionhandler: Implements interface Idecisionhandler, which is used to choose which transition to go (side, see NPDL), with method decide (idecisioncontext Decisioncontext), the method returns the name of the selected edge to go, and Decisioncontext is the channel it contacts with the engine.
• Forkhandler: Implements interface Iforkhandler, when executed to the Fork node, Forkhandler is used to determine which sides in the edge of the fork process need "forking". It has a method fork (Iforkcontext forkcontext), and Forkcontext is the channel in which it contacts the engine. Note: Forkhandler can scatter multiple forked flow on the same edge.
• Joinhandler: Implements interface Ijoinhandler, when executed to join, Joinhandler decides whether to activate parent flow, it has method join (Ijoincontext Joincontext), Joincontext is the channel in which it links with the engine.
• Serializer: Implements interface Iserializer, with method serialize (Object Valueobject) and deserialize (String text), which is responsible for converting property values. Put the attribute value in the. Convert between Net-objects (. NET objects) and Text-format (text). where Text-format (text) is used to store property values in the database.
• Htmlformatter: Implements interface Ihtmlformatter, which is used primarily to establish a connection between the property value and its corresponding web interface element, and to parse the values that the Web interface element has. If ported to the ASP. NET platform, this interface recommends rewriting.
• Processinvocationhandler: Implements interface Iprocessinvocationhandler, which implements the method of collecting initialization data of the sub-process, collecting the processing result, specifying the edge to flow after the completion of the sub-process, Processinvocationcontext is the channel in which it links with the engine.

................///////////////////////////............. Example of whether to add a delegate class

Process definition version problem process definition name and version

The information contained in a process definition compressed package is called a process definition. In netbpm, the process is distinguished by the field name, which means that the engine determines whether two processes are equal based on the name of the process. A version cannot be specified in a process definition package, and when a process definition is loaded by the engine, NETBPM checks for an older version of the process definition. If there is, NETBPM will automatically set the newly loaded process version to add 1 to the maximum number of versions of all existing previous versions of the process definition.

Process Execution and version

When calling the running component to get the process definition list method, only the highest version process definition of each process can be obtained. This ensures that the user always starts a process instance from the latest version of the process definition. When the new process version is loaded into NETBPM, all running old versions of the process instances will remain in the original process definition.

Delegate classes and versions

Another aspect of the version is the delegate class. The delegate classes defined by the different versions of the process are not shared, meaning that each process will only "see" The delegate class defined by its own process as it executes.

Exception handling mechanism

NETBPM as an integrated platform, when the process runs, it will certainly rely on a lot of other IT resources of the company, once these dependencies lead to error in Process execution, NETBPM provides 3 kinds of resolution mechanism:

1. Ignore errors
2. Record the error log (the default mechanism used)
3. Error performing rollback operation (rollback)

In the rollback mechanism, the process instance is rolled back to the state before the activity was executed. If a process error occurs when calling Eecution interface on NETBPM, all the transition (edges) that are flowing will be rolled back.

Process definition Element class diagram

For details on the process definition, see NPDL.

Frames or components used in the NETBPM

There are many frameworks, components and tools used in netbpm, most of which are excellent open source projects. such as Castle,nhibernate,log4net, nvelocity,nunit,nant, etc., do not be intimidated by these frameworks, in fact, they are just "framework" only:)

IOC container ――castle

NETBPM uses the castle framework, which is used primarily to implement IOC (control inversion or dependency injection) and to load core components in a way that relies on injections, such as dbclassloader, process definition components, running components, log components, organization architecture components, Task Scheduler components, and so on. When the Web program starts, all core components are registered to the Caslte IOC container, depending on the configuration file, and later when a component is needed, simply take advantage of the system-provided servicelocator (The Service Load tool Class) to get the instance from the container. In addition, the Task Scheduler component is also useful to Castle's startable Facility (note: The Facility is understood as an injected nature, the function of the Castle IOC kernel container expansion component. Castle itself has implemented some faciltiy, developers can also customize facility), the facitlity is mainly used to automatically run the program (here to automatically interval Scan task table, for task scheduling).

Castle is a powerful open source framework under the. NET platform, for more information about castle, see the Castle official website. In addition, Terrylee's blog about Castle's Chinese resources is also very rich.

Data Persistence layer ――nhibernate

The NHibernate component in NETBPM is a facility of castle, which is used to implement NETBPM data persistence layer and facilitate transaction support. For more information about NHibernate, please see NHibernate official website, about NHibernate as Castle facility related please see here.

Sample Web Tier ――monorail

It must have been strange when you were in the demo demo, not seeing the familiar. aspx page, but the. Rails page, why? The answer is that the NETBPM Web layer is based on the monorail framework, rather than our familiarity with the ASP. Monorail is a sub-framework for Web-layer programming under the Caslte framework, which is inspired by Ruby rails and incorporates an MVC pattern with a clear division of architecture. NETBPM uses nvelocity as the monorail of the page parsing engine, which is just a demonstration of a web interface to the NETBPM core API that tells us how to invoke the NETBPM API from the Web layer. So, although monorail has its own unique, but before it is popular and has a good tool to support, we just need to understand its operating mechanism, to be familiar with the web layer how to take advantage of the netbpm API, do not need to know too much about it. Using our familiar ASP. NET implementation Web Part is obviously a better choice:). For more information about monorail, see here.

System Log ――log4net

Log4net Everyone must be unfamiliar, netbpm use it to record the system log, about log4net more information, please see the official website of Log4net, online Chinese resources are also very rich.

Unit Test Tool ――nunit

Unit Test Tool NUnit has always been a weapon for unit testing. NETBPM The source code has been built several test projects. For more information about NUnit, please see the official website of NUnit.

Note: Migrating to the. NET Framework 2.0, you may want to change its version.

Postscript

NETBPM's design is undoubtedly ingenious, but at this stage it is clearly not a perfect workflow engine, the lack of a strong backing such as JBoss support, halfway to meet the enemy wf,netbpm far from their brothers jbpm scenery, The update does not have it fast (jbpm is already out of 3.0), and there is much less support available, however. NET platform can have such a good open source workflow project is very valuable, if you are struggling in WF, perhaps, open source netbpm will bring you a surprise:)

To write: netbpm workflow npdl detailed, a netbpm real life in the case of leave trial example