WO2016119389A1

WO2016119389A1 - Management method, device and system for system docking

Info

Publication number: WO2016119389A1
Application number: PCT/CN2015/082573
Authority: WO
Inventors: 苏懿; 张飞; 董杰
Original assignee: 华为技术有限公司
Priority date: 2015-01-30
Filing date: 2015-06-26
Publication date: 2016-08-04
Also published as: CN104618162A; CN104618162B

Abstract

Provided are a management method, device and system for system docking, which relate to the field of communications, and aim at solving the problems in the prior art of low management efficiency of system docking and consumption of manpower resources. The method comprises: according to a pre-set abnormal identification, acquiring an abnormal invoking record from at least one invoking record of an application programming interface (API); according to the abnormal invoking record of the API, determining a script factor for generation of abnormal invoking, wherein the script factor for the generation of the abnormal invoking comprises an invoking condition of the API and at least one of the invoking parameters of the API; and according to the script factor for the generation of the abnormal invoking, adjusting an API script corresponding to the abnormal invoking record. The embodiments of the present invention are used for managing system docking.

Description

Method, device and system for managing system docking

Technical field

The present invention relates to the field of communications, and in particular, to a method, an apparatus, and a system for managing system docking.

Background technique

In the prior art, when the mutual calling between multiple systems is involved, it is necessary to manually pre-define the docking code or service rules between the systems, for example, the following systems included in the NOC (Network Operation Center):

SDM (Service Desk Management) system for handling all work orders, problems, changes, etc., to ensure that these work orders operate according to established procedures;

The FM (Fault Management) system is used to filter and compress the reported alarm faults to clarify the cause of the fault.

The WFM (Workforce Management) system is used to schedule off-line personnel based on information such as the location of the off-line personnel, the location of the task, and the processing time of the task.

The processing of the network fault requires that the foregoing systems cooperate according to the docking code or the business rule between the systems, and when an abnormal call between the systems occurs, the docking code or the business rule between the systems needs to be adjusted.

In the prior art, the management of the system docking (that is, the adjustment of the docking code or the business rules between the systems) is performed manually, which is inefficient and consumes human resources. For example, when an abnormal call occurs in each of the above systems, the prior art You need BA (Business Analyst) to analyze the SDM work order information, find possible optimization points from the dimensions of professional, vendor, and region, and then optimize the points according to the specific project by SI (System Integrator). Adjusting the docking code or business rules called between systems for each system, so that each Mutual calls between systems return to normal.

Summary of the invention

The invention provides a method, a device and a system for managing the system docking, so as to solve the problem that the management of the system docking in the prior art is inefficient and consumes human resources.

In order to achieve the above object, embodiments of the present invention adopt the following technical solutions:

In a first aspect, a method for managing system docking is provided, including:

The calling server acquires an abnormal call record of the API from at least one call record of the application programming interface API according to a preset abnormal identifier, where the API is registered by the callee to any API of the calling server, The call record is used to record the call information of the API that the initiator invokes, and the exception call record of the API is the call record of the API including the exception identifier;

Determining, according to the abnormal call record of the API, a script factor that generates an exception call, the script factor that generates the exception call includes at least one of a call condition of the API and a call parameter of the API; a calling condition of the API In order to trigger a conditional factor for invoking the API, the calling parameter of the API is a transfer parameter that invokes the API;

Adjusting the API script corresponding to the exception call record according to the script factor that generates the exception call.

In conjunction with the first possible implementation of the first aspect, the determining, by the exception call record of the API, a script factor that generates an exception call includes:

The calling condition of the API included in the abnormal call record of the API is counted, and the calling condition that determines that the probability value reaches the preset threshold is the script factor that generates the abnormal call;

Or, the calling parameter of the API included in the abnormal call record of the API is counted, and the calling parameter that determines that the probability value reaches a preset threshold is the script factor that generates the abnormal call.

With reference to the first aspect, or the first possible implementation manner of the first aspect, in a second possible implementation, the adjusting the API script corresponding to the abnormal call record according to the script factor that generates the abnormal call includes:

And adjusting at least one of a calling condition and a calling parameter in the API script corresponding to the abnormal call record according to the script factor that generates the abnormal call.

With reference to the first aspect, or the first possible implementation manner of the first aspect, in a third possible implementation, the adjusting the API script corresponding to the abnormal call record according to the script factor that generates the abnormal call includes:

Querying an API associated with the script factor that generates the exception call; adding the API associated with the script factor to an API script corresponding to the exception call record.

In conjunction with the third possible implementation of the first aspect, in a fourth possible implementation, the method further includes:

Setting a correlation factor of an API registered to the calling server;

The API associated with the script factor that generates the exception call includes:

An API that matches the associated factors with the script factors that generate the exception call is queried in the API registered to the calling server.

With reference to the first aspect to any one of the possible implementations of the fourth possible implementation of the first aspect, in a fifth possible implementation, the method further includes:

The calling server receives the initiation information sent by the initiator;

After determining to invoke the API according to the event type and the event content included in the initiation information, adding the initiation information to the call record of the API;

After the API is called and the called party's called information is obtained, the called information is added to the call record of the API.

With reference to the first aspect to any one of the possible implementation manners of the fifth possible implementation manner of the first aspect, in a sixth possible implementation manner, the initiator includes a service desk management SDM system and a fault management FM The system and outside personnel manage any system in the WFM system;

The called party includes any one of a service station management SDM system, a fault management FM system, and an outside line personnel management WFM system.

With reference to the sixth possible implementation manner of the first aspect, in a seventh possible implementation manner, the initiator is a fault management FM system, and the called party is a service station management SDM system. The called information includes a work order source, and the abnormality identifier is “FM manual dispatch”;

The calling server acquires the abnormal call record of the API from at least one call record of the application programming interface API according to the preset abnormal identifier:

Obtaining the call record of the work order of all the called information from the call record of the API as "FM manual dispatch";

The determining the script factors that generate the exception call according to the abnormal call record of the API includes:

The API call condition of the API is counted in the call record of the work order source of the called information, and the call condition of the probability value reaches the preset threshold is determined as the script factor;

The adjusting the API script corresponding to the abnormal call record according to the script factor that generates the abnormal call includes:

Adjusting the API script corresponding to the API by using the calling condition that the probability value reaches a preset threshold.

With reference to the sixth possible implementation manner of the first aspect, in an eighth possible implementation manner, the initiator is a service station management SDM system, and the called party manages a WFM system for an outside party, the initiation information Including the fault processing mode, the abnormality identifier is “not arriving at the station, and the fault has been recovered”;

Obtaining, from the call record of the API, the call record of the failure processing mode of all the initiation information is “not arrived, the fault has been recovered”;

The call parameters of the API are counted in the call record of the failure detection mode of the initiating information, which is “not arrived, the fault has been recovered”, and the call parameter whose probability value reaches the preset threshold is determined as the script factor;

Adjusting the API script corresponding to the API by using the calling parameter whose probability value reaches a preset threshold.

In a second aspect, a call server is provided, including:

An obtaining unit, configured to acquire an abnormal call record of the API from at least one call record of an application programming interface API according to a preset abnormal identifier; the API is any API registered by the callee to the calling server The call record is used to record call information of the API that the initiator invokes; the exception call record of the API is a call record of the API that includes the exception identifier;

a statistical analysis unit, configured to determine, according to the abnormal call record of the API acquired by the acquiring unit, a script factor that generates an abnormal call; the script factor that generates the abnormal call includes a calling condition of the API and a call of the API At least one of the parameters; the calling condition of the API is a conditional factor that triggers the calling of the API, and the calling parameter of the API is a transfer parameter that invokes the API;

And a script adjusting unit, configured to adjust an API script corresponding to the abnormal call record according to a script factor that is generated by the statistical analysis unit to generate an abnormal call.

In conjunction with the first possible implementation of the second aspect, the statistical analysis unit is specifically configured to:

With reference to the second aspect or the first possible implementation manner of the second aspect, in a second possible implementation manner, the script adjusting unit is specifically configured to:

Adjusting an API corresponding to the abnormal call record according to the script factor that generates the abnormal call At least one of a call condition and a call parameter in the script.

With reference to the second aspect, or the first possible implementation manner of the second aspect, in a third possible implementation, the calling server further includes a query unit, configured to query, in association with the script factor that generates the exception call The script adjustment unit is specifically configured to add the API associated with the script factor to an API script corresponding to the exception call record.

With reference to the third possible implementation of the second aspect, in a fourth possible implementation, the calling server further includes a preset unit, configured to set an association factor of an API registered to the calling server;

The query unit is specifically configured to query, in the API registered to the calling server, an API that matches a correlation factor with a script factor that generates an abnormal call.

With reference to the possible implementation of the second aspect to the fourth possible implementation of the second aspect, in a fifth possible implementation, the method further includes:

a receiving unit, configured to receive initiation information sent by the initiator;

a recording unit, configured to add the initiation information to the call record of the API after determining to invoke the API according to an event type and an event content included in the initiation information;

In a third aspect, a calling system is provided, comprising: an initiator device running an initiator software system, and a called party device running the called software system, the calling system further comprising: a calling server, wherein the calling The server is connected to the initiator device and the called party device respectively;

The calling server is the calling server according to any one of the possible implementation manners of the second aspect to the fifth possible implementation manner of the second aspect;

The initiator software system of the initiator device is configured to send initiation information to the calling server; the initiation information includes a leave type and an event content;

The called software system of the called party device is configured to register an API of the called party device to the calling server; perform corresponding according to an API invoked by the calling server operating.

In a fourth aspect, a calling system is provided, comprising a multi-system device, the multi-system device comprising an initiator software system and a callee software system, the calling system further comprising: a calling server, wherein the calling server and the server The multi-system devices are connected;

An initiator software system in the multi-system device, configured to send initiation information to the calling server; the initiation information includes a leave type and an event content;

The called party software system in the multi-system device is configured to register an API of the called party software system to the calling server; and perform a corresponding operation according to the API invoked by the calling server.

Using the above scheme, the calling server statistically analyzes the law of the abnormal call of the API according to the calling record of the API, and adjusts the corresponding API script according to the law to solve the abnormal calling problem, and the efficiency of solving the abnormal calling problem is higher, and avoids Manual participation saves human resources.

DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the present invention, Those skilled in the art can also obtain other drawings based on these drawings without paying any creative work.

FIG. 1 is a schematic diagram of an inter-system call architecture according to an embodiment of the present invention;

2 is a schematic flowchart of a method for managing system interconnection according to an embodiment of the present invention;

FIG. 3 is a schematic flowchart of generating an API call record according to an embodiment of the present invention;

4 is a schematic diagram of a call record of an API according to an embodiment of the present invention;

FIG. 5 is a schematic diagram of an API script configuration according to an embodiment of the present invention;

FIG. 5b is a schematic diagram of an API script configuration adjustment according to an embodiment of the present invention; FIG.

FIG. 6a is a schematic diagram of another API script configuration according to an embodiment of the present invention;

FIG. 6b is a schematic diagram of another API script configuration adjustment according to an embodiment of the present invention;

FIG. 7 is a schematic structural diagram of a call server according to an embodiment of the present disclosure;

FIG. 8 is a schematic structural diagram of another calling server according to an embodiment of the present disclosure;

FIG. 9 is a schematic structural diagram of still another calling server according to an embodiment of the present disclosure;

FIG. 10 is a schematic structural diagram of a calling system according to an embodiment of the present disclosure;

FIG. 11 is a schematic structural diagram of another calling system according to an embodiment of the present invention.

detailed description

The technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention. It is obvious that the described embodiments are only a part of the 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 efforts are within the scope of the present invention.

The following embodiments of the present invention can be used for the inter-system call architecture as shown in FIG. 1, which includes an initiator, a callee, and a call server. The calling server is connected to the initiator and the called party, respectively. Both the initiator and the callee can be a software system that invokes a service interface for an open API, and the same software system can act as both an initiator and a callee. The software system as the called party registers an API (Application Programming Interface) that is open to the external call to the calling server, so that the calling server, when receiving the initiation information sent by the initiator, is called according to the initiation information. The callee's API implements mutual calls between systems.

It should be noted that both the initiator and the callee described herein can be understood as a software system, and the initiator and the callee can be on different physical hardware or integrated on the same physical hardware.

The embodiment of the invention provides a method for managing system docking. As shown in FIG. 2, the method includes:

S201. The calling server acquires an abnormal call record of the API from at least one call record of the API according to the preset abnormal identifier.

The API is any API registered by the callee to the calling server, and the call record is used to record the call information of the initiator calling the API, and the abnormal call record of the API is recorded as the call record of the API including the exception identifier.

It should be noted that the embodiment of the present invention is described for an API, but it should be clear to those skilled in the art that the system can be managed by the system provided by the embodiment of the present invention for other APIs registered in the calling server. The method is managed, and the calling server can implement the system docking management method provided by the embodiment of the present invention for multiple APIs at the same time.

For example, the initiator or the called party is an SDM system, and the call record of the API includes an SDM work order, and the SDM work order includes an alert type, a fault processing mode, a work order source, and the like, and the abnormal identifier may be an alarm. Type = power environment alarm", or "fault processing mode = no arrival, failure has been restored", or "work order source = manual dispatch". In this way, if the alarm type of the SDM work order in a certain call record of the API is a dynamic environment alarm, the call record is the abnormal call record.

In addition, the abnormality identifier may be preset in the scheduling server by the user or the scheduling server, or may be preset in other devices. In this case, the scheduling server needs to obtain the abnormal identifier from other devices, which is not limited by the present invention.

As shown in FIG. 1, when the inter-system call architecture is initially run, the callee registers an API that is open to the external call to the call server, where the call server can be an IPaaS (Integration Platform as a Service, integration). Platform as a service), the calling server runs an APP application in the form of an API script to implement docking between systems.

After the callee's API is registered to the calling server, the system administrator can pre-configure the API script corresponding to the API, and the calling server executes the API script to call the API. Each call record of the API is the call information of the API recorded by the calling server during an API call.

Specifically, each call record of the API includes at least the following call information:

The identifier of the API, the identifier of the API script corresponding to the API, and the event type, event content of each call to the API. In addition, if the calling parameter of the API is not empty, the calling record of the API further includes the calling parameter of the API.

For example, in the process of the initiator calling the called party, the scheduling server generates a call record of the API as shown in FIG. 3, including:

S2011: The calling server receives the initiation information sent by the initiator.

S2012. The calling server determines to add the initiation information to the call record of the API after determining to invoke the API according to the event type and event content included in the initiation information.

S2013. After the calling server calls the API and obtains the called party's called information, the called information is added to the call record of the API.

It should be noted that the API script includes a trigger event of the API, a calling condition of the API, and an identifier of the API, and the calling server determines that the event type matches the trigger event in the API script, and the event content satisfies the calling condition of the API. When the API corresponding to the identifier of the API is called.

The above process of invoking the call record of the server generation API is only a preferred implementation manner. In order to more accurately statistically analyze the rules of the API exception call, the call record of the API should include as many call dimensions as the API, according to In the above process, the call record of the API includes both the initiation information of calling the API and the called information, but in actual implementation, the call record of the API may include one of the initiation information and the called information. The invention is not limited thereto.

S202. The calling server determines, according to the abnormal call record of the API, a script factor that generates an abnormal call, and the script factor that generates the abnormal call includes at least one of a calling condition of the API and a calling parameter of the API.

The calling condition of the API is a conditional factor that triggers the calling of the API, and the calling parameter of the API is a delivery parameter that invokes the API.

Specifically, the calling server performs statistics on the calling condition of the API included in the abnormal call record of the API, and determines that the calling condition that the probability value reaches the preset threshold is a script factor that generates the abnormal call; or, the calling server The call parameters of the API included in the exception call record of the API are counted, and the call parameter whose probability value reaches the preset threshold is determined as the script factor for generating the exception call.

As an example, the initiator is the FM system and the called party is the SDM system. As shown in FIG. 4, the API call record includes: FM alarm information (ie, the initiation information), and SDM work order information (that is, the called information). And the inherent information of the API. As shown in FIG. 4, the call record of the API includes a plurality of call information, and the abnormality identifier may be any one of the FM alarm information or the SDM work order information or the API call information.

If the abnormality is identified as “FM manual dispatch”, the step S201 is specifically: the calling server acquires the call record of the “FM manual dispatch” from the at least one call record of the API.

Further, the step S202 may be: the calling server performs statistics on the calling condition in the call record of the work order of the SDM work order that is “FM manual dispatch”, and determines that the calling condition that the probability value reaches the preset threshold is the abnormality. The calling script factor, for example, the threshold is preset to 80%, and the probability of calling the condition “alarm type=power environment alarm” is 85%, then the calling condition “alarm type=power environment alarm” can be determined to generate an abnormal call. Script factor.

S203. The calling server adjusts an API script corresponding to the abnormal call record according to the script factor that generates the abnormal call.

Specifically, the adjustments to the API script include the following two methods:

Manner 1: The calling server adjusts at least one of a calling condition and a calling parameter in an API script corresponding to the abnormal calling record according to the script factor that generates the abnormal call.

For example, according to the example in step S202, if the calling server determines that the calling condition "alarm type=power environment alarm" is a script factor that generates an abnormal call, then The calling server adds the power environment alarm to the calling condition of the API in the API script corresponding to the API.

The adjustment of the API script is illustrated by using FIG. 5a and FIG. 5b. FIG. 5a is a configuration of an API script before adjustment, and FIG. 5b is a configuration of an adjusted API script.

As shown in FIG. 5a, when the initiator FM finds the root cause alarm and the alarm level of the root cause alarm is urgent, the API that identifies the creation of the SDM work order is invoked, and the call parameter for calling the API may be empty. As shown in FIG. 5b, when the initiator FM finds the root cause alarm, and the root cause alarm is an emergency or the alarm type is a power environment alarm, the API that identifies the creation of the SDM work order is called. In this way, when the type of the alarm in the originating information sent by the initiator FM to the calling server is the power environment alarm, the calling server automatically invokes the API, so that the SDM creates an SDN work order and completes the call to the SDM without The manual dispatch is manually performed, which solves the problem of abnormal call of "FM manual dispatch".

In another example, if the initiator is SDM, the callee is WFM, and the exception identifier is “not arriving, the fault has been recovered”, the calling server obtains the fault handling manner of the initiation information from the call record of the API. The call record of “not arriving at the station, the fault has been recovered” (that is, the exception call record), and the call parameters of the API in the exception call record are counted, and the probability that the delay time in the call parameter is less than 30 minutes is reached. The preset threshold (for example, 80%) increases the delay time in the calling parameters of the API.

The adjustment of the API script is illustrated by FIG. 6a and FIG. 6b. FIG. 6a is a configuration of an API script before adjustment, and FIG. 6b is a configuration of an adjusted API script.

From Figure 6a, the delay time for calling the API that creates the WFM work order task for the registration delay is 20 minutes, which may cause the off-line personnel not to go to the fault site, and the fault has been restored. From Figure 5b, the delay time for calling the API that creates the WFM work order task for the registration delay is increased to 30 minutes, which reduces the abnormal work order that generates "not arriving, the fault has been recovered".

Method 2, the calling server query is related to the script factor that generates the exception call The associated API adds the API associated with the script factor to the API script corresponding to the exception call record.

Specifically, the calling server sets an association factor of the API registered to the calling server, and the calling server queries the API associated with the script element that generates the abnormal call, including: querying the related factor in the API registered to the calling server The API that matches the scripting factor that generated the exception call.

It should be noted that the first method described above is to adjust the API that has been added to the API script. For the API that is newly registered to the calling server, the API script that can be added to the newly registered API can be added in the second way.

For example, when each API is registered to IPaaS, the administrator can set its associated factors, which can be set according to the attributes of the API, for example, an API for "registration delay to create a WFM work order task". Since the API belongs to the external delay dispatching list, the delay time of the dispatching of the API can be set. For example, the API is to create an SDM work order, and the related factor is set as a dynamic environment alarm, so that when the calling server determines that an abnormality is generated, After the script factor, the API that matches the related factors to the script factor that generated the exception is queried from the newly registered API, and the API is added to the API script.

The correlation factor is matched with the script factor that generates the abnormality, and the correlation factor may be consistent with the script factor that generates the abnormality. When there are multiple related factors in the same API, the newly registered APIs can be sorted by relevance, and the most relevant APIs are added to the API scripts, wherein one API exists consistent with multiple script factors that generate exceptions. The more relevant the factors, the higher the relevance of the API.

It should be noted that the above description is only given by the inter-system call existing between the SDM system, the FM system, and the WFM system, but those skilled in the art should understand that the system docking management method provided by the embodiment of the present invention exists for The scenarios in which multiple systems are called from each other are applicable, and the present invention does not limit this.

In a possible implementation manner of the embodiment of the present invention, the foregoing adjustment according to the API may be performed by an administrator, and specifically, the calling server will identify and generate an abnormality. The usual script factor informs the administrator as an adjustment suggestion so that the administrator can adjust the corresponding API script.

In addition, the embodiment of the present invention may further perform the foregoing steps S201 to S203 according to a certain period (such as daily or monthly, etc.), and automatically solve the problem of abnormal calling between systems, which is not limited in the embodiment of the present invention.

According to the above method, according to the call record of the API, the law of the abnormal call of the API is statistically analyzed, and the corresponding API script is adjusted according to the rule to solve the abnormal call problem, which is more efficient in solving the abnormal call problem and avoids manual participation. , saving human resources.

The embodiment of the present invention provides a call server 70, which corresponds to the method embodiment of FIG. 2, and each functional unit of the call server 70 can be used in the foregoing method steps. As shown in FIG. 7, the call server 70 includes:

The obtaining unit 71 is configured to obtain an abnormal call record from at least one call record of the application programming interface API according to the preset abnormality identifier.

The API is any API that is registered by the callee to the calling server, and the call record is used to record call information of the API that the initiator invokes; the abnormal call record of the API is to include the abnormal identifier. The call record of the API.

The statistical analysis unit 72 is configured to determine, according to the abnormal call record of the API acquired by the obtaining unit 71, a script factor that generates an abnormal call.

The script factor for generating the exception call includes at least one of a calling condition of the API and a calling parameter of the API; the calling condition of the API is a conditional element triggering the calling of the API, and the calling parameter of the API is calling the API. Passing parameters.

The script adjusting unit 73 is configured to adjust an API script corresponding to the abnormal call record according to a script factor that is generated by the statistical analysis unit to generate an abnormal call.

Specifically, after the called party's API is registered to the calling server, the system administrator can pre-configure an API script corresponding to the API, and the calling server executes the API foot. This can call this API. Each call record of the API is the call information of the API recorded by the calling server during an API call.

Wherein, each call record of the API includes at least the following call information:

Optionally, as shown in FIG. 8 , the calling server further includes: a receiving unit 74, configured to receive the initiation information sent by the initiator, and a recording unit 75, configured to use the event type included according to the initiation information. And the content of the event, after determining that the API is invoked, adding the initiation information to the call record of the API; after calling the API and obtaining the called information of the called party, adding the called information to the call of the API Recorded.

It should be noted that, in order to statistically analyze the rule of the API abnormal call, the calling record of the API should include as many call dimensions as the API, and the recording unit 75 simultaneously records the initiation information of the calling API and is called. Information, however, in actual implementation, the call record of the API may include one of the originating information and the called information. The invention is not limited thereto.

Optionally, the statistical analysis unit 72 is specifically configured to:

The calling condition of the API included in the abnormal call record of the API is counted, and the calling condition that determines that the probability value reaches the preset threshold is a script factor for generating the abnormal call;

Or, the calling parameter of the API included in the abnormal call record of the API is counted, and the calling parameter that determines that the probability value reaches a preset threshold is a script factor that causes the abnormal call.

As an example, the initiator is the FM system and the called party is the SDM system. As shown in FIG. 4, the API call record includes: FM alarm information (ie, the initiation information), and SDM work order information (that is, the called information). And the inherent information of the API. Figure 4, API The call record includes a plurality of call information, and the exception identifier may be any one of the FM alarm information or the SDM work order information or the API call information.

If the exception is identified as "FM manual dispatch", the obtaining unit 71 is specifically configured to: obtain, from the at least one call record of the API, the call record of the work order source of all the SDM work orders as "FM manual dispatch"; The statistical analysis unit 72 is specifically configured to: perform statistics on the calling conditions in the call record of the work order of the SDM work order that is “FM manual dispatch”, and determine that the calling condition that the probability value reaches the preset threshold is the abnormal call. The script factor, for example, the threshold is preset to 80%, and the probability of calling the condition "alarm type=power environment alarm" is 85%, then the calling condition "alarm type=power environment alarm" is determined to be a script for generating an abnormal call. factor.

In a possible implementation manner of the embodiment of the present invention, the script adjusting unit 73 is specifically configured to: adjust at least one of a calling condition and a calling parameter in an API script corresponding to the abnormal calling record according to the script factor that generates the abnormal calling One.

For example, if the statistical analysis unit 72 determines that the calling condition "alarm type=power environment alarm" is a script factor that generates an abnormal call, the script adjusting unit 73 adds the power environment alarm to the API in the API script corresponding to the API. In the call condition.

The adjustment of the API script is illustrated by using FIG. 5a and FIG. 5b. FIG. 5a is a configuration of an API script before adjustment, and FIG. 5b is a configuration of an adjusted API script. For details, refer to the corresponding description in the method embodiments, and details are not described herein again.

The adjustment of the API script is illustrated by FIG. 6a and FIG. 6b. FIG. 6a is a configuration of an API script before adjustment, and FIG. 6b is a configuration of an adjusted API script. Specific reference Corresponding descriptions in the method embodiments are not described herein again.

In another possible implementation manner of the embodiment of the present invention, as shown in FIG. 8, the calling server further includes a query unit 76, configured to query an API associated with the script factor that generates the abnormal call; the script adjusting unit 73 is specifically configured to add the API associated with the script factor to an API script corresponding to the exception call record.

Optionally, the calling server further includes a pre-setting unit 77, configured to set an association factor of an API registered to the calling server; thus, the query unit 76 is specifically configured to query the association in the API registered to the calling server. The factor is the API that matches the scripting factor that generated the exception call.

The above calling server is used, and the calling server statistically analyzes the law of the API abnormal call according to the calling record of the API, and adjusts the corresponding API script according to the law to solve the abnormal calling problem, and the efficiency of solving the abnormal calling problem is higher, and Avoid manual participation and save human resources.

It will be clearly understood by those skilled in the art that for the convenience and brevity of the description, only the division of the above functional modules is illustrated. In practical applications, The above functions are allocated by different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. For the specific working process of the foregoing unit, refer to the corresponding process in the foregoing method embodiment, and details are not described herein again.

An embodiment of the present invention provides a call server 90, as shown in FIG. 9, including:

a processor 91, a communications interface 92, a memory 93, and a communication bus 94; wherein the processor 91, the communication interface 92, and the memory 93 are completed by the communication bus 94 Communication with each other.

The processor 91 may be a multi-core central processing unit CPU, or an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

The memory 93 is for storing program code, and the program code includes computer operation instructions and a network flow diagram. The memory 93 may include a high speed RAM memory and may also include a non-volatile memory such as at least one disk memory.

The communication interface 92 is used to implement connection communication between these devices.

The processor 91 is configured to execute program code in the memory 93 to implement the following operations:

Determining, by the exception call record of the API, a script factor that generates an exception call, the script factor that generates the exception call includes a call condition of the API and the API At least one of the calling parameters; the calling condition of the API is a conditional factor that triggers the calling of the API, and the calling parameter of the API is a transfer parameter that invokes the API;

Optionally, the determining, according to the abnormal call record of the API, determining a script factor that generates an abnormal call includes:

Optionally, the adjusting the API script corresponding to the exception call record according to the script factor that generates the exception call includes:

Optionally, the operations further include:

Setting a correlation factor of an API registered to the calling server;

Optionally, the operations further include:

The calling server receives the initiation information sent by the initiator;

Optionally, the initiator includes any one of a service station management SDM system, a fault management FM system, and an outside line personnel management WFM system;

An embodiment of the present invention provides a calling system. As shown in FIG. 10, the calling system includes:

The initiator device 101 running the initiator software system, and the called party device 102 running the called software system, further includes: an invoking server 103, wherein the invoking server 103 and the initiating device 101 and the called party respectively The device is connected 102.

The initiator software system of the initiator device 101 is configured to send initiation information to the calling server; the initiation information includes a leave type and an event content.

The called software system of the called party device 102 is configured to register the API of the called party device to the calling server; perform corresponding operations according to the API invoked by the calling server.

The call server 103 is the call server 70 shown in FIG. 7, or the call server 80 shown in FIG. 8, or the call server 90 shown in FIG. 9. For example, refer to FIG. 7 or FIG. 8 in the above embodiment. The description of Figure 9 will not be repeated here.

According to the above system, the calling server in the system statistically analyzes the law of the abnormal call of the API according to the calling record of the API, and adjusts the corresponding API script according to the law to solve the abnormal calling problem between the software systems, and solves the abnormal calling problem. More efficient, and avoiding human involvement, saving human resources.

An embodiment of the present invention provides a calling system. As shown in FIG. 11, the calling system includes: a multi-system device 111. The multi-system device includes an initiator software system and a callee software system, and the calling system further includes: calling the server. 112, wherein the calling server 112 is connected to the multi-system device 111.

The initiator software system in the multi-system device 111 is configured to send initiation information to the calling server; the initiation information includes a leave type and an event content.

The called party software system in the multi-system device 111 is configured to register the API of the called party software system to the calling server; and perform corresponding operations according to the API invoked by the calling server.

In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the device embodiments described above are merely illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be another division manner, for example, multiple units or components may be used. Combinations can be integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be in an electrical, mechanical or other form.

The unit described as a separate component may or may not be physically separated, and the component displayed as a unit may or may not be a physical unit. To be located in one place, or distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a standalone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application, in essence or the contribution to the prior art, or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium. A number of instructions are included to cause a computer device (which may be a personal computer, server, or network device, etc.) or a processor to perform all or part of the steps of the methods described in various embodiments of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like. .

The above is only a specific embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily think of changes or substitutions within the technical scope of the present invention. All should be covered by the scope of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

A method for managing system docking, comprising:

The calling server acquires an abnormal call record of the API from at least one call record of the application programming interface API according to a preset abnormal identifier, where the API is registered by the callee to any API of the calling server, The call record is used to record the call information of the API that the initiator invokes, and the exception call record of the API is the call record of the API including the exception identifier;

Determining, according to the abnormal call record of the API, a script factor that generates an exception call, the script factor that generates the exception call includes at least one of a call condition of the API and a call parameter of the API; a calling condition of the API In order to trigger a conditional factor for invoking the API, the calling parameter of the API is a transfer parameter that invokes the API;

Adjusting the API script corresponding to the exception call record according to the script factor that generates the exception call.
The method according to claim 1, wherein said determining a script factor for generating an exception call according to an abnormal call record of said API comprises:

The calling condition of the API included in the abnormal call record of the API is counted, and the calling condition that determines that the probability value reaches the preset threshold is the script factor that generates the abnormal call;

Or, the calling parameter of the API included in the abnormal call record of the API is counted, and the calling parameter that determines that the probability value reaches a preset threshold is the script factor that generates the abnormal call.
The method according to claim 1 or 2, wherein the adjusting the API script corresponding to the abnormal call record according to the script factor for generating the abnormal call comprises:

And adjusting at least one of a calling condition and a calling parameter in the API script corresponding to the abnormal call record according to the script factor that generates the abnormal call.
Method according to claim 1 or 2, characterized in that said basis The script factor that generates the exception call adjusts the API script corresponding to the exception call record, including:

Querying an API associated with the script factor that generates the exception call; adding the API associated with the script factor to an API script corresponding to the exception call record.
The method of claim 4, wherein the method further comprises:

Setting a correlation factor of an API registered to the calling server;

The API associated with the script factor that generates the exception call includes:

An API that matches the associated factors with the script factors that generate the exception call is queried in the API registered to the calling server.
The method according to any one of claims 1 to 5, further comprising:

The calling server receives the initiation information sent by the initiator;

After determining to invoke the API according to the event type and the event content included in the initiation information, adding the initiation information to the call record of the API;

After the API is called and the called party's called information is obtained, the called information is added to the call record of the API.
The method according to any one of claims 1 to 6, wherein the initiator includes any one of a service station management SDM system, a fault management FM system, and an outside line personnel management WFM system;

The called party includes any one of a service station management SDM system, a fault management FM system, and an outside line personnel management WFM system.
A call server, comprising:

An obtaining unit, configured to acquire an abnormal call record of the API from at least one call record of an application programming interface API according to a preset abnormal identifier; the API is any API registered by the callee to the calling server The call record is used to record call information of the initiator calling the API; the abnormal call record of the API is included The call record of the API of the exception identifier;

a statistical analysis unit, configured to determine, according to the abnormal call record of the API acquired by the acquiring unit, a script factor that generates an abnormal call; the script factor that generates the abnormal call includes a calling condition of the API and a call of the API At least one of the parameters; the calling condition of the API is a conditional factor that triggers the calling of the API, and the calling parameter of the API is a transfer parameter that invokes the API;

And a script adjusting unit, configured to adjust an API script corresponding to the abnormal call record according to a script factor that is generated by the statistical analysis unit to generate an abnormal call.
The call server according to claim 8, wherein the statistical analysis unit is specifically configured to:

The calling condition of the API included in the abnormal call record of the API is counted, and the calling condition that determines that the probability value reaches the preset threshold is the script factor that generates the abnormal call;

Or, the calling parameter of the API included in the abnormal call record of the API is counted, and the calling parameter that determines that the probability value reaches a preset threshold is the script factor that generates the abnormal call.
The call server according to claim 8 or 9, wherein the script adjustment unit is specifically configured to:

And adjusting at least one of a calling condition and a calling parameter in the API script corresponding to the abnormal call record according to the script factor that generates the abnormal call.
The call server according to claim 8 or 9, wherein the call server further comprises a query unit for querying an API associated with the script factor for generating an exception call; the script adjustment unit is specifically configured to And adding the API associated with the script factor to an API script corresponding to the exception call record.
The call server according to claim 11, wherein the call server further comprises a preset unit configured to set an association factor of an API registered to the call server;

The query unit is specifically configured to query, in the API registered to the calling server, an API that matches a correlation factor with a script factor that generates an abnormal call.
The call server according to any one of claims 8 to 12, further comprising:

a receiving unit, configured to receive initiation information sent by the initiator;

a recording unit, configured to add the initiation information to the call record of the API after determining to invoke the API according to an event type and an event content included in the initiation information;

After the API is called and the called party's called information is obtained, the called information is added to the call record of the API.
A call server, comprising: a processor and a memory;

The memory stores program code for the processor to execute the program code to:

Acquiring an exception call record of the API from at least one call record of the application programming interface API according to a preset exception identifier, where the API is registered by the callee to any API of the call server, the call record Used to record call information of the API that the initiator invokes, and the abnormal call record of the API is recorded as an invocation record of the API including the exception identifier;

Determining, according to the abnormal call record of the API, a script factor that generates an exception call, the script factor that generates the exception call includes at least one of a call condition of the API and a call parameter of the API; a calling condition of the API In order to trigger a conditional factor for invoking the API, the calling parameter of the API is a transfer parameter that invokes the API;

Adjusting the API script corresponding to the exception call record according to the script factor that generates the exception call.
The call server according to claim 14, wherein the processor is configured to perform a script factor for determining an abnormal call according to the abnormal call record of the API, the processor being specifically configured to:

The calling condition of the API included in the abnormal call record of the API is counted, and the calling condition that determines that the probability value reaches the preset threshold is the script factor that generates the abnormal call;

Or, the calling parameter of the API included in the abnormal call record of the API is counted, and the calling parameter that determines that the probability value reaches a preset threshold is the script factor that generates the abnormal call.
The calling server according to claim 14 or 15, wherein the processor is configured to perform an adjustment of an API script corresponding to the abnormal call record according to the script factor for generating the abnormal call, the processor specifically Used for:

And adjusting at least one of a calling condition and a calling parameter in the API script corresponding to the abnormal call record according to the script factor that generates the abnormal call.
The calling server according to claim 14 or 15, wherein the processor is configured to perform an adjustment of an API script corresponding to the abnormal call record according to the script factor for generating the abnormal call, the processor specifically Used for:

Querying an API associated with the script factor that generates the exception call; adding the API associated with the script factor to an API script corresponding to the exception call record.
The call server according to claim 17, wherein the processor is further configured to: set an association factor of an API registered to the calling server; and the processor is configured to execute a query and the generating an exception call An aspect of the API associated with the script factor, the processor is specifically configured to query, in the API registered to the calling server, an API that matches a correlation factor with a script factor that generates an exception call.
The call server according to any one of claims 14 to 18, wherein the processor is further configured to receive the initiation information sent by the initiator;

After determining to invoke the API according to the event type and the event content included in the initiation information, adding the initiation information to the call record of the API;

After the API is called and the called party's called information is obtained, the call is adjusted. Information is added to the call record of the API.
An invoking system, comprising an initiator device running an initiator software system, and a called party device running the called software system, wherein the calling system further comprises: a calling server, wherein the calling server Connected to the initiator device and the called party device respectively;

The calling server is the calling server according to any one of claims 8 to 13, or the calling server according to any one of claims 14 to 19;

The initiator software system of the initiator device is configured to send initiation information to the calling server; the initiation information includes a leave type and an event content;

The called software system of the called party device is configured to register an API of the called party device to the calling server; perform a corresponding operation according to an API invoked by the calling server.
A calling system, comprising a multi-system device, the multi-system device comprising an initiator software system and a callee software system, wherein the calling system further comprises: a calling server, wherein the calling server and the Multi-system devices connected;

The calling server is the calling server according to any one of claims 8 to 13, or the calling server according to any one of claims 14 to 19;

An initiator software system in the multi-system device, configured to send initiation information to the calling server; the initiation information includes a leave type and an event content;

The called party software system in the multi-system device is configured to register an API of the called party software system to the calling server; and perform a corresponding operation according to the API invoked by the calling server.