Blockchain-based cross-organizational process model evolution method, medium, and electronic device

Abstract

The application discloses a cross-organization process model evolution method on a blockchain, a medium and an electronic device. The method models frequent process dynamic changes based on a time assignment diagram, and adopts a model version control strategy based on a voting mechanism to realize process model evolution. The method introduces instance execution compliance and migration compliance, and realizes state compliance checking of instances in the evolution process. Through the method, the problems of difficult actual cross-organization business process model evolution and inefficient instance migration can be effectively solved.

Description

Technical Field

[0001] This invention relates to the field of business process management technology, and in particular to a method, medium, and electronic device for cross-organizational process model evolution on a blockchain. Background Technology

[0002] As business processes become increasingly complex, many are no longer confined to a single organization, resulting in numerous business processes requiring cross-organizational collaboration. In these complex cross-organizational business processes, predefined business process models often evolve over time and with changing business needs from various parties. However, current business process management methods lack sufficient flexibility to support these changes, leading to various problems such as low enterprise management efficiency and increased security risks. Furthermore, regarding the evolution of business process models, a common practice for process instances that are currently executing according to older versions of the model but have not yet concluded is to terminate the current process and restart it, which often means a significant loss of work. Therefore, since predefined business process models may not be perfect, business process management requires continuous modification of these models and support for appropriate business process evolution methods to optimize processes. Simultaneously, for these currently executing user process instances, adopting appropriate instance migration strategies can reduce process rollback operations and lower labor costs, thereby improving enterprise management efficiency and achieving the strategic goals of enterprise business process management. Therefore, how to design process model evolution and dynamic process instance solutions to help relevant personnel cope with the dynamic changes of cross-organizational business processes is a technical problem that urgently needs to be solved, which is of great significance to the chain operation of business process management. Summary of the Invention

[0003] To overcome the shortcomings of the existing technologies, a cross-organizational process model evolution method on the blockchain is proposed, which can effectively solve the above problems.

[0004] The specific technical solution adopted in this invention is as follows:

[0005] In a first aspect, the present invention provides a method for evolving a cross-organizational process model on a blockchain, which includes the following steps:

[0006] S1. Extract the initially selected business process model from the off-chain business process trajectory data, and use the orchestration tool to model the process and form a business process timing orchestration diagram in BPMN file format.

[0007] S2. Compile and deploy the smart contract based on the initial business process timing orchestration diagram, and use this business process model as the original reference model; the smart contract includes a tool library contract, an access control contract, a voting contract, a scaffolding contract, a version control contract, and an instance control contract;

[0008] S3. When it is necessary to update the business process model, the version initiator imports the orchestration diagram data corresponding to the new business process model in BPMN format into Ethereum and conducts a voting process for the model version. If the vote passes, the reference model will be updated to the new business process model. If the vote fails, the new business process model will be abandoned.

[0009] S4. After the new version is launched, for new process instances, instances will be created and executed directly based on the new version's reference model. The business process will be started by calling the instance control contract and the version control contract. Subsequently, the execution of orchestration activities will be driven by sending and confirming messages. For old process instances that are being executed according to the old version's business process model but have not yet ended, a state compliance check must be performed before continuing execution. Old process instances that meet the state compliance check will then undergo a migration compliance check. If the old version's business process model meets both the state compliance and migration compliance checks, it will continue to migrate to the new version's reference model for execution. If the old version's business process model does not meet the state compliance or migration compliance checks, it will continue to be executed based on the original reference model, or the old version's business process model will be terminated directly and a new business process instance will be created on the new version's reference model.

[0010] As a preferred embodiment of the first aspect above, the compilation and deployment process of the smart contract specifically includes the following steps:

[0011] S21, Deployment Tool Library Contract CC;

[0012] S22. Link the utility library contract CC through the Truffle environment, then deploy the access control contract ACC, and obtain the contract reference ACC after the access control contract is deployed. link ;

[0013] S23. Link the utility library contract CC through the Truffle environment, and then pass in ACC. link Deploy the voting contract (VC) and obtain the contract reference (VC) after deployment. link ;

[0014] S24. Link the utility library contract CC through the Truffle environment, and then pass in ACC. link VC link Deploy the scaffolding contract SC using the scaffolding name (Name), and obtain the contract reference SC after the scaffolding contract is deployed. link ;

[0015] S25. Link the utility library contract CC through the Truffle environment, and then pass it to VC. link SC link To deploy the version control contract (VCC), obtain the contract reference VCC after deployment.link ;

[0016] S26. Link the utility library contract CC through the Truffle environment, and then pass in ACC. link SC link VCC link Deploy the instance control contract (ICC) to obtain the contract reference ICC after deployment. link .

[0017] As a preferred embodiment of the first aspect above, the specific implementation steps for updating the business process model in S3 are as follows: S31 to S36:

[0018] S31. The newly imported orchestration diagram BPMN data file is parsed by the translator to obtain a JSON file containing model elements, sequence streams, messages, decisions, and time constraint information.

[0019] S32. Import the data in JSON into the Ethereum blockchain by calling the access control contract and scaffolding contract interfaces on Ethereum via Web3;

[0020] S33. Verify the permissions of the version initiator by calling the access control contract. If the permission verification fails, terminate the subsequent version voting process. If the permission verification passes, continue to the subsequent version voting stage.

[0021] S34. After the version initiator passes the authorization verification and submits the new version by calling the access control contract, the version participants call the voting contract interface to make a voting decision. By default, the new version can only be released if all version participants agree. If the number of votes for the new version is insufficient, the new version status will change to Refuse and return the result of the vote failing to the version initiator. If the number of votes for the new version meets the required number, the new version status will change to Pass and return the result of the vote passing to the version initiator.

[0022] After the new version submitted by the version initiator in S35 passes the vote, the scaffolding contract and version control contract interfaces are called to update the reference model with the business process model newly imported into the Ethereum blockchain in S32, and the new version is bound to the elements, messages and decisions in the reference model.

[0023] As a preferred embodiment of the first aspect above, the smart contract interface invoked in S32 specifically includes the following steps:

[0024] S321. Iterate through the accounts of eligible participants and import them by calling the account addition method of the access control contract;

[0025] S322. Iterate through the role list in the JSON file and call the role addition method of the access control contract to import it;

[0026] S323. Traverse the model elements in the JSON file and import them using the model import method of the scaffolding contract. The model elements include events, gateways, and orchestration activities.

[0027] S324. Iterate through the messages, decision rules, and time constraint lists in the JSON file and import them using the data import method of the scaffolding contract.

[0028] As a preferred option of the first aspect mentioned above, in step S33, the access control contract needs to be invoked to authorize the version initiator for role-based access control before permission verification.

[0029] As a preferred option for the first aspect mentioned above, in step S34, a version in a deprecated state can only be re-proposed or directly deprecated.

[0030] As a preferred embodiment of the first aspect above, in step S4, the status compliance check steps are performed as shown in S41 to S43:

[0031] S41. For each old process instance that is being executed but has not yet ended, based on the old process instance ID and by calling the instance control contract interface, obtain the corresponding old process instance i stored on the blockchain. For the next orchestration activity element to be executed for old process instance i, perform an element status check. If the element is in the active state Enabled, continue to execute the message status check process of S42. Otherwise, it is considered that the element does not meet the executable state and needs to continue to be executed based on the original reference model, or directly terminate the old version business process model and create a new business process instance on the new version reference model.

[0032] S42. After determining in S41 that the current element is in an active state and continuing the process, the scaffolding contract interface is called to obtain the messages of all the preceding elements of the current element in the old process instance i. Then, the status of each message is determined by traversal. If the messages of all preceding elements meet the receiving status, the migration compliance check in S43 is continued. Otherwise, the execution based on the original reference model must continue, or the old version of the business process model is terminated directly and a new business process instance is created on the new version of the reference model.

[0033] S43. Match the completed preceding trajectories in the old process instance i with all trajectories in the new version reference model. If the completed preceding trajectories in the old process instance i are a subset of any one of the following trajectories, then migrate the old process instance i to the new version reference model for continued execution. Otherwise, continue execution based on the original reference model, or directly terminate the old version business process model and create a new business process instance on the new version reference model.

[0034] As a preferred embodiment of the first aspect above, the orchestration diagram is a timed orchestration diagram, which adds time constraints to the orchestration elements of the orchestration diagram. The time constraints include the single duration constraint of the orchestration activity, the maximum duration constraint of the orchestration activity, and the interval time constraint between orchestration activities.

[0035] In a second aspect, the present invention provides a computer-readable storage medium, characterized in that the storage medium stores a computer program, which, when executed by a processor, implements the blockchain cross-organizational process model evolution method as described in any of the solutions in the first aspect.

[0036] Thirdly, the present invention provides a computer electronic device, characterized in that it includes a memory and a processor;

[0037] The memory is used to store computer programs;

[0038] The processor is configured to, when executing the computer program, implement the blockchain cross-organizational process model evolution method as described in any of the first aspects.

[0039] Compared to existing cross-organizational business process management frameworks, this invention has the following advantages:

[0040] 1. This invention proposes a model version control strategy based on a voting mechanism, which maps the one-to-many relationship between process models and process instances to the relationship between model versions and process instances, thus solving the problem of difficult process model evolution;

[0041] 2. This invention takes into account the execution compliance and state compliance of instances during the evolution process, which can improve the security of instance execution and migration. Attached Figure Description

[0042] Figure 1 This is a flowchart of the blockchain cross-organization process model evolution method of the present invention;

[0043] Figure 2 This is a schematic diagram of the main framework of the method of the present invention;

[0044] Figure 3 This is a schematic diagram illustrating the evolution of the process model of the present invention;

[0045] Figure 4 This is a schematic diagram illustrating the compliance check of a process example of the present invention. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings.

[0047] Conversely, this invention encompasses any substitutions, modifications, equivalent methods, and solutions made within the spirit and scope of the invention as defined in the claims. Furthermore, to provide a better understanding of the invention, certain specific details are described in detail below. However, those skilled in the art will fully understand the invention even without these detailed descriptions.

[0048] To facilitate understanding, some definitions in this invention will be explained before describing the specific implementation of the invention.

[0049] Definition 1, Orchestration Diagram: TM = {E, M, D, T} represents an orchestration diagram, where E, M, D, and T represent the elements (including events, gateways, and orchestration activities), messages, decision conditions, and time constraints of the orchestration diagram, respectively. The element E = E startEvent E endEvent G parallel G exclusive ,TOT},E startEvent It is the starting event, E endEvent It is the end event, G parallel It is a parallel gateway, G exclusive A is a mutual exclusion gateway, and TOT is a time-constrained orchestration activity. Therefore, the orchestration diagram in this definition is a time-constrained orchestration diagram that takes into account the time constraints between orchestration activities, but this invention is also applicable to ordinary orchestration diagrams that do not consider the time constraints between orchestration activities.

[0050] Definition 2, Access Control Organization: CO = {U, R, UR} is an organizational structure that includes all participants in the business processes. Here, U represents a participant in the access control organization, R represents a role in the access control organization, and UR represents the mapping relationship between participants and roles in the access control organization.

[0051] Definition 3, Process Model: ML = {TM, CO} is a reference model for instance creation and execution. TM represents the orchestration diagram, and CO represents the access control organization.

[0052] Definition 4, Locus: σ = <e1, e2, ..., e |σ| > is a non-empty finite sequence of activities, representing the sequence of all orchestration activities that occur in a given process instance, where e |t| (t∈[1,|σ|]) represents the t-th orchestration activity (or start event, end event, or gateway) in the trajectory σ.

[0053] Definition 5, Process Example: I = (VID, D, List) part(St, σ) represents a user process created or executed on the blockchain business process engine based on a process model with version number VID. Here, VID represents the model version number to which the instance belongs; D = {IE, IM, IG} represents the instance's structural information, where IE, IM, and IG represent instance elements, instance message content, and instance global data, respectively; List part St represents the list of participants for the instance; σ represents the set of states for the instance; and σ represents the execution trajectory of the process instance.

[0054] Definition 6, State: St = {St Inst St Eles St Mess} represents the set of states for a process instance. Where St Inst ={Running, Finish} represents the two states of a process instance: running and finished. Eles ={Waiting, Enabled, Completed} represents the state of an element in a process instance. Waiting, Enabled, and Completed represent the waiting, activated, and completed states, respectively, corresponding to binary values ​​00, 01, and 10; St Mess =Wait, Send, Receive, Reject represent the message status in the process instance, where Wait, Send, Receive, and Reject represent the message waiting, sending, receiving, and rejecting statuses, respectively, corresponding to binary values ​​00, 01, 10, and 11; using binary storage and retrieval of element status (or message) can reduce the execution time of instance activities.

[0055] Definition 7, Model Version: V = (VID, Status, ML) represents the version information of the reference model, a generic element component based on version control. Where VID represents the version number within this version component, and Status represents the version status (Init means proposed, Pass means approved).

[0056] Definition 8. Utility Library Contract: CC = {Evar, Efun} is a smart contract that encapsulates the public enumerated variables and computation functions that can be called by the above smart contracts. Here, Evar represents the public enumerated variables, and Efun represents the public computation functions.

[0057] Definition 9, Access Control Contract: ACC = {CO addressMap RList, UList, ACC link This is a smart contract used to authorize access to smart contract operators. CO is... addressMap It stores the linked addresses of the access control organization (CO), RList = {role1, ..., role1, ..., role2, ..., role3, role4, role5, role6, role7, role8, role9, role1, role1, role1, role2, role3, role1, role2, role3, role1, role2, role3, role3, role4, role3 ...3, role3, role3, role3, rolem}Store all roles in the process of translating the metamodel (ML) to the contract, UList = {user1, ..., user} m} is the set of blockchain user accounts for all execution instances. The Access Control Organization (CO) = {U, R, UR} is an organizational structure containing all business process participants, where U represents a participant, R represents a role within the Access Control Organization, and UR represents the mapping between participants and roles within the Access Control Organization. ACC link This represents a reference to the access control contract after it has been deployed.

[0058] Definition 10, Voting Contract: VC = {VP, ACC} link VC link} is a smart contract used to publish proposals and have participants vote on them, which is implemented through ACC. link It links to the Access Control Contract (ACC) described in Chapter 3. The proposal VP = {ID, SC} address V ID Vote require Vote now `State` includes the proposal ID, scaffolding address, current version number, number of people required for the proposal to pass, number of people who have already passed the proposal, and proposal status (including Init status and Pass status). VC link This indicates a contract reference after the voting contract is deployed.

[0059] Definition 11, Scaffolding Contract: SC = {TM, ACC} link VC link SC link Name} is a smart contract that stores an orchestration graph G structure, which is accessed via ACC. link VC link The access control contract ACC and the voting contract VC are linked respectively. SC link This indicates a contract reference after the scaffolding contract is deployed, where Name is the name of the deployed scaffolding contract.

[0060] Definition 12, Version Control Contract: VCC = {V group SC link VC link VCC link} is a smart contract used to manage model versions, which is implemented through SC link and VC link It links to the scaffolding contract SC and the voting contract VC, respectively. V group ={(<E1,V1> ,<M1,V1> ,<D1,V1> ,<T1,V1> ), ..., ( <E n Vn >, <M n V n >, <D n V n >, <T n V n >)} is a set of model versions used to manage elements E, messages M, and decisions D. VCC link This indicates a reference to the contract after the version-controlled contract has been deployed.

[0061] Definition 13, Instance Control Contract: ICC = {IS, ACC} link SC link VCC link ICC link} is a smart contract used to manage process instances, which is implemented through ACC link SC link VCC link These are linked to the Access Control Contract (ACC), the Scaffolding Contract (SC), and the Version Control Contract (VCC), respectively. Here, IS represents the collection storing all process instances I. ICC link This indicates a reference to the contract after the instance control contract is deployed.

[0062] Based on the above definition, the specific implementation process of the present invention will be described in detail below.

[0063] like Figure 1 As shown, the blockchain cross-organizational process model evolution method of the present invention has the following framework: Figure 2 As shown, the specific implementation may include the following steps:

[0064] S1. Cross-organizational process modeling: Based on the enterprise's business process information, the initially selected business process model is extracted from the off-chain cross-organizational business process trajectory data, and the process modeling is performed using an orchestration tool to form a business process time orchestration diagram in BPMN file format.

[0065] In this step, the initially selected business process model typically requires process managers to sift through cross-organizational business processes from log files across enterprises to provide a reference for process modeling. After determining the appropriate business process models to be uploaded to the blockchain based on the analysis results, process managers can orchestrate the business process orchestration diagram (TM) in the chor-js modeler. The chor-js modeler supports orchestration diagrams conforming to the BPMN 2.0 specification, covering and supporting all commonly used elements of the orchestration diagrams mentioned above, and finally exports the orchestration diagram (TM) in BPMN format. However, since business processes change over time, the initially selected business process model may no longer meet the actual business needs. Therefore, the cross-organizational process model evolution method of this invention is required to continuously evolve the on-chain business process model, achieving dynamic updates of the on-chain model.

[0066] S2. Reference Model Deployment: The initial business process timing orchestration diagram is compiled and deployed as a smart contract through the Truffle environment, and this business process model is used as the original reference model; the smart contract includes a tool library contract, an access control contract, a voting contract, a scaffolding contract, a version control contract, and an instance control contract.

[0067] In an embodiment of the present invention, the process manager parses the orchestration diagram TM in BPMN format into model components in JSON format using a translator, for use in the next step of model deployment. During model deployment, the process manager can perform the deployment in a Truffle environment. Therefore, the compilation and deployment process of the above-mentioned smart contract specifically includes the following steps:

[0068] S21, Deployment Tool Library Contract CC;

[0069] S22. Link the utility library contract CC through the Truffle environment, then deploy the access control contract ACC, and obtain the contract reference ACC after the access control contract is deployed. link ;

[0070] S23. Link the utility library contract CC through the Truffle environment, and then pass in ACC. link Deploy the voting contract (VC) and obtain the contract reference (VC) after deployment. link ;

[0071] S24. Link the utility library contract CC through the Truffle environment, and then pass in ACC. link VC link Deploy the scaffolding contract SC using the scaffolding name (Name), and obtain the contract reference SC after the scaffolding contract is deployed. link ;

[0072] S25. Link the utility library contract CC through the Truffle environment, and then pass it to VC. link SC link To deploy the version control contract (VCC), obtain the contract reference VCC after deployment. link ;

[0073] S26. Link the utility library contract CC through the Truffle environment, and then pass in ACC. link SC link VCC link Deploy the instance control contract (ICC) to obtain the contract reference ICC after deployment. link .

[0074] After the initial reference model deployment is completed, the business process model is put on-chain and begins creating corresponding process instances I based on user instructions. However, in complex cross-organizational business processes, predefined business process models often change over time and with evolving business needs from multiple parties, or the predefined business process models may not be perfect. Therefore, during business process management, it is necessary to continuously modify the business process model and support appropriate business process evolution methods to optimize the process. At this point, a large number of process instances are still running on the original model. For these currently executing user process instances, adopting appropriate instance migration strategies can reduce process rollback operations and lower the time and manpower costs associated with process evolution. The following describes how this invention updates the business process model version and migrates user process instances.

[0075] S3. When it is necessary to update the business process model, the version initiator imports the orchestration diagram data corresponding to the new business process model in BPMN format into Ethereum and conducts a voting process for the model version. If the vote passes, the reference model will be updated to the new business process model. If the vote fails, the new business process model will be abandoned.

[0076] In the embodiments of the present invention, the specific implementation steps of the above-mentioned updated business process model are as follows: S31 to S36:

[0077] S31. The newly imported orchestration diagram BPMN data file is parsed by the translator to obtain a JSON file containing model elements, sequence streams, messages, decisions, and time constraint information.

[0078] It is important to note that the BPMN format orchestration diagram corresponding to the new business process model can also be used in conjunction with the orchestration of the original reference model. Figure 1 Similarly, it is created and arranged using the chor-js modeler, which will not be described in detail here.

[0079] S32. Import the data in JSON into the Ethereum blockchain by calling the access control contract and scaffolding contract interfaces on Ethereum via Web3.

[0080] In embodiments of the present invention, the invoked smart contract interface specifically includes the following steps:

[0081] S321. Iterate through the accounts of eligible participants and import them by calling the account addition method of the access control contract;

[0082] S322. Iterate through the role list in the JSON file and call the role addition method of the access control contract to import it;

[0083] S323. Traverse the model elements in the JSON file and import them using the model import method of the scaffolding contract. The model elements include events, gateways, and orchestration activities.

[0084] S324. Iterate through the messages, decision rules, and time constraint lists in the JSON file and import them using the data import method of the scaffolding contract.

[0085] S33. Verify the permissions of the version initiator by calling the access control contract. If the permission verification fails, terminate the subsequent version voting process. If the permission verification passes, continue to the subsequent version voting stage.

[0086] In an embodiment of the present invention, an access control contract needs to be invoked before permission verification to authorize role-based permission control for the version initiator.

[0087] S34. After the version initiator passes the permission verification and submits the new version by calling the access control contract, the version participants call the voting contract interface to make a voting decision. By default, the new version can only be released if all version participants agree. If the number of votes for the new version is insufficient, the new version status will change to the Refuse status and return the result of the vote failing to the version initiator. If the number of votes for the new version meets the required number, the new version status will change to the Pass status and return the result of the vote passing to the version initiator.

[0088] It should be noted that a version in a deprecated state can only be re-proposed or deprecated directly. If it is re-proposed, the S34 voting decision needs to be carried out again.

[0089] After the new version submitted by the version initiator in S35 passes the vote, the scaffolding contract and version control contract interfaces are called to update the reference model with the business process model newly imported into the Ethereum blockchain in S32, and the new version is bound to the elements, messages, decisions and time constraints in the reference model.

[0090] like Figure 3 The diagram shown illustrates the evolution of the process model according to the present invention. The present invention can link new and old process models by deploying new process models and calling contract interfaces, thereby achieving the goal of process model evolution through the coexistence of new and old models. The model version and the process model will correspond one-to-one, and subsequent process instances will have a many-to-one relationship with model versions, achieving the effect of instance version control.

[0091] S4. Instance Execution Compliance Check: After the new version is launched, new process instances will be created and executed directly based on the new version's reference model. The business process will be started by calling the instance control contract and the version control contract. Subsequently, the execution of orchestration activities will be driven by sending and confirming messages. For old process instances that are being executed according to the old version's business process model but have not yet ended, a state compliance check must be performed before continuing execution. Old process instances that meet the state compliance check will then undergo a migration compliance check. If the old version's business process model meets both the state compliance and migration compliance checks, it will continue to migrate to the new version's reference model for execution. If the old version's business process model does not meet the state compliance or migration compliance checks, it will continue to be executed based on the original reference model, or the old version's business process model will be terminated directly and a new business process instance will be created on the new version's reference model.

[0092] In embodiments of the present invention, the execution status compliance check is divided into two parts. The first part is the status compliance check, which includes element status checks and message status checks. This is mainly used to determine whether the historical execution status of the old process instance meets the prerequisites for continued execution. The second part is the migration compliance check, which is mainly used to check whether the old process instance can be migrated to the new version of the reference model for continued execution. Specific compliance check steps are as follows: S41-S43:

[0093] S41. For each old process instance that is being executed but has not yet ended, based on the old process instance ID and by calling the instance control contract interface, obtain the corresponding old process instance i stored on the blockchain. For the next orchestration activity element to be executed for old process instance i, perform an element status check. If the element is in the active state Enabled, continue to execute the message status check process of S42. Otherwise, it is considered that the element does not meet the executable state and needs to continue to be executed based on the original reference model, or directly terminate the old version business process model and create a new business process instance on the new version reference model.

[0094] S42. After determining in S41 that the current element is in an active state and continuing the process, the scaffolding contract interface is called to obtain the messages of all the preceding elements of the current element in the old process instance i. Then, the status of each message is determined by traversal. If the messages of all preceding elements meet the receiving status, the migration compliance check in S43 is continued. Otherwise, the execution based on the original reference model must continue, or the old version of the business process model is terminated directly and a new business process instance is created on the new version of the reference model.

[0095] S43. Match the completed preceding trajectories in the old process instance i with all trajectories in the new version reference model. If the completed preceding trajectories in the old process instance i are a subset of any one of the following trajectories, then migrate the old process instance i to the new version reference model for continued execution. Otherwise, continue execution based on the original reference model, or directly terminate the old version business process model and create a new business process instance on the new version reference model.

[0096] like Figure 4 The diagram illustrates the compliance checks for process instance status and migration in this invention. User process instances often need to meet certain conditions to continue execution during the execution of orchestration activities (or events, gateways, or messages). Therefore, after the new version of the reference model is uploaded to the blockchain, orchestration elements (including orchestration activities, events, and gateways) in an active state need to undergo compliance checks. Figure 4 The display shows that elements C of instance I1 and F of instance I2 are undergoing execution state compliance run-rule checks. A state compliance run-rule for a process instance means that subsequent process instance migrations will not lead to non-deterministic behaviors such as runtime errors or abnormal process termination. The state compliance run-rule includes two types: element executable state checks and message executable state checks. Element executable state checks determine whether the activation status of the current element and all its preceding elements conform to the state compliance run-rule. Message executable state checks determine whether the activation status of the message in the current orchestration activity and all its preceding messages conform to the state compliance run-rule.

[0097] Furthermore, user processes are often dynamically changing. These changes are frequently caused by internal BPMS environmental factors such as actual process changes and process anomalies, or by external BPMS factors such as changes in social laws and regulations, or changes in BPM personnel. During the execution of orchestration elements, user instances, in addition to meeting state compliance (Run-Rule), must also meet migration compliance to safely perform dynamic migration. Therefore, the Migrate-Rule in this invention checks whether a running user process instance can continue execution when migrated to a new version of the reference model. The old process instance can only continue running in the new version of the reference model if there is a prefix trajectory in the new version that matches the prefix trajectory of the old process instance, preventing subsequent process instance migrations from causing errors in process execution. This compliance is triggered on all user process instances affected by model evolution. The migration categories triggered by the Migrate-Rule can be divided into migration and no migration. Figure 4The diagram shows that due to the evolution of process model S, an evolved process model S′ was obtained, which affected the process instances I1 and I2 created and executed based on it. Specifically, Figure 4 For a running process instance I1, the evolution of the process model has not affected I1, where process instance I1 has executed orchestration elements A, or g1 B is already activated, and the next orchestration element to be executed is C, which is consistent with the order of orchestration elements in process model S'. Therefore, I1 can be executed directly based on process model S', meaning that the evolution of this model has a complete transfer effect on I1. Furthermore, for the running process instance I2, its next activated and soon-to-be-executed orchestration element is F, but F's preceding orchestration elements E and or g2 A new orchestration element X is inserted in the middle. Since the orchestration element E of process instance I2 has already been executed, the migration compliance Migrate-Rule rule treats it as not triggering a migration. That is, the effect of this model evolution on I2 is no migration. I2 needs to create a new instance process on the new model in order to continue.

[0098] Furthermore, the above-described steps can be implemented as software functional units in the form of logical instructions in memory. When this software is sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0099] Similarly, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer-readable storage medium corresponding to the blockchain cross-organizational process model evolution method provided in the above embodiments. The storage medium stores a computer program, which, when executed by a processor, implements the blockchain cross-organizational process model evolution method as described in the foregoing scheme.

[0100] Similarly, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer electronic device corresponding to the blockchain cross-organization process model evolution method provided in the above embodiments, which includes a memory and a processor;

[0101] The memory is used to store computer programs;

[0102] The processor is configured to implement the blockchain cross-organization process model evolution method as described in the foregoing scheme when executing the computer program.

[0103] It is understood that the aforementioned storage medium and memory can be random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Furthermore, the storage medium can also be any medium capable of storing program code, such as a USB flash drive, external hard drive, magnetic disk, or optical disk.

[0104] It is understood that the processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0105] It should also be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. In the embodiments provided in this application, the division of steps or modules in the device and method is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple modules or steps may be combined or integrated together, and a module or step may also be split.

[0106] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the invention. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the invention. Therefore, all technical solutions obtained through equivalent substitution or transformation fall within the protection scope of the present invention.

Claims

1. A method for evolving cross-organizational process models on a blockchain, characterized in that, Includes the following steps: S1. Extract the initially selected business process model from the off-chain cross-organizational business process trajectory data, and use the orchestration tool to perform process modeling to form a business process timing orchestration diagram in BPMN file format; S2. Compile and deploy the initial business process timing orchestration diagram into smart contracts, and use this business process model as the original reference model; the smart contracts include tool library contracts, access control contracts, voting contracts, scaffolding contracts, version control contracts, and instance control contracts; S3. When it is necessary to update the business process model, the version initiator imports the orchestration diagram data corresponding to the new business process model in BPMN format into Ethereum and conducts a voting process for the model version. If the vote passes, the reference model will be updated to the new business process model. If the vote fails, the new business process model will be abandoned. S4. After the new version is launched, for new process instances, instances are created directly based on the new version's reference model and executed. The business process is started by calling the instance control contract and the version control contract. Subsequently, the execution of orchestration activities is driven by sending and confirming messages. For old process instances that are being executed according to the old version's business process model but have not yet ended, a state compliance check must be performed before continuing execution. Old process instances that meet the state compliance check will then undergo a migration compliance check. If the old version's business process model meets both the state compliance and migration compliance checks, it will continue to migrate to the new version's reference model for execution. If the old version's business process model does not meet the state compliance or migration compliance checks, it will continue to be executed based on the original reference model, or the old version's business process model will be terminated directly and a new business process instance will be created on the new version's reference model. The specific implementation steps for updating the business process model in S3 are as follows: S31~S35: S31. The newly imported orchestration diagram BPMN data file is parsed by the translator to obtain a JSON file containing model elements, sequence streams, messages, decisions, and time constraint information. S32. Import the data in JSON into the Ethereum blockchain by calling the access control contract and scaffolding contract interfaces on Ethereum via Web3; S33. Verify the permissions of the version initiator by calling the access control contract. If the permission verification fails, terminate the subsequent version voting process. If the permission verification passes, continue to the subsequent version voting stage. S34. After the version initiator passes the authorization verification and submits the new version by calling the access control contract, the version participants call the voting contract interface to vote on the decision. By default, the new version can only be released if all version participants agree. If the number of votes for the new version is insufficient, the new version status will change to deprecated. The system will then return the result of the vote failing to the version initiator; if the number of votes for the new version meets the required number, the new version will become available. And return the voting results to the version initiator; After the new version submitted by the version initiator in S35 passes the vote, the scaffolding contract and version control contract interfaces are called to update the reference model with the business process model newly imported into the Ethereum blockchain in S32, and the new version is bound to the elements, messages, decisions and time constraints in the reference model.

2. The method for evolving cross-organizational process models on a blockchain according to claim 1, characterized in that, The compilation and deployment process of the smart contract specifically includes the following steps: S21, Deployment Tool Library Contract ; S22. Linking the utility library contract via the Truffle environment Then deploy the access control contract. Obtain a reference to the access control contract after its deployment. ; S23. Linking the utility library contract via the Truffle environment Then, by passing in To deploy voting contracts Obtain the contract reference after the voting contract is deployed. ; S24. Linking the utility library contract via the Truffle environment Then, by passing in , and scaffolding name Contract for deploying scaffolding Obtain the contract reference after the scaffolding contract is deployed. ; S25. Linking the utility library contract via the Truffle environment. Then, by passing in , To deploy version control contracts Obtain the contract reference after the version-controlled contract is deployed. ; S26. Linking the utility library contract via the Truffle environment Then, by passing in , , To deploy instance control contracts Obtain the contract reference after the instance control contract is deployed. .

3. The method for evolving cross-organizational process models on a blockchain according to claim 1, characterized in that, The smart contract interface called in S32 specifically includes the following steps: S321. Iterate through the accounts of eligible participants and import them by calling the account addition method of the access control contract; S322. Iterate through the role list in the JSON file and call the role addition method of the access control contract to import it; S323. Traverse the model elements in the JSON file and import them using the model import method of the scaffolding contract. The model elements include events, gateways, and orchestration activities. S324. Iterate through the messages, decision rules, and time constraint lists in the JSON file and import them using the data import method of the scaffolding contract.

4. The method for evolving cross-organizational process models on a blockchain according to claim 1, characterized in that, In step S33, before permission verification, the access control contract needs to be called to authorize the version initiator with role-based permission control.

5. The method for evolving cross-organizational process models on a blockchain according to claim 1, characterized in that, In step S34, a version in a deprecated state can only be re-proposed or directly deprecated.

6. The method for evolving cross-organizational process models on a blockchain according to claim 1, characterized in that, In step S4, the status compliance check steps are performed as shown in S41~S43: S41. For each old process instance that is currently executing but has not yet ended, obtain the corresponding old process instance stored on the blockchain based on the old process instance ID and by calling the instance control contract interface. For old process examples The next orchestration activity to be executed will perform an element state check; if the element is active... If the condition is met, the message status check process of S42 will continue to be executed; otherwise, the element is considered to be in an unexecutable state and must continue to be executed based on the original reference model, or the old version of the business process model will be terminated and a new business process instance will be created on the new version of the reference model. S42. After determining in S41 that the current element is in an active state and continuing the process, the old process instance is obtained by calling the scaffolding contract interface. The system retrieves all messages from the preceding elements of the current element and then iterates through them to determine the status of each message. If all messages from the preceding elements meet the receiving status, the S43 migration compliance check continues. Otherwise, the system continues to execute based on the original reference model, or the old version of the business process model is terminated and a new business process instance is created on the new version of the reference model. S43, Example of the old process The previously executed preceding trajectories are matched with all trajectories in the new version of the reference model. If the old process instance... If the completed preceding trajectories are a subset of any one of the following trajectories, then the old process instance will be... If necessary, migrate to the new version of the reference model to continue execution; otherwise, continue execution based on the original reference model, or terminate the old version of the business process model and create a new business process instance on the new version of the reference model.

7. The method for evolving cross-organizational process models on a blockchain according to claim 1, characterized in that, The orchestration diagram is a timed orchestration diagram, which adds time constraints to the orchestration elements of the orchestration diagram. The time constraints include the single duration constraint of the orchestration activity, the maximum duration constraint of the orchestration activity, and the interval time constraint between orchestration activities.

8. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the blockchain cross-organizational process model evolution method as described in any one of claims 1 to 7.

9. A computer electronic device, characterized in that, Including memory and processor; The memory is used to store computer programs; The processor is configured to implement the blockchain cross-organization process model evolution method as described in any one of claims 1 to 7 when executing the computer program.

Images