Designing a business process platform based on WF-Architecture

Designing a business process platform based on WF-Architecture

Recently, many of my friends asked me questions about designing business processes with WF. It seems that many of my friends have entered the WF development stage from their understanding of WF, so I have written a group of articles on business process platform design to share with you some of my experience in workflow development over the past few years.

 

Many people think of workflow when talking about WF, and approval when talking about workflow. Therefore, many people think that WF is an approval system. this statement is like saying that C # Is an approval system. It cannot be said wrong, but it is very one-sided.

 

I personally think that WF is another important milestone after object-oriented and visualized programming. WF embodies a design idea of separation of execution logic and object image, the design idea of object-oriented image design reflects the static relationship between objects, while WF provides the State relationship between objects in the process of mutual use. in the future development, it is hard to say whether WF can fulfill this mission. However, the impact of WF on programming ideas is definitely not just an approval system development kit. The above is just a personal opinion, it is not the content to be discussed in this article, but the experience of WF over the past three years.

 

 

I personally think that WF provides a lot of functions. Based on these functions, there are multiple groups of businesses, and there is no need to pursue all the functions of WF in applications, there is no need to pursue a perfect architecture. I personally think it is good to be suitable.

Using WF for development in my personal experience

• Business Process Platform
• Industrial Control System
• Data Service Logic Algorithms
• Application Execution Logic Control

These aspects are very good, but the architecture designed for different applications is different from the technology used.

This article is a frequently used business process platform architecture (approval system, which is used by three independent projects ).

 

Workflow template in XOML format

WF provides two workflow templates, Dll and XOML. Of course, you can implement Load to allow the engine to support Visio or any other methods.

Many people who develop the WF project for the first time use the workflow template in Dll mode, mainly because the Dll method is simpler than the XOML method.

 

In addition, there are two methods to use XOML. One is to compile XOML and the other is to load XOML.

The compilation of XOML and the loading of XOML files are very different from the implementation principles. I will not talk about the detailed descriptions in my previous articles here.

This architecture uses the method of loading XOML strings

 

 

 

 

Here we will describe the advantages and disadvantages of using DLL templates and XOML templates.

If you want to implement the same service, the comparison between the DLL template and the XOML template is as follows:

 

DLL template: it is easy for developers to design processes.

XOML template: it is difficult for developers to design processes.

 

If you want to find it difficult to choose between them, the best way is to support both methods. For example, for workflow of SharePoint3.0, the process designed with SharePointDesigner is in XOML format, the process designed with VS is in the Dll format.

 

Also, if you use the XOML string template, you cannot write code in the workflow. This issue will be discussed in the next section [combination of custom and XOML workflows ].

 

Combination of custom and XOML workflows

With the XOML string template, you cannot write code in the workflow. In many cases, you need to add code in the process. Using the XOML string template is not allowed, my solution is to encapsulate the code into a custom Activity, compile it into a DLL library, and then reference the custom Activity in the xoml string template.

 

 

One problem is the communication between a custom Activity and a process and other custom activities. Fortunately, WF provides DependencyProperty, in my previous articles, I have discussed in detail how to use DependencyProperty to implement context-based communication between custom activities and flows and other custom activities.

 

Maintenance of Business Process status

WF provides queue query and trace query. These are all WF status maintenance interfaces. However, these interfaces are system-level. I personally think it is necessary to customize a service status table.

The structure of the business status table is not discussed in this article. The following describes the interaction between the workflow instance and the business status table.

 

 

 

Physical Structure of the system

Finally, we need to select a host for the WF service and the way in which the WF service communicates with external entities. I personally do not recommend caching the WF service in the IIS Application, I often use Win services and WCF implementations,

I will not comment on the advantages and disadvantages of the two methods. If you are not familiar with the development of Win service and WCF, I suggest you learn this knowledge.

Is a common method: