Datagram-based service invocation mode

Abstract

The application relates to the technical field of inter-service communication, and discloses a service calling mode based on data messages. The application takes a Kafka cluster as a message middleware to realize asynchronous request and return message transmission between services through data messages, the services do not directly call each other and do not depend on centralized registration components, can realize decentralization at the architecture level, realize low coupling in the dependency relationship, and realize light weight on the technology tool stack.

Description

Technical Field

[0001] The present application relates to the field of inter-service communication technology, and in particular to inter-service communication technology in distributed systems and microservice architectures. Background Art

[0002] This section is intended to provide a background or context for understanding the embodiments of the present application and is for reference only. The applicant should not be considered to admit that this section belongs to the prior art that has been disclosed before the filing date of this application.

[0003] In existing enterprise applications and information systems, distributed system architectures are becoming increasingly common as business scenarios become increasingly complex and processing scales continue to expand. In distributed systems, a previously centralized monolithic application is typically split into multiple independent and relatively independently deployed service modules, which collaborate to complete the overall business process. The communication and collaboration methods between these services directly impact the system's scalability, maintainability, and reliability.

[0004] To achieve interaction and data transmission between services, various communication methods and protocols are commonly used in existing technologies. The more common ones include:

[0005] 1. Remote Procedure Call (RPC): RPC hides the details of the call, allowing the caller to call a remote service as if it were a local method. However, RPC typically requires tight interface constraints between services. When the interface or parameter definition of the called service changes, the caller must also update simultaneously, leading to potential coupling and fragility within the system.

[0006] 2. Representational State Transfer Application Programming Interface (RESTful API): RESTful APIs enable service-to-service interaction based on the Hypertext Transfer Protocol (HTTP). Due to the universality of HTTP in network transmission and the resource-based and standardized nature of the RESTful style, this approach has gained widespread adoption. However, for applications requiring high concurrency and large data volumes, the synchronous invocation of RESTful APIs still presents performance and scalability challenges.

[0007] 3. WebService: A web-based communication protocol that allows applications on different platforms and in different programming languages ​​to interoperate and exchange data over the network. Web Services enable applications to call and share functionality with each other through standard network protocols and data formats, without having to worry about the underlying implementation details. Web Services typically use XML format to transmit data. XML is more verbose than binary or simplified formats such as JSON or Protobuf, resulting in higher message overhead. In addition, SOAP messages often require complex parsing, which results in relatively low performance.

[0008] In typical business scenarios like process approval, services must not only communicate approval requests and results, but also efficiently, flexibly, and with low coupling to process identifiers, business parameters, and approval results. Using traditional RPC or RESTful communication methods in such scenarios can be subject to numerous limitations during interface changes, version upgrades, and interface anomalies.

[0009] Therefore, given existing technology, a service communication method that doesn't rely on centralized components is still needed to achieve loose coupling and flexible scalability between services, thereby meeting the needs of complex business scenarios, including process approvals. This method should be based on asynchronous communication, making the transmission of request and response data between services more efficient and easy to scale, and achieving reliable data exchange without directly calling each other. This is the technical problem that existing technologies need to solve. Summary of the Invention

[0010] The purpose of this application is to provide a datagram-based service calling method that can achieve decentralization at the architectural level, low coupling in dependencies, and lightweight in the technical tool stack.

[0011] This application discloses a datagram-based service invocation method. A Kafka cluster acts as a message middleware to implement asynchronous request and return message transmission between a requesting service and a receiving service through datagrams. The services do not directly call each other and do not rely on a centralized registration component. The method includes:

[0012] In the request service, a request message is generated according to a predefined data message format including service identification information and request parameters, wherein the predefined data message format is independent of the internal implementation of the service, does not rely on centralized components and specific communication frameworks, and can expand the service by adding or modifying fields; the request message is sent to the request topic of the Kafka cluster;

[0013] In the receiving service, the process request message is received from the approval request topic of the Kafka cluster, parsed and processed according to the service identification information and request parameters therein, and a result message is generated according to the same predefined data message format, and the result message is sent to the result topic of the Kafka cluster;

[0014] In a preferred example, after receiving the result message returned by the approval service, the process service determines the next processing logic of the current process instance based on the approval result field contained in the result message; if the approval result field indicates approval, the process instance is advanced to the subsequent approval node or the process instance is ended; if the approval result field indicates rejection, the process instance is rolled back to the initiator node based on the rejection reason shown in the approval result field, and a notification message containing the rejection reason is generated and sent again to the corresponding topic in the Kafka cluster so that the relevant services can perform corresponding business processing accordingly.

[0015] In a preferred example, the approval request topic and the approval result topic are independently configured in the Kafka cluster to achieve classified storage and transmission of process approval request messages and approval result messages.

[0016] In a preferred example, the process approval request message and the approval result message both contain process identification information that can identify a specific process instance, so that the process service can determine the corresponding approval process instance when receiving the return message.

[0017] In a preferred example, when parsing the process approval request message, the approval service selects a corresponding approval rule template for processing according to the approval node information, and generates the approval result message according to the processing result.

[0018] In a preferred example, when parsing the approval result message, the message service determines the display format of the message according to the approval result field, and sends the generated return result message to the approval service in an asynchronous manner.

[0019] In a preferred example, the Kafka cluster is a distributed cluster structure that performs redundant storage and load balancing on messages to ensure reliability and scalability in high concurrency and high data volume scenarios.

[0020] In a preferred example, when modifying the process approval logic or approval node information, it is only necessary to add, delete or update fields in the predefined data message format without synchronously adjusting the internal implementation of the process service, approval service or message service.

[0021] The application further discloses a non-transitory computer-readable storage medium, wherein computer executable instructions are stored in the non-transitory computer-readable storage medium, and the computer executable instructions are executed by a processor to implement the steps in the method described above.

[0022] The application further discloses a computer program product, comprising computer executable instructions, which are executed by a processor to implement the steps in the method described above.

[0023] In the embodiments of the application, by using a Kafka cluster-based message middleware between services for asynchronous request and return transmission of data messages, and by introducing a predefined data message format independent of internal implementation and not dependent on centralized components and specific frameworks, decoupling between services can be achieved. The technical effect is that:

[0024] 1. By using an asynchronous message transmission mode without direct calling, the services are not dependent on internal implementation changes, and when the internal logic or interface of a certain service is adjusted, other services do not need to be changed synchronously, thereby greatly reducing coupling and maintenance costs;

[0025] 2. By not relying on centralized registration components, the services are deployed and expanded in a decentralized manner, thereby improving the flexibility and scalability of the system;

[0026] 3. By only needing to follow the predefined message format without integrating specific frameworks or components, the development and debugging process of the services is simplified, the development speed is improved, and the dependence on specific technology stacks is reduced.

[0027] In other words, by using this asynchronous communication scheme based on Kafka and the predefined message format, a more flexible, lightweight and reliable interaction mode of the service architecture can be achieved, thereby improving the overall maintainability, scalability and decoupling of the system.

[0028] Further, by dynamically determining the next processing logic of the process according to the result field after the process service receives the approval result message returned by the approval service, the approval process can be promoted or rejected flexibly according to business requirements, the dynamic and flexible adjustment of the approval process is realized, and the adaptability and scalability of the system to business changes are significantly improved.

[0029] Further, by configuring independent topics for the process approval request message and the approval result message in the Kafka cluster, different types of messages can be clearly classified and managed, thereby improving the maintainability and scalability of message processing, and making the data interaction between services more orderly and efficient.

[0030] Furthermore, by including process identification information that can identify a specific process instance in both the process approval request message and the approval result message, it can be ensured that the return message can accurately correspond to the corresponding process instance, thereby improving the accuracy of process tracking and tracing, and simplifying the debugging and diagnosis work at the process instance level in the system.

[0031] Furthermore, by selecting the corresponding approval rule template for processing based on the approval node information in the approval service, the approval rules can be quickly changed, expanded or replaced according to business needs, thereby providing a high degree of flexibility and configurability for the system's process approval logic, helping to quickly respond to business changes and reduce maintenance costs.

[0032] Furthermore, by determining the message display format and transmission path according to the approval result field in the approval result message in the message service, personalized and scenario-based message output can be achieved, thereby improving the user experience and the effectiveness of message notifications, and providing customized processing capabilities for different user scenarios.

[0033] Furthermore, by using a distributed Kafka cluster to redundantly store and load-balance messages, the reliability of message transmission and the scalability of the system can be ensured in high-concurrency and high-data-volume scenarios, thereby meeting the high-performance and high-availability requirements of large-scale distributed applications.

[0034] Furthermore, by simply adding, deleting or updating fields in the predefined data message format, the process approval logic or approval node information can be modified without the need to synchronize adjustments to the internal logic of the service. This can make the system more flexible and agile in responding to business changes, reducing subsequent maintenance costs and implementation difficulties. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 This is a diagram showing the relationship between service invocation methods based on data packets according to an embodiment of the present application;

[0036] Figure 2 This is a flowchart of the collection, preprocessing, processing, and warehousing business according to an embodiment of the present application;

[0037] Figure 3-Figure 5 This is a metadata definition field diagram corresponding to a collected data message according to an embodiment of the present application;

[0038] Figure 6 This is a sample diagram of a data collection message according to an embodiment of the present application;

[0039] Figure 7 This is a sample diagram of a processed data message according to an embodiment of the present application;

[0040] Figure 8is an example of an inbound data message according to an embodiment of the present application;

[0041] Figure 9 is an example of a leave business process flow according to an embodiment of the present application;

[0042] Figure 10 is an example of a service interaction process flow according to an embodiment of the present application;

[0043] Figure 11 is an example of a multi-center change process flow according to an embodiment of the present application;

[0044] Figure 12 is an example of an approval request message according to an embodiment of the present application;

[0045] Figure 13 is an example of an approval return message according to an embodiment of the present application;

[0046] Figure 14 is an example of a pre-processed message according to an embodiment of the present application. DETAILED DESCRIPTION

[0047] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present application. However, it will be apparent to one ordinarily skilled in the art that the present application can be practiced without these specific details and that numerous implementation specific details can be varied:

[0048] Explanation of some concepts:

[0049] A Kafka cluster is a distributed messaging system deployment structure composed of multiple Kafka server (i.e., Broker) nodes. The cluster achieves redundant storage and fault tolerance capabilities for messages by storing them in partitions and replicas. Nodes work collaboratively in the cluster to provide high-throughput, scalable, and low-latency transmission channels for message production (writing) and consumption (reading). Through cluster management coordination, Kafka can maintain reliable message transmission and system high availability and scalability in the case of node failure or load changes.

[0050] In order to make the purpose, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the drawings.

[0051] Figure 1Figure 1 is a service calling mode relationship diagram based on data message according to an embodiment of the present application, which comprises three parts, namely microservices, message middleware and message. The microservices comprise process service, approval service and message service, the communication between the microservices is realized through the message middleware Kafka cluster, and the microservices do not need to call each other directly. The message middleware is the Kafka cluster, which provides a transmission channel for the microservices to send and return messages. The messages include request messages and return messages, which correspond to the input parameters and return information, respectively. The whole implementation does not depend on centralized components, such as the registration center of the microservices, and does not depend on specific implementation frameworks, only the transmission of messages is needed, and the communication between the services is not needed, which greatly reduces the coupling between the services.

[0052] Embodiment 1: Implementation of basic process approval scenario

[0053] The service calling mode based on data message is described by taking the leave approval process in an enterprise as an example.

[0054] I. System environment and participating objects

[0055] Process service: responsible for the initiation and promotion of the leave process, including receiving the submission of the leave form, creating or updating the process instance, etc.

[0056] Approval service: responsible for analyzing and processing the approval request message sent by the process service, determining the received approval request according to the preset approval rules (such as department manager approval node and supervisor approval node), and generating an approval result.

[0057] Message service: generating a corresponding message notification according to the approval request, and returning the approval result to the approval service in the form of a data message.

[0058] Kafka cluster: as a message middleware, providing an asynchronous and reliable transmission channel for the data message interaction between the above services. The Kafka cluster has at least two topics, namely the approval request topic and the approval result topic. The approval request topic is used to store the approval request message sent by the process service, and the approval result topic is used to store the approval result message and the return message generated by the approval service and the message service.

[0059] II. Predefined data message format

[0060] The message adopts a predefined format for data exchange. The main fields include:

[0061] Process identifier: used to identify a specific process instance. For example, a process instance can be referred to as process number 123.

[0062] Approval Node: used to indicate the current approval link, such as department manager approval, HR approval node, etc.

[0063] Request parameters: used to carry requested business data, such as the number of days of leave, reason for leave, and applicant's name.

[0064] Approval result: reflected in the result message, used to indicate the conclusion of approval or rejection.

[0065] Reason: When the approval result is rejection, it is used to indicate the specific reason, such as the need for additional supporting documents.

[0066] The data message format is defined independently of the service's internal implementation logic, eliminating the need for centralized components and specialized communication frameworks. As process requirements change, message content can be expanded by adding or adjusting fields without extensively modifying how services connect to each other.

[0067] 3. Transmission process of request and return messages

[0068] After a user submits a leave request, the process service generates an approval request message based on business needs. This message includes a process identifier (e.g., process number 123), an approval node (e.g., department manager approval), and request parameters (e.g., number of days requested: 3, reason for leave: family matters). The process service sends this message to the approval request topic in the Kafka cluster.

[0069] The Approval Service subscribes to the Approval Request Topic. Upon receiving the corresponding Approval Request message, it extracts information such as the process ID, approval node, and request parameters, and processes it according to predefined approval rules. After matching the approval items, the Approval Service generates a message request message and sends it to the Message Request Topic.

[0070] The message service subscribes to the message request topic. Upon receiving an approval request message, it generates a message message based on the user's approval result and returns it to the approval service. If the approval is approved, the message service generates a message result message containing the approval result corresponding to the original process ID. If the approval is rejected, the rejection and the reason (e.g., the need for additional supporting documents) are indicated in the approval result message and sent to the approval result topic.

[0071] The process service also subscribes to the corresponding topic. When it receives a return message that matches its own process ID, if the approval result is approved, it advances the process instance to the next step or ends the process. If the result is rejected, the process instance is returned to the applicant for modification and the approval request can be re-initiated as needed.

[0072] This example demonstrates that, without a registration center or dependencies on a specific framework, process services, approval services, and message services interact only through Kafka middleware and data packets, thereby achieving decoupling, decentralization, and lightweighting between services.

[0073] Example 2: Dynamic expansion of approval nodes and message field update

[0074] In practical applications, the approval process may need to be expanded. For example, a legal approval node could be added to the existing department manager approval node. Traditional approaches often require modifying service interface definitions and registry information, increasing coupling and configuration costs. This invention easily adapts to such changes through data message expansion.

[0075] When a new legal approval node is added, the process service simply expands the approval node field in the message from "Department Manager Approval" to "Legal Approval" when generating the approval request message, and adds legal review-related information to the request parameters. No modifications are required to the communication framework or registration center configuration.

[0076] After receiving a new message, the approval service only needs to add processing rules for the legal approval node in the internal logic. It can parse the corresponding fields and generate a new approval result message without changing the communication method.

[0077] Message services, like process services, can make corresponding business processing based on newly added fields, thus realizing the ability to dynamically expand the approval process.

[0078] Example 3: Data collection and storage of the operation and maintenance basic platform subsystem

[0079] The core of the operation and maintenance basic platform is a data middle platform. Based on the data middle platform, the operation and maintenance of the enterprise information system is carried out around the middle platform data. This requires the platform to be able to integrate data from different subsystems. The platform's data integration capability is to circulate the three links of data collection, data processing, and data storage based on the service call method of data messages. All data from the subsystems are collected, pre-processed, processed, and stored. The operation and maintenance basic platform uses data to supply the required data to other subsystems to meet the functions of other subsystems. The specific process is as follows: Figure 2 shown.

[0080] The business process of collection, pre-processing, processing and warehousing is as follows:

[0081]

[0082]

[0083] In the important link of data collection processing and warehousing, the subsystem data is connected through the method of combining the service calling mode of data message, which is beneficial to the decoupling of each data processing stage, and each stage can realize load separation and horizontal expansion. Since the communication mode of the application does not depend on the registration center and specific framework, the expansion service instance or topic distribution can be completed only at the Kafka level, without the need for complex adjustment of inter-service communication logic.

[0084] Embodiment four: approving the leave process.

[0085] The following is an application scenario introduction using the service calling mode based on data message. The scenario is a business scenario in which a platform user uses the process center module to submit a leave process, and an approval user approves the leave process. The whole process is divided into three steps. The first step is to initiate the process. The leave user clicks the leave process on the platform to initiate it. The second step is to submit the form. The leave user fills out the leave form and clicks submit. The third step is to approve. The approval user will see the leave approval message of the leave user in the message list of the personal portal, then click pass or reject. If it is passed, the process ends. If it is not approved, the process node returns to the initiator, the leave user node. The overall process is shown in Figure 9 .

[0086] Next is the explanation of the service interaction process of the leave approval scenario. First, the backend microservices involved. There are three backend microservices: process service, approval service, and message service. The process service is the backend service of the process center module, which has functions such as process portal, process management, and process template management. The approval service is the backend service for platform users to approve, which has functions such as approval item management, approval management, and approval delegation. The message service is a module for platform users to receive internal messages, which has functions such as message management and message strategy management. The three services need to interact with each other, but the three microservices do not need to rely on the communication framework. They only need to define the message specification, then they can realize business interaction according to the message specification. Secondly, they do not need to call each other directly, which greatly reduces the coupling between service interactions. In addition, they do not need to rely on the centralized registration center component, making the architecture more lightweight.

[0087] The overall service interaction process is as follows: first, the process service initiates an approval request message to the approval service, then the approval service initiates an approval message request message to the message service according to the approval request message and the corresponding approval item rule, the message service displays the approval message on the page according to the approval message request message, and when the approval message is approved by the user, the message service sends the approval result to the approval service in the message return message, the approval service sends the approval result to the process service in the approval return message, and the process service performs the next pass or reject operation according to the approval result message. The service interaction process is as shown in Figure 10 .

[0088] Embodiment five: complex business process.

[0089] In this embodiment, a special processing mechanism for a specific type of process (for example, “multi-center change process”) is introduced. Such a process needs to automatically generate multiple parallel approval nodes according to the conditional fields in the message, perform dynamic compliance verification on the approval nodes, and automatically backtrack when an exception occurs, thereby embodying the unique step and data processing method of the application in the specific scene of process approval. The overall process is as shown in Figure 11 .

[0090] Step 1: Process initiation and conditional field setting

[0091] (1.1) After the user submits a specific form (for example, “multi-center change process”), the process service generates an approval request message according to the pre-defined data message format. The message contains:

[0092] Business type (e.g., businessType = APPROVE_REQUEST)

[0093] Request authentication (e.g., token = kS4BN8R5GweDXPJo0UJM7jwdKQ)

[0094] Request time (e.g., time = 1704178466000)

[0095] Approval name (e.g., title = Multi-center change approval)

[0096] Business parameters (e.g., requestor name requestName = "Zhang San", requestor department requestDepartment = "Operation and Maintenance Department", requestor mobile requestMobile = 18888888888, title title = "City double-live switching of credit investigation system", change environment changeEnvironment = "production environment", change scope changeScope = ["Shanghai data center", "city data center"], business system businessSystem = "second-generation credit investigation system", planned completion time of change plannedCompletionTimeOfChange = "2023-04-07 21:00:00", technical support contact technicalSupportContact = "Li Si", verification support contact verificationSupportContact = "Zhang San", test verification report testVerificationReport = "switching scheme test verification report.docx", change implementation plan changeImplementationPlan = "switching scheme change implementation plan.docx", change rollback plan changeRollbackPlan = "switching scheme change rollback plan.docx")

[0097] Compliance verification instruction field (e.g., complianceCheck = true)

[0098] Dynamic node generation trigger condition field (e.g., conditionalExpansion = {"threshold":["Shanghai data center", "city data center", "off-site disaster recovery center"], "extraApprovals":["insertValueNode"]} indicates that when multiple data centers are involved, the approval nodes of the corresponding data centers need to be automatically inserted), and the approval request data message sample is as shown in the following table. Figure 12

[0099] (1.2) The process service sends the message containing the above-mentioned fields to the "approval request topic" in the Kafka cluster.

[0100] Step 2: Dynamic node generation and compliance verification analysis of the approval service

[0101] (2.1) After the approval service receives the message from the "approval request topic", it first checks the data centers that need to be changed according to the predetermined field (e.g., conditionalExpansion). After detecting multiple data centers, parallel approval nodes of the corresponding data center management positions need to be inserted in the subsequent approval path: such as production change management position, city change management position, off-site disaster recovery center management position, etc.​ More management positions, Disaster recovery change management position .

[0102] (2.2) If the message contains a predefined flag (e.g., complianceCheck = true), the approval service loads the corresponding compliance check rule template based on the process type (multi-center change). This template includes consistency requirements for parallel approval results. That is, after multiple data center nodes return results, the change scope must be compared for compliance to determine if it falls within the specified change scope (e.g., Shanghai data center, local data center, remote disaster recovery center).

[0103] (2.3) Based on the analysis results, the approval service generates several sub-messages for the subsequent approval. Among them:

[0104] Three parallel approval request messages are generated based on the scope of the change, pointing to the Shanghai change management post node, the same city change management post approval node, and the disaster recovery change management post. These three messages contain a parallelGroupID="PG1234" field, which is used for identification and association when the results are aggregated later. The feedback message generated by the approval is as follows: Figure 13 shown.

[0105] Step 3: Parallel approval process and result aggregation

[0106] (3.1) The approval service sends the above three approval request messages to the corresponding topics in Kafka, such as "Process Approval Request Topic". The approval service instance subscribes to the corresponding topic, receives the message from it, and processes the request. Production changes Change management position 、 In-city change management and disaster recovery change management After the approval is completed, they each generate an approval result message, which contains:

[0107] Original process identification information, for example, businessId=6775ffea133aewefcc

[0108] Information related to the parallel identifier, such as parallelGroupID="PG1234"

[0109] Approval result field (e.g., approvalResult="agree", rideControlResult="agreeWithConditions").

[0110] (3.3) After the three parallel result messages are received by the approval service, they are aggregated based on information related to the parallel identifier (e.g., ParallelGroupID). After aggregation, the approval service generates a combined result message, which not only contains the approval conclusions of the three parallel nodes, but also performs additional judgments based on predefined compliance verification rules. For example, if all data center change management positions approve the request, the compliance verification logic will record this requirement in the combined result message as a "conditional approval" mark (complianceStatus="conditionalApproval").

[0111] Step 4: Exception handling and automatic backtracking

[0112] (4.1) If a node in the parallel approval process does not return a result for a long time (for example, exceeding the set time limit of 48 hours), the approval service will automatically execute a reminder based on the pre-defined delay strategy and reminder field in the message.

[0113] For example:

[0114] delayPolicy = {"maxWaitHours":48,"escalationNode":"financeDirector"} When a timeout occurs, the approval service automatically publishes a reminder message to the "Message Notification Topic". After receiving the message, the message service sends a reminder notification.

[0115] (4.2) If a node rejects an application (for example, the local change management post rejects the local change application), the result message contains a rollback instruction (rollbackInstruction = {"targetNode":"requestNode","approvalResult":"refuse"}). After receiving the merged result message, the process service returns the process to the change requester (requestNode) node according to the rollback instruction (rollbackInstruction) and prompts the local change management post for rejection information on the user interface. This rollback capability is not necessary in ordinary message transmission, but is unique and has significant practicality in process approval scenarios.

[0116] Step 5: Final processing and archiving

[0117] (5.1) When the process service receives the final merge result message (complianceStatus="conditionalApproval") indicating that the process instance has passed and meets compliance requirements, it pushes the process instance to the subsequent change processing node. After the change processing node is completed, the process service sends a processing confirmation message to the Kafka topic. The approval service then confirms the change result after receiving it.

[0118] (5.2) Finally, when all conditions are met and all parallel nodes have completed their approvals, the Approval Service generates a final approval message with full-link audit fields (including the approval timestamp and digital signature of each node). After receiving this final message, the Process Service archives the approval record for future audits.

[0119] It can be seen from the above embodiments that the technical solution of this application has the following advantages in practical application:

[0120] Decentralization: It does not rely on centralized components such as registration centers, reducing system complexity and maintenance costs.

[0121] Low coupling: Services do not call each other directly, but only need to exchange messages according to a unified data message format, which significantly reduces the coupling between services.

[0122] Lightweight: No need to rely on a specific communication framework, developers only need to ensure that all parties follow the established message format.

[0123] Flexible expansion: Message fields can be easily added or removed, and approval nodes and process logic can be quickly adjusted without making major changes to the infrastructure.

[0124] Accordingly, the embodiments of the present application also provide a computer-readable storage medium having computer-executable instructions stored therein, which implement the various method embodiments of the present application when executed by a processor. Computer-readable storage media include permanent and non-permanent, removable and non-removable media that can implement information storage by any method or technology. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable storage media does not include transient computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0125] In addition, the embodiment of the present application also provides a process approval system based on data messages, which includes a memory for storing computer executable instructions, and a processor; the processor is used to implement the steps in the above-mentioned method implementation methods when executing the computer executable instructions in the memory. Among them, the processor can be a central processing unit (Central Processing Unit, referred to as "CPU"), a graphic processing unit (Graphic Processing Unit, referred to as "GPU"), a digital signal processor (Digital Signal Processor, referred to as "DSP"), a microcontroller unit (Microcontroller Unit, referred to as "MCU"), a neural network processor (referred to as "NPU"), an application specific integrated circuit (Application Specific Integrated Circuit, referred to as "ASIC"), a field programmable gate array (Field Programmable Gate Array, referred to as "FPGA") or other programmable logic devices, etc. The aforementioned memory can be a read-only memory (read-only memory, referred to as "ROM"), a random access memory (random access memory, referred to as "RAM"), a flash memory (Flash), a hard disk or a solid-state drive, etc. The steps of the method disclosed in each embodiment of the present invention can be directly embodied as being executed by a hardware processor, or executed by a combination of hardware and software modules in the processor.

[0126] In addition, an embodiment of the present application further provides a computer program product, which includes computer-executable instructions, and when the computer-executable instructions are executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0127] It should be noted that, in this application, relational terms such as first and second are merely used to distinguish one entity or operation from another, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article, or device. Without further restriction, an element defined by the phrase "comprising a" does not exclude the presence of other identical elements in the process, method, article, or device comprising the element. In this application, if it is mentioned that an action is performed according to a certain element, it means that the action is performed at least according to that element, including two situations: performing the action only according to that element, and performing the action according to that element and other elements. Expressions such as "multiple," "multiple," and "multiple" include 2, 2 times, 2 kinds, and more than 2, more than 2 times, and more than 2 kinds.

[0128] The serial numbers used in describing method steps do not in themselves limit the order of these steps. For example, a step with a higher serial number does not necessarily have to be executed after a step with a lower serial number. The higher serial numbered step may be executed before the lower serial numbered step, or the steps may be executed in parallel, as long as the execution order is reasonable to those skilled in the art.

[0129] This specification includes combinations of the various embodiments described herein. Individual references to embodiments (e.g., "one embodiment" or "some embodiments" or "preferred embodiments") are not mutually exclusive unless indicated as such or clear to one skilled in the art. It should be noted that the word "or" is used in this specification in a non-exclusive sense unless the context clearly indicates or requires otherwise.

[0130] All documents mentioned in this specification are considered to be included in their entirety in the disclosure of this application so that they can be used as a basis for modification when necessary. In addition, it should be understood that the above description is only a preferred embodiment of this specification and is not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of this specification should be included in the scope of protection of one or more embodiments of this specification.

[0131] In some cases, the actions recited in the claims can be performed in a different order and still accomplish the desired result. In addition, the process depicted in the accompanying figures does not necessarily require the particular order shown, or sequential order, to achieve the desired results. In certain implementations, multitasking and parallel processing can be advantageous.

Claims

1. A data message-based service calling method, characterized in that: Kafka cluster acts as a message middleware to implement asynchronous request and response message transmission between services through data packets, where the services do not call each other directly and do not rely on a centralized registration component; The services include process services, approval services, and message services; the method includes: In the process service, a process approval request message is generated according to a predefined data message format including process identification information, approval node information, and approval request parameters, wherein the predefined data message format is independent of the internal implementation of the service, does not rely on centralized components and specific communication frameworks, and the approval process can be extended by adding or modifying fields; the process approval request message is sent to the approval request topic of the Kafka cluster; In the approval service, the process approval request message is received from the approval request topic of the Kafka cluster, parsed and processed according to the approval node information and approval request parameters therein, and an approval message message is generated according to the same predefined data message format, and the approval message message is sent to the message request topic; In the message service, the approval message is received from the message request topic of the Kafka cluster, displayed to the user according to the predefined data message format, and a message approval result message is generated according to the user's approval result. The message approval result message is sent to the message result topic. Then, the approval service processes the message approval result topic and generates an approval return message and sends it to the approval result topic. After receiving the approval result message returned by the approval service, the process service determines the next processing logic of the current process instance according to the approval result field contained in the approval result message; if the approval result field indicates approval, the process instance is advanced to the subsequent approval node or the process instance is terminated; if the approval result field indicates rejection, the process instance is rolled back to the initiator node according to the rejection reason shown in the approval result field, and a notification message containing the rejection reason is generated and sent again to the corresponding topic in the Kafka cluster so that the relevant services can perform corresponding business processing accordingly; When modifying the process approval logic or approval node information, it is only necessary to add, delete or update the fields of the predefined data message format without synchronously adjusting the internal implementations of the services of all parties.

2. The data message-based service calling method according to claim 1, characterized in that: The sender service generates a request message according to a predefined data message format including identification information and consumer service business request parameters, and sends the message to the request topic of the Kafka cluster; Receive the request message from the request topic of the Kafka cluster, parse and process it according to the node information and request parameters, generate a result message according to the same predefined data message format, and send the result message to the result topic of the Kafka cluster; The result message is received from the result topic of the Kafka cluster, the result field is parsed according to the predefined data message format, a return message is generated according to the parsing result, and the return message is sent to the requester.

3. The data message-based service calling method according to claim 1, characterized in that: The approval request topic and the approval result topic are independently configured in the Kafka cluster to achieve classified storage and transmission of process approval request messages and approval result messages; The process approval request message and the approval result message both contain process identification information that can identify a specific process instance, so that the process service can determine the corresponding approval process instance when receiving the return message.

4. The data message-based service calling method according to claim 1, characterized in that: When parsing the process approval request message, the approval service selects a corresponding approval rule template for processing according to the approval node information, and generates the approval result message according to the processing result.

5. The data message-based service calling method according to claim 1, characterized in that: When parsing the approval request message, the message service determines the display format of the message according to the approval request field, and generates a message approval result message according to the result of the user approval and sends it to the approval service in an asynchronous manner.

6. The data message-based service calling method according to claim 1, characterized in that: The Kafka cluster is a distributed cluster structure that performs redundant storage and load balancing on messages to ensure reliability and scalability in high-concurrency and high-data-volume scenarios.

7. A non-transitory computer-readable storage medium, characterized in that The non-transitory computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, implement the steps of the method according to any one of claims 1 to 6.

8. A computer program product comprising computer-executable instructions, characterized in that: When the computer executable instructions are executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images