A method for constructing a service mode based on running log data

Abstract

The application provides a method for constructing service patterns based on operation log data, comprising the following steps: S1, obtaining historical service scheme data and operation log data, each service scheme being composed of multiple services and business processing logic between the services, and each operation log containing a record of whether at least one service in the service scheme is successfully operated; S2, constructing a service scheme graph corresponding to each service scheme based on the historical service scheme data and the operation log data, the service scheme graphs of all service schemes constituting a service scheme graph set, each service scheme graph being a directed graph comprising multiple nodes and edges, the nodes representing services, the edges representing business processing logic between the services, and each edge being provided with a weight value indicating the correlation strength between two nodes connected by the edge and obtained based on the operation log data; S3, mining frequent subgraphs according to the frequencies of the nodes and edges in the service scheme graph set and the weight values of the edges, and constructing service patterns based on the mined frequent subgraphs.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data mining, in particular to the field of frequent subgraph mining, and more particularly to a method for constructing a service pattern based on running log data. BACKGROUND

[0002] With the rapid development of computer technology and the deepening of practical application, the related research of service internet in the big data era is gradually mature, traditional services and information technology are gradually combined and transformed into services, and more and more offline service resources are integrated by service intermediaries and published on the Internet, resulting in more and more complex service resources on the Internet.

[0003] At the same time, the types and quantities of users are also increasing, and the needs of users are becoming complex, and only relying on existing fine-grained atomic services (corresponding to a single service) cannot effectively meet the personalized needs of users. Therefore, combining multiple atomic services to form a large-grained service scheme based on a certain business requirement becomes a feasible method. In this process, how to quickly construct a service scheme based on a large amount of atomic services is the primary problem to be solved.

[0004] Research has found that there is a certain business logic interaction relationship between many services, and these services usually appear in the form of fixed process fragments in service schemes. If these large-grained process fragments are used as the basis when constructing service schemes, different process fragments and atomic services can be combined to simplify the construction steps of service schemes and effectively improve the construction efficiency. Therefore, the concept of service pattern is proposed, which describes and characterizes large-grained process fragments, and further supports the construction of service schemes.

[0005] However, the current service pattern mining is mainly to directly calculate whether the support of the corresponding process fragment meets the minimum support according to the historical service scheme data, if so, it is considered that the process fragment is a frequent service pattern, and then the service pattern can be mined as a reference for constructing service schemes in the future. However, the service pattern mined only relying on historical service scheme data lacks the support of other information, and its accuracy needs to be improved. SUMMARY

[0006] Therefore, the purpose of the present application is to overcome the defects of the prior art and provide a method for constructing a service pattern based on running log data.

[0007] The purpose of the present application is achieved by the following technical solutions:

[0008] According to a first aspect of the present application, a method for constructing service patterns based on operation log data is provided, comprising: S1, obtaining historical service plan data and operation log data, the historical service plan data comprising a plurality of service plans, each service plan being composed of a plurality of services and business processing logic between the services, the operation log data comprising a plurality of operation logs, each operation log containing a record of whether at least one service in a service plan is successfully operated; S2, constructing a service plan graph corresponding to each service plan based on the historical service plan data and the operation log data, the service plan graphs of all service plans constituting a service plan graph set, wherein each service plan graph is a directed graph comprising a plurality of nodes and edges, a node representing a service, an edge representing business processing logic between services, and each edge being provided with a weight indicating the correlation strength between two nodes connected by the edge, the weight being obtained based on the operation log data; S3, mining frequent subgraphs according to the frequency of each node and edge in the service plan graph set and the weight of each edge, and constructing service patterns based on the mined frequent subgraphs.

[0009] In some embodiments of the present application, the weight of each edge is determined in the following manner: one or more log windows and their window times are generated according to the records of each operation log in the operation log data and the attribute of generation time; the execution times of the successful execution of each edge in each log window are determined according to the operation logs contained in each log window; and the weight of each edge is determined according to the execution times of the successful execution of each edge in each log window and the window time of each log window.

[0010] In some embodiments of the present application, the log windows and their window times are generated in the following manner: a log window is generated by reading a predetermined number of operation logs indicating the successful operation of services from the operation log data using a sliding window, and the window time of the log window is taken as the generation time of the last operation log contained in the log window.

[0011] In some embodiments of the present application, the weight of each edge is calculated in the following manner: the products obtained by multiplying the execution times of the successful execution of each log window corresponding to the edge by a decay factor are summed up and then divided by the total number of log windows.

[0012] In some embodiments of the present application, the weight of each edge is calculated in the following manner:

[0013]

[0014] wherein C t < S m , E n represents the edge E mS n the weight of the edge, r i represents the number of successful executions of the edge in the log window i, X i represents the decay factor, X i = 2 -λt , λ represents the adjustment parameter, λ > 0, t = |t k -t i |, k represents the total number of log windows currently used for calculating the weight, and t represents the absolute value of the difference between the window time of the last log window and the window time of the log window i.

[0015] In some embodiments of the present application, the method further comprises: maintaining a single linked list for each edge, each linked list node in the single linked list being used to store the number of successful executions of the edge in a log window and the window time of the log window; and deleting a linked list node when the product of the number of successful executions of the edge in the log window stored in the linked list node and the corresponding decay factor is less than a predetermined decay threshold.

[0016] In some embodiments of the present application, step S3 comprises mining the frequent subgraphs in the following manner: mining the frequent subgraphs in the service scheme graph set by using the gSpan mining manner according to the minimum support degree and the DFS encoding of the edges, wherein the labels of the edges in the DFS encoding of the edges are determined according to the frequency of occurrence of the edges and the weights of the edges.

[0017] In some embodiments of the present application, the edges with a relatively higher frequency of occurrence are assigned relatively smaller labels, and the edges with a same frequency of occurrence but a relatively larger weight are assigned relatively smaller labels.

[0018] In some embodiments of the present application, step S3 comprises: obtaining a predetermined minimum support degree, removing the nodes and edges with a frequency of occurrence less than the minimum support degree according to the frequencies of occurrence of all the nodes and edges in the service scheme graph set, and obtaining the remaining nodes and edges; updating the labels of the nodes according to the frequencies of occurrence of the nodes for the remaining nodes, wherein the nodes with a relatively higher frequency of occurrence are assigned relatively smaller labels; updating the labels of the edges according to the frequencies of occurrence of the edges as a first basis for sorting the edges and the weights of the edges as a second basis for sorting the edges for the remaining edges, wherein the edges with a relatively higher frequency of occurrence are assigned relatively smaller labels, and the edges with a same frequency of occurrence but a relatively larger weight are assigned relatively smaller labels; setting the DFS encoding of the remaining edges in the gSpan mining manner by using the updated labels of the nodes and the labels of the edges; and mining the frequent subgraphs by using the gSpan mining manner according to the minimum support degree and the DFS encoding of the remaining edges.

[0019] In some embodiments of the present application, the gSpan mining method is an improved gSpan mining method, wherein the DFS encoding in the improved gSpan mining method comprises: the identification of one node constituting an edge, the identification of another node constituting the edge, the label of one node constituting the edge, the label of the edge, the label of another node constituting the edge, and the direction of the edge.

[0020] According to a second aspect of the present application, a method for constructing a service scheme is provided, comprising: obtaining all service patterns constructed by the method according to the first aspect; selecting one or more service patterns from all service patterns, and constructing a service scheme based on the selected service patterns.

[0021] According to a third aspect of the present application, an electronic device is provided, comprising: one or more processors; and a memory, wherein the memory is configured to store executable instructions; the one or more processors are configured to implement the steps of the method according to the first aspect or the second aspect of the present application by executing the executable instructions.

[0022] Compared with the prior art, the present application has the following advantages:

[0023] In the present application, when mining frequent subgraphs from a service scheme graph set, not only historical service scheme data but also running log data corresponding to the service scheme are utilized, so as to enhance the accuracy of the service patterns constructed based on the mined frequent subgraphs. BRIEF DESCRIPTION OF DRAWINGS

[0024] The embodiments of the present application will be further described below with reference to the accompanying drawings, in which:

[0025] Figure 1 The figure is a schematic diagram of the overall flow of the method for constructing service patterns based on running log data according to the embodiments of the present application;

[0026] Figure 2 The figure is a schematic diagram of the flow of the method for constructing service patterns based on running log data according to the embodiments of the present application;

[0027] Figure 3 The figure is a schematic diagram of the storage structure of the fused service scheme graph according to the embodiments of the present application;

[0028] Figure 4 The figure is a schematic diagram of the single linked list for storing the related data of the weight of the edge according to the embodiments of the present application;

[0029] Figure 5 The figure is a schematic flowchart of returning the service scheme graph set with weights according to the embodiments of the present application;

[0030] Figure 6 The figure is a schematic diagram of the service pattern according to the embodiments of the present application;

[0031] Figure 7 Fig. 2 is a schematic diagram of service logic structure in a service mode according to an embodiment of the present application;

[0032] Figure 8 Fig. 3 is a schematic diagram of results of verifying the influence of sliding window size on service mode mining in experiment one according to an embodiment of the present application;

[0033] Figure 9 Fig. 4 is a schematic diagram of verifying the influence of minimum support on the number of mined modes in experiment two according to an embodiment of the present application

[0034] Figure 10 Fig. 5 is a schematic diagram of verifying the influence of minimum support on the average number of nodes in modes in experiment two according to an embodiment of the present application;

[0035] Figure 11 Fig. 6 is a schematic diagram of verifying the accuracy of mining results in experiment three according to an embodiment of the present application. DETAILED DESCRIPTION

[0036] In order to make the objects, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and should not be used to limit the present application.

[0037] As mentioned in the background section, the service patterns mined by the prior art from historical service plan data are not accurate enough due to the lack of other information. The mining of service patterns is first done manually, based on the relevant professional knowledge of project developers or the experience of individual users, to combine some common services in the service library to obtain a service pattern, thereby simplifying the construction process of subsequent service plans. In this process, there is not only a lack of professionalism, but also an effective verification of the service pattern. In subsequent related research, the mining of service patterns begins to use automated discovery methods, such as mining the frequency of the co-occurrence of related services in historical service plans to find some commonly used fragments. However, this method only mines historical service plans, without specific service plan success logs as data supplements, so the final results lack a certain persuasiveness and credibility. Based on the in-depth exploration of the field of service computing, the inventors have summarized three characteristics of services: priori, similarity and association. The priori of services is that in a large amount of data, priori knowledge is obtained by different users calling services to obtain different execution results, but some business processes corresponding to these results have reference value. The similarity of services is that different services have some similar characteristic attributes and functional positioning, or there is duplication between the functional positioning of the two, and the generation of new services can draw on relevant knowledge to achieve service reuse. The association of services is that in different business scenarios, some services are often used at the same time, such as a fixed combination, which can jointly meet a business requirement, so it is believed that there is an association between these services. Therefore, the strength of the association between services needs to be identified in combination with the running log data to better construct service patterns. When the present invention mines frequent subgraphs from service plan graphs, not only historical service plan data is used, but also service plan corresponding running log data is used to improve the accuracy of service patterns constructed based on the mined frequent subgraphs. As shown in Figure 1 the process of constructing service patterns, the process of the present invention mainly includes three stages, wherein:

[0038] The first stage: historical data preprocessing

[0039] Firstly, according to the format of the historical service scheme data and the historical running log data, the required information in the service scheme data and the running log data is traversed, the two kinds of historical data are fused, and a service scheme graph set with a weight value is constructed. In the data preprocessing step, the log data is effectively processed according to the time attribute, and the weight value obtained after calculation is given to the association between services, so that a service scheme graph with a weight value is obtained. Considering that the fused data (service scheme graph) is mainly stored in the form of a directed graph, a graph storage structure based on an adjacency list is designed. The whole data preprocessing process mainly utilizes the time attribute of the log data to calculate the association between each pair of services in the service scheme, obtain a dynamically changing weight value, assign the weight value to the edge in the corresponding service scheme, and store the fused data.

[0040] Second stage: frequent subgraph mining

[0041] Based on the service scheme graph set with a weight value obtained after the first stage of preprocessing, the frequent subgraph (frequent subgraph is a fragment composed of at least two services frequently appearing in the service scheme graph set, and some places directly call the mined frequent subgraph as a frequent service mode) in the service scheme graph set is mined based on the frequent subgraph mining method. When mining the frequent subgraph, not only the frequency of each node and edge in the service scheme graph set is utilized, but also the weight value of the edge is utilized, so that the accuracy of the service mode constructed by the mined frequent subgraph is higher. In order to better mine the frequent subgraph, when the gSpan algorithm is used for mining, the DFS code of the original gSpan algorithm is further improved, and a direction of the edge is added in the DFS code, so as to further improve the accuracy of the mining result.

[0042] Third stage: service mode instantiation

[0043] According to the mined frequent subgraph, a service mode is constructed according to each frequent subgraph, the required basic information and function description information of each service mode are supplemented, the services contained in each service mode and the business processing logic between the services are recorded and stored, so as to form a service mode set, so as to be called by a user when constructing a service scheme, and the construction time of the service scheme is reduced.

[0044] The above three stages are described below.

[0045] First stage: historical data preprocessing

[0046] According to an embodiment of the present application, as Figure 2As shown, the present application provides a method for constructing service mode based on operation log data, comprising steps S1, obtaining historical service scheme data and operation log data; step S2, constructing service scheme graph corresponding to each service scheme based on the historical service scheme data and the operation log data, and the service scheme graphs of all service schemes constitute a service scheme graph set, wherein each service scheme graph is a directed graph comprising multiple nodes and edges, the nodes represent services, and the edges represent the business processing logic between services, and each edge is provided with a weight value indicating the association strength between the two nodes connected by the edge based on the operation log data.

[0047] For service scheme data or operation log data, there are usually multiple data format specifications for storing data. Regardless of which format specification, it is necessary that the historical service scheme data comprises multiple service schemes, each service scheme is composed of multiple services and business processing logic between services; and the operation log data comprises multiple operation logs, each operation log contains a record of whether at least one service in the service scheme is successfully run. The number of records of whether each operation log is successfully run is artificially defined and can be set as needed, and the present application does not make any limitation thereon. Hereinafter, an example in which each operation log contains a record of whether one service in the service scheme is successfully run is described.

[0048] The illustrative data formats of the service scheme data and the operation log data are described below:

[0049] For service scheme data, according to an embodiment of the present application, the service scheme data comprises multiple service schemes, wherein the service scheme is a combination of multiple services according to a certain execution flow (corresponding to business processing logic) to achieve a specific function for a certain complex business requirement. In this embodiment, the service scheme comprises multiple services according to a predetermined business processing logic to allow the services in the service scheme to execute according to the specified flow. Illustratively, the data format for storing the service scheme is defined according to the BPMN2.0 specification. Under the BPMN2.0 specification, the historical service scheme data is stored in a BPMN file, and the storage file mainly contains some defined elements and attributes, etc. to allow the services contained in the service scheme to execute according to the specified flow when the service scheme is run; for example, the common defined fields in the BPMN file include the following:

[0050] ■startEvent: start event, which is the starting point of the flow (the flow is defined by the business processing logic between all services in the service scheme) in the entire service scheme, the type of the start event defines how the entire flow is started.

[0051] ■endEvent: end event, which marks the end of a branch of the flow or sub-flow in the service scheme, and when the flow executes to the end event, a result is thrown.

[0052] ■serviceTask: Java service task, mainly used to call Java classes, and specific functions are implemented by specifying the class to be called during flow execution in the flowable:class attribute.

[0053] ■userTask: user task, a task that needs to be manually executed by a user, when the business flow reaches this task, a new task is created for the task list of the user or group assigned to the task.

[0054] ■timerEventDefinition: timer event, an event caused by a timer, and the execution of the specific event depends on the business calendar used.

[0055] ■parallelGateway: parallel gateway, which performs parallel execution in the business flow, and can branch the main execution flow into multiple execution paths, or combine multiple execution paths into the main execution flow, and the specific function depends on the order of the entry and exit sequence flows.

[0056] ■exclusiveGateway: exclusive gateway, used to make decisions for branch modules in the flow, when the execution flow reaches this gateway, it will calculate according to the order defined by all exit sequence flows, and select the first sequence flow whose calculation condition is true (True) to execute the subsequent flow.

[0057] ■sequenceFlow: sequence flow (corresponding to business processing logic), a connector between two flow elements. In actual processes, it will be transferred according to the defined order.

[0058] For the running log data, according to an embodiment of the present application, each running log record in the running log data has a running state of whether a service is successfully run. For example, during the execution of a service plan, when the corresponding service is successfully run or fails, a running log is generated to record the running state of the service, providing sufficient data basis for the builder of the service plan to troubleshoot errors and conduct related research in the future. The running log corresponding to each service plan in the historical service plan data constitutes the running log data. Illustratively, the data format of a running log is <SessionId, ServiceId, PlanId, ServiceNextId, StartTime, FinishTime, status, DescInfo, host>, wherein the meanings of each item are as follows:

[0059] ■SessionId: running instance ID, indicating the specific instance of the current plan running;

[0060] ■ServiceId: Running service ID, the service ID currently running in the current service plan;

[0061] ■PlanId: Service plan ID, the service plan to which the current service belongs;

[0062] ■ServiceNextId: The next node service ID, the ID of the next service to be run in the service solution process;

[0063] ■StartTime: the start time of the current service operation;

[0064] ■FinishTime: the end time of the current service operation;

[0065] ■Status: The current status of the service, success (Success) or failure (False);

[0066] ■DescInfo: After a service fails, the system provides a description of the failure.

[0067] Host: The IP address of the host where the service is currently running.

[0068] Table 1 shows a schematic diagram of the storage results of the running log data:

[0069] Table 1

[0070]

[0071] By fusing historical service plan data and operation log data, a service plan graph corresponding to each service plan can be obtained. According to one embodiment of the present invention, after the data is fused, the service plan graph obtained is a directed graph data (Graph), which can be stored in a graph structure. There are many graph storage structures that can be used to store graph data, such as: adjacency matrix, CSR compression matrix, CSC compression matrix, adjacency list, etc. The service plan graph includes nodes, edges, and edge weights. Here, the adjacency list is selected as the basic graphical storage structure of the fused service plan graph for illustration. The schematic structure is as follows: Figure 3 As shown, the service node S m It is the header node of the adjacency list, denoted as H(S m ), the linked single linked list is denoted as HT(S m ), where the stored edge is denoted as En m ,S n >. The weight C corresponding to the edge is stored in the data domain t And the time constraint vector T, which mainly stores the edge En m ,S n ​​The time value T for each real-time calculation of the weight. The specific adjacency table structure is as follows:

[0072] Nodes of the service plan diagram:

[0073] Let S represent the service in the service plan, SL represent the service plan graph set generated by fusing the service plan data with the operation log data, SL={SL i |i=0,1,……,s}, then S(SL i )={S i |i=1,2,……,N}, where N represents the total number of services in the i-th fused service solution graph.

[0074] Edges of the service plan graph:

[0075] Under the premise of a directed graph, the edge in the service solution graph can be recorded as E(SL i )={ m ,S n >|m,n=1,2,……,N}, indicating that there is a business processing logic (process) association relationship between the two services.

[0076] Edge weight:

[0077] An edge E m ,S n The weight of > is a two-dimensional vector, namely W m ,S n >=(C t m ,S n >,T), where C t m ,S n > represents edge E m ,S n >, T represents the generation time of the weight in the current record; the generation time of the weight is not necessary and this item can also be omitted. Figure 3 In the adjacency table, the header node stores the service S m The corresponding node, the table node following the header node stores the service S m Pointing to the service (such as Figure 3 Service S in i 、S j 、S m ) and the weights of the edges formed.

[0078] ​​​​​​According to one embodiment of the present application, the weight of each edge is determined in the following manner: one or more log windows and their window times are generated according to the records of the running logs in the running log data and the attribute of the generation time; the number of successful executions of the edge in each log window is determined according to the running logs contained in each log window; and the weight of the edge is determined according to the number of successful executions of the edge in each log window and the window time of each log window. Preferably, the log windows and their window times are generated in the following manner: a log window is generated by reading a predetermined number of running logs indicating successful running of the service from the running log data by using a sliding window, and the generation time of the last running log contained in the log window is taken as the window time of the log window. According to one embodiment of the present application, the weight of each edge is determined in the following manner: a log window is generated by reading a predetermined number (window size, which refers to the size of the sliding window, i.e. how many running logs are read each time) of running logs indicating successful running of the service from the running log data by using a sliding window, and the generation time of the last running log contained in the log window is taken as the window time of the log window; for each edge, the number of successful executions of the edge in each log window is determined according to the running logs contained in each log window, wherein if both services connected by the edge are successfully run once in a log window, it means that the edge is successfully executed once in the log window; and for each edge, the weight of the edge is determined according to the number of successful executions of the edge in each log window and the window time of each log window. The technical solution of this embodiment can at least achieve the following beneficial technical effects: this embodiment helps to more accurately indicate the relevance of the two nodes connected by the edge according to whether the edge is successfully executed and the corresponding time attribute indicated in the running log data, and helps to more accurately mine frequent subgraphs and construct service patterns subsequently.

[0079] According to one embodiment of the present application, the weight of each edge is calculated in the following manner: the products obtained by multiplying the number of successful executions in each log window corresponding to the edge by an attenuation factor are summed up and then divided by the total number of log windows, wherein the size of the attenuation factor is negatively related to the size of the absolute value of the difference between the window time of the last log window (the newly generated log window) and the window time of the log window. Setting the negative correlation can reduce the influence of data far in the past on the calculation of the weight of the edge, so as to better calculate the relevance strength between the nodes in the recent period. For example, preferably, the weight of each edge is calculated in the following manner:

[0080]

[0081] wherein C t <S m ,S n > represents the edge E<S m ,Sn r i represents the number of successful executions of the edge in the log window i, X i represents the decay factor, X i = 2 -λt , λ represents the adjustment parameter, λ > 0, t = |t k -t i |, k represents the total number of log windows currently used to calculate the weight of the edge, and t represents the absolute value of the difference between the window time of the last log window and the window time of the log window i. The technical scheme of this embodiment can at least achieve the following beneficial technical effects: the technical scheme of this embodiment is beneficial to reducing the influence of the running log recorded for a long time on the weight of the edge, so that the weight of the edge can be more accurately determined based on the running log occurring recently, and this is helpful for more accurately mining frequent subgraphs and constructing service patterns. It should be understood that, in addition to the above embodiments, the way of determining the weight of the edge is not unique, and there are other alternative solutions that are feasible in principle, for example, the decay factor is changed to X i = 3 -λt ; for another example, the decay factor is set to X i = i / k, etc.

[0082] Since the running log data is dynamically updated, in order to more accurately construct the service pattern, the weight of the edge can be dynamically updated. According to an embodiment of the present application, the method for constructing a service pattern based on running log data further comprises: updating the weight of the edge and re-mining frequent subgraphs based on the service scheme graph set every certain time period or every time a preset number (such as 3, 5 or 9, etc.) of log windows are newly generated, and constructing a service pattern based on the mined frequent subgraphs.

[0083] Further, considering that the number of log windows increases over time, and the amount of data to be recorded also increases, in order to reduce the amount of stored data and improve the calculation efficiency of the weight, according to an embodiment of the present application, the method for constructing a service pattern based on running log data comprises: maintaining a single linked list for each edge, and each linked list node in the single linked list is used to store the number of successful executions of the edge in a log window and the window time of the log window; when the product of the number of successful executions of the edge in the log window stored in a linked list node and the corresponding decay factor is less than a predetermined decay threshold, the linked list node is deleted to ignore the influence of the data stored in the linked list node on the calculation of the weight of the edge. Assuming that the single linked list is denoted as L, the schematic structure of the single linked list is shown in Figure 4 ; wherein the table header node stores an edge <S m ,S n > in the service scheme; and the content stored in each linked list node in the single linked list is the edge <S m ,Sn >ServiceS m and Service S n The number of successful executions r i (i.e., the number of successful executions of the edge), and the window time t of the log window i , and for the data r stored in each linked list node in the single linked list i , set a decay threshold R0, calculate X i *r i If the result is less than the attenuation threshold, it means that the value calculated based on the data recorded by the current linked list node has little influence on the final calculation result of the weight. Therefore, the data of this linked list node is deleted. The technical solution of this embodiment can at least achieve the following beneficial technical effects: In view of the dynamic update of operation log data, this embodiment designs a single linked list to store the number of successful executions of each edge in a log window and the window time of the log window, ensuring that for each edge, only a constant-level single linked list needs to be provided and maintained to store the required data for weight calculation, thereby ensuring that the calculation efficiency of the weight can be greatly improved.

[0084] According to an example of the present invention, taking the service solution data as a BPMN file as an example, the schematic process of processing the historical service solution and operation log data and returning the service solution atlas with weights is as follows: Figure 5As shown, it comprises: step A1, reading historical service scheme data; step A2, parsing a BPMN file, wherein the BPMN file storing the entire service scheme data is parsed to obtain nodes (services) in the entire scheme and edges having a correlation relationship between the nodes; step A3, storing the parsed nodes and edges, initializing the weight of the edges, and obtaining an initial service scheme graph set; for example, initializing the weight of each edge as 0, 0.001, 0.00003, etc. to obtain an initial service scheme graph set, and storing it in an adjacency list; step A4, updating the weight of the edge according to the calculated weight of the edge; step A5, returning the final service scheme graph set. The schematic steps of processing the running log data to obtain the weight of the edge comprise: step B1, reading a running log; step B2, judging whether the successful running is met, if not, going to B1 to read the next data, if yes, going to step B3; step B3, executing the record number plus 1 and going to step B4; step B4, judging whether the record number is greater than or equal to a predetermined number, if yes, going to step B5, if not, going to step B1; step B5, establishing a log window, and counting the execution times of the edge, i.e. counting the execution times of the successful execution of the edge in the log window; step B6, judging whether the number of the remaining running logs is greater than or equal to a predetermined number, if yes, going to step B7, if not, going to step B1 and resetting the record number to 0; step B7, calculating the weight of the edge; then the execution times of the edge are counted according to the above condition, and the comprehensive weight of the edge is calculated, then the corresponding edge in the current service scheme graph is searched, and the weight thereof is updated (through step A5), and finally a weighted service scheme graph is returned.

[0085] According to an example of the present application, the schematic algorithm for calculating the weight of the edge is as follows:

[0086] Algorithm 1 Pretreatment (File SP, File Log, String W)

[0087] Input: historical service scheme data SP, running log data Log, sliding window size W (corresponding to a predetermined number)

[0088] Output: weighted service scheme adjacency list set

[0089]

[0090]

[0091] Second stage: frequent subgraph mining

[0092] The second main process of the present application is to perform frequent subgraph mining. Since a large number of service schemes with weight values are stored in the form of an adjacency list as a service scheme graph after the previous step, the frequent subgraph mining method is used to mine the frequent subgraph based on the service scheme graph set (graph data) generated in the previous stage, so as to realize the preliminary work of constructing the service mode.

[0093] The known graph data is an input parameter of the studied frequent subgraph mining algorithm. For the convenience of understanding, the related definitions in the graph mining process are given first.

[0094] Definition 1: Label graph. The label graph is a graph with labels (also referred to as labels, Label, in some documents) on edges and vertices. It can be expressed as G = (V, E, ∑V, ∑E, L) using a five-tuple. In the formula, V represents the node set of the graph, and records the identification (ID) of each node; E represents the edge set of the graph, ∑E and ∑V represent the label set corresponding to the node set and the edge set of the graph, respectively, and L is a label function representing the mapping relationship of labels to nodes and edges: V→∑V, E→∑E.

[0095] Definition 2: Subgraph. The graph G1 = (V1, E1, ∑V1, ∑E1, L1) is a subgraph of another graph G2 = (V2, E2, ∑V2, ∑E2, L2) when and only when the node set V1 of the graph G1 is a subset of the node set V2 of the graph G2, and the edge set E1 is a subset of E2.

[0096] There are two important concepts in the frequent subgraph mining algorithm:

[0097] Definition 3: Support. The support of a subgraph g in a given graph set G is the proportion of graphs containing the subgraph g in G, which is expressed as:

[0098]

[0099] Definition 4: Frequent subgraph. Given an input graph set G and a minimum support threshold minSUP (also referred to as minimum support, 0 < minSUP ≤ 1), if the subgraph g is a frequent subgraph, then and only then the support of the subgraph g meets the condition: SUP(g, G) ≥ minSUP.

[0100] In the frequent subgraph determination, the support of the subgraph is first calculated, and then the calculation result is compared with the set minimum support. The influence of this variable on the result needs to be analyzed in the algorithm experiment process. Moreover, based on the experimental results, the minimum support is reset.

[0101] There are two basic traversal methods in frequent subgraph mining algorithm, namely breadth-first traversal and depth-first traversal; but, at present, most of the algorithms are for mining of undirected graph, and this kind of data will produce subgraph isomorphism problem, which is defined as follows:

[0102] Definition 5 Subgraph isomorphism: for two graphs G1=(V1,E1,∑V1,∑E1,L1) and G2=(V2,E2,∑V2,∑E2,L2), if there is a bijective function f:V1→V2, and all the node adjacency (directed graph also maintains the directionality of the edge) is maintained, then G1 and G2 are isomorphic, if there is a subgraph G1' in G1 which is isomorphic to G2, then G1' is subgraph isomorphic to G2.

[0103] According to one embodiment of the present application, referring again to Figure 2 A method for constructing service mode based on running log data further comprises: step S3, mining frequent subgraph according to the frequency of each node and edge appearing in the service scheme graph set and the weight of the edge, and constructing service mode based on the mined frequent subgraph.

[0104] In order to realize less change to the original mining method, that is, improving the mining effect by using the weight of the edge, according to one embodiment of the present application, the gSpan mining method is used to mine the frequent subgraph in the service scheme graph set according to the minimum support degree and the DFS coding of the edge, wherein the label of the edge in the DFS coding of the edge is determined according to the frequency of the edge appearing and the weight of the edge. Preferably, the relatively higher label is given to the edge with relatively higher frequency of appearing, and the relatively smaller label is given to the edge with the same frequency of appearing but relatively larger weight. The technical scheme of this embodiment can at least realize the following beneficial technical effects: in the original DFS coding of the edge, the label of the edge is determined according to the frequency of the edge appearing, but this way is relatively coarse, therefore, the DFS coding of the edge is determined in combination with the weight of the edge in the present application, so that the weight of the edge can be simply and efficiently used to improve the mining method, the influence of the correlation strength of the node is concerned during mining, and the effect of mining is improved.

[0105] According to one embodiment of the present application, the frequent subgraph is mined in step S3 in the following manner: S31, obtaining a predetermined minimum support, removing nodes and edges with an occurrence frequency less than the minimum support according to the occurrence frequency of all nodes and edges in the service scheme graph set, and obtaining the remaining nodes and edges; S32, updating the label of the node according to the occurrence frequency of the node for the remaining nodes, wherein a relatively smaller label is assigned to a node with a relatively higher occurrence frequency; S33, updating the label of the edge according to the occurrence frequency of the edge as the first basis for edge sorting and the weight of the edge as the second basis for edge sorting for the remaining edges, wherein a relatively smaller label is assigned to an edge with a relatively higher occurrence frequency and a relatively smaller label is assigned to an edge with the same occurrence frequency but a relatively larger weight; S34, setting the DFS code of the remaining edges in the gSpan mining manner (i.e., the gSpan algorithm) using the updated label of the node and the label of the edge; and S35, mining the frequent subgraph using the frequent pattern mining manner according to the minimum support and the DFS code of the remaining edges. The DFS code of the edge in the gSpan algorithm is described in the form of a five-tuple: edge E = <V i ,V j > represents (i, j, l i ,l (i,j) ,l j ). Wherein, i and j are the labels of the nodes, l i ,l j is the label of the node, and l (i,j) is the label of the edge between the two nodes. If i < j, the edge is called a forward edge; otherwise, it is called a backward edge. In other words, the encoding of the DFS code includes the label i of one node constituting the edge, the label j of the other node constituting the edge, the label l i of one node constituting the edge, the label l (i,j) of the edge, and the label l j of the other node constituting the edge. The technical solution of this embodiment can achieve at least the following beneficial technical effects: The present application uses the weight of the edge as the second basis for sorting the remaining edges, which can adjust the DFS code by taking the association strength of the two nodes corresponding to the edge as a factor, so that the mined frequent subgraph is more accurate.

[0106] The foregoing embodiment is only an adjustment to the generation of the edge label in the gSpan mining method. Further, in order to reduce the probability of occurrence of isomorphic subgraphs, the gSpan mining method can be improved by adding the direction of the edge on the basis of the original DFS coding. According to an embodiment of the present application, the gSpan mining method adopts an improved gSpan mining method, wherein the DFS coding in the improved gSpan mining method comprises: the identification of one node constituting the edge, the identification of another node constituting the edge, the label of one node constituting the edge, the label of the edge, the label of another node constituting the edge, and the direction of the edge. In the original gSpan mining method, the directed graph is not supported. After research and analysis, the inventor finds that the DFS coding can be improved based on the edge, the DFS coding method used in the algorithm is redefined, the description of the direction of the edge is added, and the weight of the edge is considered in the coding process, so that the frequent subgraph mining of the weighted directed graph can be completed. The DFS coding method of the edge in the improved gSpan mining method is expanded to a six-tuple, and the direction of the edge is represented by adding an element d <i,j> , so that the directed graph can be processed like the undirected graph. The six-tuple is described as: (i, j, l i , l (i,j) , l j , d <i,j> ), wherein i, j, l i , l (i,j) , l j can refer to the definition in the foregoing five-tuple, and d <i,j> represents the direction of the edge. The edge includes unidirectional edge and bidirectional edge, and the unidirectional edge is further divided into forward edge and backward edge. Therefore, the direction of the edge can be distinguished by three different values, i.e., the forward edge, the backward edge and the bidirectional edge. For example, -1 represents the unidirectional edge and the forward edge, and the direction is node i←node j; 0 represents the bidirectional edge, and the direction is node i Node j; 1 represents a unidirectional edge and is a backward edge, and the direction is represented as node i→node j. According to one embodiment of the present application, in the improved gSpan mining method, compared with the original gSpan mining method, the size comparison of the direction of the edge is added in the lexicographic comparison. For example, in the improved gSpan mining method, after the lexicographic comparison according to the original gSpan mining method, the direction of the edge is compared to determine the size of the DFS code. When comparing the size of the direction of the edge, the size can be directly compared according to the numerical value, such as: -1<0<1. In some existing gSpan mining methods, the size of the DFS code is determined by directly comparing the size of each item in the five-tuple in turn, and therefore, according to one embodiment of the present application, the identification of one node constituting the edge, the identification of the other node constituting the edge, the label of one node constituting the edge, the label of the edge, the label of the other node constituting the edge, and the direction of the edge are compared in turn to determine the size of the DFS code. It should be understood that, since the order of each item in the DFS code can be adjusted, the order of the direction of the edge in the six-tuple can also be adjusted; alternatively, the rules used in the lexicographic comparison of the direction of the edge are defined differently, thereby generating different embodiments, which are not limited by the present application. The technical scheme of this embodiment can at least achieve the following beneficial technical effects: in the data preprocessing step, the processed data is in the format of a directed graph, and therefore the DFS code of the edge in the improved gSpan mining method is based on this format and is expanded to a six-tuple, thereby reducing the probability of subgraph isomorphism problems and improving the accuracy of the mining results.

[0107] According to one example of the present application, the process of frequent subgraph mining is described below through an illustrative algorithm:

[0108] Algorithm 2: Improved gSpan for frequent subgraph mining

[0109] Input: service plan graph set SL, minimum support min-sup

[0110] Output: mined frequent subgraph set FG

[0111] 1: Begin

[0112] / / Sort and adjust the label according to the frequency of the node in the service plan graph set SL, the frequency and weight of the edge in the service plan graph set SL (explain lines 2-4)

[0113] 2: sort (SL);

[0114] / / Remove infrequent nodes and edges according to the minimum support (explain line 3)

[0115] 3: remove (min-sup);

[0116] / / Reorder the remaining nodes by frequency and adjust labels accordingly, reorder the remaining edges by frequency and weight and adjust labels accordingly (explain line 4)

[0117] 4: reLable(SL);

[0118] / / Put all frequent single edges in the graph into the set FG_1 (similar to frequent 1-item set) (explain line 5)

[0119] 5: FG_1 <- all frequent 1-edge graphs in SL;

[0120] / / Sort the elements in FG_1 by DFS lexicographic order (explain line 6)

[0121] 6: reSort(FG_1);

[0122] / / Frequent single edges can be considered as a frequent subgraph, store them in the frequent subgraph set FG (explain line 7)

[0123] 7: FG <- FG_1;

[0124] / / Extend the subgraph by edges, mine frequent subgraphs, where for each edge e in FG_1, recursively extend and mine frequent subgraphs (explain line 8)

[0125] 8: for each edge e in FG_1 do:

[0126] / / Initialize e as subgraph fg, set fg.SL (the graph set extended by fg) as the graph set containing e (explain line 9)

[0127] 9: initialize(fg),

[0128] / / Mine frequent subgraphs (explain lines 10-13)

[0129] 10: Subgraph_Mining(SL, FG, fg);

[0130] / / Reassign the data in graph set SL after removing edge e to SL (explain line 11)

[0131] 11: SL <- SL - e;

[0132] / / If SL does not meet the minimum support (explain line 12)

[0133] 12: if SL < min-sup:

[0134] / / break out of loop (explain line 13)

[0135] 13: break;

[0136] 14: end

[0137] / / recursively mine subgraph fg by recursive mining function

[0138] Subroutine Subgraph_Mining (SL, FG, fg)

[0139] 1: begin

[0140] / / check if DFS code of subgraph fg is minimal, if not, break (explain lines 2-3)

[0141] 2: if s ≠ min(s):

[0142] 3: return;

[0143] / / if yes, add subgraph fg to frequent subgraph set FG (explain line 4)

[0144] 4: FG <- (FG U fg);

[0145] 5: enumerate fg in SL and count its subgraph c;

[0146] / / for each subgraph c, do (explain line 6):

[0147] 6: for each c do:

[0148] / / if subgraph c is greater than minimum support (explain line 7)

[0149] 7: if support(c) >= min-sup then

[0150] / / assign it to subgraph fg (explain line 8)

[0151] 8: fg <- c;

[0152] / / continue mining frequent subgraphs based on updated fg (explain line 9)

[0153] 9: Subgraph_Mining (SL fg , FG, fg)

[0154] 10: end

[0155] After mining frequent subgraphs, service patterns can be constructed according to the frequent subgraphs. First, service pattern is defined as follows. Service pattern is a sub-fragment of a service scheme, which contains abundant business processing logic, function description and other information. Generally, service pattern can be expressed as a four-tuple, i.e. Figure 6 SM = {MBasicInfo, MCompInfo, MFuncParam, QosInfo}, wherein:

[0156] MBasicInfo: basic information of service pattern, which describes the basic content of the pattern in detail; MBasicInfo = {Mid, Mname, Mfield, Mfuncdesc, CreateDate}; wherein: Mid represents the storage number of the service pattern; Mname represents the name of the service pattern; Mfield represents the classification of the field where the service pattern is located; Mfuncdesc represents the basic function summary of the service pattern; and CreateDate represents the creation time of the service pattern.

[0157] MCompInfo: all atomic services (corresponding to services) contained in the service pattern and the business logic relationship therebetween; Service represents the atomic services contained in the pattern; represents the logic structure (or business logic structure) used to define the business processing logic between the atomic services; and Relation represents the actual business processing logic relationship set between the atomic services. The details are described as follows:

[0158] a) Service: set of atomic services, Service = {S i |S i = (SID, SName, SFunc, SIp, SI, SO, Qos, SRes)}, in this application, the atomic service corresponds to the service in the service scheme, and the specific definition of the atomic service is described in the expression of the atomic service model.

[0159] b) Sequence represents sequential business logic; Or-Split and Or-Join represent selection business logic, wherein Or-Split represents selection business logic of selective execution branch, and Or-Join represents selection business logic of selective merging branch; And-Split and And-Join represent parallel business logic, wherein And-Split represents parallel business logic of subsequent branch of parallel execution, and And-Join represents parallel business logic executed after receiving parameters of two parallel branches; the five kinds of logic combinations can basically meet the requirements of most business logics. The illustrative business logic structure is as followsFigure 7 As shown:

[0160] Figure 7 In a, it is a schematic diagram of the Sequence (sequential business logic, also known as serial logic) logical structure. In this logical structure, through S i ⊙S j Represents atomic service S i After the execution is completed, the atomic service S j Only then can the execution continue, and the output of the former is the input of the latter;

[0161] Figure 7 In b, it is a schematic diagram of the Or-Split (selection logic, branch) logic structure. In this logic structure, through S i ||S j (c1,c2,……,c k ),S l (n1,n2,……,n k ) represents atomic service S j or S l As an atomic service S i The branch is executed, which is equivalent to S i .SO(c1,c2,……,c k )=S j .SI||S i .SO(n1,n2,……,n k )=S l .SI, that is, after executing S i When k input parameters are c1, c2, ..., c k , then the condition is met, that is, branch S is selected j ; If the k input parameters are n1, n2, ..., n k , then the condition is met, that is, branch S is selected l ;

[0162] Figure 7 In c, it is a schematic diagram of the Or-Join (selection logic, merging) logical structure. In this logical structure, through S i (c1,c2,……,c k ),S j (n1,n2,……,n k )⊕S l Represents atomic service S l Will choose atomic service S i or S j One of them is merged and executed, which is equivalent to S i .SO(c1,c1,……,c k )=S lSI j SO(n1, n2,..., n k ) = S l SI, i.e. when S i is executed, if the input parameter values of the K conditions of the atomic service S j are respectively c1, c2,..., c l , which are consistent with the output parameter values of S k , then the parameter transmission is carried out between S i and S i , and the execution is continued; if the input parameter values of the K conditions are respectively n1, n2,..., n l , which are consistent with the output parameter values of S k , then the parameter transmission is carried out between S j and S i , and the execution is continued.

[0163] Figure 7 d is a schematic diagram of an And-Split logical structure, in which S l △S i (c1, c2,..., c j ), S k (n1, n2,..., n l ) indicates that after the execution of the atomic service S k , the atomic services S i and S j must be executed simultaneously, which is equivalent to S l .SO = {S i .SI(c1, c2,..., c j ) U S k .SI(n1, n2,..., n l )}, i.e. after the execution of the atomic service S k , part of the output parameters of S i are used to support the continuous execution of S i , and the other part of the output parameters are used to support the continuous execution of S j .

[0164] Figure 7 e is a schematic diagram of an And-Join logical structure, in which S l (c1, c2,..., c i ), S k (n1, n2,..., n j )◇S k indicates that only when the atomic services S l and S i are executed, the execution of S j is continued.After the concurrent execution of S l is finished, the execution of S l can continue i . S k I = {S j O (n1, n2, …, n k )}. That is, after the concurrent execution of S i and S j is finished, the parameter set after the combination of the two can be used as the input parameter of S l to support the continuous execution of S i .

[0165] c) Op represents the logical structural relationship between S i and S j . Param represents the parameter set transmitted between S i and S j , Param = {content, type}, wherein the parameter i in the parameter set is represented as Param i ∈ (S i O ∪ S j I, i≠j), S i O represents that the parameter is an output parameter of S i , and S j I represents that the parameter is an input parameter of S j . Content is the specific content of the parameter, and type is the data format of the parameter. The definition of the parameter herein is also applicable to the definition of the input and output parameters of the atomic service, and will not be described in detail hereinafter.

[0166] ■MFuncParam: parameter set of the service mode; MFuncParam = {Input, Output}; Input represents the input parameter set, and Output represents the output parameter set. MFuncParam represents an overall parameter interface provided by the service mode to the user.

[0167] ■QosInfo: non-functional constraint service quality attribute (Qos attribute) information set of the service mode, which is obtained based on the Qos attribute of the atomic service contained in the mode and in combination with the business logic structure of the entire service mode, wherein the Qos-related attribute values include the following parameters: {executetime, reliability, throughput, availability} corresponding to execution time, reliability, throughput, and availability, respectively.

[0168] Based on the analysis result of atomic service properties, considering that service mode is generated by combining atomic services according to a reasonable logical structure based on a certain business requirement, the analysis believes that service mode also has the related characteristics of atomic service, namely, the three characteristics of association, a priori and similarity. Among them, the association is embodied by the parameter passing between the business logic structure of service mode and atomic service to complete certain business; the a priori is reflected in the frequency of occurrence in a large number of service schemes and the rich content with reference value; different service modes have similarity in the positioning of functions and business logic structure.

[0169] Service mode is composed of several atomic services, and the atomic service is introduced as follows:

[0170] As a minimum unit in service scheme, the atomic service is represented by an eight-tuple, for example, defined as: S i =(SID,SName,SFunc,STag,SIp,SI,SO,Qos),

[0171] ■SID: ID of atomic service S i ;

[0172] ■SName: service name of atomic service S i ;

[0173] ■SFunc: basic function description information of atomic service S i ;

[0174] ■STag: keyword set for positioning the function of atomic service S i ;

[0175] ■Sip: access address (for example: URL address) of atomic service S i ;

[0176] ■SI: set of input parameters of atomic service S i , each input parameter SInput in SI is expressed in the form of a two-tuple, SInput={content, type}, content represents the content of each input parameter of atomic service S i , and type represents the data format of the parameter;

[0177] ■SO: set of output parameters of atomic service S i , the definition of each output parameter Soutput in SO is similar to Sinput, Soutput={content, type}, content represents the content of atomic service S iThe content of each output parameter, and type indicates the data format adopted by the output parameter;

[0178] Qos: atomic service S i The set of non-functional attribute description information includes four basic parameters, {executetime, reliability, throughput, availability} corresponding to execution time, reliability, throughput and availability.

[0179] It should be understood that a plurality of frequent subgraphs can be mined from the service scheme graph set in general, and a service mode can be constructed by each frequent subgraph, so that a plurality of constructed service modes can be obtained; since the service mode contains a plurality of service fragments, and these fragments are commonly used for constructing service schemes. Therefore, when a user constructs a new service scheme, if it is found that the service scheme to be constructed contains the business logic structure defined by the corresponding service mode, the service mode can be directly selected, and other services and business processing logic that need to be used are extended on the basis of the service mode; thus, the user can more quickly, accurately and efficiently construct the required service scheme according to the existing service mode.

[0180] In order to verify the effect of the present application, the inventors conducted experiments, and the process of the experiments is described below.

[0181] 1) Experimental environment

[0182] The specific experimental environment is Intel(R) Core(TM) i7-8750H CPU@2.20GHz, the memory size is 16GB, the operating system is Windows 10 Professional 64-bit, the development tools are IntelliJ IDEA 2019.2.2, PyCharm 2019.3.3 and MySql 8.0.16. The experimental code uses Java and Python languages.

[0183] 2) Experimental data

[0184] The experimental data adopts a scheme of combining the modified public service process data set with the public link data. The service process data set is graph.data in https: / / github.com / betterenvi / gSpan / blob / master / graphdata / graph.data, which contains 2000 graph sets, and the inventors arranged 1000 graph data sets among them to construct service processes, each service process containing 5-30 atomic services; the log data adopts the link tracking data set publicly disclosed by Ali, and 5000 link data are arranged therefrom to be log data of the above-mentioned 1000 service processes.

[0185] 3) Experimental results and analysis

[0186] The development languages ​​used in the experimental method of the present invention are mainly Java and Python, and database storage is completed using MySQL.

[0187] In order to verify the effectiveness of the method in the present invention, a total of three experiments were designed. Experiment 1 verifies the impact of the sliding window size on the service pattern mining results. Since the present invention uses two source data and conducts experiments using the fused service plan graph with weights, one of which is log data, and its weight needs to be calculated according to the size of the sliding window. Therefore, it is necessary to verify the impact of the sliding window size on the service pattern mining time and results through experiments. Experiment 2 verifies the impact of the minimum support on the mining results, mainly comparing and analyzing the results from the aspects of the number of mined service patterns, mining time, and the average number of nodes in the service pattern. Experiment 3 verifies the accuracy of the mining results. This experiment mainly compares and verifies the improved gSpan mining method and the FFSM algorithm from the F1 value of the mining results.

[0188] Experiment 1 verifies the impact of sliding window size on service pattern mining

[0189] Let the service model mining support be 0.22, increase the sliding window size by 100, and conduct experiments by traversing the data set and simulating window sliding. Figure 8 As can be seen from the figure, the mining time is positively correlated with the window size; the number of service patterns increases with the window size. When the window size reaches a certain level, the number of service patterns gradually decreases, indicating that using too many historical processes for mining may not obtain effective information. Therefore, setting the sliding window size to 400 can most effectively mine service patterns.

[0190] Experiment 2 verifies the impact of minimum support on mining results

[0191] In the experiment, the sliding window size is set to 400 and the minimum support range is 0.1-0.38.

[0192] from Figure 9 As can be seen from the figure, both the running time and the number of mined patterns increase significantly with the decrease of support, indicating that the number of mined service patterns has a positive correlation with the algorithm time;

[0193] from Figure 10As can be seen from the figure, when the support is less than 0.2, the number of service modes decreases rapidly with the increase of the support, and then the number of service modes changes gently, and the average number of nodes of the service mode is maintained at about 3.5, indicating that the support parameter in the algorithm can effectively control the mining effect in the range of 0.18-0.22.

[0194] The third experiment verifies the accuracy of the experimental method

[0195] The inventor manually selects 100 service schemes for testing, and the selection principle is mainly for the data with low service scheme repetition rate. In the final output result, since the result is a single service, it is meaningless, and therefore the frequent subgraph with an average number of nodes of the service mode of two or more is selected.

[0196] In order to verify the accuracy of the mining result of the algorithm, the improved gSpan mining method and the FFSM algorithm are compared through experiments, and the F1 value is used as the final evaluation standard of the algorithm performance. The F1 value is a comprehensive evaluation index for the harmonic average of precision and recall, and the F1 value can be calculated by the following formula:

[0197]

[0198] Wherein, precision represents accuracy, which represents the proportion of correct frequent subgraphs in the selected frequent subgraph set by the algorithm, and can be calculated according to the following formula:

[0199]

[0200] Recall represents recall rate, which represents the proportion of the correct frequent subgraph set selected by the algorithm, and can be calculated according to the following formula:

[0201]

[0202] Wherein, |{relevent}| represents the number of correct frequent subgraphs mined, |{retrieved}| represents the number of frequent subgraphs mined by the improved gSPan mining method, and |{relevent}∩{retrieved}| represents the number of correct frequent subgraphs mined by the algorithm.

[0203] In order to verify the accuracy of the mining result, the present application carries out 10 repeated experiments for different supports, and takes the average value as the final result. Finally, through statistical analysis of the experimental results, the relationship between the F1 value of the two mining algorithms and the support is as shown in the following table: Figure 11

[0204] ​The experimental results show that the F1 value of the mining result increases with the increase of the support, and the improved gSpan mining method has certain improvement compared with the FFSM algorithm; when the support is 0.22 in the previous experiment, the F1 value can reach 0.95, indicating that the accuracy of the mining result of the improved algorithm is guaranteed; when the support is 0.26 and above, the F1 value of the mining result is 1, indicating that the mining method is completely reliable, but since the final mining result is relatively single, it cannot well meet the requirements of the service community in the application, therefore, the mining result with the support less than 0.26 is mainly considered.

[0205] In summary, by studying and analyzing the accuracy of the mining algorithm through the precision rate, recall rate and F1 score, it can be verified that the method in the application has stable accuracy and effectiveness, and it is proved that the algorithm in the application is feasible.

[0206] It should be noted that although the above describes each step in a specific order, it does not mean that each step must be performed in the above specific order, in fact, some of the steps can be executed concurrently, or even the order is changed, as long as the required function can be realized.

[0207] The present application can be a system, a method, and / or a computer program product. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present application.

[0208] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium include the following: 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), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch cards or punched tape, and any suitable combination of the foregoing. A non-transitory, computer-readable storage medium does not include a signal.

[0209] Having described above several embodiments of the application, any modifications and variations that fall within the scope of the described embodiments are also intended to be within the scope of the application. As will be apparent to those of ordinary skill in the art, many modifications and variations of the present application are possible in light of the above teachings. It is, therefore, to be understood that within the scope of the appended claims, the application can be practiced otherwise than as specifically described. The scope of the application should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. The disclosures of each patent, patent application, and publication cited above are hereby incorporated herein by reference, each in its entirety.

Claims

1. A method for constructing a service model based on operation log data, characterized in that: include: S1. Obtain historical service plan data and operation log data. The historical service plan data includes multiple service plans, each of which is composed of multiple services and business processing logic between services. The operation log data includes multiple operation logs, each of which contains a record of whether at least one service in the service plan has successfully run. S2. Construct a service solution graph corresponding to each service solution based on the historical service solution data and the operation log data. The service solution graphs of all service solutions constitute a service solution graph set, wherein each service solution graph is a directed graph including multiple nodes and edges, the nodes represent services, the edges represent business processing logic between services, and each edge is provided with a weight indicating the strength of association between the two nodes connected by the edge obtained based on the operation log data. The weight of each edge is determined in the following manner: one or more log windows and their window times are generated according to the attributes of the record and generation time of each operation log in the operation log data; the number of times the edge is successfully executed in each log window according to the operation log contained in each log window; and the weight of the edge is determined according to the number of times the edge is successfully executed in each log window and the window time of each log window; S3. Mining frequent subgraphs according to the frequency of occurrence of each node and edge in the service solution graph and the weight of the edge, and constructing a service model based on the mined frequent subgraph, wherein step S3 includes mining frequent subgraphs in the following manner: using the gSpan mining method to mine frequent subgraphs in the service solution graph according to the minimum support and the DFS coding of the edge, wherein the edge label in the DFS coding of the edge is determined according to the frequency of occurrence of the edge and the weight of the edge.

2. The method according to claim 1, characterized in that The log windows and their window times are generated as follows: A log window is generated by reading a predetermined number of operation logs indicating successful operation of the service from the operation log data using a sliding window, and the generation time of the last operation log contained in the log window is used as the window time of the log window.

3. The method according to claim 2, characterized in that The weight of each edge is calculated as follows: The number of successful executions in each log window corresponding to the edge is multiplied by a decay factor, the products are summed and divided by the total number of log windows, where the size of the decay factor is negatively correlated with the absolute value of the difference between the window time of the last log window and the window time of the log window.

4. The method according to claim 3, characterized in that The weight of each edge is calculated as follows: in, Represents an edge The weight of Indicates that the edge is in the log window The number of successful executions in represents the attenuation factor, , Indicates the adjustment parameters, , , Indicates the total number of log windows currently used to calculate the weight, Indicates the window time of the last log window and the log window The absolute value of the difference between the window times.

5. The method according to claim 3, characterized in that The method further comprises: A single linked list is maintained for each edge. Each linked list node in the single linked list is used to store the number of successful executions of the edge in a log window and the window time of the log window. When the product of the number of successful executions of the edge in the log window stored in a linked list node multiplied by the corresponding decay factor is less than a predetermined decay threshold, the linked list node is deleted.

6. The method according to claim 1 or 2, characterized in that Assign relatively smaller labels to edges with relatively higher occurrence frequencies, and assign relatively smaller labels to edges with the same occurrence frequencies but relatively larger edge weights.

7. The method according to claim 1 or 2, characterized in that Step S3 includes: Obtain the predetermined minimum support, and based on the frequencies of all nodes and edges appearing in the service solution graph, remove the nodes and edges whose frequencies are less than the minimum support to obtain the remaining nodes and edges; For the remaining nodes, update the node labels according to the node's frequency of occurrence, where nodes with relatively higher frequency of occurrence are assigned relatively smaller labels; For the remaining edges, update the edge labels using the frequency of occurrence as the first basis for edge sorting and the weight of the edge as the second basis for edge sorting. Edges with higher frequencies are assigned smaller labels, while edges with the same frequency but higher weights are assigned smaller labels. Use the updated node and edge labels to set the DFS encoding of the remaining edges in the gSpan mining method; According to the minimum support and the DFS encoding of the remaining edges, the gSpan mining method is used to mine frequent subgraphs.

8. The method according to claim 1 or 2, characterized in that The gSpan mining method is an improved gSpan mining method, wherein the DFS encoding in the improved gSpan mining method includes: the identifier of a node constituting an edge, the identifier of another node constituting the edge, the label of a node constituting the edge, the label of the edge, the label of another node constituting the edge, and the direction of the edge.

9. A method for constructing a service solution, characterized in that: include: Obtain all service models constructed according to the method described in any one of claims 1 to 8; Select one or more service modes from all service modes, and build a service plan based on the selected service modes.

10. A computer-readable storage medium, characterized in that A computer program is stored thereon, and the computer program can be executed by a processor to implement the steps of the method according to any one of claims 1 to 8 and 9.

11. An electronic device, characterized in that: include: one or more processors; as well as a memory, wherein the memory is used to store executable instructions; The one or more processors are configured to implement the steps of the method according to any one of claims 1 to 8 and 9 by executing the executable instructions.

Images