In-transit order change implementation method and system

Abstract

The embodiment of the invention provides an in-transit order change implementation method and system. According to the method, firstly, an in-transit modification request including an original order identifier, a to-be-modified parameter, a service type and a modification request type is received, and a data foundation can be laid for subsequent precise processing; compliance check and permission confirmation are carried out according to a preset verification rule and a key node rule, so that the modification request can be ensured to accord with a service specification, and the time consumed by manual verification is greatly shortened; a preset scene rule base is called to match a corresponding target business scene for the request passing the verification, and a corresponding in-transit modification instance is generated after the matching is passed, so that the time consumption of manually customizing a development scene can be reduced; finally, a preset process engine is called to start the modification instance and execute modification operation, the original process is automatically restarted after modification is completed, intellectualization of in-transit order modification can be achieved through the process, and the processing efficiency of the in-transit order modification is remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and system for implementing in-transit order modification. Background Technology

[0002] With the rapid development of information technology, broadband, enterprise dedicated lines, and other communication services have become core infrastructures for social production and daily life, and users' demands for real-time and flexible service activation continue to rise. Throughout the service activation process, changes to order parameters become a frequent occurrence, directly impacting user experience and operator service quality.

[0003] Currently, traditional in-transit order modification mainly relies on manual operation, which requires maintenance personnel to manually query process nodes, coordinate with third-party systems to roll back executed instructions, modify parameters, and re-initiate the process.

[0004] However, the traditional manual method of modifying orders in transit requires manual coordination of multiple systems when handling requests for modifications such as bandwidth adjustments. The processing time often cannot meet customers' needs for real-time service, resulting in low efficiency in processing orders in transit. Summary of the Invention

[0005] This invention provides a method and system for implementing in-transit order modification, which can improve the processing efficiency of in-transit order modification.

[0006] In a first aspect, embodiments of the present invention provide a method for implementing in-transit order modification, the method comprising:

[0007] Receive an in-transit modification request from the current user, wherein the in-transit modification request includes at least: the original order identifier, the parameters to be modified, the service type, and the modification request type;

[0008] The in-transit modification request is subject to target verification based on preset verification rules and key node rules, wherein the target verification includes: compliance check and permission confirmation;

[0009] The preset scenario rule base is called to match the in-transit modification request that has passed the verification with the corresponding target business scenario, and the corresponding in-transit modification instance is generated after the target business scenario is successfully matched;

[0010] The preset process engine is invoked to start the in-transit modification instance to perform the corresponding modification operation, and the original process is restarted after the modification operation is completed.

[0011] Preferably,

[0012] After receiving the in-transit modification request from the current user, and before performing target verification on the in-transit modification request based on preset verification rules and key node rules, the process further includes:

[0013] Identify the original format of the in-transit modification request, and convert the non-standardized fields in the original format into standardized field formats based on preset specifications to generate a standardized in-transit modification request;

[0014] The preset information extraction rules are invoked to extract the original order identifier, the service type, the parameters to be modified, and the modification request type from the standardized in-transit modification request;

[0015] The original order identifier, the service type, the parameters to be modified, and the modification request type are associated and bound with the original order.

[0016] Preferably,

[0017] The target verification of the in-transit modification request based on preset verification rules and key node rules includes:

[0018] D1: Determine the current service activation stage corresponding to the original order associated with the standardized in-transit modification request;

[0019] D2: Determine whether the current service activation process is in a modifiable stage based on the preset verification rules;

[0020] D3: When it is determined that the current service activation process is in the modifiable stage, check whether the resource availability of the parameter to be modified is passed. If yes, proceed to step D4; otherwise, proceed to step D5.

[0021] D4: Invoke the preset key node rule adapted to the current service activation stage, determine whether the current service activation stage has reached the preset unchangeable point. If yes, execute step D5; otherwise, return to execute the target business scenario corresponding to the in-transit modification request that has passed the verification by invoking the preset scenario rule.

[0022] D5: Return the corresponding rejection notification to the current user through a preset standardized interface and terminate the current process, wherein the rejection notification includes at least the reason for rejection.

[0023] Preferably,

[0024] The process of calling the preset scenario rule base is to match the verified in-transit modification request with the corresponding target business scenario, and to generate a corresponding in-transit modification instance after the target business scenario is successfully matched, including:

[0025] E1: Based on the service type and the modification request type, call the preset scenario rule base to match the corresponding target business scenario for the standardized in-transit modification request;

[0026] E2: Determine if the scene matching is successful. If yes, proceed to step E3; otherwise, proceed to step E8.

[0027] E3: Generate corresponding preprocessing logic based on the customized rules associated with the target business scenario;

[0028] E4: Perform validity checks on the preprocessing logic and downstream system interfaces, wherein the validity checks include: critical dependency condition checks and interface availability checks;

[0029] E5: Determine whether the validity check is passed. If yes, proceed to step E6; otherwise, proceed to step E8.

[0030] E6: Generate and store an in-transit modification instance corresponding to the standardized in-transit modification request, wherein the in-transit modification instance includes at least: the original order identifier, the instance identifier, the target business scenario name, the original order parameters, and the parameters to be modified;

[0031] E7: Associate and bind the in-transit modification instance with the original order;

[0032] E8: Return the corresponding failure message through the preset standardized interface and terminate the current process, wherein the failure message includes at least the reason for failure.

[0033] Preferably,

[0034] The step of invoking the preset process engine to start the in-transit modification instance to perform modification operations, and restarting the original process after the modification operations are completed, includes:

[0035] The preset process engine is invoked to load the preprocessing logic corresponding to the in-transit modification instance, execute the modification operation, and synchronously update the instance lifecycle state;

[0036] Suspend the original service activation process and simultaneously record the location of the paused node, parameters of the completed process, and the interaction status of the associated systems.

[0037] Invoke the preset processing steps corresponding to the target business scenario, and generate corresponding standardized modification instructions to execute the preset processing steps;

[0038] After the preset processing steps are completed, the preset process engine is invoked to restart the original service activation process from the paused node position;

[0039] Update the status of the original service activation process, and synchronize the restart status and modification results through the preset standardized interface.

[0040] Secondly, embodiments of the present invention provide an in-transit order modification system, the system comprising:

[0041] Request receiving module: used to receive in-transit modification requests sent by the current user, wherein the in-transit modification request includes at least: original order identifier, parameters to be modified, service type, and modification request type;

[0042] Multi-dimensional verification module: used to perform target verification on the in-transit modification request based on preset verification rules and key node rules, wherein the target verification includes: compliance check and permission confirmation;

[0043] Scene matching module: used to call the preset scene rule library to match the in-transit modification request that has passed the verification with the corresponding target business scene, and generate the corresponding in-transit modification instance after the target business scene has passed the matching;

[0044] Instance management module: used to call the preset process engine to start the in-transit modification instance to perform the corresponding modification operation, and restart the original process after the modification operation is completed.

[0045] Preferably,

[0046] The system further includes a request processing module after the request receiving module and before the multidimensional verification module;

[0047] The request processing module is used to perform:

[0048] Identify the original format of the in-transit modification request, and convert the non-standardized fields in the original format into standardized field formats based on preset specifications to generate a standardized in-transit modification request;

[0049] The preset information extraction rules are invoked to extract the original order identifier, the service type, the parameters to be modified, and the modification request type from the standardized in-transit modification request;

[0050] The original order identifier, the service type, the parameters to be modified, and the modification request type are associated and bound with the original order.

[0051] Preferably,

[0052] The multidimensional verification module is used to perform:

[0053] D1: Determine the current service activation stage corresponding to the original order associated with the standardized in-transit modification request;

[0054] D2: Determine whether the current service activation process is in a modifiable stage based on the preset verification rules;

[0055] D3: When it is determined that the current service activation process is in the modifiable stage, check whether the resource availability of the parameter to be modified is passed. If yes, proceed to step D4; otherwise, proceed to step D5.

[0056] D4: Invoke the preset key node rule adapted to the current service activation stage, determine whether the current service activation stage has reached the preset unchangeable point. If yes, execute step D5; otherwise, return to execute the target business scenario corresponding to the in-transit modification request that has passed the verification by invoking the preset scenario rule.

[0057] D5: Return the corresponding rejection notification to the current user through a preset standardized interface and terminate the current process, wherein the rejection notification includes at least the reason for rejection.

[0058] Preferably,

[0059] The scene matching module is used to perform:

[0060] E1: Based on the service type and the modification request type, call the preset scenario rule base to match the corresponding target business scenario for the standardized in-transit modification request;

[0061] E2: Determine if the scene matching is successful. If yes, proceed to step E3; otherwise, proceed to step E8.

[0062] E3: Generate corresponding preprocessing logic based on the customized rules associated with the target business scenario;

[0063] E4: Perform validity checks on the preprocessing logic and downstream system interfaces, wherein the validity checks include: critical dependency condition checks and interface availability checks;

[0064] E5: Determine whether the validity check is passed. If yes, proceed to step E6; otherwise, proceed to step E8.

[0065] E6: Generate and store an in-transit modification instance corresponding to the standardized in-transit modification request, wherein the in-transit modification instance includes at least: the original order identifier, the instance identifier, the target business scenario name, the original order parameters, and the parameters to be modified;

[0066] E7: Associate and bind the in-transit modification instance with the original order;

[0067] E8: Return the corresponding failure message through the preset standardized interface and terminate the current process, wherein the failure message includes at least the reason for failure.

[0068] Preferably,

[0069] The instance management module is used to perform:

[0070] The preset process engine is invoked to load the preprocessing logic corresponding to the in-transit modification instance, execute the modification operation, and synchronously update the instance lifecycle state;

[0071] Suspend the original service activation process and simultaneously record the location of the paused node, parameters of the completed process, and the interaction status of related systems.

[0072] Invoke the preset processing steps corresponding to the target business scenario, and generate corresponding standardized modification instructions to execute the preset processing steps;

[0073] After the preset processing steps are completed, the preset process engine is invoked to restart the original service activation process from the paused node position;

[0074] Update the status of the original service activation process, and synchronize the restart status and modification results through the preset standardized interface.

[0075] This invention provides a method and system for implementing in-transit order modification. The method first receives in-transit modification requests, including the original order identifier, parameters to be modified, service type, and modification request type, laying a data foundation for subsequent accurate processing. Next, compliance checks and permission confirmations are performed according to preset verification rules and key node rules, ensuring that the modification requests conform to business specifications and significantly reducing manual verification time. Then, a preset scenario rule base is invoked to match the verified requests with the corresponding target business scenario, and a corresponding in-transit modification instance is generated after successful matching, reducing the time spent on manual customized scenario development. Finally, a preset process engine is invoked to start the modification instance and execute the modification operation, automatically restarting the original process after modification. Through this process, intelligent in-transit order modification can be achieved, significantly improving the processing efficiency of in-transit order modification. Attached Figure Description

[0076] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0077] Figure 1 This is a flowchart of an embodiment of the present invention for implementing an in-transit order modification method;

[0078] Figure 2 This is a flowchart of another method for implementing in-transit order modification according to an embodiment of the present invention;

[0079] Figure 3This is a schematic diagram of an in-transit order modification system provided in an embodiment of the present invention;

[0080] Figure 4 This is a schematic diagram of another in-transit order modification system provided by an embodiment of the present invention. Detailed Implementation

[0081] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0082] like Figure 1 As shown, this embodiment of the invention provides a method for implementing in-transit order modification, which may include the following steps:

[0083] Step 101: Receive the in-transit modification request from the current user. The in-transit modification request shall include at least the following: original order identifier, parameters to be modified, service type, and modification request type.

[0084] Step 102: Perform target verification on the modification requests in transit based on the preset verification rules and key node rules. The target verification includes compliance checks and permission confirmation.

[0085] Step 103: Call the preset scenario rule base to match the verified in-transit modification request with the corresponding target business scenario, and generate the corresponding in-transit modification instance after the target business scenario is successfully matched;

[0086] Step 104: Invoke the preset process engine to start the in-transit modification instance to perform the corresponding modification operations, and restart the original process after the modification operations are completed.

[0087] In this embodiment of the invention, a method for implementing in-transit order modification is provided. The method first receives an in-transit modification request including the original order identifier, parameters to be modified, service type, and modification request type, laying a data foundation for subsequent accurate processing. Next, compliance checks and permission confirmations are performed according to preset verification rules and key node rules, ensuring that the modification request conforms to business specifications and significantly reducing the time spent on manual verification. Then, a preset scenario rule base is invoked to match the verified request with the corresponding target business scenario, and a corresponding in-transit modification instance is generated after successful matching, reducing the time spent on manually customized scenario development. Finally, a preset process engine is invoked to start the modification instance and execute the modification operation, and the original process is automatically restarted after modification. Through the above process, intelligent in-transit order modification can be achieved, significantly improving the processing efficiency of in-transit order modification.

[0088] To reduce system integration costs, in one embodiment of the present invention, the above embodiment further includes the following step after step 101 and before step 102:

[0089] Identify the original format of the in-transit modification request, and convert the non-standardized fields in the original format into standardized field formats based on preset specifications to generate a standardized in-transit modification request;

[0090] The preset information extraction rules are invoked to extract the original order identifier, the service type, the parameters to be modified, and the modification request type from the standardized in-transit modification request;

[0091] The original order identifier, the service type, the parameters to be modified, and the modification request type are associated and bound with the original order.

[0092] In this embodiment of the invention, since different initiating systems may have different data formats, the original format of the in-transit modification request can be identified first, and non-standardized fields can be converted into standardized field formats to generate a standardized in-transit modification request with a regular structure and uniform fields. Next, preset information extraction rules are invoked to accurately extract the original order identifier, service type, parameters to be modified, and modification request type from the standardized in-transit modification request, avoiding errors from manual extraction. Finally, the extracted information is associated and bound with the original order, ensuring that the in-transit modification request can be accurately associated with the corresponding original order, thereby further improving the accuracy and processing efficiency of in-transit modifications. This process does not require customizing a dedicated interface for each interface system, significantly reducing system integration costs.

[0093] In order to verify the modification request in progress, in one embodiment of the present invention, step 102 in the above embodiment includes:

[0094] D1: Determine the current service activation stage corresponding to the original order associated with the standardized in-transit modification request;

[0095] D2: Determine whether the current service activation process is in a modifiable stage based on the preset verification rules;

[0096] D3: When it is determined that the current service activation process is in the modifiable stage, check whether the resource availability of the parameter to be modified is passed. If yes, proceed to step D4; otherwise, proceed to step D5.

[0097] D4: Invoke the preset key node rule adapted to the current service activation stage, determine whether the current service activation stage has reached the preset unchangeable point. If yes, execute step D5; otherwise, return to execute the target business scenario corresponding to the in-transit modification request that has passed the verification by invoking the preset scenario rule.

[0098] D5: Return the corresponding rejection notification to the current user through a preset standardized interface and terminate the current process, wherein the rejection notification includes at least the reason for rejection.

[0099] In this embodiment of the invention, to verify in-transit modification requests: First, the original order identifier associated with the standardized in-transit modification request can be queried (e.g., queried through the CRM system) to determine the current service activation stage of the original order (e.g., resource verification, port allocation, device configuration, on-site installation); then, the preset verification rules in the dynamic configuration system are called to determine whether the current service activation stage is in the modifiable stage (e.g., whether port allocation has been completed but on-site installation has not yet started), and when the current service activation stage is in the modifiable stage, the resource availability of the parameter to be modified is checked (e.g., whether the target bandwidth is in the bandwidth list supported by the operator / whether there are sufficient network resources to support it). If the resource availability verification passes, the preset key node rules adapted to the current service activation stage are called to determine whether the current stage has reached the point of no change. If it has not reached the point of no change, it means that the modification permission is available, and the subsequent steps are continued. If it has reached the point of no change, a rejection notification containing the rejection reason (e.g., the target bandwidth does not currently support this area) is returned to the current user through a preset standardized interface (e.g., TMF641), and the current process is terminated to avoid wasting resources on invalid modification operations.

[0100] To improve scene adaptation efficiency, in one embodiment of the present invention, step 103 in the above embodiment may specifically include the following steps:

[0101] E1: Based on the service type and the modification request type, call the preset scenario rule base to match the corresponding target business scenario for the standardized in-transit modification request;

[0102] E2: Determine if the scene matching is successful. If yes, proceed to step E3; otherwise, proceed to step E7.

[0103] E3: Generate corresponding preprocessing logic based on the customized rules associated with the target business scenario;

[0104] E4: Perform validity checks on the preprocessing logic and downstream system interfaces, wherein the validity checks include: critical dependency condition checks and interface availability checks;

[0105] E5: Determine whether the validity check is passed. If yes, proceed to step E6; otherwise, proceed to step E8.

[0106] E6: Generate and store an in-transit modification instance corresponding to the standardized in-transit modification request, wherein the in-transit modification instance includes at least: the original order identifier, the instance identifier, the target business scenario name, the original order parameters, and the parameters to be modified;

[0107] E7: Associate and bind the in-transit modification instance with the original order;

[0108] E8: Return the corresponding failure message through the preset standardized interface and terminate the current process, wherein the failure message includes at least the reason for failure.

[0109] In this embodiment of the invention, to improve the efficiency of scenario adaptation: First, based on the service type (e.g., broadband / enterprise dedicated line) and modification request type (e.g., bandwidth adjustment / address change) in the standardized in-transit modification request, the preset scenario rule base in the dynamic configuration system is invoked to accurately match the target business scenario, avoiding the time-consuming nature of traditional customized development scenarios; Next, when the scenario matching is successful, corresponding preprocessing logic is generated based on the customized rules associated with the target business scenario, making the execution path of subsequent modification operations clearer; Then, the validity of the preprocessing logic and downstream system interfaces is verified to avoid modification failure due to missing dependencies or interface failures; Then, when the validity verification result is successful, the corresponding in-transit modification instance is generated and stored for subsequent instance management and full-process traceability; when the verification fails, a failure message containing the reason for failure can be returned to the user through the preset standardized interface, thereby enabling fault location.

[0110] Specifically, during the matching of target business scenarios, a secondary resource verification is first triggered. The operator's resource system is called to confirm whether there are available resources for the target bandwidth in the customer's area. After the resource verification is passed, a special modification instance for "bandwidth change in transit" is automatically generated. The association between the instance and the original order, the scenario type, the expected processing steps, and other information are recorded. The initial status of the instance is set to "pending execution" and synchronized to the instance management module for subsequent tracking.

[0111] To achieve seamless integration between the modification operation and the original process, in one embodiment of the present invention, step 104 of the above embodiment includes:

[0112] The preset process engine is invoked to load the preprocessing logic corresponding to the in-transit modification instance, execute the modification operation, and synchronously update the instance lifecycle state;

[0113] Suspend the original service activation process and simultaneously record the location of the paused node, parameters of the completed process, and the interaction status of related systems.

[0114] Invoke the preset processing steps corresponding to the target business scenario, and generate corresponding standardized modification instructions to execute the preset processing steps;

[0115] After the preset processing steps are completed, the preset process engine is invoked to restart the original service activation process from the paused node position;

[0116] Update the status of the original service activation process, and synchronize the restart status and modification results through the preset standardized interface.

[0117] In this embodiment of the invention, to achieve seamless integration between the modification operation and the original process: First, a preset process engine (e.g., the Camunda process engine, which supports the industry-standard BPMN 2.0 process modeling standard) is invoked to load the preprocessing logic associated with the in-transit modification instance and execute the modification operation. Simultaneously, the status of the in-transit modification instance is updated in real time to ensure traceability of the modification process. While executing the modification operation, the system can pause the original service activation process to avoid conflicts caused by the parallel execution of the modification and the original process. The system also records the pause node position, completed step parameters, and associated system interaction status for the normal execution of subsequent processes. Subsequently, the system can generate standardized modification instructions based on preset processing steps corresponding to the target business scenario and send them to downstream third-party systems for modification operation, replacing the manual adaptation of traditional customized interfaces and improving system collaboration efficiency. Once the preset processing steps are completed, the original service activation process can be restarted from the previously recorded pause node position. Finally, the system updates the status of the original service activation process and synchronizes the process restart status and modification results with the upstream system, facilitating later traceability and problem localization.

[0118] like Figure 2 As shown, in order to more clearly illustrate the technical solution and advantages of the present invention, the following is a detailed description of an embodiment of the present invention that provides a method for implementing in-transit order modification, which may specifically include the following steps:

[0119] Step 201: Receive the in-transit modification request from the current user;

[0120] For example, an in-transit modification request can be for a customer applying to "adjust the broadband bandwidth from 500M to 1G and the order has not reached the point where the order cannot be changed (e.g., the on-site installation stage);

[0121] Step 202: Identify the original format of the modification request in transit, and convert the non-standardized fields in the original format into standardized field formats based on preset specifications to generate a standardized modification request in transit;

[0122] Step 203: Invoke the preset information extraction rules to extract the original order identifier, service type, parameters to be modified, and modification request type from the standardized in-transit modification requests;

[0123] Step 204: Associate and bind the original order identifier, service type, parameters to be modified, and modification request type with the original order;

[0124] Step 205: Determine the current service activation stage corresponding to the original order associated with the standardized in-transit modification request;

[0125] Step 206: Determine whether the current service activation process is in the modifiable stage based on the preset verification rules;

[0126] Specifically, various service activation process templates such as "bandwidth change in transit" and "new broadband installation" can be defined through the process engine layer, and control rules for key nodes (such as unchangeable points, i.e., PONR points) can be preset. By reading the dynamically configured process and node association rules, the key control nodes corresponding to each process template can be automatically matched, providing a basis for subsequent permission judgment for in-transit modifications.

[0127] Step 207: When it is determined that the current service activation process is in the modifiable stage, check whether the resource availability of the parameter to be modified is qualified. If yes, proceed to step 208; otherwise, proceed to step 209.

[0128] Step 208: Invoke the preset key node rules adapted to the current service activation stage, and determine whether the current service activation stage has reached the preset unchangeable point. If yes, proceed to step 209; otherwise, proceed to step 210.

[0129] Step 209: Return the corresponding rejection notification to the current user through the preset standardized interface and terminate the current process. The rejection notification shall include at least the reason for rejection.

[0130] Step 210: Based on the service type and modification request type, call the preset scenario rule base to match the corresponding target business scenario for standardized in-transit modification requests;

[0131] For example, in the scenario of changing bandwidth en route, customized steps such as resource verification and parameter updates specific to this scenario can be automatically loaded, adapting to different business needs without additional development; the service type can be broadband service, and the modification request type can be bandwidth adjustment.

[0132] Step 211: Determine whether the scene matching is successful. If yes, proceed to step 212; otherwise, proceed to step 222.

[0133] Step 212: Generate corresponding preprocessing logic based on the customized rules associated with the target business scenario;

[0134] Step 213: Perform validity checks on the preprocessing logic and downstream system interfaces, including: checking key dependency conditions and checking interface availability.

[0135] Step 214: Determine whether the validity check passed. If yes, proceed to step 215; otherwise, proceed to step 222.

[0136] Step 215: Generate and store the corresponding standardized in-transit modification request in-transit instance, wherein the in-transit modification instance includes at least: original order identifier, instance identifier, target business scenario name, original order parameters, and parameters to be modified;

[0137] Step 216: Associate and bind the instance being modified in transit with the original order;

[0138] Step 217: Call the preset process engine to load the preprocessing logic corresponding to the instance being modified in transit, execute the modification operation, and synchronously update the instance lifecycle state;

[0139] Step 218: Pause the original service activation process and simultaneously record the paused node location, completed process parameters, and related system interaction status;

[0140] Step 219: Invoke the preset processing steps corresponding to the target business scenario and generate the corresponding standardized modification instructions to execute the preset processing steps;

[0141] Step 220: After the preset processing steps are completed, the preset process engine is invoked to restart the original service activation process from the paused node position;

[0142] Step 221: Update the status of the original service activation process, and synchronize the restart status and modification results through the preset standardized interface;

[0143] Specifically, process restart can invoke the restart function of the process engine layer to restore the original broadband activation process from the "paused" state to "normal execution" and continue to advance the subsequent unfinished steps (such as business testing and result feedback); status synchronization can be achieved through the TMF641 standardized interface to synchronize two pieces of information with the CRM system and service integration platform: first, the order status has been restored to "normal execution", and second, the bandwidth modification has been completed, ensuring that the upstream system obtains the latest progress of the order in real time. At this point, the entire in-transit modification process ends.

[0144] For example, the system can first call the device management system interface to send a bandwidth parameter update command, adjusting the customer's broadband device configuration from 500M to 1G. After the system reports "configuration successful," it proceeds to the next step. Then, the system interface is called to synchronously update the customer's bandwidth authentication parameters, ensuring that the customer's device can complete identity authentication and rate limiting at 1G bandwidth when accessing the network. Next, the instance management module can track the execution results of each step in real time, recording key data such as operation time and feedback information. If a step fails (e.g., device configuration timeout), a rollback mechanism is automatically triggered to restore the state before modification, and the reason for failure is recorded. After all steps are completed, the instance status is updated to "execution completed," and a modification receipt is generated, sending a "modification completed" signal to the central control process.

[0145] Step 222: Return the corresponding failure message through the preset standardized interface and terminate the current process. The failure message should include at least the reason for the failure.

[0146] like Figure 3 As shown, this embodiment of the invention provides a system for implementing in-transit order modification, the system comprising:

[0147] Request receiving module 301: used to receive in-transit modification requests sent by the current user, wherein the in-transit modification request includes at least: original order identifier, parameters to be modified, service type, and modification request type;

[0148] Multi-dimensional verification module 302: used to perform target verification on the in-transit modification request based on preset verification rules and key node rules, wherein the target verification includes: compliance check and permission confirmation;

[0149] Scene matching module 303: is used to call the preset scene rule library to match the in-transit modification request that has passed the verification with the corresponding target business scene, and generate the corresponding in-transit modification instance after the target business scene has passed the matching;

[0150] Instance management module 304: Used to call the preset process engine to start the in-transit modification instance to perform the corresponding modification operation, and restart the original process after the modification operation is completed.

[0151] based on Figure 3 The system shown is a system for implementing in-transit order modification, such as... Figure 4 As shown, after the request receiving module 301 and before the multidimensional verification module 302, it further includes: a request processing module 305;

[0152] The request processing module 305 is used to perform:

[0153] Identify the original format of the in-transit modification request, and convert the non-standardized fields in the original format into standardized field formats based on preset specifications to generate a standardized in-transit modification request;

[0154] The preset information extraction rules are invoked to extract the original order identifier, the service type, the parameters to be modified, and the modification request type from the standardized in-transit modification request;

[0155] The original order identifier, the service type, the parameters to be modified, and the modification request type are associated and bound with the original order.

[0156] like Figure 4 As shown, the multidimensional verification module 302 is used to perform:

[0157] D1: Determine the current service activation stage corresponding to the original order associated with the standardized in-transit modification request;

[0158] D2: Determine whether the current service activation process is in a modifiable stage based on the preset verification rules;

[0159] D3: When it is determined that the current service activation process is in the modifiable stage, check whether the resource availability of the parameter to be modified is passed. If yes, proceed to step D4; otherwise, proceed to step D5.

[0160] D4: Invoke the preset key node rule adapted to the current service activation stage, determine whether the current service activation stage has reached the preset unchangeable point. If yes, execute step D5; otherwise, return to execute the target business scenario corresponding to the in-transit modification request that has passed the verification by invoking the preset scenario rule.

[0161] D5: Return the corresponding rejection notification to the current user through a preset standardized interface and terminate the current process, wherein the rejection notification includes at least the reason for rejection.

[0162] like Figure 4 As shown, the scene matching module 303 is used to perform:

[0163] E1: Based on the service type and the modification request type, call the preset scenario rule base to match the corresponding target business scenario for the standardized in-transit modification request;

[0164] E2: Determine if the scene matching is successful. If yes, proceed to step E3; otherwise, proceed to step E8.

[0165] E3: Generate corresponding preprocessing logic based on the customized rules associated with the target business scenario;

[0166] E4: Perform validity checks on the preprocessing logic and downstream system interfaces, wherein the validity checks include: critical dependency condition checks and interface availability checks;

[0167] E5: Determine whether the validity check is passed. If yes, proceed to step E6; otherwise, proceed to step E8.

[0168] E6: Generate and store an in-transit modification instance corresponding to the standardized in-transit modification request, wherein the in-transit modification instance includes at least: the original order identifier, the instance identifier, the target business scenario name, the original order parameters, and the parameters to be modified;

[0169] E7: Associate and bind the in-transit modification instance with the original order;

[0170] E8: Return the corresponding failure message through the preset standardized interface and terminate the current process, wherein the failure message includes at least the reason for failure.

[0171] like Figure 4 As shown, the instance management module 304 is used to perform:

[0172] The preset process engine is invoked to load the preprocessing logic corresponding to the in-transit modification instance, execute the modification operation, and synchronously update the instance lifecycle state;

[0173] Suspend the original service activation process and simultaneously record the location of the paused node, parameters of the completed process, and the interaction status of the associated systems.

[0174] Invoke the preset processing steps corresponding to the target business scenario, and generate corresponding standardized modification instructions to execute the preset processing steps;

[0175] After the preset processing steps are completed, the preset process engine is invoked to restart the original service activation process from the paused node position;

[0176] Update the status of the original service activation process, and synchronize the restart status and modification results through the preset standardized interface.

[0177] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on an in-transit order modification system. In other embodiments of the present invention, an in-transit order modification system may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0178] The information interaction and execution process between the various units in the above-mentioned device are based on the same concept as the method embodiment of the present invention, and the specific details can be found in the description of the method embodiment of the present invention, and will not be repeated here.

[0179] This invention also provides an in-transit order modification system, comprising: at least one memory and at least one processor;

[0180] At least one memory for storing machine-readable programs;

[0181] At least one processor is configured to invoke a machine-readable program to execute an in-transit order modification method according to any embodiment of the present invention.

[0182] This invention also provides a computer-readable medium storing computer instructions, which, when executed by a processor, cause the processor to perform an in-transit order modification method according to any embodiment of this invention.

[0183] Specifically, a system or apparatus equipped with a storage medium may be provided, on which software program code implementing the functions of any of the embodiments described above is stored, and the computer (or CPU or MPU) of the system or apparatus may read and execute the program code stored in the storage medium.

[0184] In this case, the program code read from the storage medium can itself implement the function of any of the above embodiments, and therefore the program code and the storage medium storing the program code constitute part of the present invention.

[0185] Examples of storage media used to provide program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0186] Furthermore, it should be clear that not only can the program code read by the computer be executed, but also the operating system or other components operating on the computer can be instructed based on the program code to perform some or all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0187] Furthermore, it is understood that the program code read from the storage medium is written to the memory set in the expansion board inserted into the computer or to the memory set in the expansion unit connected to the computer. Then, based on the instructions of the program code, the CPU or other components installed on the expansion board or expansion unit execute some and all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0188] The various embodiments of the present invention have at least the following beneficial effects:

[0189] 1. In this embodiment of the invention, a method for implementing in-transit order modification is provided. The method first receives an in-transit modification request including the original order identifier, parameters to be modified, service type, and modification request type, laying a data foundation for subsequent accurate processing. Next, compliance checks and permission confirmations are performed according to preset verification rules and key node rules, ensuring that the modification request conforms to business specifications and significantly reducing manual verification time. Then, a preset scenario rule library is invoked to match the verified request with the corresponding target business scenario, and a corresponding in-transit modification instance is generated after successful matching, reducing the time spent on manual customized development scenarios. Finally, a preset process engine is invoked to start the modification instance and execute the modification operation, and the original process is automatically restarted after modification. Through the above process, intelligent in-transit order modification can be achieved, significantly improving the processing efficiency of in-transit order modification.

[0190] 2. In this embodiment of the invention, since different initiating systems may have different data formats, the original format of the in-transit modification request can be identified first, and non-standardized fields can be converted into standardized field formats to generate a standardized in-transit modification request with a regular structure and uniform fields. Next, preset information extraction rules are called to accurately extract the original order identifier, service type, parameters to be modified, and modification request type from the standardized in-transit modification request, avoiding errors from manual extraction. Finally, the extracted information is associated and bound with the original order, ensuring that the in-transit modification request can be accurately associated with the corresponding original order, thereby further improving the accuracy and processing efficiency of in-transit modifications. The above process does not require customizing a dedicated interface for each interface system, significantly reducing system integration costs.

[0191] 3. In this embodiment of the invention, in order to verify the modification request in transit: First, the original order identifier associated with the standardized modification request in transit can be used to query and determine the current service activation stage of the original order; then, the preset verification rules in the dynamic configuration system are called to determine whether the current service activation stage is in the modifiable stage. If the current service activation stage is in the modifiable stage, the resource availability of the parameter to be modified is checked. If the resource availability verification passes, the preset key node rules adapted to the current service activation stage are called to determine whether the current stage has reached the point of no change. If not, it means that the modification permission is available, and the subsequent steps are continued. If it has reached the point of no change, a rejection notification containing the rejection reason is returned to the current user through the preset standardized interface, and the current process is terminated to avoid wasting resources on invalid modification operations.

[0192] It should be noted that not all steps and modules in the above processes and system structure diagrams are mandatory; some steps or modules can be omitted as needed. The execution order of each step is not fixed and can be adjusted as required. The system structure described in the above embodiments can be a physical structure or a logical structure. That is, some modules may be implemented by the same physical entity, or some modules may be implemented by multiple physical entities, or they may be jointly implemented by certain components in multiple independent devices.

[0193] In the above embodiments, the hardware units can be implemented mechanically or electrically. For example, a hardware unit may include permanent dedicated circuitry or logic (such as a dedicated processor, FPGA, or ASIC) to perform the corresponding operation. The hardware unit may also include programmable logic or circuitry (such as a general-purpose processor or other programmable processor), which can be temporarily configured by software to perform the corresponding operation. The specific implementation method (mechanical, dedicated permanent circuitry, or temporarily configured circuitry) can be determined based on cost and time considerations.

[0194] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for implementing in-transit order modification, characterized in that, The method includes: Receive an in-transit modification request from the current user, wherein the in-transit modification request includes at least: the original order identifier, the parameters to be modified, the service type, and the modification request type; The in-transit modification request is subject to target verification based on preset verification rules and key node rules, wherein the target verification includes: compliance check and permission confirmation; The preset scenario rule base is called to match the in-transit modification request that has passed the verification with the corresponding target business scenario, and the corresponding in-transit modification instance is generated after the target business scenario is successfully matched; The preset process engine is invoked to start the in-transit modification instance to perform the corresponding modification operation, and the original process is restarted after the modification operation is completed.

2. The method according to claim 1, characterized in that, After receiving the in-transit modification request from the current user, and before performing target verification on the in-transit modification request based on preset verification rules and key node rules, the process further includes: Identify the original format of the in-transit modification request, and convert the non-standardized fields in the original format into standardized field formats based on preset specifications to generate a standardized in-transit modification request; The preset information extraction rules are invoked to extract the original order identifier, the service type, the parameters to be modified, and the modification request type from the standardized in-transit modification request; The original order identifier, the service type, the parameters to be modified, and the modification request type are associated and bound with the original order.

3. The method according to claim 2, characterized in that, The target verification of the in-transit modification request based on preset verification rules and key node rules includes: D1: Determine the current service activation stage corresponding to the original order associated with the standardized in-transit modification request; D2: Determine whether the current service activation process is in a modifiable stage based on the preset verification rules; D3: When it is determined that the current service activation process is in the modifiable stage, check whether the resource availability of the parameter to be modified is passed. If yes, proceed to step D4; otherwise, proceed to step D5. D4: Invoke the preset key node rule adapted to the current service activation stage, determine whether the current service activation stage has reached the preset unchangeable point. If yes, execute step D5; otherwise, return to execute the target business scenario corresponding to the in-transit modification request that has passed the verification by invoking the preset scenario rule. D5: Return the corresponding rejection notification to the current user through a preset standardized interface and terminate the current process, wherein the rejection notification includes at least the reason for rejection.

4. The method according to claim 2, characterized in that, The process of calling the preset scenario rule base is to match the verified in-transit modification request with the corresponding target business scenario, and to generate a corresponding in-transit modification instance after the target business scenario is successfully matched, including: E1: Based on the service type and the modification request type, call the preset scenario rule base to match the corresponding target business scenario for the standardized in-transit modification request; E2: Determine if the scene matching is successful. If yes, proceed to step E3; otherwise, proceed to step E7. E3: Generate corresponding preprocessing logic based on the customized rules associated with the target business scenario; E4: Perform validity checks on the preprocessing logic and downstream system interfaces, wherein the validity checks include: critical dependency condition checks and interface availability checks; E5: Determine whether the validity check is passed. If yes, proceed to step E6; otherwise, proceed to step E8. E6: Generate and store an in-transit modification instance corresponding to the standardized in-transit modification request, wherein the in-transit modification instance includes at least: the original order identifier, the instance identifier, the target business scenario name, the original order parameters, and the parameters to be modified; E7: Associate and bind the in-transit modification instance with the original order; E8: Return the corresponding failure message through the preset standardized interface and terminate the current process, wherein the failure message includes at least the reason for failure.

5. The method according to claim 1, characterized in that, The step of invoking the preset process engine to start the in-transit modification instance to perform modification operations, and restarting the original process after the modification operations are completed, includes: The preset process engine is invoked to load the preprocessing logic corresponding to the in-transit modification instance, execute the modification operation, and synchronously update the instance lifecycle state; Suspend the original service activation process and simultaneously record the location of the paused node, parameters of the completed process, and the interaction status of related systems. Invoke the preset processing steps corresponding to the target business scenario, and generate corresponding standardized modification instructions to execute the preset processing steps; After the preset processing steps are completed, the preset process engine is invoked to restart the original service activation process from the paused node position; Update the status of the original service activation process, and synchronize the restart status and modification results through the preset standardized interface.

6. A system for implementing in-transit order modification, characterized in that, The system includes: Request receiving module: used to receive in-transit modification requests sent by the current user, wherein the in-transit modification request includes at least: original order identifier, parameters to be modified, service type, and modification request type; Multi-dimensional verification module: used to perform target verification on the in-transit modification request based on preset verification rules and key node rules, wherein the target verification includes: compliance check and permission confirmation; Scene matching module: used to call the preset scene rule library to match the in-transit modification request that has passed the verification with the corresponding target business scene, and generate the corresponding in-transit modification instance after the target business scene has passed the matching; Instance management module: used to call the preset process engine to start the in-transit modification instance to perform the corresponding modification operation, and restart the original process after the modification operation is completed.

7. The system according to claim 6, characterized in that, The system further includes a request processing module after the request receiving module and before the multidimensional verification module; The request processing module is used to perform: Identify the original format of the in-transit modification request, and convert the non-standardized fields in the original format into standardized field formats based on preset specifications to generate a standardized in-transit modification request; The preset information extraction rules are invoked to extract the original order identifier, the service type, the parameters to be modified, and the modification request type from the standardized in-transit modification request; The original order identifier, the service type, the parameters to be modified, and the modification request type are associated and bound with the original order.

8. The system according to claim 7, characterized in that, The multidimensional verification module is used to perform: D1: Determine the current service activation stage corresponding to the original order associated with the standardized in-transit modification request; D2: Determine whether the current service activation process is in a modifiable stage based on the preset verification rules; D3: When it is determined that the current service activation process is in the modifiable stage, check whether the resource availability of the parameter to be modified is passed. If yes, proceed to step D4; otherwise, proceed to step D5. D4: Invoke the preset key node rule adapted to the current service activation stage, determine whether the current service activation stage has reached the preset unchangeable point. If yes, execute step D5; otherwise, return to execute the target business scenario corresponding to the in-transit modification request that has passed the verification by invoking the preset scenario rule. D5: Return the corresponding rejection notification to the current user through a preset standardized interface and terminate the current process, wherein the rejection notification includes at least the reason for rejection.

9. The system according to claim 7, characterized in that, The scene matching module is used to perform: E1: Based on the service type and the modification request type, call the preset scenario rule base to match the corresponding target business scenario for the standardized in-transit modification request; E2: Determine if the scene matching is successful. If yes, proceed to step E3; otherwise, proceed to step E7. E3: Generate corresponding preprocessing logic based on the customized rules associated with the target business scenario; E4: Perform validity checks on the preprocessing logic and downstream system interfaces, wherein the validity checks include: critical dependency condition checks and interface availability checks; E5: Determine whether the validity check is passed. If yes, proceed to step E6; otherwise, proceed to step E8. E6: Generate and store an in-transit modification instance corresponding to the standardized in-transit modification request, wherein the in-transit modification instance includes at least: the original order identifier, the instance identifier, the target business scenario name, the original order parameters, and the parameters to be modified; E7: Associate and bind the in-transit modification instance with the original order; E8: Return the corresponding failure message through the preset standardized interface and terminate the current process, wherein the failure message includes at least the reason for failure.

10. The system according to claim 6, characterized in that, The instance management module is used to perform: The preset process engine is invoked to load the preprocessing logic corresponding to the in-transit modification instance, execute the modification operation, and synchronously update the instance lifecycle state; Suspend the original service activation process and simultaneously record the location of the paused node, parameters of the completed process, and the interaction status of related systems. Invoke the preset processing steps corresponding to the target business scenario, and generate corresponding standardized modification instructions to execute the preset processing steps; After the preset processing steps are completed, the preset process engine is invoked to restart the original service activation process from the paused node position; Update the status of the original service activation process, and synchronize the restart status and modification results through the preset standardized interface.

Images