Gray scale publishing method, device, and storage medium

Abstract

This application discloses a canary release method, device, and storage medium, relating to the field of computer software technology. The method includes: upon receiving a process initiation request, extracting business data from the process initiation request; performing canary release determination on the process initiation request based on a multi-dimensional canary release strategy and business data to obtain the corresponding canary release determination result; if the canary release determination result is a successful match, creating a canary process instance corresponding to the process initiation request based on the canary version flowchart, and adding a canary release marker to the canary process instance; during the operation of the canary process instance, when detecting a call to an external system's interface by the process release system, sending the canary release marker in the request header of the call request to the external system. This solves the technical problem of existing technologies being unable to flexibly support canary release in multiple scenarios due to a single canary release determination dimension, adapting to complex initiation scenarios, improving the flexibility and accuracy of canary release, and achieving end-to-end full-link canary release.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a grayscale release method, device, and storage medium. Background Technology

[0002] In heavily regulated industries such as banking and finance, operational approval workflow systems serve as core infrastructure for business process operation, making changes to their workflows extremely risky. In these systems, flowchart releases typically employ a canary release strategy to mitigate the risks of launching new versions. However, existing canary release solutions only support canary release determination based on the initiating organization; that is, a canary version flowchart instance is only created when the initiating organization of the workflow request belongs to a pre-defined canary organization. But in real-world business scenarios, many workflows are initiated directly online by users. These requests often lack explicit organization identifiers or have overly broad organization dimensions, making canary release determination strategies based on organization ineffective for such scenarios. Therefore, the current coarse-grained canary release solution struggles to effectively implement canary releases, preventing new flowchart versions from being validated on a small scale and with low risk in a real production environment, limiting release flexibility, and making release risks uncontrollable.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a gray-scale release method, device, and storage medium, which aims to solve the technical problem that existing process release systems cannot flexibly support gray-scale release in multiple scenarios due to the single dimension of gray-scale judgment.

[0005] To achieve the above objectives, this application proposes a canary release method for use in a workflow release system, the canary release method comprising: When receiving a process initiation request, extract the business data from the process initiation request. The business data includes the process type, request header parameters, initiating Internet Protocol address, and initiating organization number. Based on the pre-configured multi-dimensional grayscale strategy and the business data, the process initiation request is grayscale determined to obtain the corresponding grayscale determination result. If the grayscale determination result is a successful match, a grayscale process instance corresponding to the process initiation request is created according to the grayscale version flowchart, and a grayscale marker is added to the grayscale process instance; During the execution of the grayscale process instance, when the process publishing system is detected calling the interface of an external system, the grayscale marker is carried in the request header of the call request and sent to the external system.

[0006] In one embodiment, the step of performing grayscale determination on the process initiation request based on a pre-configured multi-dimensional grayscale strategy and the business data to obtain the corresponding grayscale determination result includes: Match the business data with the multi-dimensional grayscale strategy; If at least one grayscale rule in the multi-dimensional grayscale strategy is matched, the successful match is taken as the grayscale determination result; If no grayscale rule in the multi-dimensional grayscale strategy is matched, the matching failure will be taken as the grayscale determination result.

[0007] In one embodiment, the multi-dimensional grayscale strategy includes request header grayscale rules and organization grayscale rules. The request header grayscale rules include preset request header field values, and the organization grayscale rules include a list of grayscale organizations. The step of matching the business data with the multi-dimensional grayscale strategy includes: When the process type is an online process, the request header parameters are matched with the preset request header field values; If the request header parameters contain the preset request header field value, then it is determined that the request header grayscale rule is matched; Match the initiating organization number with the grayscale organization list; If the initiating organization number exists in the grayscale organization list, then it is determined that the organization grayscale rule is matched.

[0008] In one embodiment, the multi-dimensional grayscale strategy includes Internet Protocol address grayscale rules, wherein the Internet Protocol address grayscale rules contain a pre-stored list of grayscale Internet Protocol addresses, and the step of matching the business data with the multi-dimensional grayscale strategy includes: When the process type is offline, the initiating Internet Protocol address is matched with the gray-scale network interconnection protocol address list; If the initiating Internet Protocol address exists in the grayscale network interconnection protocol address list, then it is determined that the Internet Protocol address grayscale rule is matched.

[0009] In one embodiment, the multi-dimensional grayscale strategy includes traffic grayscale rules, which contain pre-stored traffic percentage parameters. Before the step of creating a grayscale process instance corresponding to the process initiation request based on the grayscale version flowchart, the strategy further includes: When the process type is an online process, a first random number is generated based on the probability corresponding to the traffic percentage parameter; Calculate the ratio between the first random number and the preset baseline value. If the ratio is less than or equal to the traffic percentage parameter, determine that the process initiation request matches the traffic grayscale rule, and take the successful match as the grayscale determination result.

[0010] In one embodiment, the business data further includes a business category identifier, and the step of creating a grayscale process instance corresponding to the process initiation request based on the grayscale version flowchart includes: In response to the grayscale determination result being a successful match, the grayscale process definition identifier of the grayscale version flowchart that matches the business category identifier and the process type is retrieved and obtained; Based on the grayscale process definition identifier, load the grayscale process definition template corresponding to the grayscale version flowchart from the process definition repository. The grayscale process definition template contains the starting node and subsequent node flow logic of the grayscale version flowchart. Based on the grayscale process definition template and the business data, a grayscale process instance corresponding to the process initiation request is created, and a global instance identifier for the grayscale process instance is generated.

[0011] In one embodiment, the step of sending the grayscale marker, the initiating organization number, and the business category to the external system in the request header of the call request when the process publishing system calls the interface of an external system includes: When it is detected that the currently running grayscale process instance has flowed to the first node that needs to call an external system, a corresponding first call event is generated, and the first call event carries the system identifier of the external system; In response to the first invocation event, the grayscale marker is read from the grayscale process instance; Based on the system identifier, obtain the target request header template corresponding to the system identifier from the pre-configured request header template library; The grayscale marker is filled into the request header template to generate the call request; Send the call request to the external system.

[0012] In one embodiment, the grayscale release method further includes: When it is detected that the currently running grayscale process instance has flowed to the second node that needs to call the microservice, a corresponding second call event is generated, and the second call event carries the target call protocol supported by the microservice; In response to the second invocation event, the initiating organization number and business category identifier are read from the grayscale process instance; According to the target invocation protocol, the initiating organization number and the business category identifier are encapsulated into the request header of the second invocation request corresponding to the microservice; The second call request is sent to the microservice, which includes a process component, a scheduling service, a process service, a subscription service, a process engine, a rule engine, or a task interface.

[0013] In one embodiment, after the step of performing grayscale determination on the process initiation request based on the pre-configured multi-dimensional grayscale strategy and the business data to obtain the corresponding grayscale determination result, the method further includes: If the grayscale determination result is a match failure, create a formal process instance corresponding to the process initiation request based on the formal version flowchart.

[0014] Furthermore, to achieve the above objectives, this application also proposes a grayscale publishing device, the grayscale publishing device comprising: The request receiving module is used to extract business data from the process initiation request when receiving the process initiation request. The business data includes process type, request header parameters, initiating Internet Protocol address, and initiating organization number. The routing decision module is used to perform grayscale determination on the process initiation request based on the pre-configured multi-dimensional grayscale strategy and the business data, and obtain the corresponding grayscale determination result. The instance creation module is used to create a grayscale process instance corresponding to the process initiation request based on the grayscale version flowchart if the grayscale determination result is a successful match, and to add a grayscale marker to the grayscale process instance. The tag delivery module is used to send the grayscale tag in the request header of the call request to the external system when the process publishing system calls the interface of the external system during the operation of the grayscale process instance.

[0015] In addition, to achieve the above objectives, this application also proposes a grayscale release device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the grayscale release method as described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the grayscale release method described above.

[0017] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the grayscale release method described above.

[0018] The one or more technical solutions proposed in this application have at least the following technical effects: When the process release system receives a process initiation request, it extracts business data from the request, including process type, request header parameters, initiating Internet Protocol address, and initiating organization number, providing input for multi-condition grayscale rule matching. Based on the pre-configured multi-dimensional grayscale strategy and business data, the system performs grayscale determination on the process initiation request, enabling the grayscale strategy to adapt to various business scenarios and obtain corresponding grayscale determination results. If the grayscale determination result is a successful match, a grayscale process instance corresponding to the process initiation request is created based on the grayscale version flowchart, and a grayscale marker is added to the grayscale process instance, providing a unified credential for subsequent end-to-end identification of grayscale traffic. During the execution of the canary process instance, when the process release system detects a call to an external system's interface, a canary tag is carried in the request header of the call request and sent to the external system. This enables the external system to collaboratively complete canary verification, avoiding verification failure or data pollution due to the external system's inability to recognize canary traffic. This achieves canary business isolation, thereby solving the technical problem in existing process release systems that cannot flexibly support canary releases in multiple scenarios due to a single canary judgment dimension. It adapts to complex initiation scenarios, improves the flexibility and accuracy of canary releases, and realizes end-to-end full-link canary releases. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating an embodiment of the grayscale release method of this application. Figure 2 A flowchart illustrating another grayscale release method provided in this application; Figure 3 This is a schematic diagram of the module structure of the grayscale publishing device according to an embodiment of this application; Figure 4 This is a schematic diagram of the device structure of the hardware operating environment involved in the grayscale release method in this application embodiment. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] The main solution of this application embodiment is as follows: When receiving a process initiation request, extract the business data from the process initiation request. The business data includes the process type, request header parameters, initiating Internet Protocol address, and initiating organization number. Perform grayscale determination on the process initiation request according to the pre-configured multi-dimensional grayscale strategy and business data to obtain the corresponding grayscale determination result. If the grayscale determination result is a successful match, create a grayscale process instance corresponding to the process initiation request based on the grayscale version flowchart, and add a grayscale marker to the grayscale process instance. During the operation of the grayscale process instance, when it is detected that the process publishing system calls the interface of an external system, send the grayscale marker in the request header of the call request to the external system.

[0025] In this embodiment, for ease of description, the process publishing system will be used as the execution subject in the following description.

[0026] In heavily regulated industries such as banking and finance, operational approval workflow systems serve as core infrastructure for business process operation, making changes to their workflows extremely risky. In these systems, flowchart releases typically employ a canary release strategy to mitigate the risks of launching new versions. However, existing canary release solutions only support canary release determination based on the initiating organization; that is, a canary version flowchart instance is only created when the initiating organization of the workflow request belongs to a pre-defined canary organization. But in real-world business scenarios, many workflows are initiated directly online by users. These requests often lack explicit organization identifiers or have overly broad organization dimensions, making canary release determination strategies based on organization ineffective for such scenarios. Therefore, the current coarse-grained canary release solution struggles to effectively implement canary releases, preventing new flowchart versions from being validated on a small scale and with low risk in a real production environment, limiting release flexibility, and making release risks uncontrollable.

[0027] This application provides a solution in which the process publishing system receives a process initiation request and extracts multi-dimensional business data from the request, including process type, request header parameters, initiating Internet Protocol address, and initiating organization number. This breaks the limitation of only collecting organization information and provides sufficient basis for judgment for refined traffic filtering. Then, the system compares the multi-type business data with the preset multi-dimensional grayscale strategy to complete the grayscale judgment, supporting multi-condition combination filtering of traffic and solving the problem of insufficient coverage of single-dimensional strategies. If the grayscale rules in the multi-dimensional grayscale strategy are matched, the grayscale version flowchart is loaded to generate an independent grayscale process instance and a unique grayscale tag is bound to it. This ensures that the grayscale identity persists throughout the entire lifecycle of the process instance, preventing loss after entry point determination and covering the entire process of process initiation, flow, and task processing. When calling external system interfaces during the operation of the grayscale process instance, the grayscale tag is automatically written into the request header of the call request and passed to the downstream. The external system can accurately identify the grayscale traffic filtered through multiple dimensions and independently execute the new isolated business logic, avoiding interference from grayscale test data with formal business. This application forms a closed loop from data collection, multi-dimensional determination, instance tagging to cross-system identifier transmission, solving the technical defects of single grayscale determination dimensions and inflexibility in adapting to multiple scenarios of grayscale release. It improves the applicability and flexibility of grayscale release and effectively reduces release risks.

[0028] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a canary release device capable of performing the above functions. The following description uses a process release system as an example to illustrate this embodiment and the subsequent embodiments.

[0029] Based on this, the embodiments of this application provide a grayscale release method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the grayscale release method of this application.

[0030] In this embodiment, the grayscale release method includes steps 101-104: Step 101: When receiving a process initiation request, extract the business data from the process initiation request. The business data includes the process type, request header parameters, initiating Internet Protocol address, and initiating organization number.

[0031] Specifically, the process initiation request is a complete request message submitted by the user through the front-end page, online channels, or counter terminal for approval business. It includes all interactive data such as business forms, channel information, device information, and request headers, serving as the source carrier for all business data. Business data consists of feature fields used to distinguish traffic characteristics and support gray-scale rule matching. It does not include transaction content within the business form and is only used for traffic diversion identification. Process type distinguishes the business initiation channel, divided into online processes, offline processes, and hybrid online-offline processes. Different types of processes open different gray-scale rules in multi-dimensional gray-scale strategies to limit the effective scenarios of gray-scale strategies. Request header parameters are custom key-value information attached to the process initiation request header when the client initiates the process initiation request, such as business-custom fields like A=1 and B=2. Custom matching conditions can be configured to achieve refined gray-scale filtering based on user identity, business channel, etc. The initiating Internet Protocol address is the network interconnection protocol address of the source end of the process initiation request. It can represent the physical network location of the initiator, and can be the client IP or the source IP after being forwarded through a gateway. The initiating organization number is the business organization code to which the process initiation request belongs. It can indicate the business organization to which the initiator belongs, and can come from the organization number of the logging teller or the applying organization on the business application form.

[0032] In some embodiments, the process publishing system first receives a process initiation request sent by a client. This request includes a business payload and metadata. The system performs protocol parsing on the process initiation request, extracting the caller's preset key-value pairs from the request header to form request header parameters. It obtains the initiator's Internet Protocol address from the network layer connection information. When the system is deployed in a gateway proxy environment, it parses the actual client's Internet Protocol address from the standard extended fields according to the agreed forwarding protocol. Simultaneously, the system extracts the process type identifier and initiating organization number from the request header or business payload according to a predetermined field mapping relationship. The initiating organization number represents the business organization to which the business belongs. Finally, the system assembles the extracted process type, request header parameter set, initiating Internet Protocol address, and initiating organization number into a structured grayscale decision context, temporarily storing it as a set of key-value pairs in the thread-local variable of the current request for subsequent grayscale routing decision steps. After receiving a user's process initiation request, the process release system parses the request and extracts traffic characteristic data such as process type, request header parameters, initiating Internet Protocol address, and initiating organization number. This provides input for subsequent multi-dimensional gray-scale strategy matching, enabling the system to configure differentiated gray-scale release rules for different channels, devices, and users. This solves the problem that a single judgment dimension cannot adapt to gray-scale releases in multiple business scenarios from the data collection level.

[0033] Step 102: Perform grayscale determination on the process initiation request based on the pre-configured multi-dimensional grayscale strategy and business data to obtain the corresponding grayscale determination result.

[0034] Specifically, the multi-dimensional grayscale strategy is a set of grayscale rules encompassing multiple judgment dimensions, including request header grayscale rules, organization grayscale rules, Internet Protocol address grayscale rules, and traffic grayscale rules. Different grayscale rules correspond to different judgment factors (request header parameters, initiating Internet Protocol address, initiating organization ID, and random probability), and different process types utilize different combinations of grayscale rules. Grayscale judgment is the process of matching business data item by item against the grayscale conditions in the multi-dimensional grayscale strategy. The grayscale judgment result can be a Boolean matching conclusion, with values ​​of successful or unsuccessful matching. If the match is successful, a grayscale process instance will be created based on the grayscale version flowchart; if the match fails, a formal version process instance will be created based on the formal version flowchart.

[0035] In some embodiments, the system reads structured business data and loads all pre-stored multi-dimensional grayscale strategies in the database; it iterates through each grayscale rule in the multi-dimensional grayscale strategy, comparing the constraints within the grayscale rule with the business data one by one: verifying whether the process type conforms to the rule-defined channel, whether the request header parameters match the preset key value, whether the initiating Internet Protocol address is within the preset network interconnection protocol address range, and whether the initiating organization number is a preset organization; if all constraints of a grayscale rule are met, it is determined to be a successful match; if none of the grayscale rules are met, it is determined to be a failed match; the final matching conclusion is encapsulated as a grayscale judgment result and passed to the subsequent process instance creation step. Through multi-dimensional feature joint verification, it overcomes the limitations of traditional judgment based solely on organization number, and can flexibly adapt to various grayscale scenarios such as online business, single-organization exclusive business, and pilot projects on designated devices, accurately dividing grayscale traffic and formal traffic, providing a judgment basis for subsequent creation of grayscale process instances and grayscale labeling, and solving the technical problem of poor adaptability of grayscale release scenarios from the traffic filtering stage.

[0036] Step 103: If the grayscale determination result is a successful match, create a grayscale process instance corresponding to the process initiation request based on the grayscale version flowchart, and add a grayscale marker to the grayscale process instance.

[0037] Specifically, the grayscale version flowchart is a process template independent of the official version flowchart, configured with new nodes and business logic, and is dedicated to grayscale traffic. A grayscale process instance is a single business process document generated based on the grayscale version flowchart and populated with the current business form data, distinct from the official process instance. A grayscale marker is a unique identifier attached to the grayscale process instance's metadata, permanently bound to the grayscale process instance, and used by upstream and downstream systems to identify grayscale traffic.

[0038] In some embodiments, when the system recognizes that the grayscale determination result is a successful match, it no longer retrieves the official version flowchart, but instead retrieves the process definition repository based on the current business data to obtain the matching grayscale version flowchart; reads the business nodes, node call links and interface configuration information built into the grayscale version flowchart, fills in the form business data carried by the process initiation request, completes the initialization process, generates a grayscale process instance exclusive to the request and assigns a global instance identifier. The system synchronously writes a unique grayscale tag into the metadata field of the grayscale process instance, binds the grayscale tag to the instance, and persists it together. This grayscale tag remains unchanged throughout the entire lifecycle of the process instance. After the grayscale determination of the process initiation request passes, instead of using the official version flowchart, the grayscale-specific flowchart (i.e., the grayscale version flowchart) is retrieved to generate an independent process instance, and a unique grayscale tag is bound to it. On the one hand, this allows the grayscale traffic to run the new version of the process logic independently, achieving isolation from the official process logic; on the other hand, the grayscale tag solidifies the traffic attributes, providing a unified judgment basis for subsequent full-link interface calls to identify grayscale documents. This solves the problems of existing technologies lacking grayscale differentiation identifiers and grayscale data being mixed with official data and unable to be differentiated, ensuring that the process in the grayscale environment is isolated from the official environment.

[0039] Furthermore, during the canary release of flowcharts, the process release system supports real-time modification of the already effective canary release strategy. This means that after operations personnel adjust configuration items such as request header matching conditions (i.e., preset request header field values), add or delete canary organization lists, and modify traffic percentage parameters through the strategy management terminal, the system immediately pushes the updated canary release strategy to the configuration center. When the next process initiation request arrives, the process release system loads the latest canary release strategy to perform canary release determination, achieving real-time changes to the canary environment. For canary process instances that were created and are currently running before the canary release strategy update, their process definition identifier has already been written into the process definition identifier field of the process instance table when the instance is created. This field remains unchanged after being written when the instance is created. Each time the process engine drives the execution node transition of this canary process instance, it reads the bound process definition identifier from this field and loads the corresponding canary version flowchart driver, without re-executing the canary routing decision steps. This mechanism ensures that running canary instances are unaffected by policy changes, preventing execution exceptions due to node mismatches caused by version switching caused by differences in node definitions between the canary and official version flowcharts. Modifications to the canary release policy only apply to newly initiated process requests, ensuring that policy adjustments during the canary release process do not interrupt or interfere with the normal operation of processes already in progress. This guarantees the continuity of canary verification, balancing flexible iteration of the canary policy with the reliability of existing business operations.

[0040] Step 104: During the execution of the grayscale process instance, when the process publishing system is detected calling the interface of an external system, the grayscale marker is carried in the request header of the call request and sent to the external system.

[0041] Specifically, the operation of a canary process instance encompasses its entire lifecycle from creation to termination, including node transitions, task processing, and service calls. During execution, the canary process instance goes through multiple nodes, such as the start node, manual approval node, automatic task node, gateway branch, and end node. Automatic and service task nodes require calls to external system interfaces to complete business processing. The process publishing system is the complete system entity of the process engine platform, containing all functional modules such as the process engine, task management, and service calls. During the operation of the canary process instance, the process publishing system acts as the caller, initiating interface call requests to external systems and setting the canary flag in the call request. External systems refer to other microservices or third-party systems (such as risk control, payment, and notification systems) that need to be called during the current process execution, independent of the process publishing system. These external systems are the target of canary flag transmission, enabling the identification and differentiated processing of canary traffic by receiving the canary flags. The grayscale marker is an identifier field recorded in the grayscale process instance data. Its value indicates whether it's a grayscale process or a non-grayscale process. The grayscale marker conveys the grayscale identity of the grayscale process instance, allowing external systems to identify the grayscale attribute to which the current call request belongs. The request header is the metadata field area in the call request, independent of the business payload. It is used to convey call control information and context attributes. The request header parameters for the call request can be shown in the table below: Request header parameters of the call request

[0042] In some embodiments, when the process publishing system drives the flow of a grayscale process instance, it executes the defined logic of the current node sequentially. When it reaches a service task node or a manual task node, it reads the call information in the node configuration to determine that the current node needs to call an external system interface, triggering the grayscale tag transmission process. The system can query the instance table based on the global instance identifier of the current grayscale process instance and read the value of the grayscale tag field from the instance data. The system constructs an external call request based on the external system interface information configured for the current node, encapsulates the necessary business parameters into a request body, and sets the name of the grayscale tag and its corresponding value as a key-value pair in the request header field of the call request according to the interface call transmission protocol specification. The call request carrying the grayscale tag is then sent to the interface address of the external system through a preset protocol. After receiving the call request, the external system parses the value of the grayscale tag from the request header, identifies whether the current call request belongs to grayscale traffic, processes it according to the corresponding version logic, returns the result to the process publishing system after processing, and continues to drive the process flow after receiving the response. The grayscale markers do not change due to the success or failure of external system calls. They are always passed along with every cross-system call of the process instance, realizing the full-link transmission of grayscale markers across systems. This allows downstream external systems to distinguish between grayscale business and formal business, enabling them to selectively enable new processing logic, isolate and store grayscale test data, and avoid grayscale data from polluting the formal business ledger, thus forming a complete closed loop for grayscale traffic identification and isolation.

[0043] Based on the canary release method provided in this application, when the process release system receives a process initiation request, it extracts business data from the request. This business data includes the process type, request header parameters, initiating internet protocol address, and initiating organization number, providing input for multi-condition canary release rule matching. The system then performs a canary release determination on the process initiation request based on a pre-configured multi-dimensional canary release strategy and business data, enabling the canary release strategy to adapt to various business scenarios and obtain corresponding canary release determination results. If the canary release determination result is a successful match, a canary process instance corresponding to the process initiation request is created based on the canary version flowchart, and a canary release marker is added to the canary process instance, providing a unified credential for subsequent end-to-end identification of canary traffic. During the operation of the canary process instance, when the process release system calls the interface of an external system, the canary tag is carried in the request header of the call request and sent to the external system so that the external system can cooperate to complete the canary verification. This avoids verification failure or data pollution due to the external system's inability to recognize canary traffic, and realizes canary business isolation. This solves the technical problem that the existing process release system cannot flexibly support canary release in multiple scenarios due to the single dimension of canary judgment. It adapts to complex initiation scenarios and realizes end-to-end full-link canary release.

[0044] In some embodiments, the step of performing grayscale determination on process initiation requests based on pre-configured multi-dimensional grayscale strategies and business data to obtain the corresponding grayscale determination results includes: Match business data with multi-dimensional grayscale strategies; If at least one grayscale rule in the multi-dimensional grayscale strategy is matched, the successful match will be taken as the grayscale determination result. If no grayscale rule in the multi-dimensional grayscale strategy is matched, the matching failure will be taken as the grayscale determination result.

[0045] Specifically, a grayscale rule is a single allowance standard within a multi-dimensional grayscale strategy, containing one or more traffic characteristic constraints. In this application, the multi-dimensional grayscale strategy includes request header grayscale rules, organization grayscale rules, Internet Protocol address grayscale rules, and traffic grayscale rules.

[0046] As an example, the process deployment system first loads a pre-configured multi-dimensional grayscale strategy from the configuration center. This strategy includes grayscale rules for request headers, organizations, internet protocol addresses, and traffic, among others. Simultaneously, the system loads business data, which may include process type, request header parameters, initiating internet protocol address, and initiating organization number. The system determines the subset of grayscale rules to be used for this decision based on the process type—online processes only use request headers, organizations, and traffic grayscale rules; offline processes only use internet protocol address and organization grayscale rules; and mixed processes can dynamically determine the subset of rules to use based on the actual entry point. The process deployment system compares the corresponding decision factors in the business data with the constraints of the current grayscale rules one by one according to a preset priority order (e.g., request header matching has the highest priority, followed by organization matching, internet protocol address matching, and traffic percentage matching). For request headers and organizations, exact comparison or list inclusion comparison can be used; for traffic grayscale rules, a random number is generated and compared with a preset traffic percentage threshold. When a matching rule in any dimension is matched, the system terminates subsequent matching and outputs the result as a successful match conclusion. If none of the enabled grayscale rules are matched, the system outputs a matching failure as the grayscale determination result. This binary grayscale determination result can serve as the sole basis for selecting the grayscale version or the official version when creating subsequent process instances. Through parallel verification of multiple independent grayscale rules, it supports configuring multiple sets of differentiated traffic release standards, which can simultaneously cover various grayscale scenarios such as pilot institutions, online channels, designated devices, and custom request identifiers. As long as the business data matches any grayscale rule, it can enter the grayscale process, flexibly adapting to various business grayscale iteration needs, realizing refined grayscale traffic screening in multiple scenarios, and breaking through the limitations of traditional single-institution dimension judgment.

[0047] In some embodiments, the multi-dimensional grayscale strategy includes request header grayscale rules and organization grayscale rules. The request header grayscale rules include preset request header field values, and the organization grayscale rules include a list of grayscale organizations. The step of matching business data with the multi-dimensional grayscale strategy includes: When the process type is online process, the request header parameters will be matched with the preset request header field values; If the request header parameters contain preset request header field values, then it is determined that the request header grayscale rule is matched; Match the initiating organization number with the grayscale organization list; If the initiating organization number exists in the list of grayscale organizations, then the grayscale organization rule is determined to be matched.

[0048] Specifically, the request header grayscale rules are rule entries based on custom fields carried in the request header of the process initiation request for grayscale determination, including preset request header field values ​​as matching conditions. The organization grayscale rules are rule entries based on the business initiation organization number for grayscale determination, including a grayscale organization list as matching conditions. The grayscale organization list is a pre-stored set of all initiation organization numbers allowed to release grayscale versions. For process types of online processes (referring to business processes initiated by online channels or user self-service channels), a separate request header matching logic is enabled.

[0049] As an example, the process deployment system reads the value of the process type field from the business data. When the process type is an online process, the system determines that request header grayscale rules and organization grayscale rules are enabled for this judgment, and performs matching sequentially according to preset priority. The system searches the request header parameters of the business data using the preset request header field name configured in the request header grayscale rule as the key. If the field name exists in the request header parameters, the system further obtains the actual value of the field name and compares it precisely with the preset request header field value. When the actual value is exactly the same as the preset value, it is determined that the request header parameters contain the preset request header field value, that is, a request header grayscale rule is matched, and the hit of the request header grayscale rule is used as the basis for a successful match. If the field name does not exist in the request header parameters or the actual value is inconsistent with the preset value, the system determines that no request header grayscale rule is matched. When the process type is online or offline, for the organization grayscale rule, the system reads the initiating organization number from the business data and compares it one by one with the grayscale organization list in the organization grayscale rule. The grayscale organization list uses a list data structure to store a pre-configured set of organization numbers allowed to enter the grayscale environment. During matching, an exact value comparison is used. If there is an organization number in the grayscale organization list that is exactly the same as the initiating organization number, the system determines that the organization grayscale rule has been matched; otherwise, it is determined that no organization grayscale rule has been matched. The inclusion matching of the request header grayscale rule and the existence matching of the organization grayscale rule list are combined using OR logic. The verification of the request header grayscale rule and the organization grayscale rule are independent of each other and do not need to be satisfied simultaneously. If any rule is matched, the overall match is considered successful, that is, the overall grayscale determination result is a successful match.

[0050] In some embodiments, the multi-dimensional grayscale strategy includes Internet Protocol address grayscale rules, which contain a pre-stored list of grayscale Internet Protocol addresses. The step of matching business data with the multi-dimensional grayscale strategy includes: When the process type is offline, the initiating Internet Protocol address will be matched with the gray network interconnection protocol address list; If the initiating Internet Protocol address exists in the grayscale network Internet Protocol address list, then it is determined that the Internet Protocol address grayscale rule is matched.

[0051] Specifically, the Internet Protocol address grayscale rules are rule entries for grayscale determination based on the Internet Protocol address of the request source in the process. These rules include a pre-stored list of grayscale Internet Protocol addresses as matching conditions. The grayscale Internet Protocol address list is a pre-configured set of Internet Protocol addresses allowed to enter the grayscale environment. It can be stored using a list data structure and supports single Internet Protocol addresses or Internet Protocol address ranges.

[0052] As an example, the system loads a complete multi-dimensional grayscale strategy, reads the process type and initiating Internet Protocol address from the business data, first identifies the process type, and only executes the Internet Protocol address grayscale rule matching if the process type is determined to be an offline process. The system extracts the initiating Internet Protocol address from the business data and loads a pre-configured grayscale network interconnection protocol address list from the configuration center. This grayscale network interconnection protocol address list can be stored using a list data structure, supporting both single Internet Protocol address and Internet Protocol address range formats, and is pre-configured by operations personnel in the process deployment tool. The system performs a matching operation one by one based on each item in the grayscale list. For list items of a single Internet Protocol address type, exact string matching can be used, comparing the four decimal segments of the initiating Internet Protocol address with the four decimal segments of the list item one by one; a successful match is determined when all four segments match. For list items of Internet Protocol address range type, network segment inclusion matching can be used, converting the initiating Internet Protocol address to binary representation and performing a bitwise AND operation with the network prefix of the address range to determine whether it falls within the range of that address range. If the initiating Internet Protocol address matches any item in the grayscale list, the system determines that the Internet Protocol address grayscale rule has been matched. If no match is found after traversing all addresses in the grayscale network Internet Protocol address list, the system determines that the Internet Protocol address grayscale rule has not been matched. This Internet Protocol address grayscale rule is independent of the institution grayscale rule. Offline traffic matching any one rule is sufficient to determine a successful grayscale match; both rules do not need to be met simultaneously. By matching the Internet Protocol address grayscale rule, precise device-level traffic filtering can be achieved for offline counter test terminals. It is not necessary to include the entire branch in the grayscale institution list; only a small number of test device IPs need to be entered to verify the new version on a small scale. This refines the granularity of offline grayscale control, enriches the multi-dimensional grayscale judgment system, and effectively improves the shortcomings of relying solely on institution number grayscale, which results in an excessively large control scope and high pilot costs.

[0053] In some embodiments, the multi-dimensional grayscale strategy includes traffic grayscale rules, which contain pre-stored traffic percentage parameters. Before the step of creating a grayscale process instance corresponding to the process initiation request based on the grayscale version flowchart, the strategy further includes: When the process type is online process, a first random number is generated based on the probability corresponding to the traffic percentage parameter; Calculate the ratio between the first random number and the preset baseline value. If the ratio is less than or equal to the traffic percentage parameter, the process will initiate a request to match the traffic grayscale rule and take the successful match as the grayscale determination result.

[0054] Specifically, the traffic gray-scale rule is a strategy that controls the amount of requests entering the gray-scale version by setting a traffic percentage (e.g., 5%, 10%). It does not rely on any business attributes (it does not distinguish between request headers, organizations, or Internet protocol addresses), and it determines the traffic percentage parameter equally for all process requests based on probability. The percentage parameter is a value preset by the configuration center or operations personnel (e.g., 0.05 represents 5%), representing the expected proportion of requests entering the gray-scale process. The first random number is a uniformly distributed random floating-point number (e.g., 0.3721) within the range [0,1) generated in real time when the process request is processed. The preset baseline value can be 1.0, used to establish a proportional relationship with the random number (i.e., first random number ÷ 1.0 = random number itself), which facilitates direct comparison with the percentage.

[0055] As an example, the system reads the traffic grayscale rules adapted to online services from the multi-dimensional grayscale strategy and extracts the traffic percentage parameter pre-configured and stored by operations and maintenance. This traffic percentage parameter is used to control the proportion of online traffic grayscale release. The system first identifies the process type within the business data. Only when it is determined to be an online process is the system executed for matching this traffic grayscale rule. A random number generation function is called, which can use the nanosecond value of the current system time combined with the session identifier or user identifier of the current request as a random seed to generate a first random number uniformly distributed within the range of 1 to a preset baseline value. This ensures the independence and unpredictability of each judgment and avoids deviations in judgment results caused by multiple requests generating the same random number due to the same seed. The system calculates the ratio between the first random number and the preset baseline value and compares the calculated ratio with the traffic percentage parameter. If the ratio is less than or equal to the traffic percentage parameter, the system determines that the current request matches the traffic grayscale rule and outputs a successfully matched grayscale judgment result; if the ratio is greater than the traffic percentage parameter, the system determines that the current request does not match the traffic grayscale rule. The matching results of traffic grayscale rules are combined with the matching results of request header grayscale rules and organization grayscale rules using an OR logic combination. That is, if any grayscale rule among traffic grayscale rules, request header grayscale rules, and organization grayscale rules is matched, the overall match is considered successful; only if all grayscale rules are not matched is the match considered unsuccessful. This final grayscale determination result is temporarily stored in a thread-local variable, serving as the sole basis for selecting the grayscale version or the official version when creating subsequent process instances. By performing traffic grayscale rule matching when the process type is an online process, it is not necessary to limit specific users, devices, or organizations. Online traffic can be randomly sampled at a set ratio for grayscale verification, supplementing the probability-based traffic distribution mode in addition to targeted matching, improving the multi-dimensional grayscale determination system, and solving the shortcomings of traditional grayscale which only supports fixed-point volume release and cannot conduct small-scale pilot tests on a large number of online businesses.

[0056] refer to Figure 2Upon receiving a process initiation request, the system extracts business data from the request, including the process type, request header parameters, initiating internet protocol address, and initiating organization number. It also retrieves the pre-stored traffic percentage parameter from the traffic grayscale rules. The system then determines whether the process type is online or offline. If the process type is online, the system matches the business data against the request header grayscale rules, organization grayscale rules, and traffic grayscale rules in the multi-dimensional grayscale strategy. Specifically, it matches the request header parameters against preset request header field values; if the request header parameters contain a preset request header field value, a request header grayscale rule is matched. The system also matches the initiating organization number against the grayscale organization list; if the initiating organization number exists in the grayscale organization list, an organization grayscale rule is matched. Based on the probability corresponding to the traffic percentage parameter, a first random number is generated, and the ratio between the first random number and a preset baseline value is calculated. If the ratio is less than or equal to the traffic percentage parameter, the process initiation request is determined to match a traffic grayscale rule. When the process type is offline, the business data is matched against the internet protocol address grayscale rules and organization grayscale rules in the multi-dimensional grayscale strategy. Specifically, the initiating internet protocol address is matched against the grayscale network interconnection protocol address list. If the initiating internet protocol address exists in the grayscale network interconnection protocol address list, it is determined that the internet protocol address grayscale rule has been matched. The initiating organization number is matched against the grayscale organization list. If the initiating organization number exists in the grayscale organization list, it is determined that the organization grayscale rule has been matched. It is then determined whether at least one grayscale rule in the multi-dimensional grayscale strategy has been matched. If so, a successful match is taken as the grayscale determination result. When the grayscale determination result is a successful match, a grayscale process instance corresponding to the process initiation request is created according to the grayscale version flowchart, and a grayscale marker is added to the grayscale process instance. During the operation of the grayscale process instance, when the process release system calls an external system's interface, the grayscale marker is carried in the request header of the call request and sent to the external system. If not, a failed match is taken as the grayscale determination result. If the grayscale determination result is a failed match, a formal process instance corresponding to the process initiation request is created according to the formal version flowchart.

[0057] In some embodiments, the business data also includes a business category identifier. The steps for creating a grayscale process instance corresponding to the process initiation request based on the grayscale version flowchart include: In response to a successful match in the grayscale determination, retrieve and obtain the grayscale process definition identifier of the grayscale version flowchart that matches the business category identifier and process type; Based on the grayscale process definition identifier, load the grayscale process definition template corresponding to the grayscale version flowchart from the process definition repository. The grayscale process definition template contains the starting node and subsequent node flow logic of the grayscale version flowchart. Based on the grayscale process definition template and combined with business data, a grayscale process instance corresponding to the process initiation request is created, and a global instance identifier for the grayscale process instance is generated.

[0058] Specifically, the business category identifier is a unique code distinguishing different business lines, such as expense reimbursement, approval, and account opening, used to differentiate the flowcharts specific to each business. The gray-scale process definition identifier is a unique ID pointing to a specific gray-scale version of the flowchart, determined by both the business category and the process type. The process definition repository is a central configuration library (such as a database or configuration center) storing all formal process definition templates and gray-scale process definition templates. The gray-scale process definition template is a structured definition containing complete execution logic, including start nodes, task nodes, branch conditions, and service calls. The global instance identifier is a globally unique ID, such as a UUID, generated for each process instance, used for tracking, monitoring, and status management.

[0059] As an example, in response to a successful match in the grayscale assessment, the process release system extracts the business category identifier and process type from the business data. The business category identifier identifies the business category to which the process belongs, and the process type identifies the initiation method of the process. The system uses the business category identifier and process type as joint search criteria to initiate a query request to the process definition repository. It retrieves grayscale version flowcharts that match both the business category identifier and process type from the repository and obtains the grayscale process definition identifier for each flowchart. Based on the grayscale process definition identifier, the system initiates a load request to the process definition repository, loading the grayscale process definition template corresponding to the grayscale version flowchart. The grayscale process definition template is stored in structured data format, containing the starting node identifier, starting node type, starting node processing logic, subsequent node list, connection relationships between nodes, gateway conditions, and flow rules of the grayscale version flowchart. The system parses the grayscale process definition template to obtain the starting node definition and subsequent node flow logic. Based on the grayscale process definition template, it creates a process instance object and generates a globally unique global instance identifier for it, used for full lifecycle tracking, status management, and log association. The global instance identifier is bound to the grayscale process definition identifier, and the business category identifier, process type, initiating organization number, other business fields, and business payload from the business data are populated into the process instance object to complete the creation of the grayscale process instance. By using the business category identifier combined with the process type as a dual condition to locate the target grayscale template, it is possible to configure independent grayscale process diagrams for different business lines and different channels, avoiding mutual interference between multiple business grayscale releases; at the same time, relying on the dedicated identifier to isolate grayscale and formal process templates, it ensures that the grayscale version runs the new version of business logic independently; the global instance identifier enables unified traceability of documents across the entire platform, effectively supporting parallel and refined grayscale releases of multiple businesses, and solving the control defects of a single process diagram that cannot distinguish between businesses and channels.

[0060] In some embodiments, when a process publishing system is detected calling an interface of an external system, the step of sending a grayscale marker, the initiating organization number, and the business category to the external system in the request header of the call request includes: When it is detected that the currently running grayscale process instance has flowed to the first node that needs to call the external system, a corresponding first call event is generated. The first call event carries the system identifier of the external system. In response to the first call event, read the grayscale markers from the grayscale process instance; Based on the system identifier, retrieve the target request header template corresponding to the system identifier from the pre-configured request header template library; Fill the request header template with grayscale markers to generate the call request; Send a call request to an external system.

[0061] Specifically, the request header template library is a pre-configured collection of request header format templates organized and managed according to external system identifiers. The target request header template is the corresponding request header template retrieved from the request header template library based on the system identifier of the external system currently being called, providing a blueprint for the request header format of this call and defining the names of the specific fields that need to be transmitted.

[0062] As an example, when the process deployment system drives the flow of a grayscale process instance, upon reaching a service task node configured with external system calls (i.e., the first node), it determines that the current first node needs to call an external system and generates a corresponding first call event. This first call event encapsulates the complete context information of this call, including the system identifier of the external system to be called, the global instance identifier of the grayscale process instance, and the call parameters configured by the node. The first call event is then published to the event bus. After subscribing to this first call event, the process deployment system extracts the process instance identifier from it. Based on this global instance identifier, it queries the instance data of the current grayscale process instance from the process instance table, reads the value of the grayscale marker field, and obtains the initiating organization number and business category identifier from the instance context environment. It extracts the system identifier of the external system to be called from the first call event and uses this system identifier as the index key to initiate a retrieval from the request header template library in the configuration center. The request header template library stores request header templates for each external system according to the system identifier. Each request header template contains the request header field names and their corresponding placeholders required when calling the corresponding external system. When a new external system needs to be integrated, only a template record needs to be added to the template library without modifying the source code. After obtaining the target request header template corresponding to the system identifier to be invoked, each placeholder defined in the target request header template is traversed. If the placeholder corresponds to a grayscale marker, the actual value is read from the instance data and filled in; if it corresponds to the initiating organization number or business category, the actual value is read from the context field and filled in. All placeholders in the target request header template are replaced with actual values ​​to generate a request header containing complete key-value pairs. This header, along with the business parameters in the invocation event, is encapsulated into a complete invocation request and sent to the interface address of the external system via network protocol. The external system parses the grayscale marker and other factors from the request header, processes them according to the corresponding version logic, and returns the result. After receiving the response, the process publishing system continues to drive the process flow. Each cross-system call executes the above process independently, and the grayscale marker is always passed along with the call. Through a pre-configured request header template library, grayscale markers, initiating organization numbers, business categories, and other grayscale coloring factors are filled into the request header format expected by the target external system, realizing the dynamic transmission of grayscale markers with format adaptation between different external systems.

[0063] In some embodiments, when it is detected that the currently running grayscale process instance has flowed to the second node that needs to call the microservice, a corresponding second call event is generated, and the second call event carries the target call protocol supported by the microservice; In response to the second invocation event, read the initiating organization number and business category identifier from the grayscale process instance; According to the target invocation protocol, the initiating organization number and business category identifier are encapsulated into the request header of the second invocation request corresponding to the microservice; The second call request is sent to the microservice, which includes process components, scheduling services, process services, subscription services, process engines, rule engines, or task interfaces.

[0064] Specifically, microservices are independent service units within a process deployment system, broken down according to business capabilities. Each microservice focuses on a specific functional area and can include process components, scheduling services, process services, subscription services, process engines, rule engines, or task interfaces. These microservices collectively constitute the process deployment system and collaborate with each other through interface calls. Specifically, process components are responsible for parsing and version management of process definition templates; scheduling services are responsible for task queue management and execution scheduling; process services are responsible for the lifecycle management of process instances, including creation, suspension, resumption, and termination; subscription services are responsible for subscribing to process events and message distribution; the process engine is responsible for driving the node flow and state transitions of process instances; the rule engine is responsible for executing business rule judgments related to the process (such as evaluating expressions in conditional gateways); and the task interface is responsible for the user interface rendering and interaction of manually approved tasks.

[0065] As an example, when the process engine of the process release system drives the flow of canary process instances, when execution reaches the second node configured with calls to internal microservices of the process release system, the process engine reads the call configuration in the definition of the second node to determine that the current second node needs to call the internal microservices of the process release system. These microservices include process components, scheduling services, process services, subscription services, the process engine, the rule engine, or a task interface. Before the second node executes, the process engine generates a corresponding second call event object. This second call event object encapsulates the complete context information of this call request, including the service name of the microservice to be called and its supported target call protocol type, and publishes this event to the event bus. After the call processor of the process release system subscribes to the second call event, it extracts the global instance identifier of the canary process instance from the second call event. Based on this global instance identifier, it queries the instance data of the current canary process instance from the process instance table, and reads the initiating organization number and business category identifier from the context fields of the instance data. The initiating organization number represents the business organization to which the business belongs, and the business category identifier represents the business domain to which the business belongs. The initiating organization number and business category identifier together constitute the business dimension basis for canary routing. The process deployment system extracts the target call protocol type supported by the microservice to be called from the second call event, and selects the corresponding encapsulation method according to the protocol type: if the target call protocol is a representative state transfer style interface based on Hypertext Transfer Protocol, the name and corresponding value of the initiating organization number and the name and corresponding value of the business category identifier are set as key-value pairs in the Hypertext Transfer Protocol request header field of the second call request; if the target call protocol is a remote service call protocol, the initiating organization number and the business category identifier are set in the protocol additional context field of the remote service call request. After encapsulation, the generated second call request is sent to the interface address of the microservice to be called. The microservice to be called parses the initiating organization number and the business category identifier from the request header or protocol additional context (determined according to the call protocol type), identifies the business dimension and version belonging to the current call based on these two factors, executes the corresponding version logic, and returns the result to the process engine after processing. The process engine receives the response and continues to drive the process flow. Each cross-microservice call executes the above process independently, realizing the step-by-step transmission of grayscale coloring factors throughout the entire platform.

[0066] This application designs an independent identifier pass-through logic for internal microservice calls, adaptively assembling request headers based on communication protocols compatible with various microservices to adapt to the system's multi-protocol microservice architecture; it synchronously transmits organizational and business dimension information throughout the internal chain, enabling core components such as the process engine and rule engine to execute canary logic according to business and organizational differences, isolating different business canary operation environments, improving the internal chain identifier transmission system of the canary process, and ensuring that parallel canary releases of multiple businesses do not interfere with each other.

[0067] Furthermore, the process-driven mechanism of the process release system's process engine mainly includes two scenarios. In these scenarios, interface access between platform services needs to transparently transmit the initiating organization number and business category identifier, enabling platform service function changes to be rolled out gradually according to business type and initiating organization. The first scenario is the process initiation scenario, involving full-link interface calls to process components, scheduling services, process services, subscription services, the process engine, the rule engine, the task scheduling service, and the task service. When a user initiates a process application online, the process component receives the request and sequentially calls the scheduling service for task allocation, the process service to create a process instance, the subscription service to record event logs, and the rule engine to execute initial rule verification. The business type and organization number are transparently transmitted level by level between services through the request headers of the interface calls. The second category is the task submission scenario, involving full-link interface calls across the task interface, process service, node service, process engine, rule engine, subscription service, and task service. When a user clicks "Submit Approval Opinion" on the task interface, the task interface sends a request to the process service. The process service calls the node service to record the current node's processing result. The node service calls the process engine to drive the process flow to the next node. The process engine calls the rule engine to execute node exit condition judgments. Each service also transmits the business type and organization number level by level through request headers. In both scenarios, the initiating organization number and business category identifier transmitted are inherited from the values ​​fixed when the process instance is created, ensuring that the grayscale attributes of the same process instance remain consistent in the initiation and task submission links. When a platform service is released, each service determines whether the current call request matches the grayscale release range of its service based on the initiating organization number and business category identifier carried in the call request. This determines whether to execute the grayscale version logic or the official version logic, enabling precise control of the grayscale range for platform function changes based on business and organization dimensions, avoiding the operational risks associated with full releases.

[0068] In some embodiments, after the step of performing grayscale determination on the process initiation request based on a pre-configured multi-dimensional grayscale strategy and business data to obtain the corresponding grayscale determination result, the method further includes: If the grayscale determination result is a match failure, create a formal process instance corresponding to the process initiation request based on the formal version flowchart.

[0069] Specifically, when the grayscale determination result is a match failure, it means that the current process initiation request did not match any grayscale rule in the multi-dimensional grayscale strategy. The system will no longer retrieve the grayscale version flowchart, but will instead use the business category identifier and process type as search conditions to match the corresponding official version flowchart from the process definition repository; read the node flow logic contained in the official version flowchart, fill in the business data and business payload carried by this process initiation request, initialize and generate an official process instance and assign a global official instance identifier. The instance metadata does not write grayscale tags, and there is no need to pass through grayscale tags when calling internal and external system interfaces in subsequent flows. This realizes a traffic diversion fallback mechanism, and businesses that do not meet the grayscale conditions will uniformly run stable online official processes, ensuring the normal operation of all businesses and avoiding business anomalies caused by non-grayscale traffic loading new unverified process logic.

[0070] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the gray-scale release method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0071] This application also provides a grayscale publishing device; please refer to [reference needed]. Figure 3 The grayscale publishing device includes: The request receiving module 301 is used to extract business data from the process initiation request when receiving the process initiation request. The business data includes process type, request header parameters, initiating Internet Protocol address and initiating organization number. The routing decision module 302 is used to perform grayscale determination on the process initiation request based on the pre-configured multi-dimensional grayscale strategy and business data, and obtain the corresponding grayscale determination result. The instance creation module 303 is used to create a grayscale process instance corresponding to the process initiation request based on the grayscale version flowchart if the grayscale judgment result is a successful match, and to add grayscale markers to the grayscale process instance. The tag delivery module 304 is used to send the grayscale tag in the request header of the call request to the external system when the process publishing system calls the interface of the external system during the operation of the grayscale process instance.

[0072] The grayscale release device provided in this application, employing the grayscale release method in the above embodiments, can solve the technical problem that existing process release systems cannot flexibly support grayscale releases in multiple scenarios due to the single grayscale determination dimension. Compared with the prior art, the beneficial effects of the grayscale release device provided in this application are the same as those of the grayscale release method provided in the above embodiments, and other technical features in the grayscale release device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0073] This application provides a grayscale release device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the grayscale release method in the above embodiment 1.

[0074] The following is for reference. Figure 4 The diagram illustrates a structural schematic suitable for implementing grayscale publishing devices according to embodiments of this application. The grayscale publishing devices in these embodiments may include, but are not limited to, mobile terminals such as laptops, tablets (Portable Application Description, PADs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 4 The grayscale release device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0075] like Figure 4 As shown, the grayscale publishing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the grayscale publishing device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the grayscale distribution device to communicate wirelessly or wiredly with other devices to exchange data. Although grayscale distribution devices with various systems are shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0076] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0077] The grayscale release device provided in this application, employing the grayscale release method in the above embodiments, can solve the technical problem that existing process release systems cannot flexibly support grayscale releases in multiple scenarios due to the single grayscale determination dimension. Compared with the prior art, the beneficial effects of the grayscale release device provided in this application are the same as those of the grayscale release method provided in the above embodiments, and other technical features in this grayscale release device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0078] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0079] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0080] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the grayscale release method in the above embodiments.

[0081] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0082] The aforementioned computer-readable storage medium may be included in the grayscale release device; or it may exist independently and not be assembled into the grayscale release device.

[0083] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the canary release device, the canary release device: upon receiving a process initiation request, extracts business data from the process initiation request, including process type, request header parameters, initiating Internet Protocol address, and initiating organization number; performs canary release determination on the process initiation request based on a pre-configured multi-dimensional canary release strategy and business data, and obtains the corresponding canary release determination result; if the canary release determination result is a successful match, creates a canary process instance corresponding to the process initiation request based on the canary version flowchart, and adds a canary release marker to the canary process instance; during the operation of the canary process instance, when it detects that the process release system is calling an interface of an external system, it sends the canary release marker in the request header of the call request to the external system.

[0084] Computer program products for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0085] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0086] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0087] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described grayscale release method. This solves the technical problem that existing process release systems cannot flexibly support grayscale releases in multiple scenarios due to a single grayscale determination dimension. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the grayscale release method provided in the above embodiments, and will not be elaborated upon here.

[0088] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the grayscale release method described above.

[0089] The computer program product provided in this application can solve the technical problem that existing process release systems cannot flexibly support multi-scenario canary releases due to the single dimension of canary release determination. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the canary release method provided in the above embodiments, and will not be repeated here.

[0090] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A grayscale release method, characterized in that, The canary release method, applied to a process release system, includes: When receiving a process initiation request, extract the business data from the process initiation request. The business data includes the process type, request header parameters, initiating Internet Protocol address, and initiating organization number. Based on the pre-configured multi-dimensional grayscale strategy and the business data, the process initiation request is grayscale determined to obtain the corresponding grayscale determination result. If the grayscale determination result is a successful match, a grayscale process instance corresponding to the process initiation request is created according to the grayscale version flowchart, and a grayscale marker is added to the grayscale process instance; During the execution of the grayscale process instance, when the process publishing system is detected calling the interface of an external system, the grayscale marker is carried in the request header of the call request and sent to the external system.

2. The grayscale publishing method as described in claim 1, characterized in that, The step of performing grayscale determination on the process initiation request based on the pre-configured multi-dimensional grayscale strategy and the business data to obtain the corresponding grayscale determination result includes: Match the business data with the multi-dimensional grayscale strategy; If at least one grayscale rule in the multi-dimensional grayscale strategy is matched, the successful match is taken as the grayscale determination result; If no grayscale rule in the multi-dimensional grayscale strategy is matched, the matching failure will be taken as the grayscale determination result.

3. The grayscale publishing method as described in claim 2, characterized in that, The multi-dimensional grayscale strategy includes request header grayscale rules and organization grayscale rules. The request header grayscale rules include preset request header field values, and the organization grayscale rules include a list of grayscale organizations. The step of matching the business data with the multi-dimensional grayscale strategy includes: When the process type is an online process, the request header parameters are matched with the preset request header field values; If the request header parameters contain the preset request header field value, then it is determined that the request header grayscale rule is matched; Match the initiating organization number with the grayscale organization list; If the initiating organization number exists in the grayscale organization list, then it is determined that the organization grayscale rule is matched.

4. The grayscale publishing method as described in claim 2, characterized in that, The multi-dimensional grayscale strategy includes Internet Protocol address grayscale rules, which contain a pre-stored list of grayscale Internet Protocol addresses. The step of matching the business data with the multi-dimensional grayscale strategy includes: When the process type is offline, the initiating Internet Protocol address is matched with the gray-scale network interconnection protocol address list; If the initiating Internet Protocol address exists in the grayscale network interconnection protocol address list, then it is determined that the Internet Protocol address grayscale rule is matched.

5. The grayscale publishing method as described in claim 1, characterized in that, The multi-dimensional grayscale strategy includes traffic grayscale rules, which contain pre-stored traffic percentage parameters. Before the step of creating the grayscale process instance corresponding to the process initiation request based on the grayscale version flowchart, the strategy further includes: When the process type is an online process, a first random number is generated based on the probability corresponding to the traffic percentage parameter; Calculate the ratio between the first random number and the preset baseline value. If the ratio is less than or equal to the traffic percentage parameter, determine that the process initiation request matches the traffic grayscale rule, and take the successful match as the grayscale determination result.

6. The grayscale publishing method as described in claim 1, characterized in that, The business data also includes a business category identifier, and the step of creating a grayscale process instance corresponding to the process initiation request based on the grayscale version flowchart includes: In response to the grayscale determination result being a successful match, the grayscale process definition identifier of the grayscale version flowchart that matches the business category identifier and the process type is retrieved and obtained; Based on the grayscale process definition identifier, load the grayscale process definition template corresponding to the grayscale version flowchart from the process definition repository. The grayscale process definition template contains the starting node and subsequent node flow logic of the grayscale version flowchart. Based on the grayscale process definition template and the business data, a grayscale process instance corresponding to the process initiation request is created, and a global instance identifier for the grayscale process instance is generated.

7. The grayscale publishing method as described in claim 1, characterized in that, The step of sending the grayscale marker, the initiating organization number, and the business category to the external system in the request header of the call request when the process publishing system calls the interface of an external system includes: When it is detected that the currently running grayscale process instance has flowed to the first node that needs to call an external system, a corresponding first call event is generated, and the first call event carries the system identifier of the external system; In response to the first invocation event, the grayscale marker is read from the grayscale process instance; Based on the system identifier, obtain the target request header template corresponding to the system identifier from the pre-configured request header template library; The grayscale marker is filled into the request header template to generate the call request; Send the call request to the external system.

8. The grayscale publishing method as described in claim 1, characterized in that, The gray-scale release method also includes: When it is detected that the currently running grayscale process instance has flowed to the second node that needs to call the microservice, a corresponding second call event is generated, and the second call event carries the target call protocol supported by the microservice; In response to the second invocation event, the initiating organization number and business category identifier are read from the grayscale process instance; According to the target invocation protocol, the initiating organization number and the business category identifier are encapsulated into the request header of the second invocation request corresponding to the microservice; The second call request is sent to the microservice, which includes a process component, a scheduling service, a process service, a subscription service, a process engine, a rule engine, or a task interface.

9. A grayscale publishing device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the grayscale release method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the grayscale release method as described in any one of claims 1 to 8.

Images