A method and device for guaranteeing consistency of business rules in a conversational scenario

Abstract

The application provides a business rule consistency guarantee method and device in a conversation scenario and electronic equipment. When a user conversation is started for the first time, a conversation identifier of the user conversation is extracted. The conversation identifier is used to query a flow identifier, a flow definition version, a mapping set of a business rule unit basic name to a business version number, a flow traffic identifier and a flow instance identifier at a time when the user conversation is started for the first time. The information queried is idempotently created into a joint version snapshot with the conversation identifier as a unique index. The business rule and the flow requirement of the user conversation when the user conversation is started for the first time are solidified into the joint version snapshot. When the user conversation is suspended, a user conversation recovery event is listened to. When the user conversation recovery event arrives, a target joint version snapshot is quickly loaded based on the conversation identifier of the user conversation. The user conversation is continued according to the target joint version snapshot. It can be guaranteed that the business version rule and the flow requirement corresponding to the user conversation startup are used in the conversation process.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a method, apparatus and electronic device for ensuring the consistency of business rules in a session scenario. Background Technology

[0002] Various online service applications typically provide online conversation functionality to facilitate convenient communication between users and service providers. For example, in the insurance claims process, users can report and apply for claims through the online conversation function in applications developed by insurance institutions; similarly, in government applications, users can submit supporting documents or participate in review processes through the online conversation function in applications developed by government agencies; and in credit scenarios, users can submit credit requests or participate in repayment processes through the online conversation function in applications developed by credit institutions.

[0003] However, since the duration of online sessions can vary, and sessions may be suspended while waiting for data to be transmitted, and online business processes are constantly updated and iterated during the suspension period, when the suspended session is resumed, the business system continues to advance the session using the currently effective business version rules, which can lead to confusion in the application of business rules. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method, apparatus, and electronic device for ensuring consistency of business rules in a session scenario, thereby ensuring consistency of business decision-making during the session.

[0005] In a first aspect, embodiments of this application provide a method for ensuring the consistency of business rules in a session scenario, wherein the method includes: Listen for user session recovery events; if a user session recovery event occurs, extract the session identifier of the user session. Load the target federated version snapshot based on the session identifier of the user session, and continue to advance the user session according to the target federated version snapshot; The target unified version snapshot is pre-constructed through the following steps: When the user session is first started, the session identifier of the user session is extracted, and based on the session identifier, the process identifier, process definition version, mapping set from basic name of business rule unit to business version number, and process traffic identifier of the user session at the current time are obtained. A process instance is created and the process instance identifier is obtained. Using the user session identifier as a unique index, a joint version snapshot is created based on the process identifier, process definition version, mapping set from basic business rule unit name to business version number, process traffic identifier, and process instance identifier at the current moment of the user session.

[0006] Secondly, embodiments of this application provide a device for ensuring the consistency of business rules in a session scenario, wherein the device includes: The session listening module is used to listen for user session recovery events. If the user session recovery event arrives, the session identifier of the user session is extracted. The session recovery module is used to load a target federated version snapshot based on the session identifier of the user session, and continue to advance the user session according to the target federated version snapshot; A union version snapshot building module is used to pre-build the target union version snapshot through the following steps: When the user session is first started, the session identifier of the user session is extracted, and based on the session identifier, the process identifier, process definition version, mapping set from basic name of business rule unit to business version number, and process traffic identifier of the user session at the current time are obtained. A process instance is created and the process instance identifier is obtained. Using the user session identifier as a unique index, a joint version snapshot is created based on the process identifier, process definition version, mapping set from basic business rule unit name to business version number, process traffic identifier, and process instance identifier at the current moment of the user session.

[0007] Thirdly, embodiments of this application provide an electronic device, wherein the electronic device includes: a processor; and a memory storing a program; wherein the program includes instructions, which, when executed by the processor, cause the processor to execute the session scenario business rule consistency guarantee method described in the first aspect.

[0008] Fourthly, embodiments of this application provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the method for ensuring consistency of business rules in a session scenario as described in the first aspect.

[0009] The beneficial effects of this application are: This application provides a method, apparatus, and electronic device for ensuring business rule consistency in a session scenario. When a user session is first started, the session identifier is extracted. Using this session identifier, the process identifier, process definition version, mapping set from the basic name of the business rule unit to the business version number, process traffic identifier, and process instance identifier at the time of the first session start are queried. Then, using this session identifier as a unique index, the queried information is used to create a joint version snapshot using an idempotent method, thus solidifying the business rules and process requirements at the time of the first session start into a joint version snapshot. If a user session is subsequently suspended, the system can listen for user session recovery events. Once the user session recovers, the corresponding target joint version snapshot is quickly loaded based on the session identifier, obtaining the target joint version snapshot from the time of the first session start. The user session then continues according to this target joint version snapshot. This ensures that the business version rules and process requirements corresponding to the time of the user session start are used throughout the session, avoiding version inconsistencies caused by system iteration updates and effectively guaranteeing the consistency of business decisions during the session. Attached Figure Description

[0010] Further details, features, and advantages of this application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 This paper illustrates a flowchart of a method for ensuring consistency of business rules in a session scenario provided in an embodiment of this application. Figure 2 This illustration shows a schematic diagram of a system architecture for a business rule consistency assurance system in a session scenario provided by an embodiment of this application. Figure 3 This paper illustrates a flowchart of a method for ensuring consistency of business rules in a session scenario provided in an embodiment of this application. Figure 4 This paper illustrates an architecture diagram of a business rule consistency assurance device in a session scenario provided in an embodiment of this application. Figure 5 This illustration shows a structural block diagram of an exemplary electronic device that can be used to implement embodiments of this application, as provided in an embodiment of this application. Detailed Implementation

[0011] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0012] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0013] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this application are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0014] It should be noted that the terms "a" and "a plurality of" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0015] As described in the background section, due to the long session duration and the possibility of session suspension, changes in business rules during the session can lead to confusion in the execution of business rules by the business system upon session resumption. To better understand this issue, the following example can be used as a reference: Taking insurance claims as an example, during an insurance claims session, it's necessary to wait for the user to upload their reimbursement voucher. Since the time it takes for the user to obtain this voucher is unpredictable, the insurance claims session is usually suspended until the user uploads the voucher, at which point the online session resumes and the claims process continues. However, during this period, if the insurance business approval process rules change, and the insurance reimbursement system continues to process the claims using the currently effective version of the approval process, the rule nodes will execute the new version of the approval process. This inconsistency in decision-making within the same online session can cause confusion for the user.

[0016] Alternatively, taking a credit business scenario as an example, during a credit business session, there is a need to wait for credit inquiry results to be returned, bank card verification, manual review, AI review, customer supplementary information upload, timeout compensation, etc. During the suspension of the credit business session, the credit business process instance remains at the waiting node, retaining process variables, process nodes, and activity work items. However, during this period, the credit business system will undergo its own continuous iteration in parallel. There may be new versions of approval processes, credit rules, anti-fraud rules, credit limit rules, etc., which may be released or undergo gray-scale switching, or even version rollback. When the credit business session is awakened, for example, after manual review has ended or the user has uploaded supplementary information, if the credit business system continues to execute the credit business session according to the currently effective version after iteration, a mixed version combination will be generated. For example, the review flowchart is the old version, but the review rule nodes have executed the new version of business rules. This leads to inconsistent decision-making before and after the same credit business session, affecting the user's credit experience. For example, if a user's credit discount was 1.9% before submitting supplementary information, but the discount changes to 2.1% during the supplementary information submission period, the user will have to pay more credit interest, thus affecting the user's credit experience.

[0017] In view of this, this application provides a method, apparatus, and electronic device for ensuring consistency of business rules in a session scenario. Firstly, this application provides a method for ensuring consistency of business rules in a session scenario. This method is applied to any electronic device with a function for ensuring consistency of business rules in a session scenario, including but not limited to personal mobile terminals, computers, or servers. The method can be divided into two stages: when a user session is first started and when a user session is suspended and resumed. Each time a user session is suspended and resumed, the target federated version snapshot created idempotently at the time of the first user session start is used to ensure that the same set of business rules is used each time a session is suspended and resumed, avoiding the problem of business rule confusion. In some possible embodiments, it can be as follows... Figure 1 As shown, this method, following the sequence of initial startup -> suspension and resumption, includes the following steps: S11. When the user session is started for the first time, extract the session identifier of the user session, and obtain the process identifier, process definition version, mapping set from basic name of business rule unit to business version number, and process traffic identifier of the user session at the current time based on the session identifier, create a process instance and obtain the process instance identifier. S12. Using the user session identifier as a unique index, create a joint version snapshot based on the process identifier, process definition version, mapping set from basic name of business rule unit to business version number, process traffic identifier and process instance identifier at the current moment of the user session. S13. Listen for user session recovery events. If the user session recovery event arrives, extract the session identifier of the user session. S14. Load the target federated version snapshot based on the session identifier of the user session, and continue to advance the user session according to the target federated version snapshot.

[0018] The following will provide a detailed explanation of steps S11 to S14 with specific examples: In this application, the user session is an online session of any type and in any scenario, used for online interaction with users and to serve them. During online interaction, content is displayed to the user in the form of a chat box. The user, as the service recipient, can interact with the service provider by entering text, voice, making video calls, uploading materials, etc., within the chat box. The duration of this user session can vary depending on the business cycle of the user communication. For example, for some simple business consultation scenarios, the user session duration is relatively short, while for some online qualification review processes, the user session duration is typically longer. As one implementation method, the method provided in this application can be applied to ensure the consistency of user sessions under long session durations. As an example, the method provided in this application is applied to a risk control credit review session scenario, where the risk control credit review process may involve the following steps: Anti-fraud check (rule enforcement), credit assessment (rule enforcement), credit inquiry (requires waiting for the bank to return the result (may take several hours to several days)), manual review (requires waiting for the reviewer to process (may take one to two days)), AI review (requires waiting for the AI ​​model to complete the reasoning), customer supplementary materials (requires waiting for the customer to re-upload the materials (may take several days)), credit limit calculation (rule enforcement), final decision (giving the final credit limit).

[0019] It is understood that in this application, user sessions are bound to business processes. A business process may contain multiple business rule nodes, and each business rule node references a business rule unit. Each business rule unit can independently publish the latest version of its business rules. Taking the aforementioned risk control and credit approval process as an example, it includes multiple business rule nodes: anti-fraud rule nodes, credit rule nodes, and credit granting rule nodes. Each business rule node references a corresponding business rule unit: the anti-fraud business rule node references the anti-fraud business rule unit, and the anti-fraud business rule unit can independently publish the latest version of its anti-fraud business rules. Similarly, the credit rule node references the credit rule unit, and the credit rule unit can independently publish the latest version of its credit rules, or revert the current credit rules to a certain version of the credit rules.

[0020] Therefore, if any business rule unit corresponding to any business rule node in the business system changes, it will directly change the business rules used by the user session. Similarly, if the business process changes, especially if the process version changes, it will also trigger changes to the business rules. Even if the process version and business rule version corresponding to the user session are recorded separately, if they are not bound together, when the user session is restored, only a certain version of the business rules or only a certain version of the process may be read, both of which will lead to inconsistencies in execution. Therefore, in this embodiment, by executing steps S11 and S12, when the user session is first started, the session identifier of the user session is extracted, and the business rule version and process version corresponding to the first start of the user session are bound together with the user session identifier as a unique index to generate a joint version snapshot.

[0021] Thus, during the user session recovery phase, by executing steps S13 and S14 and using the user session identifier as the query index, the business rule version and process version corresponding to the first startup of the user session can be directly obtained. Then, the user session can continue to proceed according to the business rule version and process version. Since the user session identifier is the user session ID, which has been fixed since the creation of the user session, the same target joint version snapshot can be used to advance the user session at any time the user session is recovered, so as to ensure the consistency of the execution.

[0022] As one implementation method, the method provided in this application can be applied to, for example... Figure 2 The system for ensuring consistency of business rules in the session scenario shown includes: a session identification unit, a snapshot coordination unit, a process version loading unit, a process instance association and recovery unit, a rule task version rewriting unit, a status and idempotency verification unit, a version tracing unit, and an enhanced context unit.

[0023] The session identification unit receives user session recovery requests or listens for user session recovery events, and extracts session identifiers and classifies message types based on the received information. For example, in a risk control and credit scenario, this session identification unit receives risk control requests from credit granting, credit usage, loan management, or other business systems, or listens for recovery events from external data services, manual review, AI review, customer document supplementation, or scheduled tasks. Then, it obtains or generates user session identifiers from the requests to determine process identifiers and business scenarios. For the first received user session request, it outputs an initial start flag; for events carrying session identifiers, it outputs candidate recovery flags.

[0024] The snapshot coordination unit is used to determine whether a user session is a first launch or a user session recovery based on the user session identifier (which can be denoted as session_id) extracted by the session identification unit and combined with the first launch flag or candidate recovery flag. Simultaneously, it uses the user session identifier as an index to match the corresponding target federated version snapshot. If no target federated version snapshot is found but a first launch flag exists, it can be determined that the user session is a first launch. Then, it reads the current process version and business rule version from the process configuration file and business rule configuration file corresponding to the current business system, and writes them to the federated version snapshot. If a target federated version snapshot exists and a candidate recovery flag exists, it directly reads the target federated version snapshot based on the user session identifier, ignoring the current process configuration information and business rule configuration information of the current business system. Note that since this application uses an idempotent creation method when creating federated version snapshots, even if there are concurrent requests from the same user session, only one valid federated version snapshot will be formed.

[0025] The process configuration file records the process version at the current moment. The process version (which can be denoted as Approval, such as Credit_Approval in a credit scenario) records all process-related configuration information at the current moment. Different process versions can be identified by different version numbers. For example, the third process version can be denoted as Approval_v3, and the fourth process version can be denoted as Approval_v4. The process version records the corresponding process configuration information, which includes: process definition version, process node identifier, process flow identifier, process instance identifier, transition conditions between process nodes, process node definition, process termination conditions, process variable structure, and other information.

[0026] Here, the process definition version can be understood as the version number of the process. The process node identifier is used to represent each process node in the process, such as the anti-fraud node, credit assessment node, credit limit calculation node, manual review node, etc. The process flow identifier is used to represent the process flow or operating channel. The process instance identifier is used to represent the processing content corresponding to the process node. The transfer condition between process nodes is used to represent the conditions that need to be met to transfer from one process node to another. The process node definition is used to represent the specific function of each node. The process termination condition is used to represent the conditions that need to be met for the entire process to end. The process variable structure is used to represent the specific meaning of the variable fields carried in the process instance.

[0027] The business rule configuration file records the current business rule version (which can be denoted as RuleVersion). This version can be a snapshot of the business rules (also denoted as RuleVersionSnapshot). The business rule version records the corresponding version's business rule configuration information, including: input data structure, output result structure, business rule conditions, business rule actions, and business rule grouping information. A business rule unit is not necessarily a single business rule; it comprises a group of business rules. The business rule configuration file also configures the mapping relationship between the base name of the business rule unit and the business rule version number. This mapping set, also known as the rule version mapping, means that a business rule version includes several business rule units. By constructing a mapping set from business rule unit name to business version number, several business rule units belonging to the same business rule version are aggregated into a single data set. This facilitates the subsequent retrieval of all business rule units under the corresponding version at once, enabling the simultaneous acquisition of all business rules under all business rule units of the corresponding version.

[0028] Furthermore, the snapshot coordination unit will write the read process configuration information and business rule configuration information into the joint version snapshot shown in Table 1 below: Table 1. A schematic diagram of a joint version snapshot provided in this application.

[0029] The rule version mapping uses structured data containing process coordinates and rule mappings, as shown in the following code: { "processes": { "CreditApproval": "v3" / / The process version is v3 }, / / Process Definition "rules": { "CreditRuleUnit": "v5", / / The business rule node version is v5 "AiReviewRuleUnit": "v3" / / AI review rule node version is v3 / / Business rule definition } Following the snapshot writing method shown in Table 1 above, the following combined version snapshot can be generated: sessionId: S-20260810-001 ← User session identifier used as a unique index processKey: CreditApproval processVersion: v3 ruleVersionSnapshot: {CreditRuleUnit: v5, AiReviewRuleUnit: v3} processFlow: BETA createdTime: 2026-08-10T10:00:00Z If two initial requests concurrently write to the same session, using an idempotent creation approach, only one request will succeed. The other, upon detecting a conflict in the user session identifier, will automatically read the existing federated version snapshot corresponding to the user session identifier, strictly adhering to the idempotent execution logic of querying before building and reusing existing snapshots. Thus, regardless of subsequent online processes and rules regarding deployment, canary releases, or rollbacks, calls to the snapshot coordination unit for the same user session identifier will always return the initially created snapshot, without any in-place rewriting.

[0030] Since the process version number is only used to identify which version of the process definition, but does not reveal which process instance should continue the user session at which process node within the original process instance, as an example, suppose the joint version snapshot records a process definition version using v3. However, if it is not associated with a specific process instance, restoring it may result in finding the wrong instance or creating a new instance. Suppose the process instance identifier records the instance PI-8F21 that should be found, but if it is unknown which version of the process definition should be used to interpret it, it may use the v4 version of the process definition to interpret the instance created during v3, leading to confusion during the entire user session progression. Therefore, in some possible embodiments, when performing the above steps S11-S12, it can be achieved through the following steps: After obtaining an initial combined version snapshot based on the session identifier, process version, rule version, and traffic identifier, the user session process is started, and an actual process instance is created. The step of creating a joint version snapshot based on the user session identifier as a unique index, and on the process identifier, process definition version, mapping set from business rule unit base name to business version number, process traffic identifier, and process instance identifier at the current moment of the user session, includes: The process instance identifier of the actual process instance is backfilled into the initial joint version snapshot to obtain the target joint version snapshot.

[0031] In this embodiment of the application, the process definition version and the process instance identifier must be bidirectionally associated. That is, the instance ID is recorded in the joint version snapshot, and the snapshot is read when the instance is restored to know which instance it is, and to know which version of the process definition version is used to interpret the process instance when the instance is restored.

[0032] Based on this, in this embodiment, the process version loading unit is used to construct the target process definition coordinates, such as CreditApproval_v3, based on the traffic identifier and process version in the target federated version snapshot. It loads the target definition from the deployed multi-version process definition set, and does not use the current default process version as a fallback during the recovery phase. Specifically, when determining the first startup of a user session, it reads the currently configured process version and rule version mapping and writes fields such as sessionId, processInstanceId, processKey, processVersion, ruleVersionSnapshot, processFlow, and createdTime into the initial federated version snapshot table. Initially, the processInstanceId in the initial federated version snapshot table is set to empty to indicate that the process instance has not yet been created. The process instance identifier is used to uniquely identify the process instance so that the original process instance can be located when the session is restored.

[0033] Furthermore, the process instance association and recovery unit is used to create a process instance when a user session is first started, and to backfill the actual process instance identifier into the initial federated version snapshot table to obtain the target federated version snapshot. During recovery, the original process instance is found based on the process instance identifier in the target federated version snapshot, the current callback data is merged with the original process variables, the corresponding activity work items are identified and completed, and the instance continues execution from the original waiting node. Specifically, when a user session is first started, the process instance association and recovery unit can load the corresponding version of the process definition (such as CreditApproval_v3) based on processKey and processVersion, and then create an actual process instance according to the process definition CreditApproval_v3, such as PI-8F21, and then backfill the actual process instance into the federated version snapshot. During the process of backfilling the actual process instance into the federated version snapshot, only the process instance identifier processInstanceId field is allowed to be updated to the corresponding actual process instance; modifications to other process definition versions or rule version mappings are not allowed.

[0034] As can be seen, if the order of determining the process instance first and then the target joint version snapshot is adopted, it will lead to a mismatch between the business rule nodes and the corresponding process definition versions, and the variable structure will also be mismatched, resulting in process errors or incorrect process branches. Using the embodiment of this application, during the user session recovery phase, the method of determining the target joint version snapshot first and then the process instance is adopted. By loading the corresponding process definition according to the process version, and then using the process definition to interpret the instance corresponding to the creation of the historical process version, the original actual process instance is found by searching the processInstanceId field. In this way, it can be ensured that the business rule nodes are completely matched and the variable structure is consistent, thereby ensuring that the target joint version snapshot can be correctly restored.

[0035] The business rule node in the process definition hardcodes a business rule unit class name, such as CreditRuleUnit_v1. Therefore, the process version is bound to the business rule version. It's impossible to release a process version independently without updating the process, and similarly, it's impossible to update the process while maintaining the business rules, which contradicts the original intention of independently releasing processes and business rules. Therefore, to ensure that processes and business rules can be released independently, this application only sets a mapping set from the base name of the business rule unit to the business version number in the joint version snapshot. At runtime, the target joint version snapshot can dynamically select the corresponding business rule based on the joint version snapshot, thereby achieving runtime rewriting and concurrency isolation of rule nodes based on session rule mapping.

[0036] Since business rule execution is divided into two phases: data binding and business rule execution, the input and output data carriers are created in the data binding phase, and the actual business rule logic is executed in the business rule execution phase. If the data binding phase uses the v3 version of the process variable structure, and the actual business rule execution phase uses the v4 version of the business rule logic due to concurrent session interference, this will lead to a mismatch between the data structure and the business rule logic. To overcome this problem, the method provided in this application can also achieve the following steps when executing step S14: Before the target joint version snapshot determines the triggering business rule node, the node declaration suffix of the business rule node is removed to obtain the business rule basic unit name corresponding to the business rule node; Based on the mapping set from the basic name of the business rule unit to the business version number, determine the target business rule version number corresponding to the target joint version snapshot; The user session will continue according to the target business rule version number.

[0037] In this embodiment, the rule task version rewriting unit obtains the rule unit class name declared by the node before the rule node is triggered, removes the version suffix to form a base name, queries the rule version mapping of the session snapshot using the base name, and then synthesizes the target rule unit class name. This rule task version rewriting unit completes data binding and rule execution through a rule unit factory that resolves versions by session, avoiding modification of the core process engine.

[0038] Specifically, before triggering the corresponding business rule node based on the target joint version snapshot, the declaration of the business rule node is read first. For example, if the node declaration of unit1 node is read: CreditRuleUnit_v1, then the suffix of the node declaration of the business rule node is removed. The corresponding suffix is ​​determined based on the underscore. The version suffix in the rule unit declaration is removed according to the agreed v number or _v number _ number format. For example, the declaration suffix in CreditRuleUnit_v1 is v1. The basic unit name of the business rule corresponding to the business rule node unit1 can be obtained: CreditRuleUnit. At this time, it is still only known that the node is to execute credit rules, but it is not known which version of credit rules to use.

[0039] Furthermore, based on the basic unit name of the business rule, and based on the mapping set from the basic name of the business rule unit to the business version number in the target federated version snapshot, the corresponding target business rule version number is determined. For example, the version number v5 is found by looking up the basic name CreditRuleUnit. Based on this version number, the target business rule version number CreditRuleUnit_v5 is constructed. Then, the rule flow group used by the business rule node in this execution is pointed to the target business rule version number CreditRuleUnit_v5.

[0040] Furthermore, the rule unit processing subunit of the business rule node is replaced with a rule unit processing subunit that dynamically parses the target business rule version number according to the user session identifier. This rule unit processing subunit obtains the user session identifier from the flow variables, then parses out the target business rule version number in the target federated version, and instantiates its input and output carriers based on the business rule version number to achieve data binding. Further, a rule unit instance is created, the user session identifier is obtained from the process variables again, the same target business rule version number is parsed out, and it is passed to the rule execution stage through a thread-isolated short lifecycle context. After creation, the short lifecycle context is cleared immediately.

[0041] In this way, the parsing result of session A can be stored in the context of thread A, and the parsing result of session B can be stored in the context of thread B, without interference between the two. Furthermore, this short-lifetime context is cleared immediately after creation, preventing it from affecting subsequent rule nodes. In this application, during the data binding phase, the target rule class is parsed based on the user session identifier and placed into a thread-isolated short-lifetime context. During the rule execution phase, the target rule class is read from the same short-lifetime context, and after use, the short-lifetime context is cleared. This ensures that the rule binding and rule execution phases maintain the same rule version through the short-lifetime thread context.

[0042] Since multiple recovery events may arrive simultaneously during user session recovery, the user session processing flow cannot be blindly advanced. Therefore, in this embodiment, the process instance association and recovery unit is also used to determine the status before multiple recovery events arrive simultaneously. This requires determining: whether the business has ended, which version of the process definition was used for user session recovery, whether the original process instance still exists, and whether the previously waited work items have been completed. If the business final state is not checked before proceeding, a session that has already been rejected may be re-advanced due to a delayed callback, leading to conflicting decisions. If the existence of the process instance is not checked, operations may be performed on a lost instance, or a new instance may be created to replace it. If active work items are not checked, a work item that has already been completed with timeout compensation may be completed again by a delayed original callback, resulting in the work item being repeatedly advanced.

[0043] Therefore, in this embodiment of the application, it is necessary to verify the legality of the recovery event, and the legality verification shall be performed in the following order: Verify whether the request carries a user session identifier (sessionId) and whether the source of the user session recovery event belongs to a legitimate recovery event type, such as external callback, manual result, AI review result, supplementary document result, timeout task, or retry task.

[0044] The system queries the federated version snapshot by user session identifier to determine if it exists. If it doesn't exist, it's considered an invalid historical session recovery, and the exception is recorded and the user session recovery event is blocked. If it exists, the status of the main business task is further validated to determine if it's in a terminated state. A terminated state is defined as a main business task that has been ended, rejected, closed, or expired. If the main business task is not terminated, the process definition is loaded using the `processKey + processVersion` from the federated version snapshot. If loading fails, the process definition doesn't exist; this is recorded and blocked until the historical version is redeployed.

[0045] If loading is successful, the process instance is validated, and the original process instance is searched using the `processInstanceId` in the combined version snapshot. If the original process instance does not exist and the business has terminated, an idempotent return can be made for the late event. If the original process instance does not exist and the business has not terminated, the association is considered corrupted and manual processing is required. If the original process instance exists but has terminated, an idempotent return is made. If the process instance exists but has not terminated, the active work item is validated again to check if there is an active work item that matches the recovery source. If no matching active work item exists, it can be identified as an old callback / duplicate callback / error callback, which can be recorded and an idempotent return made. If a matching active work item exists, it indicates that all validations have passed, the callback data is merged into the process variables, the work item is completed, and the process continues from the original waiting node.

[0046] If all verifications pass, multiple user recovery events are executed serially. In some possible embodiments, including this application embodiment, the state and idempotency verification unit is used to reread the business master state, process instance state, and active work item before the user session is restored. The process is no longer advanced when the business is in a final state or the target work item is completed. If the business is not in a final state but the snapshot, process instance, or target version is missing, it is blocked due to integrity anomalies to avoid a silent switch to the current version. Specifically, the execution of step S14 may also include the following steps: Listen for user session recovery requests to determine when the user session recovery event has arrived; If multiple user session recovery events arrive, each user session recovery request acquires the session exclusive lock corresponding to the corresponding user session identifier in the order of arrival time. For the user session recovery request that has acquired the session exclusive lock, the business status, process instance status and active work items of the user session are reread. Among them, the user session recovery event that has not acquired the session exclusive lock waits for the previous user session recovery event to release the session exclusive lock before acquiring the session exclusive lock.

[0047] It is understood that in this embodiment of the application, if a user session recovery event is detected, each session recovery event can be regarded as a user session recovery request. At this time, each user session recovery request can attempt to acquire a session exclusive lock based on the user session identifier. The session exclusive lock is a processing mechanism: the user session recovery request that acquires the session exclusive lock executes the corresponding user session recovery, while other user session recovery requests that have not acquired the session exclusive lock continue to wait for the user session recovery request that has already acquired the session exclusive lock to complete its execution before continuing execution.

[0048] As one implementation, after the current user session recovery event acquires the session exclusive lock, the method further includes: If the business status is terminated or the work item in the active state has been completed, then record the source of the user session recovery event, the arrival time of the user session recovery event, and the idempotency result. If the business status has not terminated and the work item in the active state has not been completed, then the callback data carried by the user session recovery event will be merged into the process variable corresponding to the user session, and the matched work item in the active state will be completed.

[0049] If multiple user session recovery events arrive, a user session recovery event queue can be set up according to their arrival time, or a user session recovery event sequence can be set up according to their event priority from high to low. Then, a session exclusive lock is set according to the order of the user session recovery events in the sequence, so that the user session recovery events in the sequence are executed sequentially.

[0050] Specifically, for user session recovery requests that have acquired exclusive session locks, the final state of the business process, the state of the process instance, and the active work items can be reread. During this process, the state cached before the exclusive session lock is acquired cannot be used for judgment. This is to avoid situations where request A and request B arrive simultaneously. Request A acquires the exclusive session lock first, but then uses the cached state to advance the user session and releases the lock. Request B then acquires the exclusive session lock, still using the cached state, which would result in the cached state being used twice, leading to the same decision being output repeatedly.

[0051] Therefore, by rereading the business state, process instance state, and active work items, request A can acquire the session exclusive lock, reread the business state, process instance state, and active work items, and then, with work item WI-902 still active, use work item WI-902 to advance the user session, output a decision result, and then work item WI-902 will finish its work and no longer be active, before releasing the session exclusive lock. Request B acquires the session exclusive lock and rereads the business state, process instance state, and active work items. Since WI-902 is no longer an active work item, request B will either use another active work item to advance the user session, or record that work item WI-902 is complete, record idempotency, and not advance the user session. This prevents the session exclusive lock from being occupied by concurrent requests during the event interval between checking and advancing.

[0052] The above-mentioned method of using session exclusive locks can solve the problem of concurrent requests advancing user sessions at the same time, but there are still some hidden concurrency scenarios, such as: Scenario 1: A session is suspended at node A (waiting for external data), generating a recovery context for node A. If a timeout occurs, timeout compensation is triggered, and the process moves from node A to node B (waiting for manual review), generating a recovery context for node B. At this point, a delayed callback from node A arrives (e.g., a delayed return of a bank result). If only the sessionId is verified, without verifying the node, the delayed callback from node A might mistakenly complete the work item on node B. Therefore, recovery permissions need to be bound to the specific waiting node, not just the session.

[0053] Scenario 2: The manual callback arrives for the first time, successfully completing the work item and advancing the process. If the same callback arrives again due to network retries, while only verifying completion of the work item can intercept it, the process may have already progressed to the next waiting point, and a new work item has already been created. Duplicate callbacks might be mistakenly identified as being for a new work item. Therefore, a recovery sequence number is needed to distinguish between old and new batches.

[0054] Scenario 3: After a federated version snapshot is persisted, the version field may be partially altered due to storage failure or program defects. If these failures are not detected, recovery might be performed using corrupted version coordinates, leading to unpredictable decisions. Therefore, it is necessary to calculate a digest of the federated version snapshot content and re-verify it during recovery.

[0055] For the three scenarios mentioned above, the method provided in this application also includes: Before the user session recovery event arrives, an enhanced version snapshot is generated based on the currently waiting node. The enhanced version snapshot records: configuration digest, node fingerprint, recovery sequence number, and recovery token. The configuration digest is calculated based on the joint version snapshot after the first generation of the joint version snapshot. The recovery token is generated based on the node fingerprint, the recovery sequence number, and the configuration digest. When the user session recovery event arrives, based on the enhanced version snapshot of the currently waiting node, the user session recovery event is matched by digest matching, node fingerprint matching, recovery sequence number matching, and final state matching. In the case of digest matching, node fingerprint matching, recovery sequence number matching, and final state matching, the user session continues to advance based on the target joint version snapshot and the callback content carried by the user session recovery event at the current waiting node; If any of the following matches—summary matching, node fingerprint matching, recovery sequence number matching, and final state matching—fail, determine the reason for the matching failure and output the reason for the matching failure.

[0056] In the process of generating the joint version snapshot, this application may also add the fields shown in Table 2 below: Table 2. Illustrated table of added fields in the joint version snapshot provided in this application

[0057] The enhanced context unit is used to calculate the configuration summary, node fingerprint, recovery sequence number, and recovery token in Table 2 above, and associate them with the federated version snapshot. When multiple recovery events arrive concurrently, serial verification is completed in conjunction with a session exclusive lock. It can be understood that in this application, the enhanced version snapshot is an associated record generated when entering a waiting node based on the federated version snapshot, and it contains the information shown in Table 2.

[0058] Among them, the enhanced context unit adopts, for example, Figure 3 The processing flow shown generates a configuration digest, node fingerprint, recovery sequence number, and recovery token, which are then associated with the federated version snapshot. Specifically, when calculating the configuration digest, the processKey, processVersion, ruleVersionSnapshot, and processFlow from the federated version snapshot are organized in a fixed order and according to rules. Then, the rule mappings are arranged lexicographically by the base names, and null values ​​are marked with a preset null flag. This prevents federated version snapshots with the same content but different orders, such as {A:v5, B:v3} and {B:v3, A:v5}, from generating different configuration digests.

[0059] The standardization process can be performed as follows: Process identifiers and versions are arranged in a fixed field order; Rule mappings are arranged lexicographically by the base name of the rule; Null values ​​use the default null flag; Each field uses a length prefix or structured serialization to avoid ambiguity in splicing.

[0060] Let the normalization result be CanonicalSnapshot, then: configDigest = Hash(CanonicalSnapshot) Let the normalized result of the current waiting point be CanonicalNode, then: nodeFingerprint = Hash( processInstanceId || activeNodeId || activeWorkItemId || waitType ) If the current recovery sequence number is resumeSequence, and the random verification code or key stored on the system side is tokenSecret, then the recovery token can be generated as follows: resumeToken = MAC( tokenSecret, sessionId || snapshotId || nodeFingerprint || resumeSequence ||configDigest ) Furthermore, a hash operation is performed on the normalized result to generate the configuration digest. The hash operation can employ a hash algorithm that reliably outputs a fixed-length digest; the key can be a keyed message authentication algorithm, or it can be an association record of an unpredictable random value with the aforementioned fields within a trusted intranet. The recovery token only proves that a particular recovery request corresponds to a specific wait point and recovery batch under a specific snapshot; the process version and rule version are still directly read from the federated version snapshot field. Thus, if the recalculated configuration digest does not match during subsequent user session recovery, it indicates that the content of the federated version snapshot has been corrupted.

[0061] When generating a node fingerprint, the active work item of the process instance is first obtained. When the process instance is suspended, the current active work item information is retrieved from persistent data, including: processInstanceId, activeNodeId, activeWorkItemId, and waitType. Then, the retrieved current active work item information is concatenated and hashed to generate the node fingerprint. In this way, a fixed-length node fingerprint can be used to represent which waiting node the current session is waiting on.

[0062] Then, the recovery sequence number is read. The recovery sequence number is 0 when the session is first started, and it increments after each successful recovery. This recovery sequence number can be used to distinguish between new and old batches. Furthermore, a message authentication algorithm with key (MAC) is used to package the sessionId, snapshotId, nodeFingerprint, resumeSequence, and configDigest fields to calculate the recovery token.

[0063] When user session recovery events such as external callbacks, manual results, AI review results, and supplementary document results arrive, the previously generated resumeToken and the expected resumeSequence will be included in the request. The recovery token does not contain version information; the version is still directly read from the fields in the federated version snapshot. The token only proves that this request corresponds to a specific wait point and a specific batch under a specific snapshot. Furthermore, an exclusive session lock is acquired. An attempt is made to acquire a session-level exclusive lock based on the user session identifier (sessionId) to prevent two concurrent requests from passing validation and completing the work project simultaneously. Requests that fail to acquire the lock must wait.

[0064] An active task is completed and the recovery number is incremented only if the summary, node fingerprint, recovery sequence number, and final state all match. If none of these match and the final state is already processed, an idempotent return is made. If none of these match and the completeness is abnormal, the user session is blocked and the case is transferred to manual processing.

[0065] The verification process involves four conditions: digest matching, node fingerprint matching, recovery sequence number matching, and final state matching. Specifically, digest matching requires that the request's `configDigest` equals the recalculated configuration digest based on the persistent federated snapshot. If this is not true, it indicates that the federated snapshot content is corrupted. Node matching requires that the request's `nodeFingerprint` equals the node fingerprint calculated for the currently active work item. If this is not true, it indicates a delayed callback from an older node. Sequence number matching requires that the request's `resumeSequence` equals the current system sequence number. If this is not true, it means the batch has expired. Final state refers to the final state of the business process. Final state matching requires that the business is in a non-final state and the work item is still active. If not, it indicates that the business has ended or the work item has been completed.

[0066] In the embodiment of this application, when a session is suspended, an enhanced version snapshot is generated for the current waiting point based on the joint version snapshot. This enhanced version snapshot includes information as shown in Table 2, specifically including a configuration summary, node fingerprint, recovery sequence number, and recovery token. When a callback arrives, the enhanced version snapshot, combined with the set session exclusive lock, is used to re-verify whether the current snapshot and the waiting point still match. Only if there is a full match does the user session continue, and a new enhanced version snapshot is generated. If the match has been processed, a silent idempotent return is achieved; if the match is corrupted or mismatched, the process is blocked and requires manual intervention. In the event of any matching failure, the corresponding reason for the matching failure is analyzed based on the above matching conditions, and the reason for the matching failure is output.

[0067] Thus, by using the embodiments of this application and jointly normalizing the configuration digest, node fingerprint, recovery sequence number and recovery token, it can be ensured that the recovery permission is bound to a specific waiting node rather than a session. The recovery sequence number can be used to distinguish between new and old batches, avoiding confusion in callback content that affects consistency. Based on configuration digest matching, the problem of poor decision consistency caused by snapshot content corruption can be avoided.

[0068] This application's embodiments can ensure that historical sessions use the same federated version snapshot, thus avoiding the impact of online configuration changes. However, a new problem remains: version confusion during canary releases. Canary release refers to not switching all users to the latest version at once, but rather selecting a batch of users to switch to the new version first. After a period of time and finding no problems, the proportion of users switching to the new version is gradually increased until 100% is switched. Specifically, suppose the online business rule node releases rule v6 via canary release. Some new sessions use v6. During the canary release, a serious bug is discovered in business rule v6, requiring a rollback to business rule v5. After the rollback, newly created sessions will be fixed with v5 (assuming business rule v5 is correct), but sessions started during the canary release have been fixed with v6 (i.e., the buggy version). This will cause these sessions to continue using v6 upon recovery, thus continuing to generate erroneous decisions.

[0069] In this process, directly modifying the version field of the original snapshot would result in the loss of original version evidence, making it impossible to trace whether the session was ever executed using v6, or if a business rule version migration error occurs, it would be impossible to revert to the state before the migration. Specifically, if an online process or business rule configuration changes, it only affects new user sessions that have not yet created a joint version snapshot. That is, if a user session initiates a change to the online process or business rule configuration, the changed online process or business rule will be used. For historical user sessions that have already created a joint version snapshot, the joint version snapshot before the change will still be used.

[0070] To overcome this problem, the method provided in this application chooses not to modify the previously generated joint version snapshot, but instead generates a replacement joint version snapshot for the user session. That is, if the user session is created during a canary release of the process version and / or business rule version, and an anomaly occurs during the canary release, the method further includes: A replacement joint version snapshot is generated based on the original joint version snapshot. The original joint version snapshot is the joint version snapshot generated when the user session is created. The replacement joint version snapshot includes: the replacement joint version snapshot identifier, the original joint version snapshot identifier, the reason for the joint version snapshot migration and the target version combination. The target version combination includes the process version information after the canary release rollback and / or the business rule version information after the canary release rollback. The user session continues by replacing the original union version snapshot with the replacement union version snapshot as the target union version snapshot.

[0071] In this embodiment, instead of modifying the original joint version snapshot, a new replacement joint version snapshot is created. This preserves the original joint version snapshot and ensures that the complete version chain record is easy to audit later.

[0072] The replacement federated version snapshot adds the following fields to the original federated version snapshot: Replace the union version snapshot identifier replacementSnapshotId, the original union version snapshot identifier parentSnapshotId (so that it points to the original union version snapshot ID and retains the lineage), the migration reason (such as a bug in the gray-scale v6 and rolling back to v5), the approval batch (such as 2026-08-12-batch-001), and the target version combination ({processVersion:v3, rules: {CreditRuleUnit: v5, AiReviewRuleUnit: v3}}).

[0073] When a user session recovery event occurs, the current valid snapshot reference is switched only after confirming that the original active node can be mapped to the target process node. This means that the currently waiting node recorded in the union version snapshot and the enhanced version snapshot also exists in the target version process definition. The current valid snapshot reference is then switched from the original union version snapshot to the replacement union version snapshot. If changes to the target version process structure result in the node not existing, migration is not allowed. The specific reason is as follows: Assuming the original snapshot records process v3, and the current waiting node is N-MANUAL (manual review node), if migration to process v4 is required, but the N-MANUAL node in v4 has been deleted or renamed, the migration will result in the inability to find N-MANUAL when restoring using the v4 process definition, thus preventing the process instance from continuing.

[0074] In addition, if a service interruption occurs, after the service is restarted, the recovery request still queries the union version snapshot and process instance processInstanceId with sessionId, loads the process definition specified in the union version snapshot, and reads the persisted process variables, node positions and work items, and continues from the interruption point to avoid repeating the execution from the beginning.

[0075] By using the embodiments of this application, the stability of in-transit sessions and the controlled rollback of abnormal gray-scale batches can be taken into account, while preserving the complete version link.

[0076] As one implementation, this version tracing unit is used to record the user session identifier, process instance identifier, process version, and actual rule unit version in the process node log, rule execution log, or final decision record, enabling a single decision to reconstruct the version combination used. The final decision record or associated log at least stores the sessionId, processInstanceId, processKey, processVersion, and the actual rule unit version executed for each rule node. Enhanced version snapshots can also store the snapshotId and configDigest. The configuration digest contains a normalized summary of the version coordinates and does not include sensitive business content such as customer credit details, bank card numbers, or manually reviewed text.

[0077] Manual review, AI review, external data, and supplementary document results constitute recovery event data. Business conclusions from multiple review sources can be generated by separate merging rules and then written back as process variables. This application does not directly specify manual priority, AI priority, or conflict voting methods. The advantage of this approach is that the version recovery mechanism only assumes the responsibility for maintaining consistency between the technical state and the execution version, and will not change the snapshot structure and recovery process due to adjustments in the review strategy.

[0078] Based on the method provided in the first aspect, and in the second aspect, this application provides a device for ensuring the consistency of business rules in a session scenario, wherein, as... Figure 4 As shown, the device 400 includes: The session listening module 401 is used to listen for user session recovery events. If the user session recovery event arrives, the session identifier of the user session is extracted. The session recovery module 402 is used to load a target federated version snapshot based on the session identifier of the user session, and continue to advance the user session according to the target federated version snapshot; Union version snapshot construction module 403 is used to pre-build the target union version snapshot through the following steps: When the user session is first started, the session identifier of the user session is extracted, and based on the session identifier, the process identifier, process definition version, mapping set from basic name of business rule unit to business version number, and process traffic identifier of the user session at the current time are obtained. A process instance is created and the process instance identifier is obtained. Using the user session identifier as a unique index, a joint version snapshot is created based on the process identifier, process definition version, mapping set from basic business rule unit name to business version number, process traffic identifier, and process instance identifier at the current moment of the user session.

[0079] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in this application comply with relevant laws and regulations and do not violate public order and good morals.

[0080] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0081] Thirdly, exemplary embodiments of this application also provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the electronic device to perform a method according to an embodiment of this application.

[0082] An exemplary embodiment of this application also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0083] An exemplary embodiment of this application also provides a computer program product, including a computer program, wherein, when executed by a computer's processor, the computer program is used to cause the computer to perform a method according to an embodiment of this application.

[0084] refer to Figure 5 The present invention describes a structural block diagram of an electronic device 500 that can serve as a server or client of this application, which is an example of a hardware device that can be applied to various aspects of this application. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0085] like Figure 5As shown, the electronic device 500 includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM 502) or a computer program loaded from a storage unit 508 into a random access memory (RAM 503). The RAM 503 may also store various programs and data required for the operation of the electronic device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output interface (I / O interface 505) is also connected to the bus 504.

[0086] Multiple components in electronic device 500 are connected to I / O interface 505, including: input unit 506, output unit 507, storage unit 508, and communication unit 509. Input unit 506 can be any type of device capable of inputting information to electronic device 500. Input unit 506 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 507 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 508 may include, but is not limited to, disk and optical disk. Communication unit 509 allows electronic device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0087] The computing unit 501 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above. For example, in some embodiments, the aforementioned method for ensuring consistency of business rules in a session scenario can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 500 via ROM 502 and / or communication unit 509. In some embodiments, the computing unit 501 can be configured to perform the aforementioned method for ensuring consistency of business rules in a session scenario by any other suitable means (e.g., by means of firmware).

[0088] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0089] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0090] As used in this application, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0091] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0092] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0093] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

Claims

1. A method for ensuring consistency of business rules in a session scenario, characterized in that, The method includes: Listen for user session recovery events; if a user session recovery event occurs, extract the session identifier of the user session. Load the target federated version snapshot based on the session identifier of the user session, and continue to advance the user session according to the target federated version snapshot; The target unified version snapshot is pre-constructed through the following steps: When the user session is first started, the session identifier of the user session is extracted, and based on the session identifier, the process identifier, process definition version, mapping set from basic name of business rule unit to business version number, and process traffic identifier of the user session at the current time are obtained. A process instance is created and the process instance identifier is obtained. Using the user session identifier as a unique index, a joint version snapshot is created based on the process identifier, process definition version, mapping set from basic business rule unit name to business version number, process traffic identifier, and process instance identifier at the current moment of the user session.

2. The method according to claim 1, characterized in that, The step of obtaining the process identifier, process definition version, mapping set from basic business rule unit name to business version number, and process traffic identifier of the user session at the current moment based on the session identifier, creating a process instance and obtaining the process instance identifier includes: After obtaining an initial combined version snapshot based on the session identifier, process version, rule version, and traffic identifier, the user session process is started, and an actual process instance is created. The step of creating a joint version snapshot using the user session identifier as a unique index, based on the process identifier, process definition version, mapping set from business rule unit base name to business version number, process traffic identifier, and process instance identifier at the current moment of the user session, includes: The process instance identifier of the actual process instance is backfilled into the initial joint version snapshot to obtain the target joint version snapshot.

3. The method according to claim 1, characterized in that, The method further includes: Listen for user session recovery requests to determine when the user session recovery event has arrived; If multiple user session recovery events arrive, each user session recovery request acquires the session exclusive lock corresponding to the corresponding user session identifier in the order of arrival time. For the user session recovery request that has acquired the session exclusive lock, the business status, process instance status and active work items of the user session are reread. Among them, the user session recovery event that has not acquired the session exclusive lock waits for the previous user session recovery event to release the session exclusive lock before acquiring the session exclusive lock.

4. The method according to claim 3, characterized in that, The method further includes: If the business status is terminated or the work item in the active state has been completed, then record the source of the user session recovery event, the arrival time of the user session recovery event, and the idempotency result. If the business status has not terminated and the work item in the active state has not been completed, then the callback data carried by the user session recovery event will be merged into the process variable corresponding to the user session, and the matched work item in the active state will be completed.

5. The method according to claim 1, characterized in that, The loading of the target federated version snapshot based on the session identifier of the user session includes: Before the target joint version snapshot determines the triggering business rule node, the node declaration suffix of the business rule node is removed to obtain the business rule basic unit name corresponding to the business rule node; Based on the mapping set from the basic name of the business rule unit to the business version number, determine the target business rule version number corresponding to the target joint version snapshot; The user session will continue according to the target business rule version number.

6. The method according to claim 1, characterized in that, The method further includes: Before the user session recovery event arrives, an enhanced version snapshot is generated based on the currently waiting node. The enhanced version snapshot records: configuration digest, node fingerprint, recovery sequence number, and recovery token. The configuration digest is calculated based on the joint version snapshot after the first generation of the joint version snapshot. The recovery token is generated based on the node fingerprint, the recovery sequence number, and the configuration digest. When the user session recovery event arrives, based on the enhanced version snapshot of the currently waiting node, the user session recovery event is matched by digest matching, node fingerprint matching, recovery sequence number matching, and final state matching. In the case of digest matching, node fingerprint matching, recovery sequence number matching, and final state matching, the user session continues to advance based on the target joint version snapshot and the callback content carried by the user session recovery event at the current waiting node; If any of the following matches—summary matching, node fingerprint matching, recovery sequence number matching, and final state matching—fail, determine the reason for the matching failure and output the reason for the matching failure.

7. The method according to claim 1, characterized in that, If the user session is created during a canary release of the process version and / or business rule version, and an anomaly occurs during the canary release, the method further includes: A replacement joint version snapshot is generated based on the original joint version snapshot. The original joint version snapshot is the joint version snapshot generated when the user session is created. The replacement joint version snapshot includes: the replacement joint version snapshot identifier, the original joint version snapshot identifier, the reason for the joint version snapshot migration and the target version combination. The target version combination includes the process version information after the canary release rollback and / or the business rule version information after the canary release rollback. The user session continues by replacing the original union version snapshot with the replacement union version snapshot as the target union version snapshot.

8. A device for ensuring consistency of business rules in a session scenario, characterized in that, The device includes: The session listening module is used to listen for user session recovery events. If the user session recovery event arrives, the session identifier of the user session is extracted. The session recovery module is used to load a target federated version snapshot based on the session identifier of the user session, and continue the user session according to the target federated version snapshot; A union version snapshot building module is used to pre-build the target union version snapshot through the following steps: When the user session is first started, the session identifier of the user session is extracted, and based on the session identifier, the process identifier, process definition version, mapping set from basic name of business rule unit to business version number, and process traffic identifier of the user session at the current time are obtained. A process instance is created and the process instance identifier is obtained. Using the user session identifier as a unique index, a joint version snapshot is created based on the process identifier, process definition version, mapping set from basic business rule unit name to business version number, process traffic identifier, and process instance identifier at the current moment of the user session.

9. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing a program; wherein the program includes instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

Images