Workflow data processing method, device, electronic device and storage medium

Abstract

The present application relates to a workflow data processing method, device, electronic device and storage medium, the method comprising: in the case of obtaining request information sent by the caller through the target port, passing the request information to the target workflow corresponding to the request information, blocking the return thread corresponding to the request information, and obtaining the target processing result of the target workflow, after obtaining the target processing result, unblocking the return thread, and at the same time using the unblocked return thread to return the target processing result to the requester corresponding to the request information through the target port. After obtaining the target processing result, unblocking the return thread, and using the return thread to synchronously return the target processing result, so as to achieve the purpose of synchronously returning the corresponding processing result every time the request information is obtained.

Description

Technical Field

[0001] The present application relates to the technical field of workflow control, and in particular to a workflow data processing method, device, electronic device and storage medium. Background Art

[0002] In order to simplify the development process and reduce development costs, the industry uses workflow platforms for development work, such as the serverless workflow platform. In the serverless workflow platform, developers can generate business workflows by dragging and dropping existing components to reduce developers' code writing, improve development efficiency, and improve the quality of development projects.

[0003] However, this convenient workflow platform is mostly suitable for asynchronous scenarios, such as listening to messages and triggering business logic with scheduled tasks. As long as a workflow is requested, regardless of whether the workflow produces results, a successful trigger message will be returned when the workflow is triggered, but the result of the workflow will not be returned. In daily work, we are more exposed to synchronous scenarios, such as the front-end calling the back-end interface, and the back-end interface synchronously returning the call result. However, this workflow platform cannot synchronously return the result of the workflow, which makes it impossible to apply the workflow platform in synchronous scenarios. Summary of the invention

[0004] In order to overcome the problem that the workflow platform existing in the related art cannot be applied in the synchronization scenario, the present application provides a workflow data processing method, device, electronic device and storage medium.

[0005] According to a first aspect of the present application, a workflow data processing method is provided, comprising:

[0006] Acquire request information sent by the caller through the target port, wherein the request information includes a workflow identifier;

[0007] Passing the request information to the target workflow corresponding to the workflow identifier, and blocking the return thread corresponding to the request information;

[0008] Obtaining a target processing result obtained by the target workflow according to the request information;

[0009] The return thread is unblocked, and the target processing result is returned to the requester corresponding to the request information through the target port by using the unblocked return thread.

[0010] In an optional implementation manner, the request information includes:

[0011] An identifier of a trigger request and an identifier of a service corresponding to the trigger request, wherein the identifier of the trigger request is a trigger identifier generated according to a pre-acquired trigger request.

[0012] In an optional implementation, after obtaining the request information sent by the caller through the target port, wherein the request information includes a workflow identifier, the method further includes:

[0013] Generate a lockout program according to a preset lockout generation rule;

[0014] The locking procedure is mapped to an identification of the triggering request.

[0015] In an optional embodiment, the locking procedure includes a blocking instruction;

[0016] The blocking of the return thread corresponding to the trigger request includes:

[0017] Retrieving a target locking program corresponding to the trigger request according to a mapping relationship between the locking program and the trigger request;

[0018] The blocking instruction in the target locking program is used to block the return thread corresponding to the request information.

[0019] In an optional embodiment, the blocking procedure includes an unblocking instruction;

[0020] The unblocking of the return thread comprises:

[0021] After obtaining the target processing result, calling the target locking program corresponding to the trigger request according to the mapping relationship between the locking program and the trigger request;

[0022] The unblocking instruction in the target locking program is called to unblock the return thread corresponding to the request information.

[0023] In an optional implementation, after the request information is transmitted to the target workflow corresponding to the workflow identifier, obtaining the target processing result includes:

[0024] Querying a processing result corresponding to the identifier of the service from a preset transfer event set;

[0025] The processing result corresponding to the trigger request identifier among the processing results obtained by the query is used as the target processing result.

[0026] In an optional implementation, the returning the target processing result to the requester corresponding to the request information through the target port by using the unblocked return thread includes:

[0027] The target processing result is added to the unblocked return thread, so that the unblocked return thread returns the target processing result to the requester corresponding to the request information through the target port.

[0028] According to a second aspect of the present application, a workflow data processing device is provided, the device comprising:

[0029] An acquisition module, used for acquiring request information sent by the caller through the target port, wherein the request information includes a workflow identifier;

[0030] A blocking module, used for passing the request information to a target workflow corresponding to the workflow identifier, and blocking a return thread corresponding to the request information;

[0031] A result acquisition module, used to acquire a target processing result obtained by the target workflow according to the request information;

[0032] The result returning module is used to unblock the return thread, and use the unblocked return thread to return the target processing result to the requester corresponding to the request information through the target port.

[0033] In an optional implementation manner, the request information includes:

[0034] The identifier of the trigger request and the identifier of the service corresponding to the trigger request.

[0035] In an optional embodiment, the device further comprises:

[0036] A generation module, used to generate a locking program according to a preset locking generation rule;

[0037] A mapping module is used to map the locking procedure with the identifier of the trigger request.

[0038] In an optional embodiment, the locking procedure includes a blocking instruction;

[0039] The blocking module comprises:

[0040] A first calling unit, configured to call a target locking program corresponding to the trigger request according to a mapping relationship between the locking program and the trigger request;

[0041] The blocking unit is used to block the return thread corresponding to the request information by using the blocking instruction in the target locking program.

[0042] In an optional embodiment, the blocking procedure includes an unblocking instruction;

[0043] The result returning module comprises:

[0044] A second calling unit, configured to call a target locking program corresponding to the trigger request according to a mapping relationship between the locking program and the trigger request;

[0045] The unblocking unit is used to call the unblocking instruction in the target locking program to unblock the return thread corresponding to the request information.

[0046] In an optional embodiment, the blocking module further includes:

[0047] A query unit, used to query a processing result corresponding to the identifier of the service from a preset transfer event set;

[0048] The result determination unit is used to use the processing result corresponding to the trigger request identifier among the processing results obtained by the query as the target processing result obtained by the target workflow according to the request information.

[0049] In an optional implementation, the result returning module includes:

[0050] The return unit is used to add the target processing result to the unblocked return thread, so that the unblocked return thread returns the target processing result to the requester corresponding to the request information through the target port.

[0051] According to a third aspect of the present application, there is provided an electronic device, comprising: at least one processor and a memory;

[0052] The processor is used to execute the workflow data processing program stored in the memory to implement the workflow data processing method described in the first aspect of the present application.

[0053] According to a fourth aspect of the present application, a storage medium is provided, wherein the storage medium stores one or more programs, and when the one or more programs are executed, the workflow data processing method described in the first aspect of the present application is implemented.

[0054] The technical solution provided by the present application may include the following beneficial effects: when the request information sent by the caller through the target port is obtained, the request information is passed to the target workflow corresponding to the request information, the return thread corresponding to the request information is blocked, and the target processing result obtained by the target workflow according to the request information is obtained. After obtaining the target processing result, the return thread is unblocked, and the target processing result is returned to the requester corresponding to the request information through the target port by using the return thread after unblocking. Based on this, by blocking the return thread of the request information, it is possible to avoid the current asynchronous workflow directly returning useless information such as the workflow trigger success after the return thread obtains the request information. After obtaining the target processing result, the present application unblocks the return thread and uses the return thread to synchronously return the target processing result, so as to achieve the purpose of synchronously returning the corresponding processing result every time the request information is obtained.

[0055] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0057] Figure 1 It is a workflow data processing signaling diagram provided;

[0058] Figure 2 is a flowchart of a workflow data processing method provided by another embodiment of the present application;

[0059] Figure 3 It is a flowchart of obtaining a target processing result provided by an embodiment of the present application;

[0060] Figure 4 is a structural schematic diagram of a workflow data processing device provided by another embodiment of the present application;

[0061] Figure 5 It is a structural schematic diagram of an electronic device provided in another embodiment of the present application. DETAILED DESCRIPTION

[0062] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0063] See also Figure 1 , Figure 1 It is a workflow data processing signaling diagram provided.

[0064] like Figure 1 As shown, the present application sets up a transit architecture between the caller and the workflow platform (serverless flow), namely, a gateway, a public service, a knative broker, and a trigger.

[0065] When the caller needs to trigger the target workflow, the caller will send a request, which will correspond to a target workflow in the workflow platform. The caller sends the request to the public service through the gateway (Internet gateway), where each public service corresponds to a network IP. After receiving the request, the public service will set an ID for the request, and adapt the request ID and the IP of the public service to CloudEvent, then generate a lock to block the return thread of the request, and map the lock with the request ID, store the mapping relationship between the two, and finally send the adapted CloudEvent to the Knative broker, where CloudEvent is a pre-set event that triggers the target workflow corresponding to the request.

[0066] After receiving the CloudEvent, the Knative Broker triggers the target workflow in the workflow platform, receives the result returned by the target workflow, and forwards the result to the pre-deployed trigger. The trigger filters out the result of the input public service according to its internal filtering conditions, and then the public service finds the lock with the mapping relationship between the request ID and the lock corresponding to the result from the stored mapping relationship between the request ID and the lock. Since the found lock blocks the return thread of the request, the return thread can be unblocked at this time, and the result can be returned to the caller using the unblocked return thread. From then on, the caller can achieve the purpose of issuing a request and returning a result synchronously.

[0067] about Figure 1 The specific method steps are described below in the form of embodiments.

[0068] See also Figure 2 , Figure 2 It is a flowchart of a workflow data processing method provided by another embodiment of the present application.

[0069] like Figure 2 As shown, the workflow data processing method provided in this embodiment may include:

[0070] Step S201: Acquire request information sent by the caller through the target port, where the request information includes a workflow identifier.

[0071] In this step, the request information may include a workflow identifier, a trigger request identifier, and an identifier of a service corresponding to the trigger request. Generally, a workflow platform may have multiple workflows. When a caller needs to call a workflow, it will send a trigger request to the workflow platform, wherein the trigger request includes a workflow identifier. In this embodiment, the service (such as Figure 1 The public service shown in the figure) receives the trigger request sent by the caller, and then the service parses the workflow identifier contained in the trigger request.

[0072] The caller is Figure 1 The caller shown, the target port is the port for communication between the caller and the brokering infrastructure.

[0073] It should be noted that the service is a pre-built public service. After receiving the trigger request sent by the caller, the service can use a random string generation tool to generate a universal unique identifier, and use the universal unique identifier as the identifier (id) of the trigger request received by the service. The random string generation tool can be UUIDUtils, and the universal unique identifier can be the UUID born by UUIDUtils.

[0074] In addition, the service identifier can be the IP of the server that deploys the service in the network, or it can be a unique identification code pre-defined for each service. It should be noted that there is more than one service in the network, and there can be multiple services. When sending a trigger request to a public service, you can first find the most idle service from all services, and send the trigger request to the relatively idle service for subsequent processing.

[0075] Specifically, since in each service, a corresponding locking program will be mapped for any trigger request to block the return thread of the trigger request, the idleness of the service can be judged by comparing the number of valid locking programs in the service (i.e., the locking programs that are effectively blocking the return thread). The smaller the number, the more idle the service is.

[0076] Alternatively, the idleness of the service may be determined by comparing the number of unprocessed trigger requests (ie, trigger requests that are not mapped to a locking program) in the service. The fewer the unprocessed trigger requests, the more idle the service is.

[0077] It should be noted that the relevant contents of the locking procedure will be described in detail in the following steps and will not be repeated here.

[0078] Step S202: trigger the target workflow corresponding to the workflow identifier according to the request information, and block the return thread corresponding to the request information.

[0079] Since there are multiple workflows in the workflow platform, and transit architectures such as public services, knativebroker and trigger are added in this application, these transit structures need to trigger the target workflow corresponding to the workflow identifier in the workflow platform according to the workflow identifier in the trigger request. Generally, as long as the workflow identifier can be forwarded to the workflow platform, the target workflow corresponding to the workflow identifier can be triggered.

[0080] Specifically, based on the above-mentioned transit architecture, the present application proposes a solution for forwarding in the form of cloudevent. In this embodiment, an event filter can be set in advance for each workflow in the workflow platform, such as defining a trigger (where the filter condition is defined as the identifier of the corresponding workflow), and then after receiving the trigger request, the service encapsulates the trigger request id, the server IP and the workflow identifier in the request information obtained in step S201 in the form of cloudevent to obtain the cloudevent event, and then sends the cloudevent event to the knativebroker, which forwards the cloudevent event to all pre-set event filters. Only the event filter that is consistent with the workflow identifier in the cloudevent event triggers the corresponding workflow in the workflow platform, that is, the target workflow corresponding to the workflow identifier in the cloudevent event.

[0081] In addition, in this step, in order to block the return thread corresponding to the request information, a latching program, such as countdownlatch, can be used. Since this latching program is a counter, one thread is recorded when it is completed, and the counter is decremented. Therefore, a latching program can only be used once. For this reason, after obtaining the request information, this embodiment can generate a latching program according to the preset latching generation rule, and map the latching program with the identifier of the triggering request in the request information.

[0082] Specifically, taking countdownlatch as an example, there are two key program instructions in the locking program, one is countdownlatch.await, which is a blocking instruction, and the other is countdown, which is a counter decrement instruction. Since the thread that this embodiment needs to deal with is to obtain the target processing result of the target workflow, the count value in the locking program can be set to "1", and accordingly, countdown will be decremented by "1" each time it is executed. Therefore, in this embodiment, countdown is an unblocking instruction. Then, when generating the locking program, the return thread corresponding to the request information (that is, the return thread corresponding to the trigger request corresponding to the request information) can be mapped to countdownlatch.await, and the thread that obtains the target processing result of the target workflow can be mapped to countdown, so that the locking program corresponding to the request information can be generated.

[0083] Of course, it can also be other programs that can block threads and unblock threads after a certain event occurs, such as CyclicBarrier.

[0084] In addition, when mapping the request information with the locking program, the id of the triggering request in the request information can be used as the key of the key-value pair and the locking program can be used as the value of the key-value pair through a map method. In this way, the corresponding locking program can be found through the id of the triggering request.

[0085] In a specific example, the mapping relationship between the trigger request ID and the locking program can be shown in Table 1.

[0086] The id of the triggering request Lockout Procedure a Lockout Procedure A b Lockout Procedure B c Lockout Procedure C d Lockout Procedure D …… ……

[0087] Table 1

[0088] Specifically, when blocking the return thread corresponding to the request information, the target blocking program corresponding to the request information can be first called according to the mapping relationship between the blocking program and the request information, and then the blocking instruction in the target blocking program is used to block the return thread corresponding to the request information. Since the return thread corresponding to the request information has been mapped to the blocking instruction in the target blocking program, when the blocking instruction in the target blocking program is used to block the return thread corresponding to the request information, the blocking instruction of the target blocking program can be directly called and run.

[0089] In a specific example, if the id of the trigger request in the request information is c, then according to the mapping relationship in Table 1, the corresponding target blocking program can be obtained as blocking program C. After triggering the target workflow according to the above steps, calling the blocking instruction in blocking program C can block the return thread corresponding to the trigger request c.

[0090] Step S203: Obtain the target processing result obtained by the target workflow according to the request information.

[0091] In this step, the specific acquisition process can be Figure 1 The knative broker and trigger in the command are used to complete the task. For details, please refer to Figure 3 , Figure 3 It is a flowchart of obtaining a target processing result provided by an embodiment of the present application.

[0092] like Figure 3 As shown, the process of obtaining the target processing result provided by this embodiment may include:

[0093] Step S301: query the processing result corresponding to the service identifier from the preset transfer event set.

[0094] The transit event set in this step can be located in the knative broker. The transit event set includes all processing results fed back from the workflow platform. It should be noted that in addition to the processing result content of the workflow, the processing result also includes information such as the trigger request id and service ip in the cloudevent that triggers the workflow.

[0095] The specific query can be implemented through a predefined trigger, where the filtering condition in the trigger is the service IP. It should be noted that if there is more than one service in this embodiment, a trigger will be defined for each service, and for any of the services, the filtering condition in the corresponding trigger is the IP of the service.

[0096] In this step, the processing results in the transfer event set will be input into the trigger, and the processing results that are consistent with the filtering conditions in the trigger will be filtered out and fed back to the corresponding service.

[0097] In a specific example, the processing result of the transfer event set can be shown in Table 2.

[0098] Processing results The id of the triggering request Service IP Result 1 a mxD Result 2 b mxD Result 3 f mppn Result 4 g mppn …… …… ……

[0099] Table 2

[0100] For example, if the filter condition in trigger_A is "mnpq", then trigger_A will send results 1 and 2 to the service with the IP address "mnpq".

[0101] Step S302: The processing result corresponding to the identifier of the trigger request among the processing results obtained by the query is used as the target processing result obtained by the target workflow according to the request information.

[0102] Since the processing result obtained by the query in step S301 includes the identifier of the trigger request, the target processing result of the target workflow can be determined based on the mapping relationship between the identifier of the trigger request and the workflow identifier. It should be noted that the mapping relationship between the identifier of the trigger request and the workflow identifier can be obtained from the request information in step S201. A request information includes the identifier of the trigger request, the workflow identifier and the IP of the service. Then the identifier of the trigger request and the workflow identifier in the same request information have a mutual mapping relationship.

[0103] In a specific example, taking trigger request a as an example, the processing result with the identifier a containing the trigger request is result 1, and therefore, result 1 is the target processing result of the target workflow corresponding to trigger request a.

[0104] Step S204: unblock the return thread, and use the unblocked return thread to return the target processing result to the requester corresponding to the request information through the target port.

[0105] In this step, when contacting the blocking of the return thread, since there may be multiple return threads in a service, corresponding to multiple locking programs, in order to find the return thread of the trigger request corresponding to the target processing result, since the locking program and the trigger request identifiers have been mapped in the aforementioned process, and the target processing result includes the trigger request identifier, therefore, the target locking program corresponding to the trigger request can be called according to the mapping relationship between the locking program and the trigger request. The return thread blocked by the target locking program is the thread that can return the target processing result to the corresponding caller. At this time, the unblocking instruction in the target locking program can be called to unblock the return thread corresponding to the request information.

[0106] In a specific example, still taking trigger request a as an example, step S302 has obtained the target processing result of the target workflow corresponding to trigger request a, that is, result 1. Then according to Table 1, it can be known that the locking program A is the locking program corresponding to trigger request a. At this time, directly calling the countdown instruction in locking program A can release the return thread mapped by countdownlatch.await, and this return thread is the return thread corresponding to trigger request a (that is, the return thread corresponding to the request information containing trigger request a).

[0107] When using the unblocked return thread to feedback the target processing result, the target processing result can be added to the unblocked return thread. The specific way of adding can be to convert the target processing result into a preset data format and then add it to the preset position of the data stream of the return thread.

[0108] In this embodiment, when the request information is obtained, the request information is passed to the target workflow corresponding to the request information, the return thread corresponding to the request information is blocked, and the target processing result obtained by the target workflow according to the request information is obtained. After the target processing result is obtained, the blockage of the return thread is unblocked, and the target processing result is synchronously returned to the requester corresponding to the request information by using the return thread after unblocking. Based on this, by blocking the return thread of the request information, it is possible to avoid the current asynchronous workflow directly returning useless information such as the successful triggering of the workflow after the request information is obtained. After obtaining the target processing result, the present application unblocks the return thread and uses the return thread to synchronously return the target processing result, so as to achieve the purpose of synchronously returning the corresponding processing result every time the request information is obtained.

[0109] See also Figure 4 , Figure 4 It is a structural diagram of a workflow data processing device provided by another embodiment of the present application.

[0110] like Figure 4 As shown, the workflow data processing device provided in this embodiment may include:

[0111] The acquisition module 401 is used to acquire the request information sent by the caller through the target port, wherein the request information includes a workflow identifier;

[0112] The blocking module 402 is used to trigger the target workflow corresponding to the workflow identifier according to the request information, and block the return thread corresponding to the request information;

[0113] The result acquisition module 403 is used to acquire the target processing result obtained by the target workflow according to the request information;

[0114] The result returning module 404 is used to unblock the return thread, and use the unblocked return thread to return the target processing result to the requester corresponding to the request information through the target port.

[0115] In this embodiment, when the acquisition module 401 obtains the request information, the blocking module 402 passes the request information to the target workflow corresponding to the request information, blocks the return thread corresponding to the request information, and the result acquisition module 403 obtains the target processing result obtained by the target workflow according to the request information. After obtaining the target processing result, the result return module 404 unblocks the return thread, and uses the return thread after unblocking to synchronously return the target processing result to the requester corresponding to the request information. Based on this, by blocking the return thread of the request information, it is possible to avoid the current asynchronous workflow returning useless information such as the return thread directly returning the successful triggering of the workflow after obtaining the request information. After obtaining the target processing result, the present application unblocks the return thread and uses the return thread to synchronously return the target processing result, so as to achieve the purpose of synchronously returning the corresponding processing result every time the request information is obtained.

[0116] In an optional implementation, the request information includes:

[0117] The identifier of the trigger request and the identifier of the service corresponding to the trigger request.

[0118] In an optional embodiment, the device further comprises:

[0119] A generation module, used to generate a locking program according to a preset locking generation rule;

[0120] A mapping module is used to map the locking program with the identifier of the triggering request.

[0121] In an optional embodiment, the locking procedure includes a blocking instruction;

[0122] The blocking modules include:

[0123] A first calling unit, configured to call a target locking program corresponding to the trigger request according to a mapping relationship between the locking program and the trigger request;

[0124] The blocking unit is used to block the return thread corresponding to the request information by using the blocking instruction in the target locking program.

[0125] In an optional embodiment, the blocking procedure includes an unblocking instruction;

[0126] The result return module includes:

[0127] A second calling unit, configured to call a target locking program corresponding to the trigger request according to a mapping relationship between the locking program and the trigger request;

[0128] The unblocking unit is used to call the unblocking instruction in the target locking program to unblock the return thread corresponding to the request information.

[0129] In an optional embodiment, the blocking module further includes:

[0130] A query unit, used to query a processing result corresponding to the service identifier from a preset transfer event set;

[0131] The result determination unit is used to use the processing result corresponding to the trigger request identifier among the processing results obtained by the query as the target processing result obtained by the target workflow according to the request information.

[0132] In an optional implementation, the result returning module includes:

[0133] The return unit is used to add the target processing result to the unblocked return thread, so that the unblocked return thread returns the target processing result to the requester corresponding to the request information through the target port.

[0134] See also Figure 5 , Figure 5 It is a structural schematic diagram of an electronic device provided in another embodiment of the present application.

[0135] like Figure 5 As shown, the electronic device provided in this embodiment includes: at least one processor 501, a memory 502, at least one network interface 503 and other user interfaces 504. The various components in the electronic device 500 are coupled together through a bus system 505. It can be understood that the bus system 505 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 505 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Figure 5 Various buses are labeled as bus system 505 .

[0136] The user interface 504 may include a display, a keyboard, or a pointing device (eg, a mouse, a trackball, a touch pad, or a touch screen).

[0137] It can be understood that the memory 502 in the embodiment of the present invention can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM) and direct RAM bus random access memory (DRRAM). The memory 502 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0138] In some implementations, the memory 502 stores the following elements, executable units or data structures, or a subset thereof, or an extended set thereof: an operating system 5021 and an application program 5022 .

[0139] The operating system 5021 includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., which are used to implement various basic services and process hardware-based tasks. The application 5022 includes various application programs, such as a media player (Media Player), a browser (Browser), etc., which are used to implement various application services. The program for implementing the method of the embodiment of the present invention can be included in the application 5022.

[0140] In the embodiment of the present invention, by calling the program or instruction stored in the memory 502, specifically, the program or instruction stored in the application 5022, the processor 501 is used to execute the method steps provided by each method embodiment.

[0141] The method disclosed in the above embodiment of the present invention can be applied to the processor 501, or implemented by the processor 501. The processor 501 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit in the processor 501 or the instruction in the form of software. The above processor 501 can be a general processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a field programmable gate array (Field Programmable Gate Array, FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present invention can be implemented or executed. The general processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the embodiment of the present invention can be directly embodied as a hardware decoding processor to execute, or the hardware and software units in the decoding processor can be executed. The software unit can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 502, and the processor 501 reads the information in the memory 502 and completes the steps of the above method in combination with its hardware.

[0142] It is understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPDevice, DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), general purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions of the present application, or a combination thereof.

[0143] For software implementation, the technology of this article can be implemented by a unit that performs the functions of this article. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

[0144] The embodiment of the present invention also provides a storage medium (computer-readable storage medium). The storage medium here stores one or more programs. The storage medium may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a read-only memory, a flash memory, a hard disk or a solid-state drive; the memory may also include a combination of the above-mentioned types of memory.

[0145] When one or more programs in the storage medium can be executed by one or more processors, the workflow data processing method executed on the electronic device side can be implemented.

[0146] The processor is used to execute the workflow data processing program stored in the memory to implement the workflow data processing method provided by the aforementioned method embodiment executed on the electronic device side.

[0147] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0148] It can be understood that the same or similar parts of the above embodiments can be referenced to each other, and the contents not described in detail in some embodiments can refer to the same or similar contents in other embodiments.

[0149] It should be noted that, in the description of this application, the terms "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying relative importance. In addition, in the description of this application, unless otherwise specified, the meaning of "plurality" refers to at least two.

[0150] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code that includes one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0151] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0152] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0153] In addition, each functional unit in each embodiment of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0154] The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.

[0155] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0156] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A workflow data processing method, characterized in that: include: Acquire request information sent by the caller through the target port, wherein the request information includes a workflow identifier; triggering a target workflow corresponding to the workflow identifier according to the request information, and blocking a return thread corresponding to the request information; Obtaining a target processing result obtained by the target workflow according to the request information; Unblocking the return thread, and using the unblocked return thread to return the target processing result to the requester corresponding to the request information through the target port; The request information also includes: The identifier of the trigger request and the identifier of the service corresponding to the trigger request; The obtaining of the target processing result obtained by the target workflow according to the request information includes: Querying a processing result corresponding to the identifier of the service from a preset transfer event set; The processing result corresponding to the identifier of the trigger request among the processing results obtained by the query is used as the target processing result obtained by the target workflow according to the request information; The preset transfer event set inputs the processing result into the preset event filter, and the preset event filter filters out the processing results consistent with its screening conditions to obtain the target processing result.

2. The method according to claim 1, characterized in that After obtaining the request information sent by the caller through the target port, wherein the request information includes a workflow identifier, the method further includes: Generate a lockout program according to a preset lockout generation rule; The locking procedure is mapped to an identification of the triggering request.

3. The method according to claim 2, characterized in that The locking procedure includes a blocking instruction; The blocking of the return thread corresponding to the request information includes: Retrieving a target locking program corresponding to the trigger request according to a mapping relationship between the locking program and the trigger request; The blocking instruction in the target locking program is used to block the return thread corresponding to the request information.

4. The method according to claim 2 or 3, characterized in that: The blocking procedure includes an unblocking instruction; The unblocking of the return thread comprises: Retrieving a target locking program corresponding to the trigger request according to a mapping relationship between the locking program and the trigger request; The unblocking instruction in the target locking program is called to unblock the return thread corresponding to the request information.

5. The method according to claim 1, characterized in that The step of returning the target processing result to the requesting party corresponding to the request information through the target port by using the unblocked return thread includes: The target processing result is added to the unblocked return thread, so that the unblocked return thread returns the target processing result to the requester corresponding to the request information through the target port.

6. A workflow data processing device, characterized in that: The device comprises: An acquisition module, used for acquiring request information sent by the caller through the target port, wherein the request information includes a workflow identifier; A blocking module, used to trigger the target workflow corresponding to the workflow identifier according to the request information, and block the return thread corresponding to the request information; A result acquisition module, used to acquire a target processing result obtained by the target workflow according to the request information; A result returning module, used for unblocking the return thread, and using the unblocked return thread to return the target processing result to the requester corresponding to the request information through the target port; The request information also includes: The identifier of the trigger request and the identifier of the service corresponding to the trigger request; The obtaining of the target processing result obtained by the target workflow according to the request information includes: Querying a processing result corresponding to the identifier of the service from a preset transfer event set; The processing result corresponding to the identifier of the trigger request among the processing results obtained by the query is used as the target processing result obtained by the target workflow according to the request information; The preset transfer event set inputs the processing result into the preset event filter, and the preset event filter filters out the processing results consistent with its screening conditions to obtain the target processing result.

7. An electronic device, characterized in that: include: at least one processor and memory; The processor is used to execute the workflow data processing program stored in the memory to implement the workflow data processing method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that: The storage medium stores one or more programs, and when the one or more programs are executed, the workflow data processing method according to any one of claims 1 to 5 is implemented.

Images