A method and system for application of a workflow engine in a distributed scenario

Abstract

An application method and system of a workflow engine in a distributed scenario, a workflow service is a server, a third-party service is a client, comprising: developing a distributed scheduling framework, including a centralized server and a distributed client; the workflow service configures the interaction rules of the automatic expansion of the workflow service and the third-party service, the workflow service develops a general listener to read the configuration rules, and integrates the server to realize that the workflow service sends an interaction request to the third-party service; the third-party service realizes the interaction with the workflow service through the integrated client. The application realizes the interaction between the workflow service and the third-party service or the heterogeneous system through the configuration and the standard interface mode through the distributed scheduling framework, strips the interaction code between the workflow service and the business service or the heterogeneous system, thereby realizing decoupling and separation of concerns, making the workflow service more independent, and improving service stability; the development difficulty is reduced and the development efficiency is improved through configuration and dependency inversion.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of workflow engine application and distribution, and particularly relates to a method and system for implementing workflow engine in a distributed scenario based on a scheduling framework. BACKGROUND

[0002] Based on the open source workflow engine encapsulation, the implementation of workflow service has become the mainstream solution for building workflow scenarios at present. However, the current mainstream workflow engine is not designed and implemented based on a distributed architecture. Therefore, when applied in a distributed scenario, the current workflow service can only be integrated with third-party services (business services or heterogeneous systems) through the development mode of using service calls in listeners.

[0003] Taking Flowable or Activiti as an example, when the workflow service needs to interact with the third-party service in a distributed environment, the development steps are as follows:

[0004] Step 1: The business service opens a service call interface (such as FeignClient);

[0005] Step 2: Develop a listener in the workflow service to make service calls through the listener;

[0006] Step 3: Configure the listener on the node or line when configuring the workflow model.

[0007] Therefore, when there is a new workflow service interacting with the third-party service, the above three steps need to be repeated each time; when any party of the workflow or service interface changes, the other party may be affected and needs to be changed synchronously. Such a development mode cannot save any development amount, it is difficult to form a reuse capability, and it is difficult to guarantee the development specification and development quality.

[0008] CN106648573A, the application provides a kind of control method, control system and terminal of workflow business, wherein the control method of workflow business includes: detect whether the task trigger event sent by the application system is acquired;When detecting that the task trigger event is acquired, create task information according to the task trigger event;The task information is sent to the application system by the web service interface, so that the application system processes corresponding business data according to the task information.Through the technical scheme of the application, the decoupling of workflow business and the business data of application system is realized, and the intelligent creation and driving of the task information of workflow engine are realized, and the workflow engine is conveniently applied to multiple application systems.The patent mainly realizes the decoupling of workflow application and business processing through the way of front page.It realizes the task event sent by business system through workflow control system through general page, then carries the information for workflow routing in event, then jumps to corresponding business processing interface to complete processing, it mainly solves the coupling problem of workflow and business in monomer environment, when being in distributed environment, still cannot solve the problem of high coupling between workflow service and business application service. SUMMARY

[0009] In view of the problems in the prior art, the application replaces the dependence of service calling or heterogeneous system integration in the workflow through configuration and standard interface by means of a distributed scheduling framework, strips the code for interacting with business services or heterogeneous systems in the workflow service, makes the workflow service more independent, and thus improves the service stability; the configuration and interface reduce the development difficulty and improve the development efficiency, and thus realize cost reduction and efficiency increase.

[0010] The technical scheme adopted by the application is as follows:

[0011] The application method of workflow engine in distributed scenario based on scheduling framework, the workflow service is a server, and the third-party service is a client, the method comprises the following steps:

[0012] A distributed scheduling framework Tiger is developed, including a centralized server and distributed clients, the server holds a server register, a distributor and a server executor, is responsible for maintaining client registration information, routing according to registration information, completing client calling and the like; the client holds a client register, a client executor and a processor, is responsible for registering with the server, removing registration, heartbeat monitoring, receiving server request, executor execution, returning information and the like;

[0013] By configuring the interaction of the automatic expansion workflow service and the third-party service, including configuring the interaction rules of the workflow service and the third-party service, the workflow service develops a general listener integration and implements the interaction of the workflow service and the third-party service through TigerServer.

[0014] The third-party service completes the interaction with the workflow service by integrating TigerClient and implementing a client processor.

[0015] An application system of a workflow engine in a distributed scenario, comprising:

[0016] A server end holding a server end register, a distributor and a server end executor, responsible for maintaining client end registration information, routing according to the registration information, and completing client end calling;

[0017] A client end holding a client end register, a client end executor and a processor, responsible for registering with the server end, removing the registration, heartbeat monitoring, receiving the server end request, executing the executor, and returning information;

[0018] A research and development module for researching and developing a distributed scheduling framework;

[0019] A configuration module for configuring the interaction of the automatic expansion workflow service and the third-party service;

[0020] A database for storing information.

[0021] The beneficial effects of the present application are:

[0022] The present application regards the workflow service as a server end and the third-party service as a client end by self-researching a distributed scheduling framework, decouples the code coupling when integrating business services or heterogeneous systems of the workflow service, solves the problems of dynamic changes of client end service addresses, routing rules and standardized remote process calling in a distributed scenario through the framework, replaces the traditional service calling (such as Feign or Dubbo) through configuration for the interaction between services, and based on the above premise, the workflow service can no longer directly depend on the third-party service through the anti-corrosion layer, thereby greatly improving the stability of the workflow service, making the workflow service and the third-party service can be developed and iterated independently through the standard interface provided by the framework, shielding the implementation details in the service, thereby greatly reducing the difficulty of application and development of the workflow, effectively improving the development efficiency and reducing the problem troubleshooting difficulty, and achieving the purpose of cost reduction and efficiency increase. BRIEF DESCRIPTION OF DRAWINGS

[0023] Figure 1 As shown, it is a method flow chart for implementing the application of the workflow engine in the distributed scenario based on the scheduling framework. DETAILED DESCRIPTION

[0024] The present application will be further described below in conjunction with the drawings and embodiments: In order to clearly illustrate the technical features of the present application, the present application will be described in detail below through specific embodiments, and in conjunction with the drawings. The disclosure below provides many different embodiments or examples for implementing different structures of the present application. In order to simplify the disclosure of the present application, the components and settings of specific examples are described below. In addition, the present application can repeatedly refer to numbers and / or letters in different examples. Such repetition is for the purpose of simplification and clarity, and does not indicate the relationship between the various embodiments and / or settings discussed. It should be noted that the components illustrated in the drawings are not necessarily drawn to scale. The present application omits the description of well-known components and processing techniques and processes to avoid unnecessarily limiting the present application.

[0025] For example, when the running environment is a monolithic architecture, the workflow and business code are called within the system, and there is no problem. When in a distributed environment, such as a microservice architecture based on container technology, the workflow service and the business service are independent applications, and when they need to interact (there are indeed a large number of interactions between them, and the interactions continue to increase), the solution provided by the workflow engine is to make service calls through a process listener (Listener). The listener must be deployed in the workflow service. Because the business service is complex and variable, the workflow service should be relatively stable, so this highly coupled solution has brought a series of problems.

[0026] The detailed description of the distributed scheduling framework Tiger in the present application is as follows: The Tiger implementation scheme is to abstract the service parties into a server TigerServer and a client TigerClient by combining the application interaction characteristics in the distributed scenario. The bottom layer of the two is run and interacted through an independent process (NettyServer), which is decoupled from the main program, but the program can also share resources when running. At the same time, because Tiger can be integrated as an independent two-party library, the association with the application framework is very low, so it can be widely used in multiple application scenarios.

[0027] Both share the same core (TigerCore), which is responsible for providing configuration information, exception definition, parameter definition, model definition, utility class, and other public classes.

[0028] The server TigerServer mainly comprises a server registerer, a distributor, a server executor and the like core components, the server registerer provides a registration interface for the client to register and maintain a heartbeat, and saves the registration information into a database; the distributor undertakes the responsibilities of parameter checking and routing, and provides the application Tiger with the capability as an entrance; the server executor is responsible for calling the client executor according to the execution strategy and the retry strategy.

[0029] The client mainly comprises a client registerer, a processor, a client executor and the like core components, the client registerer is responsible for starting, removing registration and calling the server heartbeat interface to maintain a heartbeat; the processor is implemented by an application to realize specific business logic through an annotation and is automatically scanned and maintained in the memory when the application is started, and the client executor is responsible for receiving the execution request of the server executor, and then calling the corresponding processor to execute logical processing according to parameters and returning.

[0030] The client executor is responsible for receiving the request of the server executor and calling the client processor, and the client processor completes the execution of the client specific implementation and returns.

[0031] As shown in Figure 1 Fig. 1 is a flow chart of an application method of a workflow engine in a distributed scenario based on a scheduling framework, the distributed scheduling framework is used to regard the workflow service as a server, regard the business service as a client, separate the interaction through the framework, the workflow service is routed and called through configuration, and the client focuses on the business service itself, so that the two are decoupled, when interacting, the workflow service only needs to add a configuration, and the client internally implements an executor, and the detailed steps are as follows:

[0032] (I) developing a distributed scheduling framework

[0033] In a distributed environment, a distributed scheduling framework Tiger is developed based on Java language, the Tiger comprises a centralized server (TigerServer) and a plurality of distributed clients (TigerClient), the server holds a server registerer, a distributor and a server executor, the server registerer is responsible for maintaining client registration information, the distributor is responsible for querying the client registration information and calling the server server executor according to a configured routing rule, and the server executor is responsible for calling the client executor to complete the calling; the client holds a client registerer, a client executor and a processor, the client registerer is responsible for starting, removing registration and calling the server heartbeat interface to maintain a heartbeat; the processor is implemented by an application to realize specific business logic through an annotation and is automatically scanned and maintained in the memory when the application is started, and the client executor is responsible for receiving the execution request of the server executor, and then calling the corresponding processor to execute logical processing according to parameters and returning.

[0034] Through the distributed scheduling framework Tiger, the decoupling conditions of the workflow service and the third-party service are provided, wherein the workflow service is set as TigerServer, and the third-party service is set as TigerClient. On the one hand, the client difference is shielded; whether the client is a microservice or a heterogeneous system, the client is TigerClient under the framework, and the TigerClient also has the advantage of being convenient to manage. On the other hand, the condition of unifying the listeners in the workflow service is provided, and the extension can be easily realized through configuration. Meanwhile, the service calling logic is realized by the distributed scheduling framework. Therefore, the workflow service no longer depends on the third-party service interface, and the change of the third-party service will not affect the workflow service. Through the above two aspects, the stability of the workflow service can be greatly improved, the coupling degree between services is reduced, the development difficulty is obviously reduced, and the development efficiency is improved.

[0035] (II) The workflow service realizes automatic extension through configuration

[0036] The distributed scheduling framework enables the workflow service and the third-party service to interact very conveniently in a distributed scenario, but does not solve the problem of automatic extension when the workflow service and the third-party service are newly interacted. The present application solves this problem in two steps:

[0037] First step: realizing the interaction rule of the workflow service and the third-party service through configuration

[0038] Taking Flowable or Activiti as an example, the configuration should include the following information: process definition Key, listener type, listener Key (task definition Key or activity Id), execution time, executor identifier, and execution order.

[0039] The above configuration realizes the following characteristics: 1. compatible with multiple versions of processes (through the process definition Key instead of the process definition Id); 2. compatible with multiple listener types; 3. one listener supports multiple executor configurations.

[0040] Second step: developing a general listener to integrate TigerServer to realize the interaction between the workflow service and the third-party service.

[0041] Through the development of a general listener or the modification of the source code, the listener is triggered when the workflow is transferred. The listener first reads the configuration information of the first step, and then calls the distributor of the distributed scheduling framework Tiger according to the configuration information, realizes the interaction between the workflow service and other services, supports synchronous and asynchronous calling, supports different routing rules, supports retry, and supports link tracking.

[0042] Through the implementation mode, if inter-service interaction is needed when configuring a work flow, only one configuration needs to be added, meanwhile, the highly reusable capability provided by the scheduling framework can be obtained, the development difficulty is greatly reduced, and the development efficiency is improved.

[0043] (Three) third party service interacts with work flow service through implementing processor

[0044] In a distributed scenario, each business service logic should be as cohesive as possible, so by integrating TigerClient, the business service logic is converged to the service internally, without exposing the interface, and the implementation details are completely shielded, so that the business service can be highly reused, and only the influence of the business during the work flow transfer needs to be implemented, and the business service developer can completely ignore the work flow, thereby creating conditions for independent iteration of the work flow and the business.

[0045] The third party service first integrates TigerClient, TigerClient provides a client processor interface, the business service implements the interface through the Bean mode to complete the business logic processing, when the business service is started, TigerClient will automatically scan the client processor and be included in the memory management, and finally waits for the work flow service to call, runs the executor to execute the interface method and returns the server to complete the complete interaction process. In this way, the business service will not need to pay attention to the running state of the work flow, thereby decoupling the third party service and the work flow service, reducing the development difficulty, and at the same time, the development efficiency can be improved through parallel development.

[0046] The application further provides an application system of a work flow engine in a distributed scenario, the system is suitable for the application method of the work flow engine in the distributed scenario, and the system comprises:

[0047] The server holds a server register, a distributor and a server executor, is responsible for maintaining client registration information, routing according to the registration information, and completing client calling;

[0048] The client holds a client register, a client executor and a processor, is responsible for registering, removing registration, heartbeat monitoring, receiving server requests, executing the executor, and returning information;

[0049] The R&D module is used for researching and developing a distributed scheduling framework;

[0050] The configuration module is used for configuring the interaction between the automatic expansion work flow service and the third party service;

[0051] The database is used for storing information.

[0052] In this way, in a distributed scenario, the interaction between the workflow service and the third-party service is implemented through configuration and framework, so that the interaction between the two is simple, and meanwhile, the high-order general ability is also provided, and the developers of different services can focus on the service responsible by themselves, so that the software design idea of high cohesion and low coupling is met.

[0053] Finally, it should be noted that: the above examples are only used to illustrate the technical solutions of the present application, but not to limit it, although the present application has been described in detail with reference to the above examples, those skilled in the art should understand that: the specific embodiments of the present application can still be modified or replaced by the equivalent, without departing from the spirit and scope of the present application, any modification or equivalent replacement, which should be covered within the protection scope of the claims of the present application.

Claims

1. A method for applying a workflow engine in a distributed scenario, wherein the workflow service is the server and the third-party service is the client, characterized in that: The method comprises: Develop a distributed scheduling framework, including a centralized server and distributed clients. The server holds a server registrar, a dispatcher, and a server executor, responsible for maintaining client registration information, routing based on registration information, and completing client calls. The client holds a client registrar, a client executor, and a processor, responsible for registering with the server, removing registrations, heartbeat monitoring, receiving server requests, executing executors, and returning information. By configuring the interaction between the workflow service and third-party services, including configuring the interaction rules between the workflow service and third-party services, developing a universal listener integration for the workflow service, and implementing the interaction between the workflow service and third-party services on the server side; The third-party service implements the client processor to complete the interaction with the workflow service through the integrated client; The server registrar is responsible for maintaining client registration information; the dispatcher is responsible for querying client registration information and calling the server executor according to the configured routing rules. The server executor calls the client executor to complete the call; The client registrar is responsible for starting and removing registrations and calling the server heartbeat API to maintain heartbeats. The processor implements specific business logic through annotations in the application and is automatically scanned and maintained in memory when the application starts. The client executor is responsible for receiving execution requests from the server executor, calling the corresponding processor based on the parameters to perform logical processing, and then returning. Configure the interaction rules between workflow services and third-party services, including process definition key, listener type, listener key, execution timing, executor identifier, and execution sequence. This is used to support compatibility with multiple versions of processes, multiple listener types, and multiple executor configurations supported by one listener. Listener keys include: task definition keys and identification fields; Developing a universal listener for workflow services and integrating it with the server-side to implement interaction between workflow services and third-party services includes: developing a universal listener or modifying source code to trigger the universal listener when controlling workflow flow; the universal listener reads custom configuration information and calls the distributed scheduling framework server-side dispatcher based on the configuration information to send requests to the client to implement inter-service interaction, supporting synchronous and asynchronous calls, retries, and link tracking; The third-party service integration client provides a client processor interface. When the business service starts, the client automatically scans the client processor and incorporates it into memory management. It is used to wait for the workflow service to call, run the executor to execute the interface method and return to the server to complete the interaction process.

2. An application system of a workflow engine in a distributed scenario, wherein the system is applicable to the application method of the workflow engine in a distributed scenario according to claim 1, characterized in that: include: The server side holds the server registrar, dispatcher, and server executor, and is responsible for maintaining client registration information, routing based on registration information, and completing client calls; The client holds the client registrar, client executor, and processor, and is responsible for registering with the server, removing registrations, heartbeat monitoring, receiving server requests, executing executors, and returning information; R&D module, used to develop distributed scheduling framework; Configuration module, used to configure the interaction between the automatic expansion workflow service and third-party services; Databases, used to store information.

3. The application system of the workflow engine in a distributed scenario according to claim 2, characterized in that: The server includes: Server registrar, dispatcher and server executor; The server registrar provides a registration interface for the client to register and maintain heartbeats, and saves the registration information in the database; The dispatcher is responsible for querying the client registration information and calling the server executor according to the configured routing rules; The server executor is responsible for calling the client executor according to the execution strategy and retry strategy.

4. The application system of the workflow engine in a distributed scenario according to claim 2, characterized in that: The client includes: client registrar, client executor and processor. The client registrar is responsible for starting, removing registration and calling the server heartbeat interface to maintain the heartbeat. The processor implements specific business logic through annotations by the application and is automatically scanned and maintained in memory when the application starts. The client executor is responsible for receiving execution requests from the server executor, and then calling the corresponding processor according to the parameters to execute logical processing and return.

Images