Control system, method, device, computer device and medium for flow execution

Abstract

The application relates to a process execution control system, method, device, computer equipment and medium. The system comprises a main process module, the main process module comprises at least one node, the system further comprises a client and a service module configured in advance for the node, wherein the main process module is used for generating a data operation request according to configuration information of the client and sending the data operation request to the client, the client is used for forwarding the data operation request to the service module according to the configuration information, and the service module is used for calling a pre-configured external system and executing corresponding operation through the external system according to the data operation request. The method can realize decoupling of a main process module of process execution and an external system, so that the integration process of process execution and various external systems is simplified.

Description

Technical Field

[0001] This application relates to the field of strategy process execution technology, and in particular to a control system, method, apparatus, computer equipment and medium for process execution. Background Technology

[0002] With the continuous development of the strategy execution field, technologies have emerged to enable the interaction between the main strategy execution process and various data sources and external systems (such as user login services, advertising platforms, Python model services, etc.). The core of this technology is to use technical means to connect the main strategy execution process with external data and services, supporting the smooth operation of the strategy.

[0003] Currently, the approach used in this field relies on customized integration code to achieve the above interactions. This involves writing connection and query logic for different data sources, writing call code for external services, and writing data format conversion code.

[0004] However, this model suffers from high system coupling, rigid architecture, difficulty in flexible expansion, and the need to modify the strategy execution logic when the data source or external service changes. Summary of the Invention

[0005] Therefore, it is necessary to provide a control system, method, apparatus, computer equipment, and medium that can decouple the execution of a process from external systems to address the aforementioned technical problems.

[0006] In a first aspect, this application provides a control system for process execution, including a main process module, the main process module including at least one node, and the system further including client and service modules pre-configured for the node, wherein...

[0007] The main process module is used to generate data operation requests based on the client's configuration information and send the data operation requests to the client;

[0008] The client is used to forward data operation requests to the service module based on the configuration information;

[0009] The service module is used to call pre-configured external systems and execute corresponding operations based on data operation requests.

[0010] In one embodiment, the client's configuration information includes the address information of the service module and request parameters. The main process module is used to obtain the corresponding parameters from the pre-set context according to the request parameters and generate a data operation request based on the obtained parameters.

[0011] The client is used to send data operation requests to the service module based on the address information of the service module.

[0012] In one embodiment, the service module is used to receive results returned by an external system;

[0013] The client is also used to receive the results returned by the service module, extract the newly added fields from the results, and store the newly added fields in the context.

[0014] In one embodiment, when the data operation requests initiated by clients corresponding to multiple nodes involve the same operation object, the service modules corresponding to each node are used to sequentially call the corresponding external systems according to the distributed locks pre-set for the service modules.

[0015] In one embodiment, the client's configuration information is pre-stored in a Redis cache and in the memory of the server where the main process module is deployed;

[0016] The main process module is also used to retrieve the client's configuration information from memory. If the client's configuration information is not present in memory, it is retrieved from the Redis cache.

[0017] In a second aspect, this application provides a method for controlling process execution, comprising:

[0018] Retrieve the client configuration information that has been pre-configured for the nodes in the process;

[0019] Generate a data operation request based on the client's configuration information and send the data operation request to the client;

[0020] The client invokes the service modules pre-configured for the node.

[0021] The service module calls the corresponding external system to perform the corresponding operation based on the data operation request.

[0022] In one embodiment, the client's configuration information includes the address information of the service module, request parameters, and request method, the method further including:

[0023] Determine the corresponding service module based on the purpose of the node, and obtain the address information, request parameters, and request method of the service module.

[0024] The client's configuration information is determined based on the service module's address information, request parameters, and request method.

[0025] Configure nodes based on the service module and client configuration information.

[0026] In a third aspect, this application provides a control device for process execution, comprising:

[0027] The acquisition module is used to obtain the configuration information of the client that has been pre-configured for the nodes in the process;

[0028] The sending module is used to generate data operation requests based on the client's configuration information and send the data operation requests to the client.

[0029] The calling module is used to invoke service modules pre-configured for nodes via the client.

[0030] The processing module is used to call the corresponding external system through the service module, so that the external system can perform the corresponding operation based on the data operation request.

[0031] In a fourth aspect, this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the process execution control method provided in any embodiment of the second aspect of this application.

[0032] In a fifth aspect, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the process execution control method provided in any embodiment of the second aspect of this application.

[0033] The control system, method, apparatus, computer equipment, and media for the aforementioned process execution, through client and service modules, separate the main process module for strategy execution from the integration parts of various external systems. This allows the main process module to focus only on its own strategy execution logic without needing to handle specific external interaction details, significantly simplifying the integration process and achieving decoupling. This simplifies the integration process between process execution and various external systems and improves configurability. When adding a new external system, only the corresponding lightweight service module needs to be implemented, without modifying the main process module's program, reducing expansion costs. Attached Figure Description

[0034] Figure 1 This is a structural block diagram of the control system for process execution in some embodiments;

[0035] Figure 2 This is a flowchart illustrating the control method for process execution in some embodiments;

[0036] Figure 3 This is a flowchart illustrating the control method for process execution in some other embodiments;

[0037] Figure 4 This is a structural block diagram of the control device for process execution in some embodiments;

[0038] Figure 5 This is a diagram showing the internal structure of a computer device in some embodiments. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0040] In a first aspect, this application provides a control system for process execution, such as Figure 1 As shown, the system includes a main process module, which includes at least one node. The system also includes a client and a service module pre-configured for the node. The main process module generates a data operation request based on the client's configuration information and sends the data operation request to the client. The client forwards the data operation request to the service module based on the configuration information. The service module calls a pre-configured external system and executes the corresponding operation based on the data operation request through the external system.

[0041] Process execution refers to the entire process of driving a business process from start to finish, following preset steps (consisting of multiple nodes).

[0042] Node: refers to a specific step unit in the process. Each node corresponds to a specific task and requires pre-configuration of the client to enable interaction with external systems.

[0043] Main process module: This refers to the core module that controls the execution of the entire process. It is responsible for logically connecting nodes, generating operation requests, and coordinating client work.

[0044] Service module: refers to the intermediate module that interfaces with external systems, receives requests forwarded by clients, and calls the corresponding external systems to perform specific operations.

[0045] Client: This refers to the intermediate component that connects the main process module and the service module, and forwards the requests generated by the main process to the service module according to the configuration information.

[0046] Specifically, client configuration information refers to information pre-configured for nodes to guide client operations, such as the client's request method, ensuring that the client can correctly forward requests.

[0047] Data operation request: refers to the instruction (such as querying data, calling services, etc.) generated by the main process module based on the client configuration information to trigger operations of external systems.

[0048] External systems refer to external resources or services that need to be interacted with during the execution of the process, such as various data sources and external service systems.

[0049] Specifically, the main process module logically advances through the nodes. Based on the configuration information of the current node's client, it generates a corresponding data operation request and sends it to the client of that node. The client, according to its own configuration information, forwards the received data operation request to the corresponding service module. After receiving the request, the service module calls a pre-configured external system, which then performs the specific operation based on the request to complete the node task.

[0050] This application decouples the main strategy execution process from the external system by introducing a client and service module as an intermediate module. The specific analysis is as follows:

[0051] In traditional methods, the main strategy execution process is directly and hard-coded into the data source and external services, resulting in a deep binding of the interaction logic between the main process and the external system. If one side changes, the other side needs to be modified simultaneously.

[0052] In this application, the main process module is only responsible for generating data operation requests and sending them to the client based on the client's configuration information. It does not need to concern itself with how the requests are transmitted to external systems, the specific interface format of the external systems, or the data processing logic. The client simply forwards the requests to the corresponding service module based on the configuration information and does not participate in the main process's business logic or the specific operations of the external systems.

[0053] Furthermore, the service module is specifically designed to interface with external systems, responsible for calling these systems to perform operations. It is logically isolated from the main process and the client, establishing contact only through request forwarding. When an external system (such as a data source or service interface) changes, only the corresponding service module needs modification (e.g., adjusting the calling logic or adapting to the new interface); the main process module and the client remain unchanged. When a new external system is added, only the corresponding service module needs to be added and the client configured; the main process remains unmodified. Through this layered transmission mechanism from the main process to the client, to the service module, and then to the external system, all parties interact only through pre-defined configuration information, avoiding direct binding and thus achieving decoupling.

[0054] In one embodiment, the client's configuration information includes the address information of the service module and request parameters. The main process module is used to obtain the corresponding parameters from a pre-set context based on the request parameters, and generate a data operation request based on the obtained parameters.

[0055] The client is used to send data operation requests to the service module based on the address information of the service module.

[0056] The address information of the service module refers to the network address (such as a Uniform Resource Locator) used to locate the service module, which is the information that enables the client to accurately find and connect to the service module.

[0057] Request parameters: These are the parameter rules or templates pre-configured in the client and used to generate data operation requests. For example, request parameters may include fields such as "user ID" and "query date," and the main process needs to obtain the actual user ID and date values ​​from the context.

[0058] Context refers to the set of data accumulated during the execution of a process that can be shared by all modules. It includes the current process status information, intermediate results, and external inputs. For example, user-submitted form data, the execution results of previous nodes, and system environment variables. The main process module can extract the specific values ​​required for the request parameters from this context.

[0059] Specifically, the client's configuration information can be:

[0060] {

[0061] "url":"http: / / ip:port / slef / server / user / firstLoginTime",

[0062] "requestMethod":"POST",

[0063] "requestParams":{

[0064] "uid":"${SLEFContext.uid}"

[0065] }

[0066] }

[0067] The configuration information includes the address information of the service module, i.e., the URL (Uniform Resource Locator), the request method (POST), and the request parameter (uid). The uid is specifically configured to be obtained from the context. In other words, this configuration information is used to indicate that the corresponding uid is obtained from the context as the request parameter for this request.

[0068] Therefore, this application can extract the address information, request parameters, and other information of the service module corresponding to the node from the configuration information of the client corresponding to the node, and further generate the corresponding data operation request based on the request parameters, and send the generated data operation request to the corresponding service module based on the address information of the service module.

[0069] In this application, the client can connect to multiple service modules. For different service modules, it is only necessary to configure the client's configuration items accordingly. For example, when a new service module is changed, the address information of the service module in the client configuration is modified accordingly, and the request parameters are modified accordingly.

[0070] The beneficial effect of this embodiment is that, through the service module address information and request parameters in the client configuration, the main process module can accurately obtain the required parameters from the context and generate a data operation request. The client then accurately forwards the request based on the address information, ensuring that the process from request generation to delivery to the service module is standardized and without deviation.

[0071] In one embodiment, the service module is used to receive the results returned by the external system, and the client is also used to receive the results returned by the service module, extract the newly added fields from the results, and store the newly added fields in the context.

[0072] For example, if the current node needs to query a user's first login time, the client corresponding to the current node sends a request to the current node's service module to query the user's first login time. The service module forwards the request to the corresponding external system, which then returns the user's first login time. Assume the result returned by the external user service system is:

[0073] The response is set to {"uid":"uid1","firstLoginTime":"2025-06-03"}. After the client receives the returned result, it iterates through all the fields in the returned result and then sets the newly added field firstLoginTime to the context, i.e., SLEFContext.firstLoginTime = "2025-06-03" is set to the context for the next node to call.

[0074] The beneficial effects of this embodiment are as follows: after the service module receives the results returned by the external system, the client receives and processes them, extracts the newly added fields and stores them in the context, ensuring that the new data generated by the external interaction can be reused by the subsequent nodes of the process, forming a coherent flow of data in the process, and realizing the closed-loop transmission of results and context updates.

[0075] In one embodiment, when the data operation requests initiated by clients corresponding to multiple nodes involve the same operation object, the service modules corresponding to each node are used to sequentially call the corresponding external systems according to the distributed locks pre-set for the service modules.

[0076] The target of operation refers to the target entity that is jointly operated by multiple nodes or strategy processes, such as the same coupon for the same user, or the same advertising account.

[0077] Distributed locks are mechanisms used in distributed systems to control concurrent access to the same resource by multiple nodes, ensuring that only one node can perform operations on that resource at a time, thus avoiding conflicts.

[0078] Because there are many service modules abstracted from decoupling, they may be deployed on different service resources. For operations that are prone to inaccurate amount changes, coupon issuance, and redemption, such as amount changes, coupon over-inventory issuance, or redemption, which cannot be performed concurrently, distributed locks need to be added to different service modules for control.

[0079] Specifically, if multiple data operation requests reuse the same service module, a distributed lock can be set in that service module to control concurrency.

[0080] If multiple data operation requests involve different service modules (such as different service modules for issuing and redeeming coupons), the same distributed lock can be configured for these service modules. The granularity of the lock is precise down to the user UID and coupon code, ensuring that only one operation can be performed on the same coupon for the same user at the same time. This avoids data chaos caused by simultaneous issuance and redemption, or over-issuance caused by multiple concurrent coupon issuance processes.

[0081] For example, suppose multiple strategy processes need to query the inventory quantity of the same coupon and then issue it to users. To avoid over-issuance caused by multiple strategies issuing coupons to users concurrently at the same time, this application can take different measures for different situations, as follows:

[0082] Scenario 1: Assuming both scenarios involve issuing coupons and reuse the same service module, a distributed lock can be added to this service module for control.

[0083] Scenario Two: Assume Process One involves a user receiving an external third-party coupon (e.g., a coupon for 10 yuan off purchases of 20 yuan or more) upon meeting certain conditions; this corresponds to the coupon issuance service module. Process Two involves a user redeeming an external third-party coupon (also for 10 yuan off purchases of 20 yuan or more) in a specific scenario; this corresponds to the coupon redemption service module. These are two different service modules that can share the same distributed lock for control. The granularity of the distributed lock can be the user's UID and the coupon code. This means that by using a distributed lock, operations on the same coupon for the same user can be performed simultaneously.

[0084] For example, in a customer acquisition and advertising scenario, process one, after a strategy decision, requires adjusting the budget for advertising account 1. Process two, after a strategy decision, requires shutting down advertising account 1. Here, the control granularity of the distributed lock can be the advertising account itself; that is, operations on the same advertising account must be executed only once at a time. Therefore, when developing service modules, it is necessary to identify and correctly use distributed locks in the logic code.

[0085] The beneficial effect of this embodiment is that, by using distributed locks (precise control based on the operation object), it solves the conflict problem of concurrent operations on the same operation object by multiple nodes or multiple service modules, thus ensuring the consistency of operations.

[0086] In one embodiment, the client's configuration information is pre-stored in the Redis cache and in the memory of the server where the main process module is deployed. The main process module is also used to retrieve the client's configuration information from the memory. When the client's configuration information is not in the memory, it is retrieved from the Redis cache.

[0087] Among them, memory cache refers to the cache in the local memory of the server where the main process module is deployed. It belongs to the first level of cache and is used by the main process module for priority querying.

[0088] Redis cache: This can be a cache in a standalone Redis server, belonging to the second-level cache. When there is no valid configuration in the memory cache, the main process module will query from here.

[0089] To ensure that nodes can efficiently obtain the correct client configuration information during execution, this application employs a two-level caching mechanism for storing and retrieving configurations. The specific logic is as follows:

[0090] When configuring the main process module, a unique process number is generated, and each node corresponds to a unique node number and a dedicated client configuration; these configurations are pushed to the two-level cache (memory cache and Redis cache) mentioned above.

[0091] When a node is executed, the main process module first queries the local memory cache for the configuration information of the client of that node. If it is not invalid, it is used directly. If there is no valid configuration in the memory cache, it queries the Redis cache and stores the retrieved configuration information back into the memory cache for use in the short term.

[0092] The beneficial effects of this embodiment are as follows: by reducing the overhead of remote queries through the first-level cache, namely the local memory cache, and supplementing it with the second-level cache, the Redis cache, the two-level cache reduces direct queries to the underlying database, especially avoiding the problem of frequent database access during node execution, thus optimizing system resource consumption.

[0093] In a first aspect, this application provides a method for controlling process execution, such as Figure 2 As shown, the control methods for process execution include:

[0094] Step S21: Obtain the configuration information of the client that has been pre-configured for the nodes in the process.

[0095] Step S22: Generate a data operation request based on the client's configuration information and send the data operation request to the client.

[0096] Step S23: The service module pre-configured for the node is invoked through the client.

[0097] Step S24: The service module calls the corresponding external system to perform the corresponding operation based on the data operation request.

[0098] Specifically, the above-mentioned process execution control method is applied to the main process module, wherein the main process module includes at least one node, and the node in the process is equivalent to the node in the main process module.

[0099] Specifically, the specific implementation methods of each step from S21 to S24 can be referred to the above-described specific description of the control system for process execution, and are not specifically limited here.

[0100] In one embodiment, the client's configuration information includes the address information of the service module, request parameters, and request method. The process execution control method may further include: determining the corresponding service module according to the purpose of the node, obtaining the address information, request parameters, and request method corresponding to the service module, determining the client's configuration information according to the address information, request parameters, and request method of the service module, and configuring the node according to the configuration information of the service module and the client.

[0101] The purpose of a node can be, for example, data querying, file uploading, or user verification.

[0102] Specifically, first determine the purpose of the current node. Based on the node's purpose and the application scenarios (i.e., uses) of each service module, find the corresponding service module. From the matched service modules, extract their address information (e.g., interface URL), request parameters (e.g., data fields to be transmitted), and request methods (e.g., GET (GET Method) or POST). Integrate the above information to form the client's configuration information. Configure the client's configuration information on the corresponding node so that it can correctly call the service modules.

[0103] This application allows operators to view relevant information and perform fuzzy searches by managing the name, application scenario, purpose description, and corresponding client configuration information of the service module through a unified interface, thus assisting in configuration decisions.

[0104] Specifically, the interface can display the name of the service module as a unique identifier. The interface can also display the application scenarios corresponding to the service module, such as user login verification scenarios and order payment callback scenarios. Furthermore, it can show the specific purpose of each application scenario; for example, the user login verification scenario is used to handle user identity information verification, and the order payment callback scenario is used to receive result notifications from third-party payment platforms.

[0105] Furthermore, it can also display the corresponding client configuration information, including service address, request parameters, request method, etc., corresponding to the client reuse requirements.

[0106] Specifically, this application can be categorized and displayed by module, making it convenient for operations personnel to quickly locate the service module within the business scenario of a node when configuring strategy process nodes. It supports fuzzy searches based on keywords such as name, scenario, and purpose; for example, entering "payment" will filter out all payment-related service modules, reducing search costs.

[0107] The interface layout displays the correspondence between nodes, service modules, and clients, allowing operations personnel to intuitively understand the configuration chain and avoid misconfigurations.

[0108] This approach achieves structured management of service modules and provides operators with efficient configuration references through search and related display functions, thus solving the problem of matching efficiency during the configuration process caused by the rapid growth of service modules.

[0109] In another embodiment, this application can also input the relevant information of all service modules into a large model, and use the large model to identify service modules with high similarity or overlapping functions; when using the service, refer to the recommendations given by the large model to assist in selecting appropriate service modules.

[0110] In one embodiment, the process configuration may be modified due to changes in business operations. To ensure that the cache is updated in a timely manner after the policy process changes, and to prevent the policy process from not executing the latest policy process configuration, on the one hand, when the configuration information of the process changes, the configuration information change event can be listened to and the configuration information of the Redis cache can be updated in real time.

[0111] On the other hand, a scheduled task can be used, such as querying the strategy process configuration information every 2 minutes. If a changed strategy process is found, the new strategy process configuration information is updated in the Redis cache to ensure that the Redis cache is updated in a timely manner after the configuration information changes.

[0112] The advantages of this embodiment are as follows: by matching and configuring service modules according to node usage, it ensures that nodes can accurately connect to the required services. Key information of service modules is transformed into client configurations, avoiding manual input of numerous parameters and reducing operational complexity and error rates. When the address, parameters, etc., of a service module change, only the corresponding configuration information needs to be updated; there is no need to modify the core logic of the node, facilitating system maintenance and iteration.

[0113] In one possible application scenario, please refer to... Figure 3 The following example illustrates the steps of the control method for the execution of this application process, using a scenario where a user applies for and completes the issuance of coupons. Figure 3 As shown, Figure 3 In this context, SLEF Server is equivalent to a service module, SLEF Client is equivalent to a client, and external user service systems, external coupon service systems, and external SMS platforms are equivalent to external systems. Figure 3 In this context, the control methods for process execution may include:

[0114] After a user completes their application conversion, Node 1 generates an event message indicating that the application has been completed. This event message contains uid (user ID), eventCode (event code), and applyCompleteTime (application completion time), and the execution context is SLEFContext. Assuming the user application completion event message has uid = "uid1", eventCode = "applyComplete", and applyCompleteTime = "2025-06-03", when Node 1 receives the user application completion event, it sets the relevant fields from the event message into the context. The updated information in the context is as follows:

[0115] SLEFContext.uid="uid1", SLEFContext.eventCode="applyComplete", SLEFContext.applyCompleteTime="2025-06-03".

[0116] Node 2 queries the user's first login time from the external user service system. Assume the SLEF server address is "http: / / ip:port / slef / server / user / firstLoginTime" and the request method is POST.

[0117] The configuration information for the client corresponding to node 2 is as follows:

[0118] {

[0119] "url":"http: / / ip:port / slef / server / user / firstLoginTime",

[0120] "requestMethod":"POST",

[0121] "requestParams":{

[0122] "uid":"${SLEFContext.uid}"

[0123] }

[0124] }

[0125] When execution reaches node 2, node 2 will retrieve the corresponding parameters and populate them according to the requestParams configuration in the client's configuration information. According to the client's configuration, the uid parameter in requestParams is configured as ${SLEFContext.uid}, indicating that the value of the uid variable is retrieved from the SLEFContext context and populated into the parameter. The value of the uid variable was already set in the SLEFContext in node 1, i.e., request parameter uid = uid1. Then, the corresponding SLEF Server is called according to the URL configuration, and the SLEF Server then calls the external user service system to query the user's first login time. Assuming the external user service system returns a response = {"uid":"uid1","firstLoginTime":"2025-06-03"}, after the SLEF Client obtains the returned result, it iterates through all fields in the result and then sets the newly added field firstLoginTime into the context, i.e., SLEFContext.firstLoginTime = "2025-06-03".

[0126] Node 3 determines whether the user's application completion time equals their first login time (only checking the year, month, and day, ignoring the hour, minute, and second), i.e., whether the user's application completion time and first login time are on the same day. This is done by checking if the application completion time and first login time dates in the policy execution flow context are equal, specifically whether the `SLEFContext.applyCompleteTime` and `SLEFContext.firstLoginTime` fields are equal. If the `SLEFContext.applyCompleteTime` and `SLEFContext.firstLoginTime` fields are equal, it means the user's application completion time and first login time are on the same day, and the process proceeds to Node 4. If the `SLEFContext.applyCompleteTime` and `SLEFContext.firstLoginTime` fields are not equal, it means the user's application completion time and first login time are not on the same day, and the process proceeds to the next node, Node 5. Nodes 4 and 5 are two branches, and only one will be executed.

[0127] Node 4 queries the number of 50 yuan coupons from an external coupon service. Assume the SLEF server address is "http: / / ip:port / slef / server / coupon / count" and the request method is POST.

[0128] The configuration information for the client corresponding to this node is as follows:

[0129] {

[0130] "url":"http: / / ip:port / slef / server / coupon / count",

[0131] "requestMethod":"POST",

[0132] "requestParams":{

[0133] "couponCode":"${SLEFContext.couponCode}"

[0134] }

[0135] }

[0136] When execution reaches node 4, node 4 will retrieve the corresponding parameters based on the requestParams configuration in the client's configuration information and populate them. For example, if node 4 selects a 50 yuan coupon, assuming its coupon code is "coupon_50", the coupon code "coupon_50" will be set in the SLEFContext context, i.e., SLEFContext.couponCode = "coupon_50"; its coupon name is "50 yuan coupon", and the coupon name "50 yuan coupon" will be set in the SLEFContext context where the strategy is executed, i.e., SLEFContext.couponName = "50 yuan coupon". According to the client's configuration, the couponCode in the request parameter requestParams is configured as ${SLEFContext.couponCode}, indicating that the value of the couponCode variable is retrieved from the context and populated into the parameter, i.e., request parameter couponCode = "coupon_50". Then, according to the URL configuration, the corresponding SLEF Server is called, and the SLEF Server then calls the external coupon system to query the quantity of coupons with coupon code coupon_50. Suppose the external coupon system returns a response = {"couponCode":"coupon_50","couponCount":"100"}. After the client receives the returned result, it iterates through all the fields in the result and then sets the newly added field couponCount to the context SLEFContext, i.e., SLEFContext.couponCount = "100".

[0137] Node 5 queries the quantity of 30 yuan coupons from an external coupon service. The external service is a coupon system, and the SLEF Server corresponding to Node 5 interacts with the external coupon system. Assume the address of the SLEF Server is "http: / / ip:port / slef / server / coupon / count", and the request method is POST.

[0138] The configuration information for the client corresponding to this node is as follows:

[0139] {

[0140] "url":"http: / / ip:port / slef / server / coupon / count",

[0141] "requestMethod":"POST",

[0142] "requestParams":{

[0143] "couponCode":"${SLEFContext.couponCode}"

[0144] }

[0145] }

[0146] When execution reaches node 5, node 5 will retrieve the corresponding parameters based on the requestParams configuration in the client's configuration information and populate them. For example, if node 5 selects a 30 yuan coupon, assuming its coupon code is "coupon_30", the coupon code "coupon_30" will be set in the SLEFContext, i.e., SLEFContext.couponCode = "coupon_30"; its coupon name is "30 yuan coupon", and the coupon name "30 yuan coupon" will be set in the SLEFContext, i.e., SLEFContext.couponName = "30 yuan coupon". According to the client's configuration information, the couponCode configuration in the requestParams is ${SLEFContext.couponCode}, indicating that the value of the couponCode variable is retrieved from the context and populated into the parameter, i.e., request parameter couponCode = "coupon_30". Then, according to the URL configuration, the corresponding SLEF Server is called, and the SLEF Server then calls the external coupon system to query the quantity of coupons with coupon code coupon_30. Assuming the external coupon system returns a response = {"couponCode":"coupon_30","couponCount":"30"}, after the SLEF Client obtains the returned result, it iterates through all the fields in the result and then sets the newly added field couponCount to the top and bottom, i.e., SLEFContext.couponCount = 30.

[0147] Node 6 determines whether the number of coupons retrieved from the external coupon service system is greater than 0. Since the previous branch (node ​​4 or node 5) has already set the coupon data volume in the couponCount field of the context SLEFContext, it determines whether the number of coupons is greater than 0, that is, whether SLEFContext.couponCount is greater than 0.

[0148] If SLEFContext.couponCount is greater than 0, it means that the coupon still has valid inventory and can be issued to the user. If it is less than or equal to 0, it means that the coupon does not have valid inventory and cannot be issued to the user. In this case, the process ends directly.

[0149] Node 7 calls an external coupon service system to issue coupons to users. It needs to notify the external coupon system who (user UID) to receive which coupon (coupon code). If the execution originates from the preceding branch node 4, the coupon issued to the user will be a 50 yuan coupon, with coupon code 'coupon_50'; if it originates from the preceding branch node 5, the coupon issued to the user will be a 30 yuan coupon, with coupon code 'coupon_30'. The external system is the external coupon service system. Node 7's corresponding SLEF Server interacts with the external coupon service system. Assume the SLEF Server's address is "http: / / ip:port / slef / server / coupon / issue", and the request method is POST.

[0150] The configuration information for the client corresponding to this node is as follows:

[0151] {

[0152] "url":"http: / / ip:port / slef / server / coupon / issue",

[0153] "requestMethod":"POST",

[0154] "requestParams":{

[0155] "uid":"${SLEFContext.uid}",

[0156] "couponCode":"${SLEFContext.couponCode}"

[0157] }

[0158] }

[0159] When execution reaches node 7, node 7 retrieves the corresponding parameters based on the requestParams configuration in the client's configuration information and populates them. Previous nodes have already set the values ​​of uid and couponCode in the SLEFContext; that is, uid is taken from the uid value in the SLEFContext, which is "uid1"; couponCode is taken from the couponCode value in the SLEFContext, which is either coupon_50 or coupon_30. Then, based on the URL configuration, the corresponding SLEF Server for node 7 is called. The SLEF Server for node 7 encapsulates the ability to call the external coupon service system, forwards the request parameters to the external coupon service system, and parses the returned results from the external coupon service system.

[0160] Furthermore, the SLEF Server corresponding to node 7 transforms it into a unified return format {"uid":"uid1","couponCode":"coupon_30","issueStatus":"success"}, and then the SLEF Server returns the result to the client. After receiving the returned result, the client iterates through all the fields in the result and sets the newly added field issueStatus to the context SLEFContext, i.e., SLEFContext.issueStatus = "success".

[0161] Node 8 determines whether the user's coupon issuance status was successful. Since Node 7 has already set the user's coupon issuance status `issueStatus` in the `SLEFContext`, it checks whether `issueStatus` in the `SLEFContext` equals "success" to determine if the coupon issuance was successful. If `SLEFContext.issueStatus` equals "success", it means the user's coupon issuance was successful, and the process continues to the next node, Node 9. If `SLEFContext.issueStatus` does not equal "success", it means the user's coupon issuance failed, and the process ends.

[0162] Node 9 calls an external SMS platform to send coupon SMS messages to users, informing them of the coupons they have received and urging them to try them out, thus activating future user conversions. The external system is the external SMS platform, and the SLEF Server corresponding to Node 9 interacts with the external SMS platform. Assume the SLEF Server's address is "http: / / ip:port / slef / server / message / send", and the request method is POST.

[0163] The configuration information for the client corresponding to this node is as follows:

[0164] {

[0165] "url":"http: / / ip:port / slef / server / message / send",

[0166] "requestMethod":"POST",

[0167] "requestParams":{

[0168] "uid":"${SLEFContext.uid}",

[0169] "message": "You have received a coupon for ${SLEFContext.couponName}. Come and experience it now for great deals!"

[0170] }

[0171] }

[0172] When node 9 is executed, it retrieves the corresponding parameters based on the requestParams configuration in the client's configuration information and populates them. Previous nodes have already set the values ​​of uid and couponName in the SLEFContext; that is, uid is taken from the uid value in the SLEFContext, which is "uid1"; couponName is taken from the couponName value in the SLEFContext, which is either "50 yuan coupon" or "30 yuan coupon". Then, based on the URL configuration, the corresponding SLEF Server is called. The SLEF Server encapsulates the ability to call an external SMS platform to send SMS messages to the user, forwarding the request parameters to the external SMS platform. Since the external SMS platform processes the user's SMS sending task asynchronously and does not return the SMS sending result to the user in real time, the SLEF Server does not need to wait for the external SMS platform to return the final sending result, but directly returns the default result to the client, and then the process ends.

[0173] In a second aspect, this application provides a control device for process execution, such as Figure 4 As shown, the control device for process execution includes: an acquisition module 41, a sending module 42, a calling module 43, and a processing module 44, wherein:

[0174] The acquisition module 41 is used to acquire the configuration information of the client that has been pre-configured for the nodes in the process;

[0175] The sending module 42 is used to generate a data operation request based on the client's configuration information and send the data operation request to the client;

[0176] Module 43 is invoked to call service modules pre-configured for nodes via the client.

[0177] Processing module 44 is used to call the corresponding external system through the service module, so that the external system can perform the corresponding operation according to the data operation request.

[0178] In some embodiments, the client's configuration information includes the address information of the service module, request parameters, and request method. The processing module 44 determines the corresponding service module according to the purpose of the node, and obtains the address information, request parameters, and request method corresponding to the service module. Based on the address information, request parameters, and request method of the service module, the processing module 44 determines the client's configuration information and configures the node based on the configuration information of the service module and the client.

[0179] In a third aspect, this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the process execution control method provided in any embodiment of the first aspect of this application.

[0180] In one embodiment, the computer device may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a control method for process execution.

[0181] In a fourth aspect, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the process execution control method provided in any embodiment of the first aspect of this application.

[0182] The computer-readable storage medium may be Figure 5 The computer-readable storage medium in the computer device shown.

[0183] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0184] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0185] The above embodiments merely illustrate several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A control system for process execution, characterized in that, The system includes a main process module, which includes at least one node. The system also includes a client and service module pre-configured for the node. The main process module is used to obtain the corresponding request parameters from the pre-set context according to the client's configuration information, and generate a data operation request according to the request parameters; The client is used to send the data operation request to the service module according to the address information of the service module in the configuration information; The service module is used to call a pre-configured external system, execute the corresponding operation according to the data operation request through the external system, and receive the result returned by the external system; The client is also used to receive the results returned by the service module, extract the newly added fields from the results, and store the newly added fields into the context; Specifically, when the current node needs to query the user's first login time, the current node sends a request to the service module corresponding to the current node through the corresponding client. The service module corresponding to the current node calls the corresponding external system to obtain the user's first login time. After obtaining the returned user's first login time, the client sets the user's first login time into the context for the next node to call.

2. The system according to claim 1, characterized in that, When multiple clients on different nodes initiate data operation requests that involve the same object, the service modules corresponding to each node are used to sequentially call the corresponding external systems based on the distributed locks pre-set for the service modules.

3. The system according to claim 1, characterized in that, The client's configuration information is pre-stored in the Redis cache and in the memory of the server where the main process module is deployed; The main process module is also used to obtain the client's configuration information from the memory, and when the client's configuration information is not present in the memory, to obtain the client's configuration information from the Redis cache.

4. A method for controlling process execution, characterized in that, The method is applied to the main process module, which includes at least one node, and the method includes: Retrieve the client configuration information that has been pre-configured for the nodes in the process; The client obtains the corresponding request parameters from the pre-set context based on the client's configuration information, generates a data operation request based on the request parameters, and sends the data operation request to the client. The client invokes the service module pre-configured for the node. The service module calls the corresponding external system to perform the corresponding operation according to the data operation request, and receives the result returned by the external system. The client receives the result returned by the service module, extracts the newly added fields from the result, and stores the newly added fields into the context. Specifically, when the current node needs to query the user's first login time, the client corresponding to the current node sends a request to the service module corresponding to the current node to query the user's first login time. This allows the service module corresponding to the current node to call the corresponding external system to obtain the user's first login time. After obtaining the returned user's first login time, the client corresponding to the current node sets the user's first login time into the context for the next node to call.

5. The method according to claim 4, characterized in that, The client's configuration information includes the service module's address information, request parameters, and request method. The method further includes: The corresponding service module is determined based on the purpose of the node, and the address information, request parameters and request method of the service module are obtained. The client's configuration information is determined based on the address information, request parameters, and request method of the service module; Configure the node according to the configuration information of the service module and the client.

6. A control device for process execution, characterized in that, The device includes: The acquisition module is used to obtain the configuration information of the client that has been pre-configured for the nodes in the process; The sending module is used to obtain the corresponding request parameters from the pre-set context according to the client's configuration information, generate a data operation request according to the request parameters, and send the data operation request to the client; The calling module is used to call the service module pre-configured for the node through the client; The processing module is used to call the corresponding external system through the service module, so that the external system can perform the corresponding operation according to the data operation request, and receive the result returned by the external system. The client receives the result returned by the service module, extracts the newly added fields in the result, and stores the newly added fields in the context. When the operation objects in the data operation requests initiated by the clients of multiple nodes are the same, the service module calls the corresponding external system in sequence according to the distributed lock set in advance for the service module. Specifically, when the current node needs to query the user's first login time, the client corresponding to the current node sends a request to query the user's first login time to the service module corresponding to the current node, so that the service module corresponding to the current node calls the corresponding external system to obtain the user's first login time. After obtaining the returned user's first login time, the client corresponding to the current node sets the user's first login time in the context for the next node to call.

7. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 4 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 4 to 5.

Images