CN113282444A

CN113282444A - Visualization method and device for business process debugging

Info

Publication number: CN113282444A
Application number: CN202010104780.XA
Authority: CN
Inventors: 张鸣亮
Original assignee: Beijing Jingdong Zhenshi Information Technology Co Ltd
Current assignee: Beijing Jingdong Zhenshi Information Technology Co Ltd
Priority date: 2020-02-20
Filing date: 2020-02-20
Publication date: 2021-08-20
Anticipated expiration: 2040-02-20
Also published as: CN113282444B

Abstract

The invention discloses a visualization method and a visualization device for business process debugging, and relates to the technical field of computers. The method comprises the following steps: responding to the triggering operation of a user, creating a main debugger, and sending debugging configuration information of a service flow to a debugging engine based on the main debugger; receiving a message returned by the debugging engine in the process of debugging the business process; after the message is determined to be the first message for indicating that the parallel node is started to be executed, drawing a thread calling tree in a first area of the page and displaying the thread calling tree, and drawing and displaying a plurality of sub-flow charts nested in the same label page in a second area of the page according to the identification of the parallel node and information of a plurality of threads for executing the parallel node. Through the steps, the problems that thread management is not clear, a parent flow cannot be positioned when a sub-flow is executed in a multi-thread mode and the like in the prior art can be solved, and therefore developers can debug the service flow quickly and conveniently.

Description

Visualization method and device for business process debugging

Technical Field

The invention relates to the technical field of computers, in particular to a visualization method and a visualization device for business process debugging.

Background

The service flow is a directed graph which is composed of a starting node and a series of service function nodes and meets specific service scenes, and the directed graph comprises the transmission of data streams and describes the conversion of data or states of specific services from the beginning to the end. Other service flows are supported and called in the service flow, so that a complex service scene is conveniently split into a plurality of small service flows, and the service flows are conveniently multiplexed.

Before the service is on-line, the service flow is often locally tested in an early stage to detect whether the service flow meets the service requirement, whether the data conversion meets the expectation, and the like. In this process, the debugging function provided by the business process debugging system is particularly important. The debugging function can support a user to track the execution process of the business process, check data changes before and after a certain node in the execution business process, help the user to quickly locate problems when a test result is not in accordance with expectation, and the like.

Generally, the execution of business processes is unidirectional, that is, one thread executes one process. However, some service scenarios require parallel processing of one flow, and then merge the parallel processing results and continue to execute subsequent flows. In this case, debugging of the multi-threaded flow is involved. Most of current service flow debugging systems support multi-thread debugging, and when a plurality of threads execute nodes in parallel in the same service flow, most of the debugging systems show the currently running threads in a flat display mode in a thread stack area, and provide functions of thread switching and thread-based variable display and modification.

In the process of implementing the invention, the inventor finds that the existing business process debugging system at least has the following problems during visualization: first, thread management is unclear. Specifically, when multiple threads are debugged, all threads are displayed in the level of the thread stack area, and the call relationship among the threads cannot be known conveniently. Second, when a child flow is executed in parallel based on multiple threads, its parent flow cannot be located. Specifically, after the flow is started, a flow chart is opened for displaying the execution process of the flow; when the sub-process calling node is executed, the flow chart of the called sub-process is opened again so as to display the execution process of the sub-process; when the sub-flow calling node is in a parallel mode, a plurality of same sub-flow charts are opened at the same time. Furthermore, when the current debugging is suspended in a certain sub-flow, it cannot be determined which flow the sub-flow is called by, which brings great inconvenience to the debugging work of the business flow.

Disclosure of Invention

In view of the above, the invention provides a visualization method and a visualization device for business process debugging, which can solve the problems that the existing visualization method for business process debugging has unclear thread management, cannot locate the parent process when a sub-process is executed in a multi-thread manner, and the like, and thus, developers can quickly and conveniently debug the business process.

To achieve the above object, according to one aspect of the present invention, a visualization method for debugging a business process is provided.

The visualization method for debugging the user business process comprises the following steps: responding to the triggering operation of a user, creating a main debugger, and sending debugging configuration information of a service flow to a debugging engine based on the main debugger so that the debugging engine carries out service flow debugging according to the debugging configuration information; receiving a message returned by the debugging engine in the process of debugging the business process; after the message is determined to be a first message, drawing a thread calling tree in a first area on a page and displaying the tree, and drawing and displaying a plurality of sub-flow charts nested in the same label page in a second area on the page according to the identification of the parallel node and the information of a plurality of threads for executing the parallel node; wherein the first message is used to indicate that parallel nodes are started to execute.

Optionally, the step of drawing a thread in a first region on the page to call the tree and display includes: after receiving a second message returned by the debugging engine, creating a plurality of sub debuggers of the current debugger according to the second message, and adding the information of the sub debuggers into a sub debugger list of the current debugger; the second message is used for indicating that a plurality of threads for executing the parallel node are started, and the plurality of sub-debuggers are in one-to-one correspondence with the plurality of threads for executing the parallel node; then, a thread call tree is drawn in a first area on the page according to the sub debugger list of the current debugger and displayed.

Optionally, the step of drawing and displaying a plurality of sub-flowcharts nested in the same tab page in a second area on the page according to the identifier of the parallel node and information of a plurality of threads for executing the parallel node includes: and creating a label page named by the parallel node in a second area of the page according to the identifier of the parallel node carried by the first message, and then drawing and displaying a plurality of sub-flow charts in the label page according to the information of a plurality of threads used for executing the parallel node carried by the second message.

Optionally, the method further comprises: after a third message returned by the debugging engine is received, closing the plurality of sub-debuggers according to the third message, deleting the information of the plurality of sub-debuggers from a sub-debugger list of the current debugger, and updating the thread calling tree and the plurality of sub-flow charts nested in the same label page; wherein the third message is used to indicate that the parallel node execution is finished.

Optionally, the method further comprises: after the message is determined to be a fourth message, determining a corresponding graph of the non-parallel node in the flow chart according to the flow identification and the non-parallel node identification carried by the fourth message, and rendering the corresponding graph into a state to be executed; after receiving a fifth message, determining a corresponding graph of the non-parallel node in the flow chart to which the non-parallel node belongs according to the flow identifier and the non-parallel node identifier carried by the fifth message, and then rendering the corresponding graph into an execution completion state; the fourth message is used for indicating the start of executing the non-parallel node, and the fifth message is used for indicating the end of executing the non-parallel node.

To achieve the above object, according to another aspect of the present invention, a visualization apparatus for debugging a business process is provided.

The visualization device for debugging the business process comprises the following components: the system comprises a creating module, a debugging engine and a debugging module, wherein the creating module is used for creating a main debugger in response to the triggering operation of a user and sending debugging configuration information of a service flow to the debugging engine based on the main debugger so that the debugging engine carries out service flow debugging according to the debugging configuration information; the receiving module is used for receiving a message returned by the debugging engine in the process of debugging the business process; the drawing module is used for drawing a thread calling tree in a first area on a page and displaying the thread calling tree after the message is determined to be the first message, and drawing and displaying a plurality of sub-flow charts nested in the same label page in a second area on the page according to the identification of the parallel node and the information of a plurality of threads for executing the parallel node; wherein the first message is used to indicate that parallel nodes are started to execute.

Optionally, the drawing module draws a thread call tree in a first region on the page and displays the thread call tree, including: after receiving a second message returned by the debugging engine, creating a plurality of sub debuggers of the current debugger according to the second message, and adding the information of the sub debuggers into a sub debugger list of the current debugger; the second message is used for indicating that a plurality of threads for executing the parallel node are started, and the plurality of sub-debuggers are in one-to-one correspondence with the plurality of threads for executing the parallel node; then, a thread call tree is drawn in a first area on the page according to the sub debugger list of the current debugger and displayed.

Optionally, the drawing module, according to the identifier of the parallel node and information of a plurality of threads for executing the parallel node, draws and displays a plurality of sub-flowcharts nested in the same tab page in a second area on the page, including: and the drawing module creates a label page named by the parallel node in a second area of the page according to the identifier of the parallel node carried by the first message, and then draws and displays a plurality of sub-flow charts in the label page according to the information which is carried by the second message and is used for executing a plurality of threads of the parallel node.

To achieve the above object, according to still another aspect of the present invention, there is provided an electronic apparatus.

The electronic device of the present invention includes: one or more processors; and storage means for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the visualization method for business process debugging of the present invention.

To achieve the above object, according to still another aspect of the present invention, there is provided a computer-readable medium.

The computer-readable medium of the invention has stored thereon a computer program which, when executed by a processor, implements the visualization method for business process debugging of the invention.

One embodiment of the above invention has the following advantages or benefits: the method comprises the steps of establishing a main debugger in response to a triggering operation of a user, sending debugging configuration information of a business process to a debugging engine based on the main debugger, drawing a thread call tree in a first area of a page and displaying the thread call tree after receiving a message returned by the debugging engine in the process of debugging the business process as a first message for indicating that parallel nodes are started to be executed, drawing a plurality of sub-process graphs nested in the same label page in a second area of the page and displaying the sub-process graphs according to identification of the parallel nodes and information of a plurality of threads for executing the parallel nodes, and can solve the problems that thread management is unclear, a parent process of the sub-process cannot be positioned in the process of executing the sub-process in a multi-thread mode and the like in the prior art, so that developers can quickly and conveniently debug the business process.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

fig. 1 is a main flow diagram of a visualization method for business process debugging according to a first embodiment of the present invention;

FIG. 2 is a flow chart diagram of a visualization method for business process debugging according to a second embodiment of the present invention;

FIG. 3 is a flow chart diagram of a visualization method for business process debugging according to a third embodiment of the present invention;

FIG. 4a is a first schematic diagram of a visualization interface in a business process debugging process according to a third embodiment of the present invention;

FIG. 4b is a second schematic diagram of a visual interface in a business process debugging process according to the third embodiment of the present invention;

FIG. 4c is a third schematic diagram of a visual interface in a business process debugging process according to the third embodiment of the present invention;

FIG. 4d is a fourth schematic diagram of a visual interface in the process of debugging the business process according to the third embodiment of the present invention;

FIG. 4e is a fifth schematic view of a visual interface in a business process debugging process according to the third embodiment of the present invention;

FIG. 5 is a schematic diagram of the main modules of a visualization apparatus for debugging a business process according to a fourth embodiment of the present invention;

FIG. 6 is a schematic diagram of the main modules of a visualization system for business process debugging according to a fifth embodiment of the present invention;

FIG. 7 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;

FIG. 8 is a schematic block diagram of a computer system suitable for use with the electronic device to implement an embodiment of the invention.

Detailed Description

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

It should be noted that the embodiments and features of the embodiments may be combined with each other without conflict.

Fig. 1 is a main flow diagram of a visualization method for business process debugging according to a first embodiment of the present invention. The method of the embodiment of the invention can be executed by a visualization device (or called a debugging GUI) for debugging the business process. As shown in fig. 1, a visualization method for business process debugging according to an embodiment of the present invention includes:

step S101, responding to the triggering operation of a user, creating a main debugger, and sending debugging configuration information of a service flow to a debugging engine based on the main debugger so that the debugging engine can debug the service flow according to the debugging configuration information.

Illustratively, the user's trigger operation may be: the user selects a business process on the software interface and then clicks the "start debug" button. In response to a trigger operation by the user, execution of step S101 is started.

In step S101, after creating the master debugger, the debugging GUI may send debugging configuration information to the debugging engine based on the master debugger. The debugging configuration information may include information such as an operation flow identifier, contents of a flow file, a breakpoint set by a user, and positions of some dependent files used in the flow.

After receiving the debugging configuration information, the debugging engine can carry out debugging initialization work according to the debugging configuration information. The debugging initialization is mainly used for establishing a debugging environment of the debugging. After the debugging initialization work is completed, the debugging engine prepares to execute the business process and feeds back a message to the debugging GUI in the process of executing the business process.

And step S102, receiving a message returned by the debugging engine in the process of debugging the business process.

Illustratively, the message may be a first message for indicating that parallel node execution is started, a fourth message for indicating that non-parallel node execution is started, or other messages returned by the debug engine. In a business process, there are parallel nodes (alternatively referred to as "parallel call sub-process nodes") and non-parallel nodes. Parallel nodes refer to nodes executed by a plurality of threads, and non-parallel nodes refer to nodes executed by a single thread.

Step S103, after the message is determined to be the first message, drawing a thread calling tree in a first area on the page and displaying the thread calling tree, and drawing and displaying a plurality of sub-flow charts nested in the same label page in a second area on the page according to the identification of the parallel node and the information of a plurality of threads for executing the parallel node.

Wherein the first message is used to indicate that parallel nodes are started to execute. In specific implementation, when the debug engine executes to the parallel node, a first message may be sent to the debug GUI, where the first message includes information such as a flow identifier and a parallel node identifier. After the first message is received by the debugging GUI, a thread calling tree can be drawn in a first area (or called a thread stack area) on a page, and the calling relationship among multiple threads in the service flow debugging process is clearly shown in a tree structure. And the debugging GUI can draw and display a plurality of sub-flowcharts nested in the same label page in a second area on the page according to the identification of the parallel node and the information of a plurality of threads for executing the parallel node. By nesting a plurality of sub-flow charts corresponding to parallel nodes in the same label page, the quick positioning to the parent flow of the sub-flow charts is facilitated.

In the embodiment of the invention, the problems that the thread management is not clear, the parent flow cannot be positioned when the sub-flow is executed in a multi-thread mode and the like in the prior art are solved through the steps, and therefore, developers can debug the service flow quickly and conveniently.

Fig. 2 is a partial flow diagram of a visualization method for debugging a business process according to a second embodiment of the present invention. As shown in fig. 2, a visualization method for business process debugging according to an embodiment of the present invention includes:

step S201, responding to the triggering operation of a user, creating a main debugger, and sending debugging configuration information of a service flow to a debugging engine based on the main debugger, so that the debugging engine carries out service flow debugging according to the debugging configuration information.

Illustratively, the user's trigger operation may be: the user selects a business process on the software interface and then clicks the "start debug" button. In response to a trigger operation by the user, execution of step S201 is started.

In step S201, after creating the master debugger, the debugging GUI may transmit debugging configuration information to the debugging engine based on the master debugger. The debugging configuration information may include information such as an operation flow identifier, contents of a flow file, a breakpoint set by a user, and positions of some dependent files used in the flow.

Wherein the message may include: a message indicating the start of execution flow, a first message indicating the start of execution of the parallel node, a fourth message indicating the start of execution of the non-parallel node, and other messages returned by the debug engine. For example, after completing the debugging initialization work, the debugging engine sends a message "start execution flow" to the debugging GUI. After receiving the message of "starting to execute the flow", the debugging GUI may find the flow file according to the flow identifier carried in the message, then create a tab page according to a second area (or referred to as a "flow chart display area") of the flow file on the page, and display a flow chart (or referred to as a main flow chart) corresponding to the flow file in the tab page.

Step S202, receiving a message returned by the debugging engine in the process of debugging the business process.

Step S203, when the message is a fourth message, determining a corresponding graph of the non-parallel node in the flow chart according to the flow identifier and the non-parallel node identifier carried by the fourth message, and then rendering the corresponding graph into a state to be executed.

In a business process, there are parallel nodes (alternatively referred to as "parallel call sub-process nodes") and non-parallel nodes. Parallel nodes refer to nodes executed by a plurality of threads, and non-parallel nodes refer to nodes executed by a single thread.

In one example, the debug engine, upon execution to a common node (i.e., a non-parallel node), may send a fourth message to the debug GUI indicating the start of execution of the non-parallel node, the fourth message containing the flow identification and the node identification. After receiving the fourth message, the debugging GUI may determine the flowchart where the node is located according to the process identifier carried in the fourth message, then determine the corresponding graph of the node in the flowchart where the node belongs according to the node identifier, and then render the corresponding graph into a state to be executed. For example, the color of the corresponding graph may be rendered into a color that is used to characterize the state to be executed.

Step S204, when the message is a first message, according to the parallel node identification carried by the first message, creating a label page named by the parallel node in a second area of the page. After step S204, steps S205 to S208 may be performed.

In one example, a debug engine, upon execution to a parallel node, may send a first message to the debug GUI indicating the start of execution of the parallel node, the first message containing a flow identification and a node identification. After receiving the first message, the debugging GUI may create a tab page named with the parallel node at a certain position of the second area of the page (for example, the right side of the tab page where the main process is located) according to the node identifier carried in the first message, so as to display the execution processes of all sub-processes under the parallel node.

And step S205, receiving a second message returned by the debugging engine.

In one example, the debug engine may determine the number of threads to execute the parallel node based on the configuration information for the parallel node, then create and launch a thread, and send a second message to the debug GUI. Wherein the second message is used to indicate that a plurality of threads for executing the parallel node are started. The second message may include information such as the flow identification, the name of the new thread, the identification of the sub-flow to be executed by the new thread, etc. Thereafter, the debug GUI receives the second message.

In specific implementation, after starting a thread for executing the parallel node, the debug engine may send a message indicating that the thread is started to the debug GUI, that is, send the start messages of the threads in sequence; alternatively, the debug engine may send a message to the debug GUI indicating that execution of all threads of the parallel node is to be initiated after all threads of the parallel node are initiated.

Step S206, a plurality of sub debuggers of the current debugger are created according to the second message, and the information of the sub debuggers is added to a sub debugger list of the current debugger.

In one example, the debugging GUI may create a plurality of sub debuggers of the current debugger according to the second message, and store the information of the thread carried by the second message in each sub debugger, and the debugging GUI may add the information of each newly created sub debugger to a list of sub debuggers of the debugger currently located. The sub-debuggers correspond to a plurality of threads for executing the parallel nodes one by one. In a specific implementation, the current debugger may be a master debugger or a sub debugger. And the main debugger and the sub debugger are used for communicating with a debugging engine.

And step S207, drawing a thread calling tree in a first area on the page according to the sub debugger list of the current debugger and displaying the thread calling tree.

In the embodiment of the present invention, since the structure of the current debugger reflects the call relationship between the parent thread and the multiple threads (i.e., child threads) executing the parallel node, a thread call tree may be drawn and displayed in the first region on the page according to the list of child debuggers of the current debugger.

And step S208, drawing and displaying a plurality of sub-flowcharts in the label page according to the information, carried in the second message, of the plurality of threads for executing the parallel nodes.

In one example, the debugging GUI may find a previously created tab page (such as a tab page) named by the parallel node according to the node identifier carried in the second message, create a tab page named by each thread executing the parallel node in the tab page, and draw and display a sub-flowchart to be executed by the thread in the tab page named by each thread.

In the embodiment of the invention, the problems that the thread management is not clear, the parent flow cannot be positioned when the sub-flow is executed in a multithreading mode and the like in the conventional visualization method for debugging the business flow can be solved through the steps, so that developers can quickly and conveniently debug the business flow.

Fig. 3 is a flowchart illustrating a visualization method for debugging a business process according to a third embodiment of the present invention. The method of the embodiment of the invention can be executed by a debugging GUI (a debugging visual component, which can be called a device for business process debugging) and a debugging engine together. As shown in fig. 3, a visualization method for business process debugging according to an embodiment of the present invention includes:

step S301, a main debugger is created by the debugging GUI, and debugging configuration information of the business process is sent to a debugging engine.

In this step, after creating the master debugger, the debug GUI may send debug configuration information to the debug engine based on the master debugger. The debugging configuration information may include information such as an operation flow identifier, contents of a flow file, a breakpoint set by a user, and positions of some dependent files used in the flow.

Step S302, debugging initialization is carried out by a debugging engine.

After receiving the debugging configuration information, the debugging engine can carry out debugging initialization work according to the debugging configuration information. The debugging initialization is mainly used for establishing a debugging environment of the debugging.

After the debugging initialization work is completed, the debugging engine prepares to execute the business process and feeds back a message to the debugging GUI in the process of executing the business process. For example, after completing the debugging initialization work, the debugging engine sends a message "start execution flow" to the debugging GUI. After receiving the message of "starting to execute the flow", the debugging GUI may find the flow file according to the flow identifier carried in the message, then create a tab page according to a second area (or referred to as a "flow chart display area") of the flow file on the page, and display a flow chart (or referred to as a main flow chart) corresponding to the flow file in the tab page.

Step S303, the debug engine sends a fourth message to the debug GUI.

Wherein the fourth message is used to indicate the start of execution of the non-parallel node. In one example, the debug engine, when executing to a common node (i.e., a non-parallel node), may send a fourth message to the debug GUI, the fourth message containing the flow identification and the node identification.

Step S304, the debugging GUI determines a corresponding graph of the non-parallel node in the flow chart according to the flow identification and the non-parallel node identification carried by the fourth message, and then renders the corresponding graph into a state to be executed.

In this step, after receiving the fourth message, the debugging GUI may determine the flowchart where the node is located according to the process identifier carried in the fourth message, then determine the corresponding graph of the node in the flowchart where the node is located according to the node identifier, and then render the corresponding graph into the state to be executed. For example, the color of the corresponding graph may be rendered into a color that is used to characterize the state to be executed.

Step S305, the debugging engine sends a fifth message to the debugging GUI.

Wherein the fifth message is used to indicate that the non-parallel node execution is finished. In one example, when the debug engine finishes executing a common node, a fifth message may be sent to the debug GUI, where the fifth message may include information such as a process identifier, a node identifier, and a node execution result. The node execution result may be indication information of execution success or execution failure.

Step S306, the debugging GUI determines a corresponding graph of the non-parallel node in the flow chart to which the non-parallel node belongs according to the flow identifier and the non-parallel node identifier carried in the fifth message, and then renders the corresponding graph into an execution complete state.

Wherein the execution complete state comprises: an execution success status, an execution failure status. In this step, the debugging GUI may determine the flowchart where the node is located according to the process identifier carried in the fifth message, then determine the corresponding graph of the node in the flowchart according to the node identifier, and then render the corresponding graph into an execution success state or an execution failure state according to the node execution result. For example, the debugging GUI may render the corresponding graph into a color for characterizing the successful execution or a color for characterizing the failed execution according to the node execution result. In addition, the debugging GUI can also find the identifier of the previous node according to the internally maintained node execution linked list, find the corresponding graph in the flow chart according to the identifier of the previous node, and render the directed line segment between the graphs corresponding to the two nodes in the flow chart into a color for representing successful execution or a color for representing failed execution.

Step S307, the debug engine sends a first message to the debug GUI.

Wherein the first message is used to indicate the start of execution of the parallel node. In this step, the debug engine, when executing to a parallel node, may send a first message to the debug GUI, the first message including the flow identifier and the node identifier.

Step S308, the debugging GUI creates a label page named by the parallel node in the second area of the page according to the identifier of the parallel node carried by the first message.

In this step, after receiving the first message, the debugging GUI may create a tab page named with the parallel node at a certain position of the second area of the page (for example, the right side of the tab page where the main process is located) according to the node identifier carried in the first message, so as to display the execution processes of all sub-processes under the parallel node.

Step S309, the debug engine sends a second message to the debug GUI.

Wherein the second message is used to indicate that a plurality of threads for executing the parallel node are started. In this step, the debug engine may determine the number of threads for executing the parallel node based on the configuration information for the parallel node, then create and start a thread, and send a second message to the debug GUI. Wherein the second message is used to indicate that a plurality of threads for executing the parallel node are started. The second message may include information such as the flow identification, the name of the new thread, the identification of the sub-flow to be executed by the new thread, etc. Thereafter, the debug GUI receives the second message.

Step S310, the debugging GUI creates a plurality of sub-debuggers of the current debugger according to the second message, adds the information of the sub-debuggers into a sub-debugger list of the current debugger, draws and displays a thread calling tree in a first area on a page according to the sub-debugger list of the current debugger, and draws and displays a plurality of sub-flow charts in the label page according to the information of a plurality of threads which are carried by the second message and used for executing the parallel nodes.

The sub-debuggers correspond to a plurality of threads for executing the parallel nodes one by one. In a specific implementation, the current debugger may be a master debugger or a sub debugger. And the main debugger and the sub debugger are used for communicating with a debugging engine.

Step S311, the debug engine sends a third message to the debug GUI.

Wherein the third message is used for indicating that the parallel node execution is finished.

Step S312, the debugging GUI closes the plurality of sub-debuggers according to the third message, deletes the information of the plurality of sub-debuggers from the sub-debugger list of the current debugger, and updates the thread calling tree and the plurality of sub-flow charts nested in the same label page.

Fig. 4a to 4e are schematic diagrams of a visualization interface in a business process debugging process according to a third embodiment of the present invention. The change of the visual interface in the business process debugging process is described with reference to fig. 4a to 4 e.

FIG. 4a shows a business flow diagram in this example, including a start node, a data transformation node, a parallel sub-flow call node (i.e., a "parallel node"), and an end node.

And when the debugging engine executes to the parallel sub-process calling node, sending a first message to the debugging GUI. The debugging GUI refreshes the page according to the first message, and the result of the refreshing is shown in FIG. 4 b. Specifically, the debugging GUI may create a tab page named with the parallel node on the right side of the tab page where the main flow is located according to the node identifier carried in the first message, and is used to display the execution processes of all sub-flows under the parallel node.

Next, the debug engine determines the number of threads for executing the parallel node according to the configuration information of the parallel node, then creates and starts the threads, and sends a second message to the debug GUI. The debugging GUI refreshes the page according to the second message, and the result of the refreshing is shown in FIG. 4 c. Specifically, the debugging GUI draws and displays a thread call tree in a first area (i.e., a thread stack area) on the page, and draws and displays a plurality of sub-flowcharts nested in the same tab page in a second area on the page.

Then, when the parallel node execution is finished, the debugging engine sends a message for indicating the parallel node execution is finished to the debugging GUI. The debugging GUI refreshes the page according to the message, and the result of the refreshing is shown in FIG. 4 d. Specifically, the debugging GUI updates a thread call tree in a first region of the page and updates a flowchart in a second region of the page.

Next, the debug engine sends a message indicating the end of execution of the flow to the debug GUI when execution of the flow ends. The debugging GUI refreshes the page according to the message, and the result of the refreshing is shown in FIG. 4 e.

Fig. 5 is a schematic block diagram of a visualization apparatus for debugging a business process according to a fourth embodiment of the present invention. As shown in fig. 5, a visualization apparatus 500 for debugging a business process according to an embodiment of the present invention includes: a creating module 501, a receiving module 502 and a drawing module 503.

The creating module 501 is configured to create a master debugger in response to a trigger operation of a user, and send debugging configuration information of a service flow to a debugging engine based on the master debugger, so that the debugging engine performs service flow debugging according to the debugging configuration information.

In one example, after creating the master debugger, creation module 501 may send debug configuration information to the debug engine based on the master debugger. The debugging configuration information may include information such as an operation flow identifier, contents of a flow file, a breakpoint set by a user, and positions of some dependent files used in the flow. After receiving the debugging configuration information, the debugging engine can carry out debugging initialization work according to the debugging configuration information. The debugging initialization is mainly used for establishing a debugging environment of the debugging. After the debugging initialization work is completed, the debugging engine prepares to execute the business process and feeds back a message to a visualization device (or called a 'debugging GUI') for debugging the business process during the execution of the business process.

A receiving module 502, configured to receive a message returned by the debugging engine in the process of performing business process debugging.

Illustratively, the message received by the receiving module 502 may be a first message indicating that parallel node execution is started, a fourth message indicating that non-parallel node execution is started, or other messages returned by the debug engine. In a business process, there are parallel nodes (alternatively referred to as "parallel call sub-process nodes") and non-parallel nodes. Parallel nodes refer to nodes executed by a plurality of threads, and non-parallel nodes refer to nodes executed by a single thread.

A drawing module 503, configured to draw and display a thread call tree in a first area on a page after determining that the message is a first message, and draw and display a plurality of sub-flowcharts nested in the same tab page in a second area on the page according to the identifier of the parallel node and information of a plurality of threads for executing the parallel node; wherein the first message is used to indicate that parallel nodes are started to execute.

Wherein the first message is used to indicate that parallel nodes are started to execute. In specific implementation, when the debug engine executes to the parallel node, a first message may be sent to the debug GUI, where the first message includes information such as a flow identifier and a parallel node identifier. After the first message is received by the debugging GUI, the thread call tree can be drawn in a first area (or referred to as "thread stack area") on the page by the drawing module 503, so that the call relationship between multiple threads in the service flow debugging process is clearly shown in a tree structure. And the drawing module 503 may draw and display a plurality of sub-flowcharts nested in the same tab page in a second area on the page according to the identifier of the parallel node and information of a plurality of threads for executing the parallel node. By nesting a plurality of sub-flow charts corresponding to parallel nodes in the same label page, the quick positioning to the parent flow of the sub-flow charts is facilitated.

In one optional example, drawing the thread call tree and displaying by the drawing module 503 in the first region on the page may include: after receiving a second message returned by the debugging engine, creating a plurality of sub debuggers of the current debugger according to the second message, and adding the information of the sub debuggers into a sub debugger list of the current debugger; the second message is used for indicating that a plurality of threads for executing the parallel node are started, and the plurality of sub-debuggers are in one-to-one correspondence with the plurality of threads for executing the parallel node; then, a thread call tree is drawn in a first area on the page according to the sub debugger list of the current debugger and displayed.

In an alternative example, the drawing module 503 draws and displays a plurality of sub-flowcharts nested in the same tab page in a second area on the page according to the identification of the parallel node and information of a plurality of threads for executing the parallel node, including: the drawing module 503 creates a tab page named by the parallel node in the second area of the page according to the identifier of the parallel node carried in the first message, and then draws and displays a plurality of sub-flow charts in the tab page according to the information of the plurality of threads used for executing the parallel node carried in the second message.

In the embodiment of the invention, the problems that thread management is not clear, a parent flow cannot be positioned when a child flow is executed in a multithreading mode and the like in the prior art are solved through the device, and therefore developers can debug the service flow quickly and conveniently.

Fig. 6 is a schematic block diagram of a visualization system for business process debugging according to a fifth embodiment of the present invention. As shown in fig. 6, a visualization system 600 for debugging a business process according to an embodiment of the present invention includes: debug GUI601, debug engine 602.

The debugging GUI601 is used for responding to the triggering operation of a user, creating a main debugger, and sending debugging configuration information of a business process to a debugging engine based on the main debugger so that the debugging engine can debug the business process according to the debugging configuration information; the debugging GUI601 is further configured to receive a message returned by the debugging engine in the process of performing business process debugging; the debugging GUI601 is further configured to draw and display a thread call tree in a first area on a page after determining that the message is the first message, and draw and display a plurality of sub-flowcharts nested in the same tab page in a second area on the page according to the identifier of the parallel node and information of a plurality of threads for executing the parallel node; wherein the first message is used to indicate that parallel nodes are started to execute.

And the debugging engine 602 is configured to perform debugging initialization according to the debugging configuration information, execute the service flow after the debugging initialization is completed, and feed back a message to the debugging GUI during the service flow execution process. Wherein the message may include: a message indicating the start of execution flow, a first message indicating the start of execution of the parallel node, a fourth message indicating the start of execution of the non-parallel node, and other messages returned by the debug engine. For example, after completing the debugging initialization work, the debugging engine sends a message "start execution flow" to the debugging GUI. After receiving the message of "starting to execute the flow", the debugging GUI may find the flow file according to the flow identifier carried in the message, then create a tab page according to a second area (or referred to as a "flow chart display area") of the flow file on the page, and display a flow chart (or referred to as a main flow chart) corresponding to the flow file in the tab page.

In the embodiment of the invention, the problems that the thread management is not clear, the parent flow cannot be positioned when the child flow is executed in a multithreading mode and the like in the prior art are solved through the system, and therefore, developers can debug the service flow quickly and conveniently.

Fig. 7 shows an exemplary system architecture 700 of a visualization method for business process debugging or a visualization apparatus for business process debugging to which an embodiment of the present invention may be applied.

As shown in fig. 7, the system architecture 700 may include

terminal devices

701, 702, 703, a network 704, and a server 705. The network 704 serves to provide a medium for communication links between the

terminal devices

701, 702, 703 and the server 705. Network 704 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

A user may use the

terminal devices

701, 702, 703 to interact with a server 705 over a network 704, to receive or send messages or the like. Various communication client applications, such as a business process debugging application, a shopping application, a web browser application, a search application, an instant messaging tool, a mailbox client, social platform software, and the like, may be installed on the

terminal devices

701, 702, and 703.

The

terminal devices

701, 702, 703 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

The server 705 may be a server providing various services, such as a background management server providing support for business process debugging applications browsed by users using the

terminal devices

701, 702, and 703. The background management server may analyze and perform other processing on the received data such as the service flow debugging request, and feed back a processing result (e.g., a service flow debugging result) to the terminal device.

It should be noted that, the visualization method for debugging the business process provided by the embodiment of the present invention is generally executed by a terminal device, and accordingly, the visualization apparatus for debugging the business process is generally disposed in the terminal device.

It should be understood that the number of terminal devices, networks, and servers in fig. 7 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to FIG. 8, shown is a block diagram of a computer system 800 suitable for use in implementing an electronic device of an embodiment of the present invention. The computer system illustrated in FIG. 8 is only one example and should not impose any limitations on the scope of use or functionality of embodiments of the invention.

As shown in fig. 8, the computer system 800 includes a Central Processing Unit (CPU)801 that can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)802 or a program loaded from a storage section 808 into a Random Access Memory (RAM) 803. In the RAM 803, various programs and data necessary for the operation of the system 800 are also stored. The CPU 801, ROM 802, and RAM 803 are connected to each other via a bus 804. An input/output (I/O) interface 805 is also connected to bus 804.

The following components are connected to the I/O interface 805: an input portion 806 including a keyboard, a mouse, and the like; an output section 807 including a signal such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 808 including a hard disk and the like; and a communication section 809 including a network interface card such as a LAN card, a modem, or the like. The communication section 809 performs communication processing via a network such as the internet. A drive 810 is also connected to the I/O interface 805 as necessary. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 810 as necessary, so that a computer program read out therefrom is mounted on the storage section 808 as necessary.

In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication section 809 and/or installed from the removable medium 811. The computer program executes the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 801.

It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor includes a creation module, a reception module, and a rendering module. Where the names of these modules do not in some cases constitute a limitation on the module itself, for example, a receiving module may also be described as a "module that receives messages returned by a debug engine".

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to perform the following: responding to the triggering operation of a user, creating a main debugger, and sending debugging configuration information of a service flow to a debugging engine based on the main debugger so that the debugging engine carries out service flow debugging according to the debugging configuration information; receiving a message returned by the debugging engine in the process of debugging the business process; after the message is determined to be a first message, drawing a thread calling tree in a first area on a page and displaying the tree, and drawing and displaying a plurality of sub-flow charts nested in the same label page in a second area on the page according to the identification of the parallel node and the information of a plurality of threads for executing the parallel node; wherein the first message is used to indicate that parallel nodes are started to execute.

The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A visualization method for business process debugging, the method comprising:

responding to the triggering operation of a user, creating a main debugger, and sending debugging configuration information of a service flow to a debugging engine based on the main debugger so that the debugging engine carries out service flow debugging according to the debugging configuration information;

receiving a message returned by the debugging engine in the process of debugging the business process;

after the message is determined to be a first message, drawing a thread calling tree in a first area on a page and displaying the tree, and drawing and displaying a plurality of sub-flow charts nested in the same label page in a second area on the page according to the identification of the parallel node and the information of a plurality of threads for executing the parallel node; wherein the first message is used to indicate that parallel nodes are started to execute.

2. The method of claim 1, wherein the step of drawing the thread in the first region on the page calls the tree and displays the thread comprises:

after receiving a second message returned by the debugging engine, creating a plurality of sub debuggers of the current debugger according to the second message, and adding the information of the sub debuggers into a sub debugger list of the current debugger; the second message is used for indicating that a plurality of threads for executing the parallel node are started, and the plurality of sub-debuggers are in one-to-one correspondence with the plurality of threads for executing the parallel node; then, a thread call tree is drawn in a first area on the page according to the sub debugger list of the current debugger and displayed.

3. The method of claim 2, wherein said step of drawing and displaying a plurality of sub-flowcharts nested within the same tab page in a second area of the page based on the identity of the parallel node and information about a plurality of threads executing the parallel node comprises:

and creating a label page named by the parallel node in a second area of the page according to the identifier of the parallel node carried by the first message, and then drawing and displaying a plurality of sub-flow charts in the label page according to the information of a plurality of threads used for executing the parallel node carried by the second message.

4. The method of claim 3, further comprising:

after a third message returned by the debugging engine is received, closing the plurality of sub-debuggers according to the third message, deleting the information of the plurality of sub-debuggers from a sub-debugger list of the current debugger, and updating the thread calling tree and the plurality of sub-flow charts nested in the same label page; wherein the third message is used to indicate that the parallel node execution is finished.

5. The method of claim 1, further comprising:

after the message is determined to be a fourth message, determining a corresponding graph of the non-parallel node in the flow chart according to the flow identification and the non-parallel node identification carried by the fourth message, and rendering the corresponding graph into a state to be executed; after receiving a fifth message, determining a corresponding graph of the non-parallel node in the flow chart to which the non-parallel node belongs according to the flow identifier and the non-parallel node identifier carried by the fifth message, and then rendering the corresponding graph into an execution completion state; the fourth message is used for indicating the start of executing the non-parallel node, and the fifth message is used for indicating the end of executing the non-parallel node.

6. A visualization apparatus for business process debugging, the apparatus comprising:

the system comprises a creating module, a debugging engine and a debugging module, wherein the creating module is used for creating a main debugger in response to the triggering operation of a user and sending debugging configuration information of a service flow to the debugging engine based on the main debugger so that the debugging engine carries out service flow debugging according to the debugging configuration information;

the receiving module is used for receiving a message returned by the debugging engine in the process of debugging the business process;

the drawing module is used for drawing a thread calling tree in a first area on a page and displaying the thread calling tree after the message is determined to be the first message, and drawing and displaying a plurality of sub-flow charts nested in the same label page in a second area on the page according to the identification of the parallel node and the information of a plurality of threads for executing the parallel node; wherein the first message is used to indicate that parallel nodes are started to execute.

7. The apparatus of claim 6, wherein the rendering module renders the thread call tree in a first region on the page and displays the thread call tree comprises:

8. The apparatus of claim 7, wherein the rendering module renders and displays a plurality of sub-flow graphs nested in a same tab page in a second region on a page based on the identification of the parallel node and information for a plurality of threads executing the parallel node comprises:

and the drawing module creates a label page named by the parallel node in a second area of the page according to the identifier of the parallel node carried by the first message, and then draws and displays a plurality of sub-flow charts in the label page according to the information which is carried by the second message and is used for executing a plurality of threads of the parallel node.

9. An electronic device, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-5.

10. A computer-readable medium, on which a computer program is stored, which program, when being executed by a processor, is adapted to carry out the method of any one of claims 1 to 5.