An information system integration service optimization method based on big data processing

Abstract

The application discloses a kind of information system integration service optimization methods based on big data processing, comprising the following steps: obtaining multi-source data in information system integration service and carrying out collection, association, matching and cleaning, obtain integrated service event data set;Extract work order, interface, business system, resource, alarm and personnel object, generate object-oriented service state identification sequence;Service state transition model is constructed based on improved object-oriented generalized stochastic Petri net model;Through object token playback and state deduction, concurrent call conflict, resource waiting, interface blocking, abnormal retry and process rework are identified, and service bottleneck feature set is obtained;According to service influence range, generate service optimization priority sequence and service adjustment strategy set, and realize closed-loop update through configuration verification and data backflow.The application can improve the accuracy of information system integration service bottleneck positioning and optimization adjustment.

Description

Technical Field

[0001] This invention relates to the field of information system integration service technology, and more specifically to an information system integration service optimization method based on big data processing. Background Technology

[0002] As the level of informatization in sectors such as government affairs, finance, manufacturing, energy, education, and healthcare continues to increase, the demand for data exchange, interface calls, resource collaboration, and service linkage between different business systems is also growing. Information system integration services have gradually evolved from single-system deployments to comprehensive service processes involving multi-system, multi-interface, multi-resource, and multi-role collaboration. During system integration services, data such as work order data, interface call data, system operation data, resource monitoring data, alarm data, and service feedback data are typically generated. This data is distributed across different business platforms, operation and maintenance platforms, interface gateways, monitoring systems, and work order systems, and is characterized by complex sources, inconsistent field structures, different time granularities, implicit object relationships, and large data scale.

[0003] Existing methods for optimizing information system integration services largely rely on manual experience, fixed rules, or single-indicator statistics for analysis. They typically judge service anomalies based on work order processing time, interface failure count, alarm quantity, or resource utilization. While these methods can identify some explicit problems, they struggle to reconstruct the complete service state transition process and explain the correlation between interface blocking, resource waiting, abnormal retries, concurrent call conflicts, and process rework. When multiple work orders, interfaces, business systems, and resource nodes participate in the same service process simultaneously, traditional methods tend to treat problems piecemeal, failing to accurately determine the true source and scope of impact of bottleneck nodes.

[0004] Furthermore, information system integration services exhibit distinct discrete event characteristics. The processes of request acceptance, interface configuration, data synchronization, joint testing, resource application, exception handling, and result feedback are not simple linear flows but involve state changes such as concurrency, waiting, mutual exclusion, competition, rollback, and recovery. Existing methods based on log statistics or ordinary process analysis are insufficient in expressing the collaborative states of multiple objects, making it difficult to accurately model the state transition relationships between service objects. This results in service optimization strategies often remaining at the level of alarm handling or work order expediting, failing to generate coordinated optimization results oriented towards interfaces, resources, work order paths, and exception handling paths.

[0005] Therefore, how to provide an information system integration service optimization method based on big data processing is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] One objective of this invention is to propose an information system integration service optimization method based on big data processing. This invention fully utilizes big data processing, object-oriented modeling, and an improved object-oriented generalized stochastic Petri net model. It details the process of event-driven processing, object-centric modeling, service state transition analysis, bottleneck feature identification, optimization priority generation, and closed-loop updating of work order data, interface call data, system operation data, resource monitoring data, alarm data, and service feedback data during the information system integration service process. This method can transform scattered service data into a predictable service state transition model and identify concurrent call conflicts, resource waiting, interface blocking, abnormal retries, and process rework states based on object token replay results. It then generates a service optimization priority sequence and a set of service adjustment strategies, possessing advantages such as strong data correlation, accurate bottleneck location, highly targeted service optimization, and continuous model updates.

[0007] An information system integration service optimization method based on big data processing according to an embodiment of the present invention includes the following steps: S1. Obtain work order data, interface call data, operation data, resource data, alarm data and feedback data from the information system integration service, and perform distributed collection, format unification, time association, object matching, event merging and anomaly cleaning on the above data to obtain the integration service event data set; S2. Extract work order objects, interface objects, business system objects, resource objects, alarm objects, and personnel objects from the integrated service event data set. Perform object-centralized processing on the status fields, flow fields, and association fields of each object to obtain an object-oriented service status identifier sequence. S3. Based on the object-oriented service state identifier sequence, construct an improved object-oriented generalized stochastic Petri net model, map the object state to the place node, the object identifier to the token, and the service action to the transition node, to obtain the service state transition model. S4. Based on the service state transition model, token replay and state inference are performed on the actual service event trajectory to identify concurrent call conflicts, resource waiting, interface blocking, abnormal retry and process rework states, and obtain the service bottleneck feature set. S5. Analyze the service impact range based on the service bottleneck feature set and object association relationship, and perform priority analysis based on the service impact range to obtain the service optimization priority sequence and service adjustment strategy set; S6. Generate a set of optimization configurations to be executed based on the service adjustment strategy set, perform rule verification, dependency verification and conflict verification on the set of optimization configurations to be executed, and feed the optimized data back to the model to obtain the service optimization result after closed-loop update.

[0008] Optionally, step S2 includes the following steps: S21. Based on the work order number, interface number, system number, resource number, alarm number, and personnel number of the integrated service event data set, identify and group the service objects in the same service process to obtain the service object set; S22. Extract relationships based on the calling relationships, dependency relationships, processing relationships, and feedback relationships between objects in the service object set to obtain a service object association relationship set; S23. Based on the running status, processing status, occupancy status, abnormal status and feedback status of the service object set, perform status coding to obtain the object status code set; S24. Organize the service object association set and the object status code set according to the time sequence to obtain the object-oriented service status identifier sequence.

[0009] Optionally, step S3 includes the following steps: S31. Based on the object type and object status, map the work order, interface, system, resource, alarm and personnel status to the nodes of the object status library to obtain the object status library set; S32. Based on the state change events, map service flow, interface call, resource request, exception handling and result feedback to transition nodes to obtain a set of service action transitions; S33. Generate an object identifier token based on the object identifier and object status location, and configure it to the corresponding object status database node to obtain the initial service status identifier; S34. Based on the triggering conditions, waiting distribution, occurrence frequency and recovery status of the service action transition set, configure the instant transition attributes, random transition attributes, trigger rate parameters, occurrence probability parameters and object constraint attributes for the transition nodes to obtain the transition parameter set; S35. Based on the set of object state library, the set of service action transitions, the initial service state identifier and the set of transition parameters, construct input arc, output arc, inhibition arc and object association arc to generate an improved object-oriented generalized stochastic Petri net model and obtain the service state transition model.

[0010] Optionally, step S32 includes the following steps: S321. Identify object state changes between adjacent events based on the object-oriented service state identifier sequence to obtain a candidate state change event set; S322. Determine the action type based on the preceding object state, following object state, and trigger field in the candidate state change event set to obtain a service action type set; S323. Merge repetitive actions, equivalent actions, and invalid actions according to the service action type set to obtain a standardized service action set; S324. Construct service action transition nodes based on the standardized service action set and the relationship between service objects to obtain the service action transition set.

[0011] Optionally, step S34 includes the following steps: S341. Based on the action triggering conditions in the service action transition set, mark the state transition actions that do not consume waiting time as instant transitions to obtain the instant transition set. S342. Based on interface calls, resource requests, data synchronization, joint debugging tests, and manual processing actions, mark service actions with duration and probability of occurrence as random transitions to obtain a set of random transitions. S343. Generate a set of transition weight parameters based on the occurrence frequency, waiting distribution, anomaly recovery, and triggering state of the random transition set; S344. Based on the immediate transition set, the random transition set, and the transition weight parameter set, configure object constraint attributes for synchronization, mutual exclusion, waiting, resource contention, and interface dependency relationships between service objects to obtain the transition parameter set.

[0012] Optionally, step S4 includes the following steps: S41. Perform object token replay based on the service state transition model and the actual service event trajectory to obtain the service state replay result; S42. Based on the service status replay results, identify the token retention, token accumulation, and token missing states in the nodes of the object status database to obtain the service waiting state set. S43. Based on the service waiting state set, trace the corresponding transition nodes, object identification tokens and object association arcs to obtain concurrent call conflict paths, interface blocking paths, resource contention paths, abnormal retry paths and process rework paths; S44. Based on the above path, bottlenecks are merged to obtain a set of service bottleneck features.

[0013] Optionally, step S42 includes the following steps: S421. Based on the token entry and exit status of each object status storage node in the service status replay results, identify storage nodes with waiting accumulation and obtain a set of candidate waiting nodes. S422. Based on the object type and service stage corresponding to the candidate waiting node set, distinguish between interface waiting nodes, resource waiting nodes, manual processing waiting nodes, and exception recovery waiting nodes to obtain a categorized waiting node set. S423. Extract the set of waiting trigger actions based on the preceding transitions, following transitions, and object identifier tokens associated with each node in the classification waiting node set; S424. Perform link tracing based on the set of waiting trigger actions, object association arcs, and service object association relationships to obtain the set of service waiting states.

[0014] Optionally, step S5 includes the following steps: S51. Based on the service bottleneck feature set and the relationship between service objects, extract the number of times the bottleneck occurs, the bottleneck duration status, the number of affected objects, the number of associated work orders, the cross-system impact path, and the service feedback results to obtain the service impact feature set. S52. Based on the service impact feature set, sort the interface blocking nodes, resource contention nodes, abnormal retry nodes, process rework nodes, and concurrent call conflict nodes to obtain the service optimization priority sequence; S53. Based on the service optimization priority sequence, match different bottleneck nodes to interface rearrangement, resource reallocation, work order path adjustment, exception handling path adjustment and concurrent call control adjustment to obtain an initial service adjustment strategy set; S54. Based on the initial service adjustment strategy set, perform action merging, deduplication, and object dependency marking to obtain the service optimization priority sequence and service adjustment strategy set.

[0015] Optionally, S52 includes the following steps: S521. Generate a bottleneck impact range identifier based on the number of affected objects, the number of associated work orders, and the cross-system impact path; S522. Generate a bottleneck stability indicator based on the number of times the bottleneck occurs and the duration of the bottleneck. S523. Generate a service response impact identifier based on the service feedback results and the relationship between the business systems; S524. Based on the bottleneck impact range identifier, bottleneck stability identifier, and service response impact identifier, a comprehensive sorting is performed to obtain the service optimization priority sequence.

[0016] Optionally, step S6 includes the following steps: S61. Generate a set of optimization configurations to be executed based on the service adjustment strategy set, including interface call order, resource allocation relationship, work order flow path and exception handling path; S62. Perform rule, dependency and conflict checks on the set of optimization configurations to be executed to obtain a set of executable service optimization configurations; S63. Perform configuration updates based on the executable service optimization configuration set, collect optimized multi-source runtime data, and obtain the optimized service event data set; S64. Update the object state library, token distribution state, transition nodes, object constraint attributes and transition parameters in the model according to the optimized service event data set to obtain the service optimization result after closed-loop update.

[0017] The beneficial effects of this invention are as follows: By distributing, time-correlated, object-matched, and event-merging the work order data, interface call data, system operation data, resource monitoring data, alarm data, and service feedback data in information system integration services, this invention transforms service data that was originally scattered across different platforms and systems into a unified integrated service event data set. Compared to relying solely on a single work order record or a single interface log, this invention establishes a foundation for the correlation between work orders, interfaces, business systems, resources, alarms, and personnel, thereby improving the completeness of service analysis from a data perspective.

[0018] This invention constructs an improved object-oriented generalized stochastic Petri net model, mapping service object states to object state database nodes, service object identifiers to object identifier tokens, and service actions to transition nodes. This allows for a unified expression of concurrency, waiting, mutual exclusion, resource contention, and anomaly recovery relationships in information system integration services. Compared to ordinary flowchart or rule-based analysis methods, this invention can more accurately depict the service state transition process involving multiple objects, avoiding the problem of incomplete state relationship representation in complex service scenarios.

[0019] This invention, through object token replay and state transition simulation of actual service event trajectories, can identify token retention, token accumulation, and token missing states in the object state database nodes. It further tracks concurrent call conflict paths, interface blocking paths, resource contention paths, abnormal retry paths, and process rework paths. Compared to methods that only count interface failures, resource utilization, or work order timeout durations, this invention can pinpoint service bottlenecks from the state transition process itself, improving the accuracy and interpretability of bottleneck identification.

[0020] This invention analyzes the service impact scope based on a set of service bottleneck characteristics and the relationships between service objects. It comprehensively considers factors such as the frequency of bottleneck occurrences, duration, number of affected objects, number of related work orders, cross-system impact paths, and service feedback results to generate a service optimization priority sequence and a set of service adjustment strategies. Compared to methods that prioritize based on alarm levels or manual experience, this invention ensures that the optimization order better reflects the actual service impact, improving the targeting and execution efficiency of information system integration service optimization.

[0021] This invention performs rule verification, dependency verification, and conflict verification on the set of configurations to be optimized, and then feeds the optimized service event data back to an improved object-oriented generalized stochastic Petri net model, achieving a closed-loop update of service optimization results. Compared to methods that output optimization suggestions all at once, this invention can continuously correct object state locations, token distribution states, transition nodes, object constraint attributes, and transition parameters based on subsequent runtime data, enabling the model to adapt to changes in different service stages, different interface environments, and different business system collaboration relationships. Attached Figure Description

[0022] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of an information system integration service optimization method based on big data processing proposed in this invention; Figure 2 This is a schematic diagram of the improved object-oriented generalized stochastic Petri net model structure proposed in this invention; Figure 3 This is a schematic diagram of the service bottleneck identification and closed-loop optimization process proposed in this invention. Detailed Implementation

[0023] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0024] refer to Figures 1-3 An information system integration service optimization method based on big data processing includes the following steps: S1. Obtain work order data, interface call data, operation data, resource data, alarm data and feedback data from the information system integration service, and perform distributed collection, format unification, time association, object matching, event merging and anomaly cleaning on the above data to obtain the integration service event data set; S2. Extract work order objects, interface objects, business system objects, resource objects, alarm objects, and personnel objects from the integrated service event data set. Perform object-centralized processing on the status fields, flow fields, and association fields of each object to obtain an object-oriented service status identifier sequence. S3. Based on the object-oriented service state identifier sequence, construct an improved object-oriented generalized stochastic Petri net model, map the object state to the place node, the object identifier to the token, and the service action to the transition node, to obtain the service state transition model. S4. Based on the service state transition model, token replay and state inference are performed on the actual service event trajectory to identify concurrent call conflicts, resource waiting, interface blocking, abnormal retry and process rework states, and obtain the service bottleneck feature set. S5. Analyze the service impact range based on the service bottleneck feature set and object association relationship, and perform priority analysis based on the service impact range to obtain the service optimization priority sequence and service adjustment strategy set; S6. Generate a set of optimization configurations to be executed based on the service adjustment strategy set, perform rule verification, dependency verification and conflict verification on the set of optimization configurations to be executed, and feed the optimized data back to the model to obtain the service optimization result after closed-loop update.

[0025] In this embodiment, S1 specifically includes: The information system integration service platform obtains the work order number, work order type, submission time, acceptance time, processing personnel, processing node, processing opinion, and completion status from the work order system.

[0026] The platform obtains the interface number, calling system, called system, request time, response time, call result, number of retries, error code and return status from the interface gateway.

[0027] The platform obtains system number, service module, running status, access volume, abnormal response, service restart record and data synchronization status from the business system running platform.

[0028] The platform obtains the occupancy, waiting, and release status of server resources, database resources, middleware resources, message queue resources, and network channel resources from the resource monitoring platform.

[0029] The platform obtains alarm number, alarm type, triggering object, trigger time, recovery time, processing status, and repeated triggering status from the alarm platform.

[0030] The platform obtains feedback recipients, feedback content, feedback status, service evaluation, confirmation results, and supplementary processing requests from the service feedback platform.

[0031] The platform performs distributed aggregation of the aforementioned work order data, interface call data, system operation data, resource monitoring data, alarm data, and service feedback data, and divides the data from different sources into several data fragments according to data type, access channel, and time batch.

[0032] For each data shard, the platform uses a unified field format to map fields that represent the same meaning across different platforms to a unified field name.

[0033] When there is a correlation between the task number in the work order system, the request link number in the interface gateway, and the event number in the alarm platform, the platform will uniformly map them to the service event association identifier.

[0034] The platform continues to perform time correlation processing, converting time fields generated by different systems into a unified time format, and establishing a time series according to the event occurrence time, event reception time, and event writing time.

[0035] When time delays exist between different systems, the platform corrects the time sequence based on the interface request-response relationship, work order flow records, alarm trigger records, and resource status change records to prevent subsequent models from mistakenly writing delays as actual process rollbacks.

[0036] The platform matches service object identifiers, associating work order numbers, interface numbers, business system numbers, resource numbers, alarm numbers, and personnel numbers with the same service process, thus forming an object identifier mapping relationship.

[0037] The object identifier mapping relationship is used to describe which objects are involved in a service event.

[0038] A single API call failure event can be associated with a work order object, an API object, two business system objects, a resource object, an alarm object, and a personnel object.

[0039] The platform performs event merging for repeatedly collected events, retains key events where the service status has changed, and deletes invalid events that are completely duplicated, have severely missing fields, or cannot restore the associated objects.

[0040] The platform cleans abnormal fields, marking missing times, invalid numbers, unidentifiable objects, and data that clearly does not conform to the service process logic as events to be reviewed.

[0041] The platform can restore the fields by analyzing upstream and downstream events, and complete the object identifier and status fields based on the relationship between the preceding and following events.

[0042] After the above processing, the platform obtains an integrated service event data set.

[0043] Each event data entry in this collection includes at least the event identifier, event time, event type, associated object, object status, triggering action, source system, and processing result.

[0044] In this embodiment, S2 specifically includes: The platform extracts work order objects, interface objects, business system objects, resource objects, alarm objects, and personnel objects from the object identifier field in the integrated service event data set to obtain a service object set.

[0045] Work order objects are identified by work order number, interface objects by interface number, business system objects by system number, resource objects by resource number, alarm objects by alarm number, and personnel objects by personnel number.

[0046] When there are multiple interface objects and multiple resource objects in the same service process, the platform retains the independent identifier of each object and does not merge them into a single process node, so that the subsequent model can express the concurrency of multiple objects and the relationship of resource competition.

[0047] The platform extracts relationships based on the calling relationships, dependency relationships, processing relationships, and feedback relationships between objects in the service object set, thus obtaining a set of service object association relationships.

[0048] The call relationship is used to represent the request and response relationship between the interface object and the business system object.

[0049] Dependency relationships are used to represent the dependencies between business system objects and resource objects, database objects, or middleware objects.

[0050] Processing relationships are used to represent the processing relationships between personnel objects, work order objects, and alarm objects.

[0051] Feedback relationships are used to represent the confirmation relationships between service feedback objects, work order objects, and business system objects.

[0052] The platform further encodes the status of the service recipients.

[0053] The statuses of work order objects—created, accepted, processing, pending integration, pending confirmation, completed, and reworked—are converted into work order status codes.

[0054] The states of an interface object, such as pending configuration, in call, waiting for response, successful call, failed call, and retrying, are converted into interface state codes.

[0055] The idle, occupied, waiting, congested, and released states of resource objects are converted into resource state codes.

[0056] Alarm objects and personnel objects generate status codes according to their corresponding statuses.

[0057] Object state coding includes object type, object number, state meaning, event time, and associated action.

[0058] The platform serializes the set of object status codes and the set of service object associations according to the event occurrence time and service flow order, to obtain an object-oriented service status identifier sequence.

[0059] Each item in the sequence includes the time when the event occurred, the object identifier, the object state, the associated object, the triggering action, and the relationship between the preceding and following states.

[0060] Object-oriented service status identifier sequences can simultaneously express the status changes of multiple objects in the same service process, avoiding the problem that a single work order process sequence is difficult to express the concurrent relationships of multiple interfaces, multiple resources, and multiple systems.

[0061] In this embodiment, S3 specifically includes: The platform constructs an improved object-oriented generalized stochastic Petri net model based on the sequence of service status identifiers.

[0062] This model is based on generalized random Petri nets and introduces object state storage, object identification tokens, object constraint attributes, and object association arcs to express the multi-object collaborative relationships in information system integration services.

[0063] The platform maps work orders, interfaces, business systems, resources, alarms, and personnel statuses to nodes in the object status database based on object type and object status, thus obtaining a collection of object status databases.

[0064] The object state library node is used to represent the state position of a service object in a certain service stage.

[0065] The processing status of a work order object corresponds to the work order processing database node, the waiting response status of an interface object corresponds to the interface waiting response database node, and the congestion status of a resource object corresponds to the resource congestion database node.

[0066] The platform maps service flow, interface call, resource request, exception handling and result feedback into transition nodes based on state change events, thus obtaining a set of service action transitions.

[0067] Transition nodes represent service actions that cause a change in the state of a service object.

[0068] Service actions include work order acceptance, interface configuration, interface call, data synchronization, resource application, joint debugging and testing, exception alarm, manual handling, interface retry, resource release and result feedback.

[0069] The platform generates an object identifier token based on the object identifier and the object status location, and configures the object identifier token to the corresponding object status database node to obtain the initial service status identifier.

[0070] The object identifier token is used to indicate the current position of a specific service object in the model.

[0071] A work order object token being in the work order processing repository node indicates that the work order is currently being processed.

[0072] An interface object token in the interface waiting response repository node indicates that the interface is in the waiting response phase.

[0073] If a resource object token is in a resource congestion repository node, it means that the resource has become a congestion object that may affect the service process.

[0074] Based on the triggering conditions, waiting distribution, occurrence frequency, and recovery status of the service action transition set, the platform configures instant transition attributes, random transition attributes, trigger rate parameters, occurrence probability parameters, and object constraint attributes for the transition nodes, thereby obtaining a transition parameter set.

[0075] The instant transition attribute is used to represent state transition actions that do not consume service wait time.

[0076] When a work order status changes from "created" to "accepted," or an alarm status changes from "triggered" to "pending confirmation," the corresponding action can be set to change immediately.

[0077] Random transition attributes are used to represent service actions that have a duration and a probability of occurrence.

[0078] Interface calls, data synchronization, resource requests, joint debugging tests, manual handling, and exception recovery can all be set to random transitions.

[0079] The transition trigger rate parameter is generated based on the ratio between the number of times the same type of service action appears in the historical event trajectory and the total number of service events.

[0080] The probability parameter of a transition is generated based on the proportion of different subsequent transitions occurring under the same preceding object state.

[0081] The abnormal recovery parameters are generated based on the average recovery time from the triggering of the abnormality to the completion of the recovery, the number of repeated triggers, and the recovery success status.

[0082] The higher the frequency of a certain transition node in the historical trajectory, the more stable the waiting time, and the clearer the successful recovery state, the higher the confidence level of the corresponding transition parameters in model playback and state inference.

[0083] Object constraint attributes are used to limit synchronization relationships, mutual exclusion relationships, waiting relationships, resource contention relationships, and interface dependencies between different objects.

[0084] Synchronization means that multiple objects must simultaneously meet state conditions before subsequent service actions can be triggered.

[0085] Mutual exclusion means that multiple service actions cannot occupy the same resource object at the same time.

[0086] A wait relationship indicates that a service object must wait for another service object to complete its state transition before it can continue its flow.

[0087] Resource contention refers to the competitive state that occurs when multiple interface objects or work order objects simultaneously request the same resource object.

[0088] Interface dependency means that the result of calling an interface object affects the subsequent state of another interface object or business system object.

[0089] The platform constructs input arcs, output arcs, suppression arcs, and object association arcs based on the object state library set, service action transition set, initial service state identifier, and transition parameter set.

[0090] The input arc represents the preconditions from the place node to the transition node.

[0091] The output arc represents the subsequent state from the transition node to the storage node.

[0092] A suppression arc means that a certain transition is prohibited from being triggered when a certain token state exists on a certain place node.

[0093] Object association arcs represent the dependency, synchronization, and competition relationships between multiple objects.

[0094] After the above construction, the platform generates an improved object-oriented generalized stochastic Petri net model and obtains a service state transition model.

[0095] In this embodiment, S32 specifically includes: The platform identifies object state changes between adjacent events based on the sequence of object-oriented service state identifiers, thus obtaining a set of candidate state change events.

[0096] When an interface object transitions from a call to a state waiting for a response, the platform identifies this change as a candidate state change event for the interface waiting class.

[0097] When a resource object changes from idle to occupied, the platform identifies this change as a candidate status change event for resource request.

[0098] When a work order object changes from being processed to being reworked, the platform identifies this change as a candidate status change event for the process rework category.

[0099] The platform determines the action type based on the preceding object state, the following object state, and the trigger field in the candidate state change event set, thus obtaining a service action type set.

[0100] Trigger fields include interface request fields, resource request fields, alarm trigger fields, manual processing fields, and feedback confirmation fields.

[0101] The platform merges repetitive actions, equivalent actions, and invalid actions based on the set of service action types to obtain a standardized set of service actions.

[0102] Repetitive actions refer to actions of the same object that are repeatedly recorded in a series of events without any substantial change in its state.

[0103] Equivalent actions refer to records with different field names on different platforms but corresponding to the same service action.

[0104] Invalid actions refer to records that cannot be associated with changes in object state or do not affect service state migration.

[0105] The platform constructs service action transition nodes based on the standardized service action set and the relationship between service objects, thus obtaining the service action transition set.

[0106] Each service action transition node includes action type, preceding location, following location, associated object, triggering condition, and transition attributes.

[0107] In this embodiment, S34 specifically includes: The platform marks state transition actions that do not consume waiting time as instant transitions based on the action triggering conditions in the service action transition set, thus obtaining the instant transition set.

[0108] Instant transitions are used to describe actions that do not reflect a clear service duration, such as logical judgments, status confirmations, and field matching.

[0109] The platform marks service actions with duration and probability of occurrence as random transitions based on interface calls, resource requests, data synchronization, joint debugging tests, and manual processing actions, thus obtaining a set of random transitions.

[0110] Random transitions are used to describe actions in system integration services that involve uncertainty in waiting time, execution time, and results.

[0111] The platform generates a set of transition weight parameters based on the frequency of occurrence, waiting distribution, anomaly recovery, and triggering status of the random transition set.

[0112] The frequency of occurrence is determined by the number of times the same action appears in the historical event trajectory.

[0113] The waiting distribution is obtained by statistically analyzing the difference between the action trigger time and the action completion time.

[0114] Anomaly recovery is determined by the sequence of service events from the triggering of the anomaly to the completion of the recovery.

[0115] The trigger state is determined by the state of the object token in the transition pre-requisite library.

[0116] The platform configures object constraint attributes for synchronization, mutual exclusion, waiting, resource contention, and interface dependency relationships between service objects based on the set of instant transitions, the set of random transitions, and the set of transition weight parameters, thus obtaining the set of transition parameters.

[0117] The transition parameter set is used to control the triggering conditions, triggering order, and triggering results of each transition node in the service state transition model.

[0118] In this embodiment, S4 specifically includes: The platform inputs the actual service event trajectory into the service state migration model and performs object token replay according to the event time sequence to obtain the service state replay result.

[0119] Object token replay refers to mapping the state changes of each object during the actual service process to the corresponding object state database node, and moving the object identifier token according to the triggering result of the transition node.

[0120] When the actual event trajectory matches the preconditions in the model, the token completes the state transition according to the input arc, transition node, and output arc.

[0121] When the actual event trajectory fails to trigger a corresponding changeover, the platform records the playback deviation and marks it as potentially indicating process anomalies, missing data, or object dependency conflicts.

[0122] The platform identifies token retention, token accumulation, and token missing states in the nodes of the object status database based on the service status replay results, and obtains a set of service waiting states.

[0123] Token retention indicates that the object identifier token remains in the state database node of a certain object for an extended period of time, suggesting that there is a waiting or processing delay in the service process involving that object.

[0124] The criteria for determining token retention are: the object identifier token stays in a node of a certain object state database for more than 1.5 times the historical average stay time of similar service phases, and no normal post-transition is triggered.

[0125] Token stacking indicates that multiple object identifier tokens are concentrated in the same object state repository node, suggesting that there is congestion in the interface, resource, or personnel processing links corresponding to that state.

[0126] The criteria for determining token accumulation are: the number of object identifier tokens existing simultaneously in the same object state database node exceeds twice the historical average number of tokens of that node, or the number of tokens entering in multiple consecutive service batches is greater than the number of tokens leaving.

[0127] A missing token indicates that a certain transition node should have a preceding object token, but the corresponding token did not appear during the actual replay process, indicating that there was a jump, omission in processing, or missing data in the service process.

[0128] The criterion for determining missing tokens is: a certain transition node meets the conditions for generating a subsequent state, but lacks the necessary preceding object identifier token or associated object token, resulting in the model replay path being unable to close.

[0129] The platform tracks the corresponding transition nodes, object identifier tokens, and object association arcs based on the service waiting state set to obtain concurrent call conflict paths, interface blocking paths, resource contention paths, abnormal retry paths, and process rework paths.

[0130] Concurrent call conflict path is used to represent a path where multiple interface objects or business system objects trigger calls simultaneously and wait due to mutual exclusion constraints.

[0131] Interface blocking paths are used to represent the paths in which an interface object remains in a state that is either in a call, waiting for a response, or retrying for an extended period of time.

[0132] Resource contention path is used to represent a path where multiple work order objects or interface objects simultaneously request the same resource object, resulting in resource waiting.

[0133] The abnormal retry path is used to represent the path in which the interface object or business system object repeatedly enters the retry state after the alarm object is triggered.

[0134] The process rework path is used to represent the path that a work order object takes from the status of being processed, pending confirmation, or completed to being reworked.

[0135] The platform performs bottleneck merging based on the above path to obtain a set of service bottleneck features.

[0136] Bottleneck merging merges multiple bottleneck paths belonging to the same interface, resource, business system, or service phase, preventing the same problem from being counted repeatedly.

[0137] The service bottleneck feature set includes basic information such as bottleneck type, bottleneck object, associated objects, bottleneck path, persistent status, occurrence frequency, and scope of impact.

[0138] In this embodiment, S42 specifically includes: Based on the token entry and exit status of each object's status repository node in the service status replay results, the platform identifies repository nodes with accumulating waiting information and obtains a set of candidate waiting nodes.

[0139] When the number of tokens entering a storage node exceeds the number of tokens leaving the storage node and the difference persists, the storage node is identified as a candidate waiting node.

[0140] Based on the object type and service stage corresponding to the candidate waiting nodes, the platform distinguishes between interface waiting nodes, resource waiting nodes, manual processing waiting nodes, and exception recovery waiting nodes, thus obtaining a set of categorized waiting nodes.

[0141] The interface waiting node corresponds to the state of the interface object waiting for a response, a failed call, or a retry.

[0142] The resource waiting node corresponds to the state of resource object occupancy, congestion, or delayed release.

[0143] The status of personnel objects corresponding to the manual processing waiting nodes is pending assignment, in process, or awaiting feedback.

[0144] The abnormal recovery waiting node corresponds to the alarm object in the status of pending confirmation, being processed, or being repeatedly triggered.

[0145] The platform extracts the set of waiting trigger actions based on the preceding transitions, following transitions, and object identifier tokens associated with each node in the category of waiting nodes.

[0146] The set of actions to be triggered is used to describe the combination of service actions that cause a waiting state.

[0147] The platform performs link tracing based on the set of waiting trigger actions, object association arcs, and service object association relationships to obtain a set of service waiting states.

[0148] The service waiting state set not only records the waiting nodes, but also the preceding actions, associated objects, and subsequent impact paths that result from the waiting.

[0149] In this embodiment, S5 specifically includes: Based on the service bottleneck feature set and the relationship between service objects, the platform extracts the number of times the bottleneck occurs, the bottleneck duration, the number of affected objects, the number of related work orders, the cross-system impact path, and the service feedback results to obtain the service impact feature set.

[0150] The number of times a bottleneck occurs is used to indicate how frequently the same bottleneck object is identified in the service event track.

[0151] The bottleneck persistence state is used to represent the persistent state of a bottleneck object in the corresponding state library node.

[0152] The number of affected objects indicates the number of work order objects, interface objects, business system objects, and resource objects that are directly or indirectly affected by the bottleneck.

[0153] The number of associated work orders is used to indicate the scope of service tasks involved in the bottleneck.

[0154] Cross-system impact path is used to represent the path by which a bottleneck object affects multiple business systems through interface calls and object dependencies.

[0155] Service feedback results are used to indicate user confirmation, supplementary processing requests, rework feedback, and service completion feedback.

[0156] The platform generates a bottleneck impact range identifier based on the set of service impact characteristics.

[0157] Bottleneck impact scope identification includes local impact, link impact, and cross-system impact.

[0158] Local impact means that the bottleneck only affects a single work order object, a single interface object, or a single resource object.

[0159] Link impact indicates that the bottleneck affects multiple interface objects, resource objects, personnel objects, or alarm objects in the same service link.

[0160] Cross-system impact means that the bottleneck affects two or more business system objects through interface dependencies, or affects the data synchronization and joint debugging process between multiple business systems.

[0161] The platform generates a bottleneck stability identifier based on the number of times a bottleneck occurs and the duration of the bottleneck.

[0162] Bottleneck stability indicators include occasional bottlenecks, recurring bottlenecks, and persistent bottlenecks.

[0163] Intermittent bottlenecks indicate that the bottleneck occurs in a small number of service trajectories and lasts for a shorter period than the average duration of similar phases.

[0164] A recurring bottleneck indicates that the bottleneck appears repeatedly in multiple service trajectories.

[0165] A persistent bottleneck indicates that the bottleneck exists for a long time in the same object's state library, where tokens are stuck or piled up.

[0166] The platform generates service response impact identifiers based on service feedback results and the relationship between business systems.

[0167] Service response impact indicators include low-impact feedback, rework feedback, and service interruption feedback.

[0168] Low impact feedback indicates that the service outcome has been confirmed and no rework has been required.

[0169] Rework feedback indicates that the service feedback has caused the work order to re-enter the rework status.

[0170] Service interruption feedback indicates that a bottleneck has caused business system objects to enter a state of service unavailability or integration failure.

[0171] The platform sorts services based on bottleneck impact range identifier, bottleneck stability identifier, and service response impact identifier to obtain a service optimization priority sequence.

[0172] Bottleneck nodes corresponding to cross-system impact, persistent bottlenecks, and service interruption feedback are prioritized over those corresponding to local impact, occasional bottlenecks, and low-impact feedback.

[0173] Based on the service optimization priority sequence, the platform matches different bottleneck nodes to interface rearrangement, resource reallocation, work order path adjustment, exception handling path adjustment, and concurrent call control adjustment, thus obtaining an initial set of service adjustment strategies.

[0174] The blocking nodes correspond to adjustments in the order of interface calls, adjustments in the interface retry interval, and pre-validation of dependent interfaces.

[0175] Resource contention nodes correspond to adjustments in resource release order, resource allocation priority, and concurrent call rate limiting.

[0176] The abnormal retry node corresponds to the abnormal confirmation path adjustment, recovery action pre-check, and duplicate alarm merging.

[0177] The rework node in the process corresponds to the forward movement of the work order confirmation node, the review by the processing personnel, and the verification of feedback conditions.

[0178] Concurrent calls to conflicting nodes are queued for mutual exclusion interfaces, synchronous interfaces are merged and triggered, and conflicting interfaces are delayed in execution.

[0179] The platform performs action merging, deduplication, and object dependency marking based on the initial service adjustment strategy set to obtain a service optimization priority sequence and a service adjustment strategy set.

[0180] Action merging is used to combine multiple adjustment actions that act on the same object into a unified strategy.

[0181] Deduplication is used for strategies to remove duplicates.

[0182] Object dependency tags are used to describe the object state conditions and dependent object states that must be met before an adjustment action can be performed.

[0183] In this embodiment, S6 specifically includes: The platform generates a set of optimization configurations to be executed, including interface call order, resource allocation relationship, work order flow path and exception handling path, based on the service adjustment strategy set.

[0184] The set of optimization configurations to be executed includes fields for the object to be adjusted, adjustment action, preconditions, affected object, rollback conditions, and execution result record.

[0185] The platform performs rule verification, dependency verification, and conflict verification based on the set of optimization configurations to be executed, and obtains a set of executable service optimization configurations.

[0186] Rule validation is used to determine whether the adjustment action conforms to the service processing rules and interface call rules of the information system integration service.

[0187] Dependency checks are used to determine whether the work order objects, interface objects, business system objects, and resource objects involved in the adjustment action satisfy the prerequisite dependencies.

[0188] Conflict checking is used to determine whether there are resource usage conflicts, interface call conflicts, or work order path conflicts between multiple adjustment actions.

[0189] Executable service optimization configurations that pass rule validation, dependency validation, and conflict validation are added to the executable service optimization configuration set.

[0190] Optimization configurations that fail verification will not be executed directly. The platform will generate a review identifier, a record of the cause of the conflict, and a list of adjustments to be confirmed.

[0191] The review indicator is used to indicate configuration adjustments that require manual confirmation.

[0192] The conflict reason log is used to record object dependency conflicts, interface call conflicts, resource usage conflicts, or service rule conflicts that fail the validation.

[0193] Adjustments pending confirmation are used for manual review or delayed execution in subsequent service processing.

[0194] The platform performs configuration updates based on the set of executable service optimization configurations. The updates include the order of interface calls, resource allocation relationships, work order flow paths, and exception handling paths.

[0195] After the configuration is updated, the platform continues to collect optimized work order data, interface call data, system operation data, resource monitoring data, alarm data, and service feedback data to obtain an optimized service event data set.

[0196] The platform updates the object state location, token distribution state, transition nodes, object constraint attributes, and transition parameters in the improved object-oriented generalized stochastic Petri net model based on the optimized service event data set, and obtains the service optimization result after closed-loop update.

[0197] The object state library is updated to add, merge, or correct service object state nodes.

[0198] The token distribution status update is used to reflect the stay and flow of optimized service objects in various status databases.

[0199] Transition node updates are used to correct the mapping relationship between service actions and object states.

[0200] Object constraint attribute updates are used to correct synchronization, mutual exclusion, waiting, resource contention, and interface dependencies.

[0201] Transition parameter updates are used to correct trigger rate parameters, occurrence probability parameters, and recovery state parameters.

[0202] Through the aforementioned closed-loop update, this invention enables the service state migration model to continuously adapt to changes in interfaces, resources, work order flow, and exception handling during the information system integration service process.

[0203] This invention unifies multiple objects, multiple states, multiple actions, and multiple constraint relationships into a service state transition model through object-oriented event-based processing and an improved object-oriented generalized stochastic Petri net model.

[0204] By replaying object tokens, this invention can reconstruct the actual service event trajectory at the model level, discover the stagnation, accumulation, and missing phenomena of object tokens in the repository node, and further trace the object relationships and service paths that cause bottlenecks.

[0205] By analyzing the scope of service impact, this invention can distinguish the degree of impact of different bottlenecks on work orders, interfaces, business systems, resources, and service feedback, making the optimization sequence more closely aligned with the actual service impact.

[0206] By configuring verification and optimizing data feedback, this invention can form a continuously updated service optimization closed loop, enabling the information system integration service platform to maintain stable optimization capabilities under different project stages, different system environments, and different interface linkages.

[0207] Example 1: To verify the feasibility of this invention in practice, it was applied to an information system integration service scenario within a comprehensive business management platform. This platform simultaneously connects to a business acceptance system, a unified identity authentication system, a data exchange system, an electronic signature system, an SMS notification system, a file storage system, and an operation and maintenance monitoring system. Daily service operations involve numerous cross-system interface calls, work order processing, resource requests, exception handling, and user feedback. Since different subsystems are supported by different service modules, interface logs, resource monitoring logs, work order logs, and alarm records are distributed across multiple platforms. Traditional manual troubleshooting can only detect whether a single work order has timed out or a single interface has failed, making it difficult to determine whether service delays stem from interface blocking, resource waiting, concurrent call conflicts, or abnormal retries.

[0208] In this scenario, the following data is first acquired: work order data, API call data, system operation data, resource monitoring data, alarm data, and service feedback data. Work order data includes work order number, acceptance node, processing node, processing personnel, workflow status, and completion result; API call data includes API number, calling system, called system, call status, call duration, and retries; system operation data includes business system number, service instance status, and middleware operation status; resource monitoring data includes server resources, database connection pool, message queue backlog, and storage space status; alarm data includes alarm object, alarm level, trigger status, and recovery status; and service feedback data includes user confirmation results, secondary processing records, and service satisfaction indicators. After distributed aggregation, format standardization, time correlation, object identifier matching, event fragmentation and merging, and anomaly field cleaning, the above data forms an integrated service event data set.

[0209] Subsequently, the integrated service event data set undergoes centralized object processing. The system uses work order number, interface number, business system number, resource number, alarm number, and personnel number as object identifiers to aggregate work order objects, interface objects, business system objects, resource objects, alarm objects, and personnel objects within the same service process. For each service object, the system extracts its running status, processing status, occupancy status, exception status, and feedback status, and generates an object-oriented service status identifier sequence according to the order of event occurrence. This sequence can represent the status changes of the same work order between acceptance, interface configuration, data synchronization, joint debugging and testing, exception handling, and result feedback; it can also represent the status changes of the same interface between normal call, waiting, retry, recovery, and blocking.

[0210] After completing the centralized object processing, an improved object-oriented generalized stochastic Petri net model is constructed. The model maps work order processing status, interface call status, system operation status, resource occupancy status, alarm triggering status, and personnel handling status to object state library nodes. It maps the identifiers of work order objects, interface objects, business system objects, resource objects, alarm objects, and personnel objects to object identifier tokens. It maps service actions such as request acceptance, interface configuration, data synchronization, joint debugging testing, resource application, anomaly alarms, manual processing, and result feedback to transition nodes. Status transition actions that do not consume waiting time are configured as immediate transitions, while actions with duration and probability of occurrence, such as interface calls, resource applications, data synchronization, joint debugging testing, and manual processing, are configured as random transitions. A set of transition parameters is generated based on historical frequency, waiting distribution, anomaly recovery status, and successful triggering status.

[0211] During model operation, the system inputs the actual service event trajectory into the service state transition model for object token replay. If the token corresponding to a certain interface object remains in the interface waiting place node for a long time, and multiple subsequent work order objects enter the same waiting path, it is determined that the interface has an interface blocking path. If the token corresponding to a resource object accumulates in the resource occupying place node, causing multiple interface transitions to fail to trigger, it is determined that the resource has a resource contention path. If an alarm object repeatedly triggers an abnormal recovery transition, causing the work order object to return to the joint debugging test or parameter correction node multiple times, it is determined that there is an abnormal retry path or a process rework path. Through the above token retention, token accumulation, and token missing states, the system obtains a set of service bottleneck characteristics.

[0212] After obtaining the service bottleneck feature set, the system analyzes the service impact scope by combining the service object relationships. The system counts the occurrence frequency, duration, number of affected objects, number of associated work orders, cross-system impact paths, and service feedback results for each type of bottleneck, and generates a service optimization priority sequence accordingly. For interface blocking nodes, the system generates interface call order adjustment strategies and interface rate limiting strategies; for resource contention nodes, the system generates resource reallocation strategies and connection pool parameter adjustment strategies; for process rework nodes, the system generates work order path adjustment strategies; for abnormal retry nodes, the system generates abnormal handling path optimization strategies; and for concurrent call conflict nodes, the system generates concurrent call control adjustment strategies.

[0213] After generating the strategy, the system does not directly apply all adjustments to the runtime environment. Instead, it first creates a set of optimized configurations to be executed and performs service rule verification, object dependency verification, and configuration conflict verification on this set. Once the verification passes, the system executes the configuration update and continues to collect optimized work order data, interface call data, system operation data, resource monitoring data, alarm data, and service feedback data to obtain an optimized service event data set. The optimized data then flows back to the improved object-oriented generalized stochastic Petri net model to update the object state repository, token distribution state, transition nodes, object constraint attributes, and transition parameters, thus forming a continuous optimization closed loop.

[0214] In the test run of this embodiment, continuous service data from the same integrated business platform was selected as the verification object, including 12,460 service tickets, 5,278,000 interface call records, 386,000 system operation events, 912,000 resource monitoring records, 28,640 alarm records, and 11,830 service feedback records. When using traditional rule-based statistical methods, the system can only output single-point anomalies such as service ticket timeouts, interface failures, and excessive resource consumption, failing to accurately explain the state transition relationships between anomalies. Using the method of this invention, the system can associate service ticket objects, interface objects, resource objects, and alarm objects in the same service process into the same state transition model, and identify five types of bottleneck paths: interface blocking, resource contention, abnormal retries, process rework, and concurrent call conflicts.

[0215] Test results show that after one optimized configuration update, the average interface waiting time decreased from 4.8 seconds to 2.1 seconds, the average work order processing time decreased from 9.6 hours to 6.4 hours, the abnormal retry rate decreased from 18.7% to 9.5%, the process rework rate decreased from 14.2% to 7.1%, the number of resource contention events decreased from 36.4 per 1,000 work orders to 15.8, and the service feedback satisfaction rate increased from 82.6% to 91.3%. These results demonstrate that this invention can utilize an improved object-oriented generalized stochastic Petri net model to represent the state of information system integration service processes and pinpoint bottlenecks, and improve service efficiency and stability through a set of service adjustment strategies.

[0216] Table 1 Comparison of operational data before and after information system integration service optimization.

[0217] As shown in Table 1, after adopting the method of this invention, the average interface waiting time was reduced from 4.8 seconds to 2.1 seconds. This indicates that by identifying the token retention status in the interface waiting repository through object token replay, the system can accurately locate the interface blocking path to the specific interface object and its preceding and following transition nodes, and reduce interface waiting through interface call order adjustment and concurrency control strategies. This result demonstrates that this invention does not solely rely on the number of interface failures to determine anomalies, but rather identifies the formation path of interface blocking based on the service state transition process.

[0218] The average processing time for work orders decreased from 9.6 hours to 6.4 hours, primarily because the model can identify process rework paths and manual waiting nodes. When a work order object token travels back and forth multiple times between integration testing, parameter correction, and result feedback, the system categorizes it as a process rework bottleneck and generates a work order path adjustment strategy based on the relationship between personnel objects and interface objects. As a result, work order processing no longer relies on manual item-by-item checking, improving service processing efficiency.

[0219] The anomaly retry rate and process rework rate decreased by 49.20% and 50.00% respectively, indicating that the improved object-oriented generalized stochastic Petri net model can effectively express anomaly recovery transitions and fallback paths. Traditional statistical methods can usually only detect a high number of anomalies, but cannot determine whether anomaly retries affect the work order flow. This invention, through the state transition record of object identifier tokens, associates alarm objects, interface objects, and work order objects within the same service process, enabling quantitative analysis of the impact of anomaly retries on the service process.

[0220] Both resource contention events and concurrent call conflict events decreased significantly, indicating that object constraint attributes can express the synchronization, mutual exclusion, waiting, resource contention, and interface dependency relationships between service objects. When multiple interface objects simultaneously request the same resource object, the model can identify token accumulation in the resource occupancy library and convert it into a resource contention path or a concurrent call conflict path. Through resource reallocation and concurrent call control adjustments, the system reduces service blocking caused by resource contention.

[0221] The service feedback satisfaction rate increased from 82.6% to 91.3%, indicating that the service optimization priority sequence can reflect the actual service impact range. Because the priority analysis comprehensively considers the number of bottleneck occurrences, their duration, the number of affected objects, the number of related work orders, cross-system impact paths, and service feedback results, the optimization strategy can prioritize nodes with a significant impact on the overall service experience. The results in Table 1 demonstrate that this invention can achieve bottleneck localization, strategy generation, and model closed-loop updates based on multi-source service data and multi-object state transition relationships.

[0222] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for optimizing information system integration services based on big data processing, characterized in that, Includes the following steps: S1. Obtain work order data, interface call data, operation data, resource data, alarm data and feedback data from the information system integration service, and perform distributed collection, format unification, time association, object matching, event merging and anomaly cleaning on the above data to obtain the integration service event data set; S2. Extract work order objects, interface objects, business system objects, resource objects, alarm objects, and personnel objects from the integrated service event data set. Perform object-centralized processing on the status fields, flow fields, and association fields of each object to obtain an object-oriented service status identifier sequence. S3. Based on the object-oriented service state identifier sequence, construct an improved object-oriented generalized stochastic Petri net model, map the object state to the place node, the object identifier to the token, and the service action to the transition node, to obtain the service state transition model. S4. Based on the service state transition model, token replay and state inference are performed on the actual service event trajectory to identify concurrent call conflicts, resource waiting, interface blocking, abnormal retry and process rework states, and obtain the service bottleneck feature set. S5. Analyze the service impact range based on the service bottleneck feature set and object association relationship, and perform priority analysis based on the service impact range to obtain the service optimization priority sequence and service adjustment strategy set; S6. Generate a set of optimization configurations to be executed based on the service adjustment strategy set, perform rule verification, dependency verification and conflict verification on the set of optimization configurations to be executed, and feed the optimized data back to the model to obtain the service optimization result after closed-loop update.

2. The information system integration service optimization method based on big data processing according to claim 1, characterized in that, S2 includes the following steps: S21. Based on the work order number, interface number, system number, resource number, alarm number, and personnel number of the integrated service event data set, identify and group the service objects in the same service process to obtain the service object set; S22. Extract relationships based on the calling relationships, dependency relationships, processing relationships, and feedback relationships between objects in the service object set to obtain a service object association relationship set; S23. Based on the running status, processing status, occupancy status, abnormal status and feedback status of the service object set, perform status coding to obtain the object status code set; S24. Organize the service object association set and the object status code set according to the time sequence to obtain the object-oriented service status identifier sequence.

3. The information system integration service optimization method based on big data processing according to claim 1, characterized in that, S3 includes the following steps: S31. Based on the object type and object status, map the work order, interface, system, resource, alarm and personnel status to the nodes of the object status library to obtain the object status library set; S32. Based on the state change events, map service flow, interface call, resource request, exception handling and result feedback to transition nodes to obtain a set of service action transitions; S33. Generate an object identifier token based on the object identifier and object status location, and configure it to the corresponding object status database node to obtain the initial service status identifier; S34. Based on the triggering conditions, waiting distribution, occurrence frequency and recovery status of the service action transition set, configure the instant transition attributes, random transition attributes, trigger rate parameters, occurrence probability parameters and object constraint attributes for the transition nodes to obtain the transition parameter set; S35. Based on the set of object state library, the set of service action transitions, the initial service state identifier and the set of transition parameters, construct input arc, output arc, inhibition arc and object association arc to generate an improved object-oriented generalized stochastic Petri net model and obtain the service state transition model.

4. The information system integration service optimization method based on big data processing according to claim 3, characterized in that, S32 includes the following steps: S321. Identify object state changes between adjacent events based on the object-oriented service state identifier sequence to obtain a candidate state change event set; S322. Determine the action type based on the preceding object state, following object state, and trigger field in the candidate state change event set to obtain a service action type set; S323. Merge repetitive actions, equivalent actions, and invalid actions according to the service action type set to obtain a standardized service action set; S324. Construct service action transition nodes based on the standardized service action set and the relationship between service objects to obtain the service action transition set.

5. The information system integration service optimization method based on big data processing according to claim 3, characterized in that, S34 includes the following steps: S341. Based on the action triggering conditions in the service action transition set, mark the state transition actions that do not consume waiting time as instant transitions to obtain the instant transition set. S342. Based on interface calls, resource requests, data synchronization, joint debugging tests, and manual processing actions, mark service actions with duration and probability of occurrence as random transitions to obtain a set of random transitions. S343. Generate a set of transition weight parameters based on the occurrence frequency, waiting distribution, anomaly recovery, and triggering state of the random transition set; S344. Based on the immediate transition set, the random transition set, and the transition weight parameter set, configure object constraint attributes for synchronization, mutual exclusion, waiting, resource contention, and interface dependency relationships between service objects to obtain the transition parameter set.

6. The information system integration service optimization method based on big data processing according to claim 1, characterized in that, S4 includes the following steps: S41. Perform object token replay based on the service state transition model and the actual service event trajectory to obtain the service state replay result; S42. Based on the service status replay results, identify the token retention, token accumulation, and token missing states in the nodes of the object status database to obtain the service waiting state set. S43. Based on the service waiting state set, trace the corresponding transition nodes, object identification tokens and object association arcs to obtain concurrent call conflict paths, interface blocking paths, resource contention paths, abnormal retry paths and process rework paths; S44. Based on the above path, bottlenecks are merged to obtain a set of service bottleneck features.

7. The information system integration service optimization method based on big data processing according to claim 6, characterized in that, S42 includes the following steps: S421. Based on the token entry and exit status of each object status storage node in the service status replay results, identify storage nodes with waiting accumulation and obtain a set of candidate waiting nodes. S422. Based on the object type and service stage corresponding to the candidate waiting node set, distinguish between interface waiting nodes, resource waiting nodes, manual processing waiting nodes, and exception recovery waiting nodes to obtain a categorized waiting node set. S423. Extract the set of waiting trigger actions based on the preceding transitions, following transitions, and object identifier tokens associated with each node in the classification waiting node set; S424. Perform link tracing based on the set of waiting trigger actions, object association arcs, and service object association relationships to obtain the set of service waiting states.

8. The information system integration service optimization method based on big data processing according to claim 1, characterized in that, S5 includes the following steps: S51. Based on the service bottleneck feature set and the relationship between service objects, extract the number of times the bottleneck occurs, the bottleneck duration status, the number of affected objects, the number of associated work orders, the cross-system impact path, and the service feedback results to obtain the service impact feature set. S52. Based on the service impact feature set, sort the interface blocking nodes, resource contention nodes, abnormal retry nodes, process rework nodes, and concurrent call conflict nodes to obtain the service optimization priority sequence; S53. Based on the service optimization priority sequence, match different bottleneck nodes to interface rearrangement, resource reallocation, work order path adjustment, exception handling path adjustment and concurrent call control adjustment to obtain an initial service adjustment strategy set; S54. Based on the initial service adjustment strategy set, perform action merging, deduplication, and object dependency marking to obtain the service optimization priority sequence and service adjustment strategy set.

9. The information system integration service optimization method based on big data processing according to claim 8, characterized in that, S52 includes the following steps: S521. Generate a bottleneck impact range identifier based on the number of affected objects, the number of associated work orders, and the cross-system impact path; S522. Generate a bottleneck stability indicator based on the number of times the bottleneck occurs and the duration of the bottleneck. S523. Generate a service response impact identifier based on the service feedback results and the relationship between the business systems; S524. Based on the bottleneck impact range identifier, bottleneck stability identifier, and service response impact identifier, a comprehensive sorting is performed to obtain the service optimization priority sequence.

10. The information system integration service optimization method based on big data processing according to claim 1, characterized in that, S6 includes the following steps: S61. Generate a set of optimization configurations to be executed based on the service adjustment strategy set, including interface call order, resource allocation relationship, work order flow path and exception handling path; S62. Perform rule, dependency and conflict checks on the set of optimization configurations to be executed to obtain a set of executable service optimization configurations; S63. Perform configuration updates based on the executable service optimization configuration set, collect optimized multi-source runtime data, and obtain the optimized service event data set; S64. Update the object state library, token distribution state, transition nodes, object constraint attributes and transition parameters in the model according to the optimized service event data set to obtain the service optimization result after closed-loop update.

Images