KR102668324B1 - Method for managing interface, interface governance system, and a storage medium storing a computer-executable program to manage the interface - Google Patents

Abstract

The present invention provides an interface management method which comprises the steps of: providing a failure handling guide based on failure information on a detected failure when the failure of a computing system is detected; handling the failure based on the failure handling guide; and registering action details of the handled failure and evaluation details of the failure handling guide.

Description

{Method for managing interface, interface governance system, and a storage medium storing a computer-executable program to manage the interface}

The following disclosure relates to an interface management method, an interface governance system, and a storage medium for storing a computer-executable program that manages the interface.

Based on computing systems, various types of information are exchanged between companies and numerous application systems within a company.

Computing systems are increasingly cloud systems, but many are also on-premise systems within companies. The transition from the traditional on-premise system environment to the cloud system environment is rapidly occurring.

If the types of computers are different in heterogeneous computing systems, a system can be built that can interface with the connected computing system and interfaces such as API (Application Programming Interface).

However, these system interconnection systems may have different application principles, implementation methods, and management standards, and have problems that are difficult to monitor.

With regard to this system interconnection system, checking problems or failures through administrators can take a long time and can cause problems with the currently running computing system, making it difficult to manage and verifying solutions.

In addition, when the resources of the computing system within a company are increased, problems such as those mentioned above may occur repeatedly on the interface with the existing computing system, making it difficult to take accurate and reliable measures for these recurring problems.

The disclosed embodiment is intended to solve the above problems, and is a method for managing the interfaces of computing systems, an interface governance system that can easily manage the interfaces of interconnected computing systems and easily verify the accuracy of the management results. , and providing a storage medium for storing computer-executable programs that manage the interface of computer systems.

The disclosed embodiments include a method for managing interfaces of computing systems that develops interfaces for smoothly transmitting and receiving data between different computing systems, an interface governance system, and a computer-executable program that manages interfaces of computer systems. It provides a storage medium for storing.

The disclosed embodiments store a method for managing interfaces of computing systems, an interface governance system, and a computer-executable program that can quickly identify and easily manage failures between connected computing systems, and manage interfaces of computer systems. It provides a storage medium that

The disclosed embodiments store a method for managing interfaces of computing systems that can accurately and reliably deal with repeated failures of connected computing systems, an interface governance system, and a computer-executable program that manages interfaces of computer systems. It provides a storage medium that

The disclosed embodiment includes a method for managing an interface that can efficiently perform interface design, construction, management, operation and maintenance, an interface governance system, and storing a computer-executable program for managing interfaces of computer systems. It provides storage media.

One embodiment disclosed includes: when a failure of a computing system is detected, providing a failure handling guide based on failure information about the detected failure; Handling the failure based on the failure handling guide; and registering action details of the handled failure and evaluation details of the failure handling guide.

The interface management method includes the step of grouping at least one of the failure information, the failure handling guide, action details for the failure, and evaluation details of the failure handling guide by failure type.

The interface management method includes the step of indexing at least one of the failure information, the failure handling guide, action details for the failure, and evaluation details of the failure handling guide by failure type.

One embodiment of the disclosure includes a database storing data; and a processor that processes the data, wherein, when a failure of the computing system is detected, the processor provides a failure handling guide based on failure information about the detected failure, and resolves the failure based on the failure handling guide. Provides an interface governance system that processes and registers the action details of the processed failure and the evaluation details of the failure handling guide.

The processor is characterized in that it groups at least one of the failure information, the failure handling guide, the action details of the failure, and the evaluation details of the failure handling guide by failure type.

The processor is characterized in that at least one of the failure information, the failure handling guide, the action details of the failure, and the evaluation details of the failure handling guide are indexed by failure type.

One embodiment disclosed includes: when a failure of a computing system is detected, providing a failure handling guide based on failure information about the detected failure; Handling the failure based on the failure handling guide; and a storage medium storing a computer-executable program that manages an interface for registering action details for the processed failure and evaluation details of the failure handling guide.

According to the disclosed embodiment, data can be easily transmitted and received between different computing systems by building an interface that connects the computing systems.

According to the disclosed embodiment, the interfaces of interconnected computing systems can be easily managed and the management results can be easily verified for accuracy.

According to the disclosed embodiment, failures between interconnected computing systems can be quickly identified and easily managed.

According to the disclosed embodiment, repeated failures between interconnected computing systems can be dealt with accurately and reliably.

According to the disclosed embodiment, interface design, construction, management, operation, and maintenance can be performed efficiently.

1 is a conceptual diagram of an interface governance system according to an embodiment
Figure 2 is a diagram illustrating in detail an example of the interface governance platform mentioned above.
Figure 3 is a diagram conceptually illustrating an architecture for managing the interface of a computing system using the interface governance platform illustrated above.
Figure 4 is a diagram conceptually showing examples of functions of a distributed agent adapter according to an embodiment.
FIG. 5 is a diagram illustrating an example of managing interface-related data transmitted from a computing system based on an interface governance platform according to an embodiment.
Figure 6 is a diagram illustrating an example of a method for managing the interface of a computing system according to an embodiment
Figure 7 is a diagram disclosing the interface governance platform of the present invention
Figure 8 is a diagram disclosing the standard information management module of the present invention
9 is a diagram illustrating a user interface (UI) screen provided by the interface management method of the present invention.
10 is a diagram illustrating a user interface (UI) screen provided by the interface management method of the present invention.
11 is a diagram illustrating a user interface (UI) screen for applying for an interface provided by the interface management method of the present invention.
12 is a diagram disclosing an interface definition template related to the present invention.
13 is a flow chart disclosing the interface management method of the present invention
Figure 14 is a diagram disclosing the interface governance platform of the present invention
15 is a diagram disclosing the life cycle management module of the present invention
Figure 16 is a diagram illustrating the life cycle management process of the interface of the present invention
17 is a diagram illustrating a user interface (UI) screen provided by the interface management method of the present invention.
18 is a diagram illustrating a user interface (UI) screen provided by the interface management method of the present invention.
19 is a flow chart disclosing the interface management method of the present invention
Figure 20 is a diagram disclosing the interface governance platform of the present invention
Figure 21 is a diagram disclosing the specification definition module of the present invention
Figure 22 is a diagram disclosing the development automation module of the present invention
Figure 23 is a diagram showing the interface mapping definition of the present invention
Figure 24 is a diagram showing reference information stored in the interface information storage of the present invention
Figure 25 is a diagram showing object information for each interface service component of the present invention
26 is a flow chart disclosing the interface management method of the present invention.
Figure 27 is a diagram illustrating an example in which the interface governance system collects log data according to an embodiment
FIG. 28 is a diagram illustrating an example of generating log data for at least one step included in an interface-related process according to an embodiment
29 is a diagram illustrating an example of a user interface (UI) for collector access information according to an embodiment
30 is a diagram illustrating an example of a user interface (UI) for collector performance information according to an embodiment
31 is a flowchart illustrating an example of collecting log data by an interface management method according to an embodiment.
Figure 32 is a diagram illustrating an example in which an interface governance system provides interface monitoring information according to an embodiment
Figure 33 is a diagram illustrating another example in which the interface governance system according to an embodiment provides interface monitoring information
34 is a diagram illustrating an example of a user interface (UI) for log data collected based on an integrated solution according to an embodiment.
35 is a diagram illustrating an example of a user interface (UI) for interface mapping information according to an embodiment
36 is a diagram illustrating an example of a user interface (UI) for work-related interface monitoring information according to an embodiment
37 is a diagram illustrating another example of a user interface (UI) for work-related interface monitoring information according to an embodiment.
38 is a flowchart illustrating an example in which an interface management method according to an embodiment provides interface monitoring information.
Figure 39 is a diagram illustrating an example in which an interface governance system according to an embodiment provides monitoring and management setting information through a user interface (UI)
40 is a diagram illustrating another example in which the interface governance system according to an embodiment provides monitoring and management setting information through a user interface (UI)
41 is a diagram illustrating an example of a user interface (UI) for aggregate information according to an embodiment
42 is a diagram illustrating an example of a user interface (UI) for interface status information according to an embodiment
43 is a diagram illustrating an example of a user interface (UI) for resource monitoring information according to an embodiment
44 is a diagram illustrating an example of a user interface (UI) for performance monitoring information according to an embodiment
45 is a diagram illustrating an example of a user interface (UI) for transaction monitoring information according to an embodiment
46 is a diagram illustrating an example of a user interface (UI) for detailed message information according to an embodiment
47 is a diagram illustrating an example of a user interface (UI) for adapter backlog monitoring information according to an embodiment
48 is a diagram illustrating an example of a user interface (UI) for adapter queue monitoring information according to an embodiment
49 is a diagram illustrating an example of a user interface (UI) for channel state information according to an embodiment
50 is a diagram illustrating an example of a user interface (UI) for user information according to an embodiment
51 is a diagram illustrating an example of a user interface (UI) for responsible interface information according to an embodiment
52 is a diagram illustrating an example of a user interface (UI) for interface group information according to an embodiment
53 is a diagram illustrating an example of a user interface (UI) for system information according to an embodiment
54 is a diagram illustrating an example of a user interface (UI) for interface information according to an embodiment
55 is a flowchart illustrating an example in which the interface management method according to an embodiment provides monitoring and management setting information through a user interface (UI).
Figure 56 is a diagram illustrating an example in which an interface governance system detects failures and provides solutions according to an embodiment
57 is a diagram illustrating another example in which an interface governance system according to an embodiment detects failures and provides solutions.
58 is a diagram illustrating an example of a user interface (UI) for notification information according to an embodiment
59 is a flowchart illustrating an example of converting a data format by an interface management method according to an embodiment.
Figure 60 is a diagram disclosing the interface governance platform of the present invention
61 is a diagram illustrating the notification rule setting screen of the present invention
Figure 62 is a diagram illustrating the duplicate notification suppression rule setting screen of the present invention
63 is a diagram illustrating the notification message template management screen of the present invention
Figure 64 is a flow chart disclosing the interface management method of the present invention
Figure 65 is a diagram disclosing the interface governance platform of the present invention
66 is a diagram illustrating the failure handling method of the present invention
67 is a diagram illustrating the error handling screen of the present invention
Figure 68 is a diagram illustrating the failure statistics screen of the present invention
Figure 69 is a diagram illustrating the error processing status monitoring screen of the present invention
70 is a flow chart disclosing the interface management method of the present invention

1 is a conceptual diagram of an interface governance system according to an embodiment.

The disclosing embodiment may provide a control system 100 that provides an interface governance platform 10000.

The example interface governance platform 10000 can collect, monitor, and manage interface information of various computing systems. The control system 100 can control and manage the interface governance platform 10000.

In this example, the interface governance platform (10000) may be connected to an external cloud system or an on-premises system through an API or the like.

When the distributed agent adapter 10 is installed in a cloud system or an on-premise system, it can distribute data communication between each system or perform protocol conversion for data communication between each system.

The distributed agent adapter 10 can process data according to conditions set in the installed computing system. The distributed agent adapter 10's own log data according to data processing can be transmitted to the interface governance platform 10000 and used for monitoring interface data.

The interface governance platform 10000 can monitor the interface and communication status between systems based on related information such as the solution of each system or the interface received from the distributed agent adapter 10. The interface governance platform 10000 can take action on failures of related computing systems based on the monitored results and remotely manage the computing systems.

Detailed examples of this are disclosed below.

The interface governance platform 10000 can access a configuration repository that stores interface components of computing systems or application solutions within those systems.

To this end, the interface governance platform 10000 can collect data from computing systems or application solutions within those systems through standard APIs or custom APIs provided by those systems or solutions.

The interface governance platform 10000 can monitor information within the computer system or information related to the interface of the system through additional log data, even data not provided by the computing system solution.

The interface governance platform (10000) can be used for monitoring and failover of interfaces, creation of service automation, service recycling, and service verification through related information setting repository access linking technology such as the interface of the computing system.

To this end, the interface governance platform 10000 may include a standardization module that standardizes and manages the interface or a monitoring module that monitors the system through the interface.

Below, an embodiment of an interface governance platform (10000) that can manage a system through an interface will be disclosed in detail.

Figure 2 is a diagram illustrating in detail an example of the interface governance platform mentioned above.

The interface governance platform 10000 may include an interface standardization module 1000 and an interface monitoring module 2000.

The interface standardization module 1000 can generalize and manage information obtained from interfaces based on interface application principles, interface implementation methods, or interface management standards for interfaces with connected computing systems according to a management system. Here, generalizing the information obtained from the interface according to the management system is called interface standardization.

Standardization of interfaces can be performed based on various linkage technologies for managing interfaces and naming rules for identifying multiple interfaces.

The interface standardization module 1000 can manage a computing system through a connected interface and the interface based on standardized information obtained from the interface.

The interface standardization module 1000 can manage standardized information collected from the interface, that is, standard information.

For example, the connection method transmitted and received between interfaces, the rules defining the interface, and the structure, type or arrangement of data transmitted and received on the interface are different for each interface. The interface standardization module 1000 can store this standard information for each interface and manage it as standardized information.

The interface standardization module 1000 may provide an interface definition screen that provides a mapping design for the interface that each computing system wishes to build. This allows the computing system to automatically create interfaces, test the created interfaces, or manage the life cycle of the created interfaces.

The interface standardization module 1000 may include modules such as a standard information management module 1100, a specification definition module 1200, a life cycle management module 1300, and a development automation module 1400. The interface standardization module 1000 ) will be described later below.

Meanwhile, the interface monitoring module 2000 can monitor a computing system connected through a standardized or registered interface.

The interface monitoring module 2000 can collect log data collected from various applications by the application integration solution of the cloud system through a standard API. Likewise, the interface monitoring module 2000 can collect log data collected by the application integration solution of the on-premise system from applications of multiple systems through a standard API.

The interface monitoring module 2000 can receive data that cannot be collected by the integrated solution of each system from the log processor of the cloud system or the log processor of the on-premise system.

Distributed agent adapters in cloud systems or on-premise systems can complement the limitations of standard interfaces and implement customized interface functions through distributed transactions.

The interface monitoring module 2000 according to the embodiment can monitor interface-related data provided by the integrated solution of each system. Additionally, the interface monitoring module 2000 can monitor interface-related data not provided by the integrated solution from the log processor, or separate log data collected by the distributed agent adapter.

An embodiment of the interface monitoring module 2000 may provide statistical information on collected log data. And the interface monitoring module 2000 can learn the collected information using machine learning to check abnormal behavior and provide errors to the interface manager.

In this drawing, an example of the interface monitoring module 2000 includes a log collection module 2100, a control module 2200, and a failure notification module 2300. The interface monitoring module 2000 is described below. Described in detail later.

The control system 100 may include a computer server 110 having at least one processor and a storage or database 120, and may use this to control and manage the interface governance platform 10000.

In this way, the interface governance platform (10000) can standardize and manage the design of the interface of the computing system. Therefore, the interface governance platform (10000) systematically manages the computing system through the interface. In addition, even when additional resources of the computing system are built, the interface governance platform 10000 can improve the performance or management efficiency of the computing system through the managed interface.

Figure 3 is a diagram conceptually illustrating an architecture for managing the interface of a computing system using the interface governance platform illustrated above.

When expanding the internal computing system and connecting internal and external computing systems, there may be several interfaces between computing systems.

When integrating application systems within a company (Enterprise Application Integration (EAI)), interfaces between internal systems may be required. For example, in the case of an on-premise system, an Enterprise Application Integration (EAI) system such as SAP Process Orchestration (SAP PO) can be used. In the case of a cloud system, it can also be used as an EAI system such as SAP's Integration Suite (SAP IS) or IBM Sterling.

Even when large-capacity data connection is required, such as a real-time data streaming platform, various interfaces can be used.

Computing systems such as cloud systems or on-premise systems can be linked to each other through various system interfaces (I/F).

As mentioned, the interface may be an interface between systems within the management network, or between an internal system and an external system.

For example, the exemplified interface may be an interface linked between on-premise systems, or an interface between an integrated system of an on-premise system and a cloud system.

An example of the interface governance platform (10000) to be launched includes an interface standardization module (1000) that standardizes, registers, and manages the interfaces of various application solutions input through APIs, and collects, converts, and processes information transmitted from the interfaces. It may include a monitoring module (2000) that aggregates and performs statistical processing.

In the example of this figure, the integrated solution 22 of the on-premise system may collect interface data from multiple computing systems within the system. The integrated solution 22 of the on-premise system can receive data for the interface from various types of legacy systems within the on-premise system. Legacy systems can be connected to other systems through an integrated solution (22).

The integrated solution 22 may include a log processor, and the integrated solution 22 may collect data related to the interfaces of individual systems within the on-premise system. The integrated solution 22 can collect log data for a standardized interface, including interface data transmitted by legacy systems and applications. A log processor installed within the integrated solution 22 or separately can collect non-standardized interface data.

And the integrated solution 22 or the log processor within the integrated solution 22 can transmit log data related to the interface and non-standardized interface data of the on-premises system to the interface governance platform 10000. For example, non-standardized interface-related data is not provided by the integrated solution 22, but may be collected separately within the solution for monitoring, or may include at least one of additional information required for monitoring stored in the computer system.

Meanwhile, the on-premises system may separately include a distributed agent adapter 12. The distributed agent adapter 12 can perform conversion on data that the integrated solution 22 cannot convert. The distributed agent adapter 12 can supplement the processing of interface data that the integrated solution 22 cannot support or perform extended data processing.

When the distributed agent adapter 12 is installed in an on-premises system, the distributed agent adapter 12 can act as a hub for interface data within the on-premises system and can also perform tasks related to security or authentication.

The distributed agent adapter 12 may generate additional self-monitoring log data related to the processing of the above data within the on-premise system. And the distributed agent adapter 12 can transmit the generated self-monitoring data to the interface governance platform 10000. This is described in detail below.

cloud system

The integrated solution 25 of the cloud system can receive interface data from various software installed in the cloud. In this example, the cloud system is a cloud system that provides SaaS software.

The integrated solution 25 can collect standardized interface data not only from SaaS software but also from application systems installed within a cloud system.

If a log processor is installed in the integrated solution 25 of the cloud system, the log processor can collect what occurs in the processes of the integrated solution 25 in relation to the interface (interface I/F) of various solutions in the cloud system. For example, a log processor can generate log data from non-standardized interface data generated during the process when software is executed.

Likewise, non-standardized interface-related data is not provided by the integrated solution 25, but may be collected separately within the solution for monitoring, or may include at least one of the additional information required for monitoring stored in the computer system.

And the integrated solution 25 and the log processor within the integrated solution 25 can each transmit the interface data and interface-related data of the cloud system to the interface governance platform 10000.

Meanwhile, a distributed agent adapter 15 may also be installed separately in the cloud system. The distributed agent adapter 15 of the cloud system can distribute and convert data from systems that the integrated solution 25 cannot process. The distributed agent adapter 15 can transmit its own log data generated during distributed processing to the interface governance platform 10000.

If the distributed agent adapter 15 is installed in a cloud system, the distributed agent adapter 15 can support data processing or protocol conversion of interface data outside the defined functional constraints of the integrated solution 25 of the cloud system.

With the recent transition to cloud systems, there are cases where heterogeneous systems are integrated, such as integration of cloud systems and on-premises systems.

In such cases, the distributed agent adapters 12 and 15 installed in the on-premise or cloud system can transmit and receive data related to the interface with the integrated solution or distributed agent adapter of the other system. The example of this figure illustrates that the distributed agent adapter 15 of a cloud system and the distributed agent adapter 15 of a third cloud system or on-premises system can transmit and receive data related to the interface.

Likewise, the integrated solution or distributed agent adapter 15 can transmit self-monitoring data of collected interface-related data or distributed processed data to the interface governance platform 10000. Detailed examples of distributed agent adapters are described below.

Even when multiple systems are combined, the interface governance platform (10000) can collect, manage, and monitor standardized interface data of these systems or data related to separate, non-standardized interfaces.

For example, the interface standardization module 1000 of the interface governance platform 10000 can manage standard information of the interface.

The interface standardization module 1000 can register and manage each interface using standard information of the interface (interface I/F) of the cloud system or on-premise system.

The interface standardization module 1000 can newly register and test interfaces, or automate interface management services.

Additionally, the interface standardization module 1000 can provide various automation tools that can automatically manage managed interfaces, and can overall manage processes such as interface creation, management, operation, and disposal.

The interface monitoring module 2000 may perform monitoring, such as processing statistics of data collected in relation to the interface (interface I/F) of a cloud system or an on-premise system.

The interface monitoring module 2000 includes a collector hub that can collect various data related to the interface, and can convert or statistically process the collected data.

The interface monitoring module 2000 can provide a dashboard to the administrator about the monitoring situation in real time or at a specific time.

Additionally, the interface monitoring module 2000 can provide a function to check and repair system failures through the interface of a cloud system or on-premise system based on the monitored data.

The interface governance platform (10000) can provide services related to integration, construction, management, and monitoring of multiple computing systems.

The interface governance platform (10000) as in the embodiment can manage systems integratedly without the need for personnel to reside in the computing system for system integration and operation.

FIG. 4 is a diagram conceptually illustrating examples of functions of a distributed agent adapter according to an embodiment.

In this drawing, the cloud system is shown at the top and the on-premises system is shown at the bottom.

Generally, in a cloud system, events according to open API may occur. In the case of application services (e.g., SaaS services) provided by a cloud system, standardized interface events can be generated on the cloud system.

Meanwhile, when a cloud system provides a SaaS service, etc., a third party using the cloud system can install, change, and run the application ( ^3rd party app), and interface-related data may be generated accordingly.

In order to collect or deliver these standardized interface events, an integrated solution related to the interface may be installed in the cloud system, and a separate distributed agent adapter 10 may also be installed.

Examples of SaaS-type integrated solutions of cloud systems include SAP's SuccessFactors, Concur, and Ariba, and integrated solutions provided by cloud systems include SAP's Integration Suite.

Meanwhile, in an on-premise system, an integrated solution can be installed to manage applications installed on each resource. SAP's Process Orchestration and MS's Biztalk are examples that are installed in on-premise systems and provide integrated solutions.

When the distributed agent adapter 10 according to an embodiment is installed in an on-premises system (marked by A in this figure), it can provide hub technology that can link and integrate various computing systems.

Additionally, the distributed agent adapter 10 may receive various messages related to the interface of another computing system, or conversely, may transmit various messages related to the interface of the other computing system.

The distributed agent adapter 10 has a queue function for messages transmitted between systems, ensuring the safety of transmission and reception when transmitting (represented by B in this figure) or receiving (represented by C in this figure) messages between systems. and can efficiently process large amounts of data.

In addition, the distributed agent adapter 10 may provide the function of an adapter application that complements the technical limitations of the integrated solution of the cloud system or on-premise system (indicated by D in the drawing). Here, it is shown that the distributed agent adapter 10 installed in a cloud system can function as an adapter application, but it can function similarly even if the distributed agent adapter 10 is installed in an on-premises system.

As an example, the distributed agent adapter 10 can be distributed and installed in each system, thereby reducing the load in processing events or log data generated in various interfaces and having the effect of distributing actual resources.

The interface governance platform 10000 can manage the status of the installed distributed agent adapter 10 and can also register the distributed agent adapter 10 in the cloud or on-premises system. You can register and manage distributed agent adapters installed in the cloud or on-premise system.

In addition, when a problem occurs in the managed system or risk management is required, when an emergency response is required due to a system problem, or during system improvement or regular inspection, the computing system can be managed in an integrated and efficient manner without additional input of human resources. .

Hereinafter, specific embodiments of the interface governance platform 10000 and the functional modules included in the platform 10000 that can manage homogeneous or heterogeneous computing systems in an integrated and efficient manner will be disclosed.

FIG. 5 is a diagram illustrating an example of managing interface-related data transmitted from a computing system based on an interface governance platform according to an embodiment.

The interface governance platform 10000 may receive interface-related data or requests from application solutions 26, 27, 28, and 29 installed on various computing systems.

Application solutions 26, 27, 28, and 29 may be integrated solutions installed in a cloud or on-premises system, a log processor installed therein or separately, or a distributed agent adapter, as illustrated. Here, for convenience, they are indicated as application solutions (26, 27, 28, 29).

The interface governance platform 10000 can be linked with application solutions 26, 27, 28, and 29. The interface governance platform 10000 can also link and receive interface standard information held by the client's computing system. For example, the interconnection information received by the interface governance platform (10000) is the system management information of the computing system held by the client's computing system, the personnel information of executives and employees for user authentication, or the construction of an interface with the computing system. It may include necessary payment system information, etc.

The interface governance platform 10000 may include an interface standardization module 1000 and an interface monitoring module 2000.

A client using application solution 1 (26) to application solution n (27) may request the interface governance platform (10000) to develop or create interfaces (I/F) related to various application solutions.

The control system 100 may include at least one server 110 and a storage device 120 such as a storage or database that stores various data including interface data.

The control system 100 may control the interface standardization module 1000 of the interface governance platform 10000. The interface standardization module 1000 approves requests for development or creation of an interface (I/F) transmitted to the interface governance platform 10000 by reviewing standard information or clients.

Under the control of the control system 100, the interface standardization module 1000 can manage and generate standard information about the interface of the computing system.

As an example, a client may develop application solution 1 and request development, modification, or creation of associated interfaces as needed.

The interface standardization module 1000 can receive the development, change, or creation of such an interface, approve or reject it, or manage the interface.

As another example, when the developer of the client's application solution n requests development of a new interface, the operator of the application solution n may approve or reject the application solution n based on the interface standardization module 1000.

In this way, not only the administrator of the control system, but also the administrator of other computing systems accesses the interface governance platform (10000) and approves the creation, change, management, or disposal of interfaces based on the interface standardization module (10000). Interface management can be performed.

Meanwhile, the interface monitoring module 2000 of the interface governance platform 10000 may collect interface data generated by application solutions A 28 to solution Z 29 of the computing system or log data related thereto.

For example, application solution A 28 to solution Z 29 may include an EAI solution for each computing system, or may be a distributed agent adapter that generates its own log data when performing distributed data processing.

The interface monitoring module 2000 can receive and monitor interface data or log data transmitted by various solutions in the system, such as the EAI solution.

Therefore, if a problem such as a failure occurs in the developed and registered interface, or if a problem is predicted based on real-time status, it is possible to respond preemptively.

In the following embodiments, specific examples of applying for and managing the development of an interface, monitoring it, and taking action against failures, as well as user interfaces provided by the interface governance platform 10000, are also illustrated in detail.

FIG. 6 is a diagram illustrating an example of a method for managing the interface of a computing system according to an embodiment.

Register interface-related information related to the application solution of the computing system in the interface governance platform (S110).

The computing system includes at least one on-premise system or at least one cloud system. The application solution may include an integrated solution related to the interface of the computing system.

Interface information on the development, creation, and approval of interfaces of various application solutions can be registered in the interface governance platform.

Data related to the interface is received from the computing system through the interface governance platform (S120).

Standardized data related to the interface can be received from integrated solutions of the computing system. Standardized data related to the interface refers to interface data that follows the prescribed format and content of data transmitted and received by the integrated solution.

Meanwhile, log data related to the interface can be received from the integrated solution, a log processor installed in the integrated solution, or a log processor installed separately. In the case of data that cannot be provided by the integrated solution itself, log data related to the interface can be received from a log processor installed within the integrated solution or installed separately from the integrated solution. Alternatively, information stored in storage in the computing system may be received from a log processor.

If a separate distributed agent adapter is installed in the computing system, the distributed agent adapter performs distributed processing of data, such as data collection, conversion, and processing, separately from the data processing of the computing system. The distributed agent adapter can generate its own log data according to the above distributed processing. The interface governance platform can receive log data directly from the distributed agent adapter or log data sent by the distributed agent adapter to the integrated solution through the integrated solution.

Meanwhile, it can also receive data about various computing systems needed for interface management.

Based on the registered interface-related information, data related to the received interface is monitored or the computing system is managed (S130).

Interfaces registered with the interface governance platform can be monitored based on data related to the received interface.

Data related to the interface may be received from the integrated solution of each computing system, a log processor or distributed agent adapter installed within the integrated solution or separately installed.

If there is an abnormality in the monitoring results of data related to the interface through the interface governance platform, the administrator can take action and manage the computing system or application solution.

Therefore, the design, construction, management, operation, and maintenance of these interfaces can be performed easily and efficiently.

A detailed example of this will be disclosed below.

According to the disclosed embodiment, the interfaces of interconnected computing systems can be easily managed and the management results can be easily verified for accuracy.

According to the disclosed embodiment, failures between interconnected computing systems can be quickly identified and easily managed.

According to the disclosed embodiment, repeated failures between interconnected computing systems can be dealt with accurately and reliably.

According to the disclosed embodiment, interface design, construction, management, operation, and maintenance can be performed efficiently.

Interfaces between various systems can be built and operated within a company. At this time, interfaces within a company play an important role in smooth information exchange by connecting different systems and data. However, developing and operating interfaces between various systems can be accompanied by problems such as standardization issues, visibility issues, and development efficiency.

In order to solve this problem, the present invention seeks to provide a method of systematizing a standardization system for building a company's interface by registering standard information such as interface ID, naming rules, and linkage patterns. Through this, it is possible to visually manage the standard information required for interface construction during the development and operation stages and provide automated guides, thereby improving development productivity and quality, and providing convenience in terms of construction, maintenance, and monitoring.

Figure 7 is a diagram disclosing the interface governance platform of the present invention.

The interface governance platform 10000 may include an interface standardization module and an interface monitoring module.

The interface standardization module may include a reference information management module 1100 and a development automation module 1400, and the interface monitoring module may include a control module 2200. Here, the description will focus on the modules related to the present invention, but the above-described embodiments will be referred to for other components.

The standard information management module 1100 can register and manage standard information related to the interface required to build and manage the interface. In one embodiment, the standard information management module 1100 may collect standard information from a related system (eg, SAP PO, etc.). The standard information management module 1100 can automate interface development through the development automation module 1400 based on the collected standard information and monitor it through the control module 2200. A detailed description of the reference information management module 1100 will be provided later.

The development automation module 1400 can be used to build service automation based on the standardized information. Here, services that can be automated may include construction and development item creation services, test services, and previously developed service information standardization verification services. That is, the development automation module 1400 can automate various services based on the above-described standardized information.

In one embodiment, the interface governance platform allows interfaces to be built in a standardized manner even in the development stage based on registered standard information. In other words, the interface governance platform can manage various standard information necessary for building an interface as in the above-described embodiment, so if necessary, the interface can be built in a standardized manner even at the development stage.

In one embodiment, the interface governance platform may provide an interface application guide based on registered standard information. Likewise, the interface governance platform can provide users with guidance on the information needed to manage the interface. For example, an interface governance platform can provide users with guidance on the baseline information that must be registered for interface management. Guides provided by the interface governance platform may include how to create an interface list, progress management, and how to create an interface mapping specification. Additionally, the interface governance platform can provide the ability to upload or download the provided guides in Excel file format for each area. In addition, in the case of customer companies that do not have an internal system to manage the interface, the interface governance platform can of course directly manage the customer company's interface. Through this, the interface governance platform can intuitively and systematically manage input methods and service construction procedures through the provided guide.

The control module 2200 can provide the above-described standard information, etc. as information based on the task name of the interface and can be used as matching information. More specifically, the control module 2200 can provide matching information between the interface name used (understood) by the person in charge and the name of the interface object developed in the actual integrated solution system. The control module 2200 can provide interface history performed through the matching information. Here, the interface history may include monitoring log information. This will be described later.

The interface standardization system established in this way provides quick and easy access to the standard information required for interface construction at various stages such as development, operation, and maintenance, and allows developers to build interfaces in a unified manner. Additionally, by providing automated guidance, it can contribute to improving developers' development productivity and maintaining development quality. Additionally, establishing a standardized interface can provide convenience in terms of problem prevention and monitoring at the operation stage.

Therefore, the present invention can provide a technology that can manage interface construction and operation within a company in an efficient and standardized manner. Through this, it can contribute to improving the company's overall system development and operational efficiency and quality.

Figure 8 is a diagram disclosing the standard information management module of the present invention.

The standard information management module 1100 includes an interface standard information management unit 1101, an interface identification information generation unit 1102, a naming rule providing unit 1103, an integrated solution providing unit 1104, and a standardized linkage pattern providing unit 1105. It can be included. At this time, the units included in the standard information management module 1100 are divided to explain the functions performed by the standard information management module 1100 and are not limited to the names of the components.

The standard information management unit 1101 can register and manage standard information necessary for building and managing an interface. Here, the reference information may briefly include interface identification information, interface naming rules, linkage patterns, etc.

More specifically, the standard information managed by the standard information management unit 1101 may include target system information, interface information, and linked message structure. Here, the target system information may include management code information of the target system, target system name, target system type, IP information of the target system, linkage protocol information, connection information, and person in charge information.

The interface information may include a group name for each business standard and technical information (for example, it may include synchronous or asynchronous information, connection direction information, etc.). Additionally, the linked message structure may include a source message structure and a target message structure.

In one embodiment, the standard information management unit 1101 may collect standard information through API linkage with a system that manages interface component information. Here, the interface component corresponds to information that is subject to matching with reference information. Additionally, linked systems may include a system that manages the target system, a personnel information system, and an electronic approval system. In one embodiment, the standard information management unit 1101 may collect the management code, name, administrator, IP information, and system type of the target system from the system that manages the target system. In one embodiment, a target system existing within a customer company can directly synchronize information through linking with the interface governance platform of the present invention. The interface governance platform can maintain consistency of system identification among responsible personnel by utilizing the relevant reference information.

In addition, the standard information management unit 1101 can collect personnel information-related personnel information (user information, company ID, phone number, email information, etc.) by linking with the personnel information system. At this time, in order for the personnel information system to access the interface governance platform, SSO (Single Sign On authentication) may be required. Additionally, the standard information management unit 1101 may be linked to the electronic approval system. In other words, the interface governance platform is SAP Through linking with integrated solutions such as PO/IS, information on interface service components to be matched with standard information can be collected.

The interface identification information generator 1102 may generate interface identification information by reflecting the nature or technical nature of the work. In one embodiment, the interface identification information generator 1102 may generate an ID using the identification information of the interface. Through this, the interface ID can serve as target identification information for the interface for communication with the person in charge of the linked task.

The naming rule providing unit 1103 may provide naming rules for each component development item for interface construction. Here, the naming rule provided by the naming rule providing unit 1103 is to maintain consistency and prevent confusion, and commonly used naming rules can be applied.

In one embodiment, the naming rule provider 1103 may automatically provide naming rules for interface service component objects. Here, the interface service component object may correspond to the development component of the integrated solution. Accordingly, the naming rule provider 1103 provides naming rules for the components constituting the interface service: target system code, data type name, message type name, interface service name, and mapping object name that converts the message structure. You can. In addition, the naming rule provider 1103 provides linkage direction, synchronous/asynchronous processing method (for example, provides S as an abbreviation for synchronous processing method, and provides A as abbreviation for asynchronous processing method), linkage protocol. Additional information such as can be coded and added. Accordingly, readability in terms of monitoring and operation management can be improved. In other words, if you provide a naming rule according to the service component of the interface when registering an interface, there is an advantage that you can intuitively know the characteristics of the service component of the interface just from the code value during later development.

The integrated solution provider 1104 may provide an optimal EAI solution based on at least one of data size, transaction amount, and data nature. At this time, please refer to the above description for the explanation of the EAI solution. Additionally, the EAI solution provider 1104 may select at least one EAI solution from among the provided EAI solutions.

The standardized linkage pattern providing unit 1105 can provide linkage protocol information for each target system, conversion information, and a standardized linkage pattern according to the message transmission method. At this time, the standardized link pattern refers to a standardized form of data exchange between systems, and the main types of standardized link patterns are synchronous link, asynchronous link, and 1:1 (one-to-one) link. , 1:N (one-to-many) linkage, etc. Additionally, the standardized linkage pattern providing unit 1105 may select the most appropriate linkage pattern among the provided linkage patterns.

In one embodiment, the interface governance platform can be used in the development automation module 1400 and control module 2200, which describe the above-mentioned generated interface ID, provided interface naming rule, linkage pattern, and standard information, etc. At this time, the interface governance platform can manage the standardization information by registering it in a database.

Figure 9 is a diagram illustrating a user interface (UI) screen provided by the interface management method of the present invention.

As in the above-described embodiment, the interface governance platform can provide a user interface (UI) screen to build and operate interfaces between various systems.

In this figure, the user interface screen may include an interface application status 30, an interface application list 31, and an interface definition list 32.

In addition, the user interface screen is decorated with icons such as application modification, application closure, review completion, review rejection, operation transfer request, application, application rejection, developer acceptance, developer rejection, development/disposal completion, testing completion, and operation transfer completion. Sorting is possible. Through this, the life cycle of the interface can be managed, which will be described later.

More specifically, the method of managing the interfaces of computing systems of the interface governance platform (hereinafter referred to as the interface management method) can provide various search methods through the interface application status 30. In one embodiment, the interface application status 30 may include the application status of the interface in a search form based on at least one of search term, solution, application date, progress stage, progress status, application classification, and project name. Accordingly, the user can search the interface application status 32 based on at least one of the search formulas.

Additionally, the interface management method can manage the interface creation procedure through the interface application list 31. The interface application list 31 may include application order number, CSR number, application type, solution name, progress stage, progress status, project name, applicant name, application date and time, and reviewer name.

Additionally, the interface management method can manage the creation of an interface ID through the interface definition list 32. The interface definition list 32 may include an interface ID, interface name, source system ID, and target system ID. At this time, the interface definition list 32 corresponds to the actual interface list.

Thereafter, when one interface is selected, the interface management method may provide a detailed information screen for the selected interface. This will be described later.

Figure 10 is a diagram illustrating a user interface (UI) screen provided by the interface management method of the present invention.

The interface management method can provide a detailed information screen for the selected interface. Here, the interface detailed information screen may include interface application information 33, interface definition information 34, and interface history information 35.

In one embodiment, a user may input N (here, N is a natural number) pieces of interface definition information 34 into one interface application information 33. In other words, when applying for an interface, you can apply for N interfaces at once. That is, the interface management method can receive one interface application information 33 containing N pieces of definition information.

In one embodiment, the interface application information 33 may include basic application information of the company that applied for interface construction. For example, the interface application information 33 may include company name, application type, application number, CSR number, reviewer name, emergency status, solution name, completion request date, application title, project name, application details, etc. .

In one embodiment, the user can select definition information to be checked from the application details of the interface through the detailed information screen of the interface. Here, users can respond to administrators on the interface governance platform. Accordingly, the interface management method can provide definition information 34 of the selected interface. Here, the interface definition information 34 may include design definition details of the interface. For example, the interface definition information 34 may include source system information, definition information, and target system information. At this time, the interface definition information 34 may include a linkage target system, linkage protocol method, processing method, transmission mode, transmission cycle, transmission size, and mapping specifications. In this way, the interface management method of the present invention manages the classification, system ID, system name, linkage method, and definition information of the source system and target system of the interface, enabling efficient construction of interfaces within a company. In addition, the interface management method can manage the interface construction procedure and life cycle by managing the interface application information (33) and definition information (34), and improves interface design standardization and history management, interface construction standardization, and productivity. You can do it.

In one embodiment, the interface history information 35 may include history information of the selected interface. For example, the interface history information 35 may include number, progress stage, progress status, processor ID, processor name, processing details, and processing date and time.

Figure 11 is a diagram showing a user interface (UI) screen for applying for an interface provided by the interface management method of the present invention.

In one embodiment, a user can apply for a new interface through the interface governance platform. To this end, users can create definitions through the user interface provided by the interface governance platform.

The user interface for creating a definition is interface definition name, definition ID, management ID, solution type, internal and external linkage information, module name, source system information, target system information, processing method, transmission mode, transmission cycle, number of occurrences, data size, It can include DB connection processing conditions, Web Service URL, source FTP Directory, target FTP directory, and attachment file input window.

At this time, the user can select internal or external from the internal and external linkage information (36) and then select the source system and target system. Afterwards, the user can select the target system of the source system (37) and the target system of the target system (38). To this end, the user can select the search button (37, 38) to display the target system search pop-up window (39). When the user interface receives an input signal for selecting the search button from the user, it outputs a target system search pop-up window 39 and allows the target system to be searched through major classification, medium classification, and search term settings. Afterwards, the target system can be applied to the source system or target system through data search and application.

When the definition written in this way is submitted to the interface governance platform, the interface governance platform can build an interface based on the submitted definition format.

Figure 12 is a diagram disclosing an interface definition template related to the present invention.

As in the above-described embodiment, the interface management method can manage the creation of an interface ID through an interface definition list so that an interface between systems of the present invention can be built and operated.

For this purpose, this drawing explains an example of a definition template.

In one embodiment, the definition template may be an Interface Mapping Specification. The interface mapping specification may include the interface name, interface overview, mapping specification author, mapping specification creation date, interface ID, interface group ID, interface type, number of transmissions, host module, transmission type, interface mode, record unit size, and standard type. You can. Additionally, it may include information on the source system and target system. Information on the source system and target system may include information on system ID, system name, system person in charge name and contact information, and system linkage pattern. Additionally, it may include mapping information of a request message (Request Message) and a response message (Response Message or Async Callback Message) of the source system and the target system, respectively.

Additionally, the information included in the definition template of this drawing is only an example and is not limited thereto. In particular, of course, in order to implement the operation of the corresponding interface, necessary information such as which request is connected to which response, the format and structure of each message, and the protocol used can of course be included.

Accordingly, by using a definition template like the one shown in this diagram, the interface governance platform can ensure consistent interaction between different systems.

Figure 13 is a flow chart disclosing the interface management method of the present invention.

In one embodiment, the interface management method may register reference information of an interface related to an application solution of a computing system (S210).

Here, the computing system may include at least one on-premise system or at least one cloud system, and the application solution may include an integrated solution related to an interface of the computing system. Additionally, the reference information of the interface may include target system information, interface information, and linked message structure information. At this time, the interface management method may be linked with a computing system to register reference information. For this, please refer to the contents described above in FIGS. 6 and 8.

In one embodiment, the interface management method may generate interface identification information based on interface reference information (S220).

In one embodiment, the interface management method may generate an ID of the interface using identification information based on standard information of the interface. Here, the interface ID can serve as object identification information for the interface for communication with the person in charge of the linked task. At this time, the ID of the interface can be automatically generated as an ID that can indicate characteristic information of the interface. For this, please refer to the content described above in FIG. 8.

In one embodiment, the interface management method may provide a definition for constructing an interface (S230).

In one embodiment, an interface management method may provide a definition for building an interface. Here, the interface definition information may include design definition details of the interface. For example, interface definition information may include source system information, definition information, and target system information. At this time, the interface definition information may include the linkage target system, linkage protocol method, processing method, transmission mode, transmission cycle, transmission size, and mapping specifications. For this, please refer to the contents described above in FIGS. 9 to 12.

In this way, when a standardization system for interface construction is systemized based on interface identification information and definitions, such as the interface management method of the present invention, convenience can be provided to users in terms of interface construction, maintenance, and monitoring.

The interface governance platform manages the interfaces used for integration and connection between various IT systems and processes of a company or organization, and can effectively manage the entire cycle of connection and integration between interfaces. Below, it will be explained in detail.

Figure 14 is a diagram disclosing the interface governance platform of the present invention.

The interface governance platform 10000 may include an interface standardization module and an interface monitoring module 2000. The interface standardization module may include a life cycle management module 1300 and a development automation module 1400. Here, the description will focus on the modules related to the present invention, but the above-described embodiments will be referred to for other components.

The life cycle management module 1300 can overall manage the life cycle procedures of application, reception, review, construction, testing, operation, and disposal of the interface. To this end, the life cycle management module 1300 may provide a user interface (UI) screen that can be accessed by applicants, recipients/reviewers, EAI operators, and EAI developers. Additionally, the life cycle management module 1300 may provide a user interface (UI) screen that can manage roles and permissions according to procedures for each person in charge. A detailed description of the life cycle management module 1300 will be provided later.

The life cycle management module 1300 may provide the development automation module 1400 with information for automating service construction. In other words, the life cycle management module 1300 supports integration with continuous integration (CI) and continuous deployment (CD) tools and provides information that allows changes to the interface to be automatically tested and deployed. It can be provided to the development automation module 1400. In one embodiment, the life cycle management module 1300 may transmit linkage information with the EAI solution to the development automation module 1400 for interface automation development. An embodiment in which the development automation module 1400 automates service construction based on information provided will be described later.

The interface monitoring module 2000 can collect information about application, reception, review, construction, testing, operation, and disposal of the interface from the life cycle management module 1300. At this time, the interface monitoring module 2000 may utilize the standard information collected through the life cycle management module 1300 to provide monitoring information that can be used from the perspective of the person in charge. Likewise, the interface monitoring module 2000 may provide the collected monitoring information to the life cycle management module 1300 to determine that interfaces that are no longer in use are subject to disposal.

The interface monitoring module 2000 can convert the collected information and perform statistical processing. In particular, the interface monitoring module 2000 may be linked with the life cycle management module 1300 to provide information on interfaces to be discarded. The interface monitoring module 2000 may detect unused interfaces based on monitored data and provide discard candidate information to the life cycle management module 1300. In one embodiment, the interface monitoring module 2000 may request the life cycle management module 1300 to discard the interface when the life cycle of the interface ends or is no longer needed.

Additionally, the interface monitoring module 2000 may detect that there is no log record or data in which the interface has been used for more than a preset time and provide the information to the life cycle management module 1300 as a candidate group for disposal. Additionally, the person in charge may request the life cycle management module 1300 to discard the interface if necessary. Accordingly, the user of the life cycle management module 1300 can perform the interface disposal procedure after approval. At this time, the life cycle management module 1300 can safely remove data and resources related to the discarded interface and, if necessary, keep records related to the discard. In other words, the function of directly deactivating or deleting the interface subject to disposal can be performed directly through the integrated solution, and the interface governance platform can manage the procedures and keep the history related to the disposal of the interface.

Through this, the interface governance platform can effectively support the organization's IT connection and increase the efficiency and stability of related work.

Figure 15 is a diagram disclosing the life cycle management module of the present invention.

The life cycle management module 1300 can manage the life cycle procedures of application, reception, review, construction, testing, operation, and disposal of the interface. In one embodiment, the life cycle management module 1300 includes a user interface provision unit 1301, an authority confirmation unit 1302, an interface application management unit 1303, an interface development unit 1304, an interface test unit 1305, and an interface management unit. It may include (1306). Here, it is natural that the units included in the life cycle management module 1300 are intended to distinguish functions performed by the life cycle management module 1300 and are not physical components.

The user interface provider 1301 may provide a user interface screen for interface management to interface-related tasks. Here, interface-related work personnel may include interface applicants, recipients/reviewers, and EAI developers. However, interface-related work personnel are arbitrarily divided by job role, and it goes without saying that different work personnel may perform the role depending on the customer company that actually operates the interface. For example, in a small company, one person in charge may perform multiple roles. In other words, in the case of a large company, the receiver, reviewer, EAI operator, and EAI developer are equipped with separate personnel, and the EAI operator can assign the construction of the interface to the EAI developer. On the other hand, in smaller companies, the receiver, reviewer, EAI operator, and EAI developer may all be the same person. However, in this specification, the people in charge will be classified and explained based on their roles.

At this time, the interface applicant represents the field or business person in charge of applying for interface construction, and the receptionist/reviewer represents the EAI development reviewer. EAI developers represent the people in charge of actually operating and developing EAI. Therefore, after the EAI development reviewer approves the applied interface, the interface to be built can be assigned to the EAI operation developer.

The user interface screen provided by the user interface provider 1301 of the life cycle management module 1300 will be described later.

The authority confirmation unit 1302 can check the authority of the person in charge of accessing the work through the above-described user interface. More specifically, the user interface provided by the life cycle management module 1300 can be accessed by interface applicants, acceptors/reviewers, EAI operators, and EAI developers. At this time, the authority confirmation unit 1302 can determine whether the information accessed by each task manager on the user interface screen is appropriate. Thereafter, the authority confirmation unit 1302 can provide information to the task manager only when the authority for the information accessed by the task manager is approved.

In one embodiment, the life cycle management module 1300 can manage the interface construction process by linking the electronic payment system and CSR (Change Service Request). At this time, the authority confirmation unit 1302 is linked with the process payment module 1307 of the electronic payment system and can perform the payment approval process of the electronic payment system during the application and approval process of building and operating the interface.

The interface application management unit 1303 can process the reception and review of interfaces, starting with new applications for interfaces. More specifically, you can apply to build a new interface through the interface application management unit 1303. Additionally, in one embodiment, the interface application management unit 1303 may apply for association of a new interface through the applicant. At this time, the interface application management unit 1303 can primarily check whether the mapping definition is consistent when the applicant creates and saves the mapping definition through the applicant. At this time, for description of the mapping definition, refer to the above-described embodiment.

In addition, when a new interface application is applied, the interface application management unit 1303 can “receive” or “reject” the interface application through the acceptor for each integrated solution (e.g., EAI solution, ETL solution, etc.). . Afterwards, the interface application management unit 1303 may review the mapping definition for interface development through a reviewer and then proceed with “review” or “rejection.” In one embodiment, the interface application management unit 1303 may review the mapping definition for interface development through a reviewer and then approve the necessary submission requests. Additionally, the interface application management unit 1303 may assign an appropriate EAI developer after reviewing the mapping definition through a reviewer.

Additionally, the interface application management unit 1303 can proceed with the interface change procedure if changes occur while the interface is being operated in the actual operating environment. More specifically, the interface application management unit 1303 can apply for a change in the interface according to a change in the interface requirements, and change the interface through reception and review, similar to the above-described embodiment.

In one embodiment, when an interface is assigned through the interface application management unit 1303, the interface development unit 1304 may review and feed back the interface mapping definition and then proceed with interface development through the EAI developer. At this time, opinions and revised history of reviewing and feedback on the mapping definition may be recorded in the mapping definition.

The interface development unit 1304 can actually build the interface that has passed the review. The interface development unit 1304 may apply the level of automated construction of the interface based on the interface connection method and compliance with standardization. Here, the automation deployment level represents the scope of development elements. Depending on the degree of standardization of the interface, the scope of automation development elements may vary. For example, an interface service development component may include various objects that define data types, message types, mapping transformations between messages, service interfaces, and the relationships between them. At this time, the interface development unit 1304 may partially automatically generate and utilize at least one of the interface service development elements according to the degree of standardization.

At this time, the interface development unit 1304 may build the interface using an external development tool. Additionally, the interface development unit 1304 can automatically build an interface through the development automation module described above. Hereinafter, an embodiment of automatically building an interface will be described later.

The interface test unit 1305 can verify and modify the constructed interface through several test cases. At this time, the interface test unit 1305 can monitor the performance of the built interface, perform error logging and management, security audit, etc. Additionally, the interface test unit 1305 may request verification of the interface through the applicant of the target system. That is, the interface test unit 1305 can request verification from the applicant, and personnel on both sides of the linked target system can perform verification of the linked test system by sending and receiving data through the established interface.

If the interface passes the test, the interface transfer unit 1306 can transfer it to be used in an actual operating environment. At this time, the interface transfer unit 1306 may reflect the interface built in the operating system after confirmation of the interface applicant.

In this way, when the interface is managed through the life cycle management module 1300 of the interface governance platform, the connection between various services, applications, and systems can be easily created through the interface, and the management and maintenance of the interface can be systematically and systematized.

Figure 16 is a diagram explaining the life cycle management process of the interface of the present invention.

As described above, applicants, applicants/reviewers, EAI operators, and EAI developers can manage the life cycle of the interface through the user interface screen provided by the life cycle management module.

The applicant represents the person in charge of the field or business who applies to build an interface, the receptionist/reviewer represents the EAI development reviewer, and the EAI developer represents the person in charge of actually operating the EAI and developing the interface for the target system. For this, please refer to the above explanation.

Looking at the process, the applicant can request the receptionist/reviewer to build a new interface.

The receptionist/reviewer can review the application based on the application information in the interface applied by the applicant. Specifically, the receptionist/reviewer can accept or reject the application based on the interface application information. At this time, the application can be reviewed by the person in charge of each integrated solution. When an interface application is received, the filer/reviewer can review the mapping definition for interface development and then assign interface development to an EAI developer. At this time, the receptionist/reviewer can review the mapping definition against the linked standard criteria.

However, after an interface development request is assigned to an EAI developer, the EAI developer can review the mapping definition and provide feedback. At this time, EAI developers can review the mapping definition and provide feedback for the development of a practical interface. For example, EAI developers can review SQL errors, missing file storage location information, etc. At this time, the EAI developer can deliver review feedback on the mapping definition to the applicant, and the applicant can modify the mapping definition based on the EAI developer's feedback.

EAI developers can build interfaces according to their requirements. EAI developers can determine the level of automation deployment (scope of development elements) based on connection method and compliance with standardization. Additionally, EAI developers can request verification (testing) of the constructed interface from the applicant.

Applicants can check the interface. Applicants can check the interface and request that the interface operation be transferred to the EAI developer. Accordingly, EAI developers can reflect (transfer) the approved interface to the operating system.

If changes occur while using the transferred interface, the applicant can apply to change the interface again. Likewise, applicants may submit interface change requests to the receiver/reviewer. The receptionist/reviewer can review the interface change application and request the EAI developer to change the interface (process of assigning a developer), and the EAI developer can reflect the changes in the interface.

Figure 17 is a diagram illustrating a user interface (UI) screen provided by the interface management method of the present invention.

In one embodiment, the interface governance platform may provide a user interface (UI) screen that manages the interface.

This drawing explains the user interface screen provided by the life cycle management module. The user interface screen includes interface summary (40), interface status (41), integrated solution graph (42), interface application status (number of interfaces, 43), shortcut icon (44), interface application list (45), and announcements ( 46) may be included.

The interface summary 40 may indicate the number of internal interfaces, external interfaces, internal systems, and external systems, and the number of interfaces currently in application.

Interface status 41 is a graph showing the number of interfaces of each target system.

The integrated solution graph (42) is a graph showing the number of new cases for each integrated solution. Here, the number of new cases by integrated solution represents the number of new interfaces by integrated solution and by month.

The interface application status 43 may indicate the number of interfaces for the interface application status. For example, it can indicate how many interfaces are waiting for review/reception, how many interfaces are under development/testing, and how many interfaces have been transferred to operation.

The shortcut icon 44 may include an interface new application icon, an interface change application icon, a system inquiry icon, and a system registration request icon. Users can go directly to the corresponding function by selecting the corresponding icon.

The interface application list 45 may indicate a list of the current interface application status. The interface application list can indicate the interface application category (new or changed), solution type, project name, applicant name, progress stage, and progress status.

Notice 46 may represent a notice that the interface governance platform wishes to deliver to users.

Through this, users of the interface governance platform can manage the life cycle of the interface from one screen.

Figure 18 is a diagram illustrating a user interface (UI) screen provided by the interface management method of the present invention.

This drawing explains the user interface screen provided by the life cycle management module.

The user interface screen may include the interface operation status 47 and the interface list 48.

Here, the interface operation status 47 may support a search function through various filters.

The interface list 48 represents a list of interfaces currently being managed. The interface list (48) contains the operation record for each interface, interface status, solution name, internal and external classification, module, group name, interface ID, interface management ID, interface name, source system ID and source system name, and target system. It can indicate the ID and name of the target system.

At this time, the user can easily apply for change or disposal of the interface through the user interface screen. Additionally, the user can set and release groups for each interface through the user interface screen. Additionally, the interface governance platform can provide a list of interfaces included in the user interface screen as an Excel file.

The user interface screen provided by the life cycle management module can support effective management of the interface. As a result, users can easily access interface information through the screen and quickly perform necessary management tasks.

Figure 19 is a flow chart disclosing the interface management method of the present invention.

The interface management method of the present invention can provide a user interface (UI) that manages an interface related to an application solution of a computing system (S310).

The user interface provided here corresponds to a screen that can overall manage the life cycle procedures of application, reception, review, construction, testing, operation, and disposal of the interface. Regarding this, please refer to the details described above in FIG. 14.

The interface management method of the present invention can check the authority of a user accessing the user interface (S320).

The user interface provided by the interface management method can provide various functions for managing the interface. At this time, the interface management method may grant different permissions depending on the user accessing the management screen. Regarding this, please refer to the details described above in FIG. 15.

The interface management method of the present invention can request the development of an interface according to the user's interface application request (S330).

At this time, the interface management method may receive interface application information from a user requesting development of the interface. The interface management method can approve or reject whether to proceed with development of the interface based on the application information of the interface.

In one embodiment, when development of an interface is requested, a mapping definition for development of the interface may be reviewed. For an explanation of the mapping definition, please refer to the above.

In one embodiment, when the development of an interface is completed, verification may be requested from each computing system related to the developed interface. Thereafter, the interface management method can transmit and receive data with computing systems.

Figure 20 is a diagram disclosing the interface governance platform of the present invention.

The interface governance platform 10000 may include a specification definition module 1200 to provide a mapping design for the interface that each computing system wishes to build. Additionally, the interface governance platform 10000 may include a development automation module 1400 so that the computing system automatically creates an interface and tests the created interface. Here, the description will focus on the modules related to the present invention, but the above-described embodiments will be referred to for other components.

The specification definition module 1200 may include a user interface providing unit 1201, a specification defining unit 1202, and a validity checking unit 1203 to manage an interface mapping definition.

The development automation module 1400 may include an interface creation unit and a test unit to automatically create an interface. The development automation module 1400 can automatically create objects for each component of the interface service corresponding to the designed mapping definition. At this time, the development automation module 1400 may automatically generate code and settings among the components of the interface according to the mapping definition. For example, the development automation module 1400 can generate automated code from mapping definitions. Additionally, the development automation module 1400 may support version management and synchronization of components.

Additionally, the development automation module 1400 can perform tests to verify the generated interface service and find errors or problems in the service in advance. For example, the development automation module 1400 can verify the service by simulating test scenarios and use cases for the designed interface.

Through this, the interface governance platform (10000) of the present invention enables efficient interface management through integration of development functions for interface design and construction and operation functions for interface verification and distribution.

Figure 21 is a diagram disclosing the specification definition module of the present invention.

The specification definition module 1200 may include a user interface providing unit 1201, a specification defining unit 1202, and a validity checking unit 1203 to manage an interface mapping definition. Here, it is natural that the units included in the specification definition module 1200 are intended to distinguish functions performed by the specification definition module and are not physical components.

The user interface provider 1201 may provide a user interface (UI) for a screen for creating a mapping definition for building an interface. At this time, the user interface providing unit 1201 may be the same as or different from the user interface of the other modules described above. That is, the configuration provided by the user interface provider 1201 may be a configuration implemented independently by the specification definition module 1200 or a configuration implemented jointly with other modules.

Here, the mapping definition corresponds to the design document for developers to develop the interface. At this time, the user interface provider 1201 may configure a mapping definition creation screen using standard information or meta information stored in the interface information storage. In one embodiment, a user can easily map data elements in the mapping definition using a drag and drop interface on the mapping definition creation screen provided by the user interface provider 1201.

In one embodiment, the user interface provider 1201 may provide a template for a predefined mapping definition to the user. In particular, the user interface provider may provide templates for major interface types. Through this, users can intuitively and easily create interface mapping definitions.

The specification definition unit 1202 can define a message structure, map input data, and define functions. For example, the specification definition unit 1202 can visualize the data structure of the message. Additionally, the specification definition unit 1202 can define connection and conversion rules between different data structures. Additionally, the specification definition unit 1202 can support users to directly define specific conversion logic or validation logic. Through this, users can easily define and manage complex message structures and conversion rules.

The validity check unit 1203 may check the validity of the input data and store the mapping definition. More specifically, the validity check unit 1203 can immediately check the validity in real time when the user inputs data or mapping rules and provide an error message. In one embodiment, the mapping definition whose validity has been verified through the validation unit 1203 may be stored in the interface information storage. At this time, the validity check unit 1203 can prevent data loss by automatically saving the user's work contents. Additionally, the validation unit 1203 may provide the user with an error report on problematic parts after validation. Through this, the accuracy and consistency of data can be guaranteed and errors or problems can be prevented in advance.

Through this, information about the interface and mapping rules can be managed and tracked comprehensively.

Figure 22 is a diagram disclosing the development automation module of the present invention.

The development automation module 1400 may include an interface creation unit 1401 and a test unit 1402 to automatically create an interface. As described above, it is natural that the units included in the development automation module 1400 are intended to distinguish functions performed by the development automation module and are not physical components.

The interface creation unit 1401 may generate an interface service component based on the standard information and meta information stored in the interface information repository and the interface mapping definition information created through the specification definition module. Additionally, the interface creation unit 1401 can manage version information of the interface.

In one embodiment, the interface creation unit 1401 may check whether an actual service exists before creating an interface service. To this end, the interface creation unit 1401 can verify the naming rule of the interface. At this time, the interface creation unit 1401 may provide a screen to check the name of the interface through the user interface provision unit.

Additionally, the interface creation unit 1401 can check whether the corresponding interface service is created and version information of the interface in conjunction with the application solution. At this time, the interface creation unit 1401 can utilize the API to check whether the corresponding application service has been created and the version information of the interface by linking with the application solution of another computing system. To this end, the interface creation unit 1401 can access the application solution settings repository.

That is, the development automation module 1400 can access a repository that manages version information such as source code, settings, and documents using application solution setting repository access technology. For example, the development automation module 1400 can manage read or write permissions for the settings repository for each user or group, and manage the API key or access token used to programmatically access the settings repository. there is.

In one embodiment, the interface creation unit 1401 may automatically create an object for each interface service component when the corresponding interface has not been created. In particular, the interface creation unit 1401 can automatically generate objects of interface service components in a related order according to the input signal of the user selecting a button through the user interface provision unit.

In one embodiment, objects for each interface service component include association relationship information and precedence relationship information. Accordingly, the interface generator 1401 may apply the automatic creation range of the object differently according to the degree of standardization for each storage type based on at least one of the object's association relationship information and precedence relationship information.

Thereafter, the interface creation unit 1401 may provide a screen confirming the interface creation information through the user interface unit.

The test unit 1402 may provide a test screen for verifying the generated interface service. At this time, the test unit 1402 may provide a test screen for verifying the interface service generated through the user interface provider. In one embodiment, the test unit 1402 may perform a test data generation function, a test data transmission function, a transmission result collection function, and a test result information provision function. More specifically, the test data creation function may provide a function for editing test data.

In one embodiment, the test data transmission function and the transmission result collection function may be linked with an application solution to transmit test data to the application and collect the results. More specifically, the test unit 1402 can compare and verify existing data and result data transmitted through a newly built interface. For example, the test unit 1402 stores existing data when a new integrated solution is introduced without changing the existing target system, when the existing integrated solution is converted to a new integrated solution, or when the integrated solution is upgraded. Data from the newly built interface can be verified.

The interface governance platform can implement and manage interconnection between application solutions and other systems or services using the above-described embodiments.

Figure 23 is a diagram showing an interface mapping definition of the present invention.

As described above, the interface governance platform can provide a mapping definition definition screen for interface creation.

Here, the mapping definition definition screen can provide definition ID, definition professional information, interface list, and mapping ss definition items.

The mapping definition professional information is about the mapping definition ID, whether the standard applies to the requested data, whether the standard applies to the provided data, mapping definition author name, mapping definition registration date, request layout person in charge, provided layout person in charge, layout description, and layout classification. May contain information. In particular, standard application of requested data and provided data can be determined by providing a service proxy based on the metadata of the relevant transmitted and received messages, thereby providing a standardized processing method to transmit and receive messages.

In addition, the interface list includes interface name, interface classification information, provided system ID, provided system name, provided module name, service status information, last start date, Tx type information, request system ID, request system name, and request. Can include the module name.

Mapping definition items may include transmission/reception classification code, layout type, field sequence number, level, Java package name, field name, field Korean name, occurrence count, data type, length, field description, etc. A user can save a mapping definition item by entering mapping definition information in the fields included in the mapping definition item.

Based on the information created in this way, an XML file can be automatically created and a VO (Value Object) can be automatically created. Here, automatically generating an XML file means that when the user inputs some parameters or settings, the corresponding XML structure is automatically created. Additionally, automatically creating a VO refers to the function of automatically creating a VO class based on the schema of a database table or information from other data sources.

Through the mapping definition, metadata of usable objects can be compared, and version management of object metadata is possible. Here, the object may represent each object created for each interface component described above. The present invention can use the metadata of these objects to compare each object or manage the version of the object metadata.

Figure 24 is a diagram showing reference information stored in the interface information storage of the present invention.

The interface governance platform can construct a mapping definition creation screen using standard information stored in the interface information repository to create an interface.

This drawing shows reference information stored in the interface information storage for this purpose.

For example, an interface governance platform may provide an interface information screen. The interface information screen may include an interface ID, basic information about the interface ID, information about the requesting system, and information about the providing system.

Basic information about the interface ID may include the service status of the interface, interface type information, host module information, Tx type information, definition ID, interface classification, sub module information, layout classification information, etc.

Requested system information and provided system information may include system name, system module information, system submodule information, system person in charge, transmission protocol information, program name, system-function name (operation), etc., respectively. Additionally, each may include the requester ID of the requesting system and the provider ID of the providing system.

The interface governance platform can automatically create objects of interface service components through interface standard information or meta information and mapping definitions.

At this time, information on objects for each interface service component can be stored and managed through ESR (Enterprise Service Repository) registration. The ESR information of the object will be described later.

Figure 25 is a diagram showing object information for each interface service component of the present invention.

This drawing is a drawing containing ESR/ID information of objects for each interface service component for interface automation creation.

For example, the interface object includes ESR information such as Layout Namespace information, Consumer Namespace information, Provider Namespace information, Consumer Request Data Type, and Provider Request. Data Type (Provider Request Data Type), Consumer Response Data Type, Provider Response Data Type, Consumer Request Message Type, Provider Request Message Type), Consumer Response Message Type, Provider Response Message Type, requester service interface name, provider service interface name, request message mapping information, response message mapping information, action mapping information, etc. It can be included.

Additionally, the interface object is ID information, including configuration scenario ID, configuration scenario description, integrated configuration description, provider component ID, provider interface name, provider interface namespace, sender component ID, sender interface name, and sender interface namespace. , may include the sender channel name.

As described above, when defining namespaces for ESR and ID, objects or services can be prevented from overlapping with each other and managed in an organized manner. ESR information and ID information as shown in this figure can help with interface automation by ensuring the uniqueness of objects in the namespace and providing an organized structure.

Figure 26 is a flow chart disclosing the interface management method of the present invention.

In one embodiment, the interface management method may provide a mapping definition creation screen for creating an interface based on the standard information of the stored interface (S410).

Here, the mapping definition corresponds to the design document for developers to develop the interface. At this time, the user interface provider may configure a mapping definition creation screen using standard information or meta information stored in the interface information storage. For this, please refer to the details described above in FIGS. 2 and 21.

In one embodiment, the interface management method may create an interface based on a mapping definition and reference information (S420).

More specifically, the interface management method can verify the naming convention of the service of the interface. Additionally, the interface management method can check version information of objects according to the service components of the interface. In one embodiment, the interface management method may automatically generate the object in an associated order based on an input signal. In one embodiment, the interface management method may provide a test screen to verify the created interface. For this, please refer to the contents described above in FIGS. 3, 5, and 22.

Figure 27 is a diagram illustrating an example in which the interface governance system collects log data according to an embodiment

In the example shown, the interface governance system 10000 may include an interface monitoring module. The interface monitoring module may include a log collection module 2100. Here, the description will focus on modules related to the present invention, but for other components, refer to the above-described embodiment of FIG. 2.

The interface governance platform 10000 can receive log data for at least one step included in the interface-related process 300 of the integrated solution 26 from the log generator 50 for the integrated solution 26. there is. In one embodiment, the integrated solution 26 is installed in a cloud system or an on-premises system and can collect log data related to the interface of various computing systems within the system. A detailed embodiment of this is described above in FIG. 3. Please refer to it. For example, according to the present invention, if integrated solution 26 includes an EAI solution of a computing system, interface governance system 10000 may extract monitoring log data with which the EAI solution interfaces. The integrated solution 26 can link multiple computing systems through an interface and store the performance history as log data. The interface governance system (10000) can extract the corresponding log data stored in the storage (70) of the integrated solution (26) through methods such as direct access, access through standard API, and access through the log collection agent (60). .

Additionally, the integrated solution 26 may store monitored log data in a repository 70 within the integrated solution 26. In this case, logging methods, logging ranges, and log formats can be implemented in various ways depending on the integrated solution 26, and log data provision methods and technologies can be implemented in various forms.

The log generator 50 may generate log data for at least one step included in the interface-related process 300 of the integrated solution 26. In one embodiment, the logging generator 50 may be configured to determine whether to generate log data for each step included in the process, the logging level, and the role to be performed for each step. Here, the logging level may indicate the degree, type, and detail of events in which log data is generated based on at least one of the type of process or business importance. Additionally, the role performed at each stage may include source information for each stage of the process in which log data was generated, such as location information for each stage of the process in which log data was generated, and the time at which log data was generated.

In one embodiment, the logging generator 50 may determine whether to apply the logging function to each step according to global rule and local rule conditions. Here, the global rule may include variables that affect the entire logging of the process, for example, variables for the basic logging policy. Additionally, local rules may include detailed variables when logging for each step. In one embodiment, based on the priorities of the global rule and the local rule, the local rule may be applied prior to the global rule.

In one embodiment, the log generator 50 may be applied within the interface-related process 300, and log data may be generated for each step included in the process 300. Detailed embodiments of this are described below.

In one embodiment, log generator 50 may generate log data that integration solution 26 cannot provide in a standard manner. That is, separately from the log data that the integrated solution 26 can provide, the log generator 50 can generate log data that the integrated solution 26 cannot provide. In this case, the log data may be stored in storage 70 within the integrated solution 26.

In one embodiment, application of the log generator 50 may be determined depending on the type of integrated solution 26. That is, the log generator 50 may not generate corresponding log data depending on the type of integrated solution 26. For example, if the type of integrated solution 26 is SAP PO and custom log data is not required, the log generator 50 may not be applied.

In one embodiment, the log collection agent 60 included in the integrated solution 26 accesses the storage 70 to extract and collect log data that the integrated solution 26 cannot provide in a standard manner. You can. That is, among all log data collected for at least one step included in the interface-related process 300, log data that the integrated solution 26 cannot provide in a standard manner is extracted and collected by the log collection agent 60. It can be.

Therefore, according to the present invention, information can be supplemented in addition to the monitoring log provided by the integrated solution 26.

In other words, according to the present invention, log data exists in the storage 70 within the integrated solution 26, but if the log data cannot be provided by the integrated solution 26 in a standard manner, separate log collection The agent 60 may access the storage 70 of the integrated solution 26 to extract and collect corresponding log data.

In one embodiment, if the log data can be provided by the integration solution 26 in a standard manner, without the log collection agent 60, by providing a universal, standard API 80 to access the repository 70. Corresponding log data can be extracted. Therefore, according to the present invention, it is possible to expand and support restrictions on the monitoring function provided by the integrated solution 26 through the log generator 50 and the log collection agent 60. Additionally, log data for at least one step included in the process 300, that is, specialized monitoring additional information, may be logged to provide information defined by the user.

In one embodiment, the log collection agent 60 may be installed in the integrated solution 26 in a deploy form, and in this case, the extracted log data may be provided to the log collection module 2100 in the form of a web service. there is.

The log collection module 2100 may include a collector generator 2101, a storage-linked collector 2102, an API-linked collector 2103, an agent-linked collector 2104, and a message queue 2105. At this time, the components included in the log collection module 2100 are divided to explain the functions performed by the log collection module 2100, and are not limited to the names of the components.

The collector generator 2101 acquires collector setting information set by user input, and creates at least one of a storage-linked collector 2102, an API-linked collector 2103, or an agent-linked collector 2104 based on the acquired collector setting information. can be created. In one embodiment, the collector setting information may include at least one of collector connection information for the integrated solution 26 or collector performance information for the log collector, which will be described in detail below.

In one embodiment, the collector creation unit 2101 may determine whether to create a collector depending on the type of integrated solution 26. Additionally, in one embodiment, the collector generator 2101 may create at least one collector based on collector setting information depending on the type of integrated solution 26.

The storage-linked collector 2102 may collect log data by accessing the storage 70 within the integrated solution 26. In one embodiment, when the collected log data is large in volume, the storage-linked collector 2102 may collect log data by directly accessing the storage 70. Through this, log collection efficiency can be achieved.

The API-linked collector 2103 can collect log data through linkage with the standard API 80 provided by the integrated solution 26. In this case, log data collected through the standard API 80 may include log data that the integrated solution 26 can provide. Here, the log data that the integrated solution 26 can provide may be referred to as log data standardized by the integrated solution 26 or a term with equivalent technical meaning.

The agent-linked collector 2104 can collect log data through linkage with the log collection agent 60. In this case, log data collected through the log collection agent 60 may include log data that the integrated solution 26 cannot provide. Here, log data that the integrated solution 26 cannot provide may be referred to as log data that has not been standardized by the integrated solution 26 or a term with an equivalent technical meaning.

The message queue 2105 may store collected log data. That is, according to the present invention, a large amount of log data can be stably secured through the message queue 2105.

In one embodiment, the interface monitoring module may perform computing system monitoring using log data. In one embodiment, the interface monitoring module may detect a computing system-related failure using log data and perform failover of the computing system. In one embodiment, the interface monitoring module may generate monitoring information related to the interface of the computing system using log data.

In this example, the interface governance platform 10000 may be connected to an external cloud system or an on-premises system through an API or the like. In one embodiment, the interface governance platform 10000 may be controlled and managed by the control system 100. The control system 100 may include a computer server 110 having at least one processor and a storage or database 120, and may use this to control and manage the interface governance platform 10000.

FIG. 28 is a diagram illustrating an example of generating log data for at least one step included in an interface-related process according to an embodiment

In one embodiment, interface-related process 300 may include various steps depending on integrated solution 26. In this figure, the case where the interface-related process 300 includes the first to sixth steps (41, 42, 43, 44, 45, and 46) is explained. Additionally, a log generator may be applied to at least one step of the interface-related process 300.

When an HTTPS request message is received from a sending node (sender), the first step 301 of generating an original message by defining variables corresponding to the HTTPS request message may be performed. In this case, the log generator 51 installed for the first step 301 may generate the original message corresponding to the first step 301 as log data.

Additionally, a second step 302 may be performed to determine whether an error exists in the original message. If there is no error in the original message, a third step 303 is performed to generate a mapping conversion message between the interface that each computing system of the transmitting node and the receiving node (receiver) wants to build, based on the original message. It can be. In this case, the log generator 52 installed for the third step 303 may generate a mapping conversion message corresponding to the third step 303 as log data.

Additionally, a fourth step 304 of generating a response original message based on the mapping conversion message may be performed. Here, the generated response original mesh can be transmitted to the receiving node. Additionally, the log generator 53 installed for the fourth step 304 may generate the original response message corresponding to the fourth step 304 as log data.

On the other hand, if an error exists in the original message, the fifth step 305 of correcting the error may be performed. In one embodiment, the sixth step 306 of adjusting the error may be performed according to the correction result for the error set through the user interface. In this case, the log generator 54 installed for the sixth step may generate an error message for the error corresponding to the sixth step 306 as log data.

In one embodiment, log data generated through a log generator for each step may be collected by the log collection agent 60.

29 is a diagram illustrating an example of a user interface (UI) for collector access information according to an embodiment

In one embodiment, the collector generator 2101 of the interface governance platform 10000 provides a user interface (UI) for setting the collector access information 61 of the log collector for the integrated solution 26 as in the above-described embodiment. can be provided. That is, the user can set connection properties for the integrated solution 26 through the user interface for the collector connection information 61.

The collector connection information 61 may include connection information about the integrated solution 26 of the log collector. In one embodiment, the collector connection information 61 may include a connection ID 62 and connection parameters 63 of the log collector to the integrated solution 26. The connection ID 62 may include the connection ID of the log collector used when the log collector calls the standard API 80 provided by the integrated solution 26.

The connection parameters 63 may include information indicating an access method to the integrated solution 26. For example, the connection parameters 62 may include passwd, user, client, lang, and sysnr. passwd may contain the user's password. For example, passwd can be set to 0128 by user input. user may contain the user name. For example, user can be set to ney by user input. client may contain the client number. For example, client can be set to 800 by user input. lang can contain system languages. For example, lang may be set to EN, which represents English, by user input. sysnr may contain a system number. For example, sysnr can be set to 00 by user input.

Additionally, the information included in the connection parameter 62 in this figure is only an example and is not limited thereto, and of course, various access method information may be included.

Accordingly, the interface governance platform 10000 can provide smooth access to the integrated solution 26 for each log collector using collector access information as shown in this figure.

30 is a diagram illustrating an example of a user interface (UI) for collector performance information according to an embodiment

In one embodiment, the collector generator 2101 of the interface governance platform 10000 provides a user interface (UI) for setting the collector performance information 71 of the log collector for the integrated solution 26 as in the above-described embodiment. can be provided. That is, the user can set the log data collection information of the log collector through the user interface for the collector performance information 71.

Collector performance information 71 may include information about which log data to collect and how to collect it, and information about the collection status. In one embodiment, the collector performance information 71 includes the collector type 72, connection ID 73, instance key 74, activation information 75, and task interval 76 of the log collector for the integrated solution 26. ), task information (81), task status (82), execution time (83), processing time (84), and performance result message (85).

Collector type 72 may indicate the type of log collector and the type of log data collected by the log collector. For example, collector type 72 may be set to AAE Msg Log Collector by user input.

The connection ID 73 may include the connection ID of the log collector to the integrated solution 26. For example, the connection ID 73 may be set to POS.WS by user input. That is, the type of each collector can be matched with the access ID of the log collector.

Instance key 74 may include an instance key for integrated solution 26. For example, the instance key 74 may be set to POS/AAEMLCS by user input.

Activation information 75 may include information on whether the corresponding log collector is activated. For example, the activation information 75 may be set to 'Yes' indicating that the corresponding log collector is activated by the user's input.

The task interval 76 may include the log collection performance interval of the corresponding log collector. For example, the task interval 76 may be set to 10 ms by user input.

The task information 81 may include information on whether the corresponding log collector performs log collection. For example, the task information 81 may indicate 'yes' indicating that the corresponding log collector is performing log collection.

The task status 82 may include information on whether log collection by the corresponding log collector was successful. For example, the task status 82 may indicate 'success', indicating that the log collector succeeded in collecting logs.

The execution time 83 may include the log collection time of the corresponding log collector. For example, execution time 83 may represent 2023/07/06 09:55:51, which is the time when the log collector collected logs.

Processing time 84 may include the time required to collect logs from the corresponding log collector. For example, processing time 84 may represent 16ms, which is the time the log collector takes to collect logs.

The performance result message 85 may include a performance result message depending on whether the log collection of the corresponding log collector is successful or not. For example, the performance result message 85 may indicate 'Success', which is an execution result message indicating that the log collector succeeded in collecting logs.

Additionally, the information included in the collector performance information 71 of this figure is only an example and is not limited thereto, and of course, various access method information may be included.

Accordingly, using the collector access information as shown in this figure, the interface governance platform (10000) can provide smooth log collection for the integrated solution (26) for each log collector.

31 is a flowchart illustrating an example of collecting log data by an interface management method according to an embodiment.

Collector setting information set by user input is acquired (S510). In one embodiment, the collector setting information may include at least one of collector connection information for the integrated solution or collector performance information for the log collector.

In one embodiment, log data may be generated by a log generator for at least one step included in an interface-related process of the integrated solution. For this, please refer to the contents described above in FIGS. 29 and 30.

Log data for at least one step included in the interface-related process of the integrated solution is received using the log collector selected based on the collector setting information (S520).

In one embodiment, if the size of log data collected by the log collector is greater than the threshold, log data can be collected by directly accessing a repository included in the integrated solution using the log collector.

In one embodiment, depending on the type of log collector selected based on collector setting information, standardized log data is collected through an API provided by the integrated solution or non-standardized log data is collected from a log collection agent included in the integrated solution. At least one of log data can be received. In one embodiment, received log data may be stored in a message queue. For this, please refer to the contents described above in FIGS. 27 and 28.

Computing system monitoring is performed using the collected log data (S530). In one embodiment, log data may be used to detect computing system-related failures and perform failover measures for the computing system. In one embodiment, log data may be used to generate monitoring information related to the interface of a computing system. For this, please refer to the contents described above in FIGS. 2 and 3.

Figure 32 is a diagram illustrating an example in which an interface governance system provides interface monitoring information according to an embodiment

In the illustrated example, the interface governance system 10000 may include an interface standardization module and an interface monitoring module. The interface monitoring module may include a log collection module 2100. Additionally, the interface standardization module may include a reference information management module 1100. Here, the description will focus on modules related to the present invention, but for other components, refer to the above-described embodiment of FIG. 2.

In one embodiment, the integrated solution may transfer data between a sending system and a receiving system, and log data may refer to records associated with such transfers. In one embodiment, the integrated solution may be installed in a cloud system or an on-premises system to provide log data related to the interface of multiple computing systems within the system, and the log collection module 2100 of the interface monitoring module may collect log data from the integrated solution. can receive. For detailed embodiments of this, please refer to the details described above in FIG. 3.

The log collection module 2100 may acquire log data about the interface of the computing system. In one embodiment, the log collection module 2100 may convert log data into a standardized, standardized format.

Additionally, the log collection module 2100 may generate work-related interface monitoring information from log data based on interface-related standard information pre-stored in the standard information management module 1100. In one embodiment, the log collection module 2100 may generate work-related interface monitoring information based on interface mapping information between interface-related standard information and development object information included in log data.

Additionally, the log collection module 2100 may provide work-related interface monitoring information through a user interface. In one embodiment, work-related interface monitoring information may include at least one of transaction information, interface statistics information, or error information.

In this example, the interface governance platform 10000 may be connected to an external cloud system or an on-premises system through an API or the like. In one embodiment, the interface governance platform 10000 may be controlled and managed by the control system 100. The control system 100 may include a computer server 110 having at least one processor and a storage or database 120, and may use this to control and manage the interface governance platform 10000.

Figure 33 is a diagram illustrating another example in which the interface governance system according to an embodiment provides interface monitoring information

The log collection module 2100 includes a message queue 2105, a standardization conversion unit 2106, a transaction information generation unit 2107, an interface statistical information generation unit 2108, an error information generation unit 2109, and an interface matching unit 2110. ) and a user interface processing unit 2111. The reference information management module 1100 may include an interface information storage 1110. At this time, the components included in the log collection module 2100 and the reference information management module 1100 are divided to explain the functions performed by the log collection module 2100 and the reference information management module 1100. It is not limited to the name.

The standardization conversion unit 2106 may convert the format of log data obtained from the message queue 2105 into a standardized format based on the interface standard information included in the interface information storage 1110. In one embodiment, the standardization conversion unit 2106 may convert various types of log data corresponding to different types of integrated solutions into unified information. In one embodiment, the standardization conversion unit 2106 can standardize log data into a certain format according to interface standard information such as message information of log data, start time and end time of log data delivery, and size of log data. .

The transaction information generator 2107 may generate transaction information about the interface from log data. In one embodiment, log data may include transaction information, system-related data, and performance-related data. For example, transaction information may include the number of transactions that occurred by time period and transaction processing results.

The interface statistical information generator 2108 may generate interface statistical information from log data. In one embodiment, interface statistical information may be generated separately by period, interface, work group, and resource.

The error information generator 2109 may generate error information about the interface from log data. In one embodiment, error information may include interface error information, system error information, error code, and error message included in log data. In one embodiment, the error information may include the results of indexing, classifying, or error pattern analysis on the above-described error-related log data. In one embodiment, error information may include the maximum number of transactions, minimum number of transactions, average processing time, transaction volume, transaction trend, and transaction size for transactions with abnormal patterns.

The interface matching unit 2110 can map log data and interface standard information. In one embodiment, the interface matching unit 2110 may map the interface standard information included in the interface information storage 1110 with the development object included in the log data corresponding to the interface standard information. According to the present invention, the user's information utilization can be improved by matching log data from a technical perspective and interface standard information from a business perspective. Detailed embodiments of this are described below.

The user interface processing unit 2111 may provide work-related interface monitoring information based on the mapping result according to the user's input through the user interface. According to the present invention, work-related monitoring information can be utilized for work through various analysis and statistical information based on log data. That is, according to the present invention, log data obtained from an integrated solution can be processed into interface monitor information, which is meaningful data. Detailed embodiments of this are described below.

34 is a diagram illustrating an example of a user interface (UI) for log data collected based on an integrated solution according to an embodiment.

In one embodiment, the integrated solution may provide a user interface (UI) for the message monitoring screen 86 based on log data. The message monitoring screen 86 may include a list of log data 87.

Log data (87) includes interface type (Interface), interface namespace (Interface Namespace), message processing status (status), start time (Start Time), end time (End Time), integration scenario (Integration Scenario), and transmission component. It may include a (Sender Component) and a receiving component (Receiver Component). In one embodiment, at least one of the information included in the log data 87 is an interface service component object name that can be used to make the log data more intuitively understandable through meaningful code standardization.

The interface type may indicate an interface related to the corresponding log data. In one embodiment, the type of interface may be named according to the nature of the interface. In one embodiment, the type of interface may be determined based on at least one of an interface ID, interface name, transmission system code, reception system code, processing method code, or message direction (e.g., inbound, outbound). You can. For example, the interface type can be expressed by coding as follows: '[I/FID]_[interface name][transmission system code][reception system code]_[processing method code][Outbound/Inbound direction]'.

The interface namespace serves as an identifier for the interface object and can be expressed in the form of a URL (Uniform Resource Locator). In one embodiment, the interface namespace may be determined based on at least one of a company domain name, business module name, or target system code for the corresponding interface. For example, the interface namespace can be expressed as 'http://[company domain name]/[business module name]/[target system code]' for the corresponding interface.

The message processing status may indicate the message transmission status of the interface. For example, the message processing status can be displayed as 'Delivered' when the interface receives the message from the sending system and finally delivers the message to the receiving system, which is the target system.

In one embodiment, notation information according to the message processing method and status may be displayed as follows.

“TO_BE_DELIVERED”: Processing status within the messaging system. In one embodiment, the messaging system may refer to a messaging queue within an integrated solution.

“DELIVERING”: A message is being delivered from the messaging system to the target system.

“DELIVERED”: The message has successfully reached the target system.

“HOLDING”: This is the message status when the preceding message cannot be delivered as a sequential processing message.

“NON_DELIVERED”: An attempt was made to process a normal message, but delivery of the message failed.

“FAILED”: Reprocessing was attempted the maximum number of times with the message processing policy, but ultimately could not be delivered.

“WAITING” The message was attempted to be sent more than once but failed, and is currently waiting for another attempt.

The start time is the time when the integrated solution starts performing the interface to transmit data. For example, the start time can be expressed as '2023.07.10 1:50:55.701 PM' when the integrated solution started performing the interface. The end time may indicate the end time of interface execution. For example, the end time can be expressed as '2023.07.10 1:55:56:279 PM', when the integrated solution finished performing the interface.

An integration scenario can represent a flow of messages in which applications interconnect and communicate to perform a specific process (e.g., a business process). In one embodiment, the integration scenario may be determined based on the transmitting component, receiving component, and interface type. A transmission component may represent a transmission system that generates an event to transmit data. A receiving component may represent a receiving system that receives data. And the combination of these determines the name of the integrated scenario.

In one embodiment, the log collection module 2100 of the interface governance platform 10000 may receive log data 87 from the integrated solution as in the above-described embodiment. In one embodiment, log data 87 received from the integrated solution may be stored in message queue 2105.

Additionally, the information included in the log data 87 in this figure is only an example and is not limited thereto, and of course, information on various log data may be included.

35 is a diagram illustrating an example of a user interface (UI) for interface mapping information according to an embodiment

In one embodiment, the user interface processing unit 2111 of the interface governance platform 10000 displays a user interface (UI) for the interface mapping pattern screen 90 for matching between interface reference information and log data as in the above-described embodiment. ) can be provided.

The interface mapping pattern screen 90 may include interface mapping information. In one embodiment, the interface mapping pattern screen 90 may include interface reference information 91, log data mapping pattern 92, and interface mapping result 93.

The interface standard information 91 may include interface information based on the business name of the interface. In one embodiment, the interface standard information 91 may include an interface ID, work-related interface content, and work group. In this case, the interface ID may include an identifier to identify the corresponding interface. For example, the interface ID can be expressed as 'FRP_PP0650'. Additionally, the work-related interface content may include interface content related to the corresponding work process. For example, work-related interface content can be expressed as ‘(SAP->SmartERP) BT request’. Additionally, the work group may include work groups related to work processes for the corresponding interface. For example, a business group can be represented as ‘Group Sales Management’.

In one embodiment, the interface standard information 91 may include some information that is representative of work-related information among all interface standard information. In this case, the partial information has a standard information key or equivalent technical meaning. It may be referred to by a term having.

In one embodiment, the interface reference information 91 may be searched according to the interface ID, interface content, and work group selected according to user input.

The log data mapping pattern 92 may include development object information included in log data. In one embodiment, the log data mapping pattern 92 may include a transmission namespace, a transmission interface, a transmission business system, a reception namespace, a reception interface, and a reception business system for log data. In one embodiment, development object information may be added to the log data mapping pattern 92 by user input.

The interface mapping result 93 may include a mapping result between the interface reference information 91 and the log data mapping pattern 92. In one embodiment, the interface mapping result 93 may match development object information included in log data with interface information based on the task name of the corresponding interface.

Additionally, the information included in the interface mapping pattern screen 90 of this figure is only an example and is not limited thereto, and of course, various access method information may be included.

36 is a diagram illustrating an example of a user interface (UI) for work-related interface monitoring information according to an embodiment

In one embodiment, the user interface processing unit 2111 of the interface governance platform 10000 displays a user interface (UI) for the interface status screen 94 for providing work-related interface monitoring information through a user interface as in the above-described embodiment. ) can be provided.

The interface status screen 94 may include work-related interface monitoring information. In one embodiment, work-related interface monitoring information may be generated based on interface mapping information. In one embodiment, the interface status screen 94 may include a search field 95, transaction processing status information 96, transaction volume information 97, and interface history information 98.

The search field 95 can perform a search according to execution time, task group, system, and interface ID selected according to user input. In one embodiment, the search field 95 may perform a search according to the message type, interface name, transmission system, reception system, and processing method of the log data selected according to the user input.

Transaction processing status information 96 can indicate the number of successful and failed transactions for each business group. For example, the transaction processing status information 96 may represent the number of successful transactions (5,264) and the number of failed transactions (994) in the form of a bar graph for the B2B business group.

Transaction volume information 97 may indicate transaction volume according to period for each business group. Here, the transaction volume may indicate the size of the interface message. For example, the transaction volume information 97 may represent the transaction volume for the one-year average and the transaction volume for the period average of the B2B business group in the form of a bar graph, respectively.

The interface history information 98 may include information such as interface ID, work-related interface name, work group, sending system, sending work system, receiving system, receiving work system, transaction processing status, average response time, and average volume. . In one embodiment, the interface history information 98 may be generated based on interface reference information. For example, the interface name, work group, sending system, sending work system, receiving system, and receiving work system included in the interface standard information may be added to the interface detail information 98.

In one embodiment, work-related interface monitoring information including the above-described error information may be added to the interface status screen 94 and provided to the user.

Therefore, according to the present invention, the user's information utilization can be improved by providing the user with work-related interface monitoring information generated by matching log data from a technical perspective and interface standard information from a business perspective. Additionally, the information included in the interface status screen 94 of this figure is only an example and is not limited thereto, and of course, various access method information may be included.

37 is a diagram illustrating another example of a user interface (UI) for work-related interface monitoring information according to an embodiment

In one embodiment, the user interface processing unit 2111 of the interface governance platform 10000 displays a user interface (user interface) for the real-time interface history screen 101 for providing work-related interface monitoring information through the user interface as in the above-described embodiment. UI) can be provided.

The real-time interface history screen 101 may include work-related interface monitoring information. In one embodiment, work-related interface monitoring information may include a search field 102, transaction occurrence trend information 103, interface history information 104, message information 105, and update field 106.

The search field 102 can perform a search according to execution time, task group, system, and interface ID selected according to user input. In one embodiment, the search field 102 may perform a search according to the message type, interface name, transmission system, reception system, and processing method of the log data selected according to the user input.

Transaction occurrence trend information 103 may include at least one of the number of transactions or transaction volume by time period for the day of the selected execution time. Here, transaction volume may indicate the size of interface messages for the day. Additionally, the number of transactions may include the number of transactions for the day and the number of transactions for the previous day. In one embodiment, the transaction occurrence trend information 103 may be displayed in the form of a bar graph or a line graph.

The interface history information 104 may include information such as interface ID, work-related interface name, work group, sending system, sending work system, receiving system, receiving work system, transaction processing status, average response time, and average volume. .

The message information 105 may include message information about the interface details selected in the interface details information 104. In one embodiment, the message information 105 includes interface ID, interface name, message status, business group, sending system, sending business system, consumer system ID (Con. Sys. ID), receiving system, and receiving task. Includes system, message type, processing method, error message, start time, end time, sending processing time, receiving processing time, processing time, provider execution time, response time, transaction volume, sending message ID, and receiving message ID. can do.

The update field 106 can update transaction occurrence trend information 103, interface history information 104, and message information 105 based on the search conditions of the search field 102. In one embodiment, the update field 106 may determine whether to update based on user input. In one embodiment, the update field 106 may be automatically updated at preset intervals (eg, 10 seconds).

Additionally, the information included in the real-time interface details screen 101 of this figure is only an example and is not limited thereto, and of course, various access method information may be included.

38 is a flowchart illustrating an example in which an interface management method according to an embodiment provides interface monitoring information.

Obtain log data about the interface of the computing system (S610). In one embodiment, log data may be received from an integrated solution. For this, please refer to the contents described above in FIGS. 32 to 34.

Based on pre-stored interface-related standard information, work-related interface monitoring information is generated from log data (S620). In one embodiment, the format of log data may be converted into a standardized format based on pre-stored interface-related standard information.

In one embodiment, at least one of transaction information, interface statistics information, or error information for an interface may be generated from log data. In one embodiment, work-related interface monitoring information may be generated from at least one of transaction information, interface statistical information, or error information about the interface, based on pre-stored interface-related standard information.

In one embodiment, work-related interface monitoring information corresponding to log data may be generated based on matching information between pre-stored interface-related reference information and log data. For this, please refer to the contents described above in FIGS. 35 and 36.

Work-related interface monitoring information is provided through the user interface (S630). In one embodiment, work-related interface monitoring information may include at least one of transaction processing status information, transaction volume information, or interface history information. For this, please refer to the content described above in FIG. 36.

Figure 39 is a diagram illustrating an example in which the interface governance system according to an embodiment provides monitoring and management setting information through a user interface (UI)

In the example shown, the interface governance system 10000 may include an interface monitoring module. The interface monitoring module may include a log collection module 2100 and a control module 2200. Here, the description will focus on modules related to the present invention, but for other components, refer to the above-described embodiment of FIG. 2.

The log collection module 2100 may acquire log data about the interface of the computing system. In one embodiment, the log data may include log data converted to a standardized format.

The control module 2200 may generate at least one of monitoring information or management setting information corresponding to the person in charge based on log data.

In one embodiment, the monitoring information may include at least one of interface monitoring information for an interface, system monitoring information for a computing system, or error monitoring information for at least one of the computing system or the interface. Detailed embodiments of this are described below. In one embodiment, the management setting information may include at least one of role authority, task authority, or management target corresponding to the person in charge of log data. Detailed embodiments of this are described below.

The control module 2200 may provide at least one of monitoring information or management setting information through a user interface. In one embodiment, at least one of monitoring information or management setting information may be provided according to at least one of the role authority or task authority of the person in charge.

Here, the role permission may indicate access permission to the user interface screen granted to the person in charge according to the user type.

For example, user types can be divided into administrator, developer, and general user. At this time, the administrator represents the person in charge of overall management and operation of the computing system and interface, assigning roles and authority to the person in charge, and managing various setting parameters. The developer represents the person in charge of monitoring the computing system and the entire interface. Generally, the EAI person in charge is given the role of developer and represents the person in charge of actually operating and developing EAI. In the case of general users, they have the right to access the interface or target system according to the job they are responsible for, or the interface at the work group level and the right to access the personalized dashboard. Therefore, business users and target system operators/developers, etc. may be subject to the general user role. The person in charge is arbitrarily classified by job role, and of course, other person in charge may perform the role depending on the size of the company, human resources status, customer company, etc.

For example, the control module 2200 may provide monitoring information and management setting information to the administrator according to the administrator's role authority. Additionally, the control module 2200 may provide monitoring information to the EAI representative according to the role authority of the EAI representative. Additionally, the control module 2200 may provide at least one monitoring object among the monitoring objects included in the monitoring information to the field manager and system manager according to the role authority of the field manager and system manager.

Additionally, the work authority may indicate the work authority for the computing system and interface granted to the person in charge according to the user's work. For example, the control module 2200 may provide monitoring information corresponding to the interface in charge and the system in charge according to the work authority of the field manager and system manager.

In this example, the interface governance platform 10000 may be connected to an external cloud system or an on-premises system through an API or the like. In one embodiment, the interface governance platform 10000 may be controlled and managed by the control system 100. The control system 100 may include a computer server 110 having at least one processor and a storage or database 120, and may use this to control and manage the interface governance platform 10000. For this, please refer to the contents described above in FIGS. 1 to 3.

40 is a diagram illustrating another example in which the interface governance system according to an embodiment provides monitoring and management setting information through a user interface (UI)

In one embodiment, the control module 2200 includes an interface aggregate information provider 2201, an interface statistics information provider 2202, an interface history information provider 2203, a system information provider 2204, and performance information. Providing unit 2205, transaction information providing unit 2206, error management information providing unit 2207, message queue information providing unit 2208, channel information providing unit 2209, setting management information providing unit 2210, authority It may include an information provision unit 2211 and a collector information provision unit 2212. Detailed embodiments of this are described below.

The interface aggregate information providing unit 2201 can provide the administrator with interface status and aggregate information centered on task grouping. For example, the interface aggregate information provider 2201 may provide message queues, number of occurrences, number of errors, and message backlog status.

The interface statistical information provider 2202 may provide interface statistical information in the form of personalized monitoring to the user. For example, the interface statistics information provider 2202 may provide statistics and status information based on the interface in charge of the user.

The interface history information provider 2203 can provide real-time interface history information about the interface. In one embodiment, the interface history information provider 2203 may provide real-time transaction history information for the interface. Regarding this, please refer to the above-mentioned contents.

The system information provider 2204 may provide resource monitoring information of the computing system. For example, the system information provider 2204 may include CPU information, memory information, and thread information of the corresponding computing system.

The performance information provider 2205 may provide performance monitoring information for the interface. In one embodiment, the performance information provider 2205 may provide interface processing performance information. In one embodiment, interface processing performance information may be used to select an optimization target for each interface.

The transaction information provider 2206 may provide transaction monitoring information. In one embodiment, the transaction information provider 2206 may provide various information including transaction occurrence trends for the interface.

The error management information providing unit 2207 may provide error information. In one embodiment, the error management information provider 2207 may provide an action management function for error messages for the interface. In one embodiment, error information may include error type, error history, and error processing details. Additionally, the error management information provider 2207 can provide a failure search function that can search failure history.

The message queue information provider 2208 can provide message queue state management information. In one embodiment, the message queue information provider 2208 may provide at least one of adapter backlog monitoring information or adapter queue monitoring information. In one embodiment, the message queue information provider 2208 may provide information about the message queue that stores log data collected from the integrated solution.

The channel information provider 2209 may provide channel status information. In one embodiment, the channel information provider 2209 may provide status information on channels connected to the target system.

The settings management information provider 2210 may provide dynamically applicable parameter setting information through the settings management screen. In one embodiment, the settings management information provider 2210 may provide setting management information for work groups, error codes, etc.

The authority information provider 2211 can provide setting information that grants authority and management targets to each person in charge. In one embodiment, the authority information provider 2211 may provide setting information about the work group, target system, and interface in charge of the corresponding work manager. In one embodiment, the rights information provider 2211 may provide setting information for notification message rules.

The collector information provider 2212 may provide collector connection information about the collector that collects log data. Regarding this, please refer to the above-mentioned contents.

At this time, the components included in the control module 2200 are divided to explain the functions performed by the control module 2200 and are not limited to the names of the components.

Therefore, according to the present invention, personalized information for each person in charge can be provided in the form of a monitoring dashboard. According to the present invention, it is possible to provide a user interface screen that is more convenient from the perspective of the person in charge than the technical and complex user interface (UI) provided by the integrated solution. Additionally, according to the present invention, analysis screen information including various monitoring information and management setting information generated using log data can be provided. In one embodiment, analysis screen information may be provided in various graph forms. In addition, according to the present invention, it is possible to provide convenience and speed to the person in charge by analyzing, recognizing, and detecting monitoring information.

41 is a diagram illustrating an example of a user interface (UI) for aggregate information according to an embodiment

In one embodiment, the control module 2200 of the interface governance platform 10000 may provide a user interface (UI) for the aggregate screen 200.

The tally screen 200 may include aggregate information about the administrator's system and interface. In one embodiment, the tally screen 200 may include system tally information 201, interface processing result information 202, and interface queue waiting information 203. In one embodiment, the tally screen 200 may be displayed when login is performed with administrator authority.

System aggregate information 201 may include legacy connections, threads, and queue information for the computing system. In one embodiment, system aggregate information 201 may include status information about GPU usage, memory occupancy, GC work rate, and EJB sessions. For example, legacy connections may include the number of normally connected legacy connections and the number of legacy connections in which an error occurred. For example, threads display the number of normal or load states based on processing time, etc., and message queues can display message queue status information related to the interface of major main systems such as ERP.

Interface processing result information 202 may indicate processing results for each interface group. For example, the interface processing result information 202 may indicate the number of successful processing, number of processing failures, and number of failed actions for the corresponding interface. Here, the number of failed actions may represent the number of times the person in charge of work has completed processing errors in the failed interface.

Interface queue waiting information 203 may indicate the number of queue waits for the interface. For example, the interface queuing information 203 may indicate the number of normal queuing states, the number of delayed states, and the number of backlog states of the corresponding interface. Here, the number of normal states of queue waiting may represent the number of cases in which the queue waiting time is less than the first threshold (eg, 100%) compared to the average over a certain period (eg, 7 days). The number of delay states may represent the number of cases in which the queue waiting time is greater than a first threshold and less than a second threshold (e.g., 200%) relative to the average over a certain period. The number of backlog states may indicate the number of cases in which the queue waiting time is greater than the second threshold compared to the average over a certain period.

Additionally, the information included in the tally screen 200 of this figure is only an example and is not limited thereto, and of course, various information may be included.

42 is a diagram illustrating an example of a user interface (UI) for interface status information according to an embodiment

In one embodiment, the control module 2200 of the interface governance platform 10000 may provide a user interface (UI) for the interface status screen 204.

The interface status screen 204 may include the user's interface status information. In one embodiment, the interface status screen 204 may include the user's responsible interface information 205 and error status information 206. In one embodiment, the interface status screen 204 may be displayed when login is performed with the authority of the person in charge. In one embodiment, interface status information can be searched based on the execution time selected by user input and the system in charge of the user.

The responsible interface information 205 may include a transmitting system, a receiving system, a server, interface processing results (eg, success, failure, progress), average response time, maximum response time, and average volume.

Error status information 206 may include error type, error code, processing status, error occurrence time, interface ID, interface name, work group, sending system, sending work system, receiving system, and receiving work system for the interface. .

Additionally, the information included in the interface status screen 204 of this figure is only an example and is not limited thereto, and of course, various information may be included.

43 is a diagram illustrating an example of a user interface (UI) for resource monitoring information according to an embodiment

In one embodiment, the control module 2200 of the interface governance platform 10000 may provide a user interface (UI) for the resource monitoring screen 207.

The resource monitoring screen 207 may include resource monitoring information for at least one of the corresponding computing system or interface. In one embodiment, the resource monitoring screen 207 includes memory utilization 208, CPU utilization 209, thread utilization 210, GC work ratio 211, EJB sessions 212, and database utilization 213. can do. In one embodiment, the resource monitoring information may indicate at least one of application thread pool utilization or system thread pool utilization. In one embodiment, resource monitoring information may be expressed in graph form.

Memory utilization 208 may indicate memory utilization. In one embodiment, memory usage 208 may indicate memory changes over a period of time (e.g., 30 minutes). CPU utilization 209 may indicate CPU utilization. In one embodiment, CPU utilization 209 may indicate CPU changes over a period of time. Thread utilization 210 may indicate thread utilization. In one embodiment, thread utilization 210 may indicate changes in threads over a period of time. The GC work rate 211 may indicate the GC work usage rate. EJB session 212 may indicate the number of EJB sessions. The database utilization rate 213 may indicate the utilization rate for at least one of a database or a disk.

Additionally, the information included in the resource monitoring screen 207 of this figure is only an example and is not limited thereto, and of course, various information may be included.

44 is a diagram illustrating an example of a user interface (UI) for performance monitoring information according to an embodiment

In one embodiment, the control module 2200 of the interface governance platform 10000 may provide a user interface (UI) for the performance monitoring screen 214.

The performance monitoring screen 214 may include performance monitoring information for at least one of the corresponding computing system or interface. In one embodiment, the performance monitoring screen 214 may include response time for each group 215, response time for each interface 216, and message information 217. In one embodiment, the performance monitoring screen 214 can be viewed based on execution time, task group, system, and interface ID selected by user input.

Response time by group 215 may represent the average response time for each work group.

The response time per interface 216 may represent the average response time for each interface and interface ID. In one embodiment, the response time for each interface 216 may represent the average response time for a certain period (eg, search period, previous month).

Message information 217 may include message information about interface details. In one embodiment, the message information 217 includes interface ID, interface name, message status, task group, sending system, sending business system, consumer system ID (Con. Sys. ID), receiving system, and receiving task. System, message type, processing method, error message, start time, end time, transmission processing time, reception processing time, processing time, provider execution time (P. execution time), response time, transaction volume, transmission message ID and a received message ID.

Here, the consumer system ID may indicate the actual consumer system ID of the message in the case of a common interface with multiple consumers on one interface. Transmission processing time may represent the time from the time it enters the integrated solution system from the consumer system until it leaves the provider system. In case of a synchronous interface, the reception processing time can represent the time from the time it enters the integrated solution system from the provider system until it leaves the consumer system. Processing time may represent the sum of transmission processing time and reception processing time. Provider execution time may indicate the time taken to process a message in the provider system in the case of a synchronous interface. Response time may represent the sum of processing time and supplier execution time.

Additionally, the information included in the performance monitoring screen 215 of this figure is only an example and is not limited thereto, and of course, various information may be included.

45 is a diagram illustrating an example of a user interface (UI) for transaction monitoring information according to an embodiment

In one embodiment, the control module 2200 of the interface governance platform 10000 may provide a user interface (UI) for the transaction monitoring screen 218.

The transaction monitoring screen 218 may include transaction information for at least one of the corresponding computing system or interface. In one embodiment, the transaction monitoring screen 218 may include monitoring summary information 219, transaction volume 220, number of failed transactions 221, and message information 222.

Monitoring summary information 219 may represent transaction summary information. In one embodiment, the monitoring summary information 219 may include the total number of transactions, the number of successful transactions, the number of failed transactions, the number of ongoing transactions, the failure occurrence rate, and the total transaction volume.

Transaction volume 220 may represent transaction volume according to period for each business group. Here, the transaction volume may indicate the size of the interface message. In one embodiment, transaction volume 220 may represent the sum of interface message sizes.

The number of failed transactions 221 may represent the number of failed transactions according to the period for each business group. In one embodiment, the number of failed transactions 221 may represent the total number of failed transactions among interface messages.

Message information 222 includes interface ID, interface name, message status, business group, sending system, sending business system, consumer system ID (Con. Sys. ID), receiving system, receiving business system, message type, processing method, and error. It can include message, start time, end time, sending processing time, receiving processing time, processing time, provider execution time (P. execution time), response time, transaction volume, sending message ID, and receiving message ID. Regarding this, please refer to the above-mentioned contents.

Additionally, the information included in the transaction monitoring screen 218 of this figure is only an example and is not limited thereto, and of course, various information may be included.

46 is a diagram illustrating an example of a user interface (UI) for detailed message information according to an embodiment

In one embodiment, the control module 2200 of the interface governance platform 10000 may provide a user interface (UI) for the message details screen 242.

The message details screen 242 may include message details of the transaction message. In one embodiment, the message details screen 242 may include a message ID 243, message meta information 244, message content 245, and processing log information 246.

The message ID 243 may include a message ID for the corresponding transaction message when the corresponding transaction message included in the message information is selected. Here, the message ID 243 may include a unique message ID assigned to the transaction. For example, if the selected transaction message corresponds to a transmission message, the message ID 243 may include the transmission message ID. Additionally, if the selected transaction message corresponds to a received message, the message ID 243 may include the received message ID.

Message meta information 244 may include interface meta information about the message when the corresponding transaction message is selected. In one embodiment, message meta information 244 includes message status, start time, end time, sending system, receiving system, message type, Outbound Business System, Outbound Namespace, and Outbound Namespace. It may include an outbound interface, an inbound business system, an inbound namespace, and an inbound interface.

Additionally, the message content 245 may provide message data for each processing step of the corresponding message by version. In one embodiment, the message content 245 may include version information and detailed message content. In one embodiment, the message content 245 may include transmitted message content or received message content depending on the type of the corresponding message, that is, a transmitted message or a received message.

Processing log information 246 may include detailed log information for processing the corresponding transaction within the integrated solution. In one embodiment, the processing log information 246 may include log processing status, log processing time, and detailed log information. In one embodiment, the processing log information 246 may include a transmission processing log or a reception processing log depending on the type of the corresponding message, that is, a transmitted message or a received message. Additionally, the information included in the transaction monitoring screen 218 of this figure is only an example and is not limited thereto, and of course, various information may be included.

47 is a diagram illustrating an example of a user interface (UI) for adapter backlog monitoring information according to an embodiment

In one embodiment, the control module 2200 of the interface governance platform 10000 may provide a user interface (UI) for the adapter backlog monitoring screen 223.

The adapter backlog monitoring screen 223 may include adapter backlog monitoring information for at least one of the corresponding computing system or interface. In one embodiment, the adapter backlog monitoring screen 223 may include transmitting component information 224 and receiving component information 225. In one embodiment, adapter backlog monitoring information can be queried by server and component based on user input.

Transmission component information 224 may include servers, components, business systems, monitoring status, EOIO (Exactly once in order), processing backlog with errors, and processing backlog without errors. Here, the monitoring status may indicate whether monitoring is performed through CCMS (computing center management system). EOIO can indicate the number of messages of an interface pattern that are processed in order at one time. The processing backlog including errors may indicate the number of processed messages, including the number of messages with errors. The processing backlog without errors may represent the number of messages processed, not including the number of messages with errors.

The receiving component information 225 may include servers, components, business systems, monitoring status, EOIO, processing backlog with errors, and processing backlog without errors. Regarding this, please refer to the above-mentioned contents.

Additionally, the information included in the adapter backlog monitoring screen 223 in this figure is only an example and is not limited thereto, and of course, various information may be included.

48 is a diagram illustrating an example of a user interface (UI) for adapter queue monitoring information according to an embodiment

In one embodiment, the control module 2200 of the interface governance platform 10000 may provide a user interface (UI) for the adapter queue monitoring screen 226.

The adapter queue monitoring screen 226 may include adapter queue monitoring information 227 for at least one of the corresponding computing system or interface.

Adapter queue monitoring information 227 may include servers, server nodes, adapter queues, number of entries in queue, number of thread allocations and executions, and maximum number of threads. Here, the number of queue entries may indicate the number of messages entered into the adapter queue. Thread allocation and execution count can indicate the number of messages allocated to threads and running. The maximum number of threads may indicate the maximum number of threads allocated to the adapter queue.

Additionally, the information included in the adapter queue monitoring screen 226 in this figure is only an example and is not limited thereto, and of course, various information may be included.

49 is a diagram illustrating an example of a user interface (UI) for channel state information according to an embodiment

In one embodiment, the control module 2200 of the interface governance platform 10000 may provide a user interface (UI) for the channel status monitoring screen 228.

The channel state monitoring screen 228 may include channel state monitoring information 229 for at least one of the corresponding computing system or interface. In one embodiment, the channel status monitoring information 229 can be searched based on the server, connection channel, channel status, adapter type, connection direction, and component by user input.

In one embodiment, channel states may include error, warning, ok, stopped, and unknown. Here, the error may indicate the status of the channel where the error occurred. A warning may indicate the status of an inactive channel. Normal may indicate the state of a channel that is operating normally. Outage may indicate the status of a channel being down. Unknown may indicate the state of a channel whose state is unknown.

Additionally, the information included in the channel status monitoring screen 228 in this figure is only an example and is not limited thereto, and of course, various information may be included.

50 is a diagram illustrating an example of a user interface (UI) for user information according to an embodiment

In one embodiment, the control module 2200 of the interface governance platform 10000 may provide a user interface (UI) for the user information screen 230.

The user information screen 230 may include user information 231 for at least one of the corresponding computing system or interface. In one embodiment, when a user is added to the user information screen 230, a screen for adding user information for the added user may be additionally activated. In one embodiment, an account password change screen for the user may be additionally activated. In one embodiment, the user information screen 230 may be provided to the administrator.

User information 231 may include user ID, user name, user type, user status, company, department, company phone number, personal phone number, email, messenger ID, and employee number. In this case, the user type of each user may indicate either administrator or user.

In one embodiment, user information 231 may be directly entered by the user. Additionally, in one embodiment, the user information 231 may be automatically registered and synchronized in conjunction with the customer company's personnel information system through the provided API. In one embodiment, other single sign on (SSO) authentication may be supported for the user information 231.

Additionally, the information included in the user information screen 230 in this figure is only an example and is not limited thereto, and of course, various information may be included.

51 is a diagram illustrating an example of a user interface (UI) for responsible interface information according to an embodiment

In one embodiment, the control module 2200 of the interface governance platform 10000 may provide a user interface (UI) for the responsible interface screen 232.

The responsible interface screen 232 may include responsible interface information for at least one of the corresponding computing system or interface. In one embodiment, the responsible interface screen 232 may include user account information 233, a responsible system 234, and a responsible interface 235. In one embodiment, the responsible interface screen 232 may be provided to administrators and users.

User account information 233 may include user IDs and user names for administrators and users.

The interface in charge 235 may include information on the interface in charge of the user selected in the user account information 233. In one embodiment, the responsible interface 235 may include a work group, interface information, interface ID, responsible information, a transmitting system, and a receiving system for the responsible interface that the user is responsible for. In one embodiment, an interface in charge of the corresponding user may be added or deleted through the responsible interface 235. In one embodiment, if the user is not an administrator, system-related interfaces registered with the user in charge of settings can be viewed and added.

The responsible system 234 may include information on the responsible system in charge of the user selected in the user account information 233. In one embodiment, the responsible system 234 may include system information and business systems. In one embodiment, the system in charge of the user may be added or deleted through the in charge system 234. In one embodiment, if the user is not an administrator, registered systems can be viewed and added by allowing the user to be in charge.

Additionally, the information included in the responsible interface screen 232 in this drawing is only an example and is not limited thereto, and of course, various information may be included.

52 is a diagram illustrating an example of a user interface (UI) for interface group information according to an embodiment

In one embodiment, the control module 2200 of the interface governance platform 10000 may provide a user interface (UI) for the interface group screen 236.

The interface group screen 236 may include interface group information 237 for at least one of the corresponding computing system or interface. In one embodiment, the interface group screen 236 may be provided to the administrator.

Interface group information 237 may include a work group for the interface, whether to use it, creation date and time, modification date and time, and registrant. Here, the work group may include a work group related to the work process for the corresponding interface. Usage may indicate whether the corresponding interface group is used. Creation date and time may indicate the creation date and time of the interface group. The modification date and time can indicate the modification date and time when the group name, usage status, and group description of the interface group were modified.

Additionally, the information included in the interface group screen 236 in this figure is only an example and is not limited thereto, and of course, various information may be included.

53 is a diagram illustrating an example of a user interface (UI) for system information according to an embodiment

In one embodiment, the control module 2200 of the interface governance platform 10000 may provide a user interface (UI) for the system information screen 238.

The system information screen 238 may include system information 239 for at least one of the corresponding computing system or interface. In one embodiment, system information screen 238 may be provided to an administrator.

System information 239 may include system name, system type, person in charge setting, availability, creation date, modification date, and registrant. In one embodiment, the system type may be selected as one of SAP module, SAP-based 3rd party, or legacy system.

In one embodiment, the person in charge setting may indicate whether to allow the person in charge of the system. In this case, in the case of a system where the manager setting is selected as not allowed, the system-related manager interface and system in charge cannot be added to the user in the manager interface screen.

In one embodiment, system information 239 may be added or modified in system information screen 238. When system information 239 is added, the business system of the corresponding system can be set. In this case, the work system to which the system belongs may be registered. For example, the business system may include meta information such as SAP PO's business system.

Additionally, the information included in the system information screen 238 in this figure is only an example and is not limited thereto, and of course, various information may be included.

54 is a diagram illustrating an example of a user interface (UI) for interface information according to an embodiment

In one embodiment, the control module 2200 of the interface governance platform 10000 may provide a user interface (UI) for the interface information screen 240.

The interface information screen 240 may include interface information 241 for at least one of the corresponding computing system or interface. In one embodiment, the interface information screen 240 may be provided to the administrator.

The interface information 241 may include interface information based on the business name of the interface. In one embodiment, the interface information 241 may include a work group, interface ID, interface name, importance, usage status, creation date, modification date, and registrant. In this case, the work group may include work groups related to the work process for the corresponding interface. The interface ID may include an identifier to identify the corresponding interface. Additionally, the interface name may include interface content related to the relevant business process.

In one embodiment, interface information may be added through user input. In this case, the added interface information may include business group, interface ID, interface name, importance, response time, usage status, interface description, transmitting system, receiving system, mapping specification, and functional specification when adding an interface. Here, the mapping specification may include generation cycle, message type, processing method, transmission program, reception program, and mapping document. The message type can be either synchronous or asynchronous. The processing method can be selected as an interface processing method: On-Demand, Batch, Real-Time, or Near Real-Time. The interface information 241 can be directly input by the user as above, but can also be provided through internal linkage with the standard information management module.

Additionally, the information included in the interface information screen 240 of this figure is only an example and is not limited thereto, and of course, various information may be included.

55 is a flowchart illustrating an example in which the interface management method according to an embodiment provides monitoring and management setting information through a user interface (UI).

Obtain log data about the interface of the computing system (S710). In one embodiment, log data may be formatted into a standardized format. For this, please refer to the content described above in FIG. 39.

Based on the log data, at least one of monitoring information or management setting information corresponding to the person in charge is generated (S720). In one embodiment, based on the log data, monitoring information may be generated including at least one of interface monitoring information for an interface, system monitoring information for a computing system, or error monitoring information for at least one of the computing system or the interface. there is. In one embodiment, management setting information including at least one of role authority, task authority, or management target corresponding to the person in charge of log data may be generated based on the input of the person in charge. For this, please refer to the contents described above in FIGS. 39 and 40.

At least one of the monitoring information or management setting information is provided through the user interface (S730). In one embodiment, at least one of monitoring information or management setting information may be provided according to at least one of the role authority or task authority of the person in charge. For this, please refer to the contents described above in FIGS. 39 and 40.

Figure 56 is a diagram illustrating an example in which an interface governance system detects failures and provides solutions according to an embodiment

In the example shown, the interface governance system 10000 may include an interface monitoring module. The interface monitoring module may include a log collection module 2100 and a failure notification module 2300. Here, the description will focus on modules related to the present invention, but for other components, refer to the above-described embodiment of FIG. 2.

The log collection module 2100 may acquire log data about the interface of the computing system. In one embodiment, the log data may include log data converted to a standardized format.

The failure notification module 2300 may detect a failure in at least one of the computing system or interface from the log data based on predefined failure determination criteria information. In one embodiment, the failure notification module 2300 may detect a failure in at least one of the computing system or the interface by comparing the value of the log data with a threshold based on failure determination criterion information. Through this, according to the present invention, real-time failures can be detected based on log data.

In one embodiment, the failure notification module 2300 may detect symptoms of an abnormality in at least one of the computing system or the interface based on statistical information about log data. In one embodiment, the failure notification module 2300 may detect symptoms of abnormality in at least one of the computing system or the interface by comparing the amount of change in log data with a threshold. Through this, according to the present invention, failures can be prevented by predicting abnormal symptoms based on changes in log data.

Additionally, the failure notification module 2300 may provide at least one of failure information or a failure action guide according to at least one of the failure or abnormal symptom. In one embodiment, the failure notification module 2300 may obtain failure action information based on user input. Detailed embodiments of this are described below.

In this example, the interface governance platform 10000 may be connected to an external cloud system or an on-premises system through an API or the like. In one embodiment, the interface governance platform 10000 may be controlled and managed by the control system 100. The control system 100 may include a computer server 110 having at least one processor and a storage or database 120, and may use this to control and manage the interface governance platform 10000. For this, please refer to the contents described above in FIGS. 1 to 3.

57 is a diagram illustrating another example in which an interface governance system according to an embodiment detects failures and provides solutions.

In one embodiment, the example interface governance system 10000 may include a log collection module 2100 and a failure notification module 2300. At this time, the components included in the log collection module 2100 and the failure notification module 2300 are separated to explain the functions performed by the log collection module 2100 and the failure notification module 2300, and the names of the components are It is not limited.

The log collection module 2100 may include a message queue 2105 and a standardization conversion unit 2106. The message queue 2105 may store collected log data. The standardization conversion unit 2106 can convert the format of log data into a standardized format.

The failure notification module 2300 includes a failure detection unit 2301, an abnormality symptom detection unit 2302, a guide provision unit 2303, a notification provision unit 2304, a failure action management unit 2305, and a failure information storage unit 2306. It can be included.

The failure detection unit 2301 may determine whether there is a failure in at least one of the computing system or the interface based on log data standardized in a standardized format. In one embodiment, the failure detection unit 2301 may determine whether there is a failure based on predefined failure determination criteria information. For example, failure determination criteria information may include CPU usage rate, interface processing results, error message information, resource usage rate, thread threshold value, data size, transaction amount, etc.

In one embodiment, the failure detection unit 2301 may determine whether there is a failure depending on whether the interface succeeds or fails. In one embodiment, the failure detection unit 2301 may determine whether there is a failure depending on whether a business standard error is included in the log data. In one embodiment, the failure detection unit 2301 may determine whether there is a failure depending on whether resource usage exceeds a threshold. For example, the failure detection unit 2301 may determine that a failure has occurred when resource usage exceeds a threshold.

The abnormal symptom detection unit 2302 may detect abnormal symptoms for at least one of the computing system or the interface based on statistical information about log data. In one embodiment, the abnormality symptom detection unit 2302 may detect abnormality symptoms according to the amount of change in the monitoring target of log data. For example, the abnormal symptom detection unit 2302 may detect abnormal symptoms according to transaction occurrence trends, transaction pattern change amount, error pattern, interface, message queue, and resource change amount.

In one embodiment, the abnormality symptom detection unit 2302 may determine that an abnormality symptom exists when the amount of change in the monitoring target is greater than a threshold value. In one embodiment, the abnormality symptom detection unit 2302 may determine that an abnormality symptom exists when the change amount to be monitored deviates from a preset pattern. In one embodiment, the amount of change in the monitoring target may be learned and accumulated as statistical information through machine learning and stored in the failure information storage 2306.

The guide provider 2303 may provide a guide for troubleshooting based on detected errors or abnormal symptoms. In one embodiment, the guide provider 2302 may provide a failover guide based on the failover hit rate for previous failover history. In other words, according to the present invention, previous failure action details can be reused to resolve the failure. In one embodiment, previous failure action history may be learned and accumulated by machine learning and stored in the failure information repository 2306.

The notification provider 2304 may provide at least one of failure information or a failure action guide through a notification. In one embodiment, failure information may include failure type, failure cause, and failure content. In addition, the failover guide may include action details to resolve the corresponding failure, a user evaluation of the corresponding action guide, and a failover hit rate according to the result of the action based on the corresponding action guide.

The failover management unit 2305 can obtain the action results according to the user's failover. In one embodiment, the failover management unit 2305 may reflect the user evaluation and status of failover completion in the corresponding failover guide. Detailed embodiments of this are described below.

58 is a diagram illustrating an example of a user interface (UI) for notification information according to an embodiment

In one embodiment, the notification provider 2304 of the interface governance platform 10000 may provide a user interface (UI) for the notification screen 190.

The notification screen 190 may include failure information. In one embodiment, the notification screen 190 may include failure confirmation information 191 and notification content information 192.

The failure confirmation information 191 may include failure information provided as an alert. In one embodiment, the fault confirmation information 191 may include occurrence time, notification title, confirmation status information, and confirmation time. In one embodiment, the notification subject may include an interface message error based on the server identifier and interface name.

Notification content information 192 may include a notification title and notification content. In one embodiment, the notification content may include server and client identifiers, business group, interface name, sending system, receiving system, message ID, error occurrence time, error message, error code, and error type.

In one embodiment, the notification screen 190 may include alarm information about various information such as fault information, CPU, memory, and thread status. Additionally, the information included in the fault screen 190 in this figure is only an example and is not limited thereto, and of course, information about various types of fault information may be included.

59 is a flowchart illustrating an example of converting a data format by an interface management method according to an embodiment.

Obtain log data about the interface of the computing system (S810). In one embodiment, log data may be formatted into a standardized format. For this, please refer to the contents described above in FIGS. 56 and 57.

Based on predefined failure determination criteria information, a failure in at least one of the computing system or the interface is detected from the log data (S820). In one embodiment, a failure in at least one of the computing system or the interface may be detected by comparing the value of monitoring information about log data with a threshold. In one embodiment, before step S730, abnormal symptoms for at least one of the computing system or the interface may be detected based on statistical information about the log data. For this, please refer to the contents described above in FIGS. 56 and 57.

At least one of failure information or failure action guide according to the detected failure is provided (S830). In one embodiment, at least one of failure information or a failure action guide may be determined based on at least one of the detected failure or abnormal symptom, and at least one of the failure or abnormal symptom may be provided.

In one embodiment, the failover guide may be determined based on a failover hit rate according to previous failovers for the failover guide.

In one embodiment, after step S730, failover information corresponding to at least one of the failure information or the failover guide may be obtained, and a failover hit rate for the failover guide may be determined based on the failover information. For this, please refer to the contents described above in FIGS. 56 to 58.

Figure 60 is a diagram disclosing the interface governance platform of the present invention.

The interface governance platform (10000) uses a failure notification module (2300) to provide the ability to check and recover failures (including errors) through the interface of a cloud system or on-premises system based on monitored data. ) may include. Here, the description will focus on modules related to the present invention, but the above-described embodiments will be referred to for other components.

The failure notification module 2300 may include a notification management screen providing unit 2301, a failure detection unit 2302, and a notification generating unit 2303. Here, it is natural that the units included in the failure notification module 2300 are intended to distinguish functions performed by the specification definition module and are not physical components.

The notification management screen provider 2301 may provide a notification setting function through the notification management screen. More specifically, the notification management screen provider 2301 may provide a notification rule setting function, a notification message template management function, and a duplicate notification suppression rule setting function. A detailed explanation of this will be provided later through the notification management screen.

The failure detection unit 2302 may receive failure information of a connected computing system. At this time, the failure detection unit may determine whether there is a failure based on the failure information. If it is determined that there is a failure, the failure detection unit 2302 may transmit the failure information to the notification generation unit 2303.

The notification generator 2303 may apply notification duplication removal rules based on the received failure information.

Additionally, the notification generator 2303 can apply notification rules.

The notification generator 2303 may apply a notification message template to generate a notification.

Thereafter, the notification generator 2303 may load a notification message to which the template is applied into the notification message queue in order to generate a notification.

Afterwards, the notification message loaded in the notification message queue may be delivered to the interlocking module container 2400.

The notification message delivered to the interlocking module container 2400 is delivered to at least one of the email notification module 2401, SMS notification module 2402, SNS notification module 2403, and other notification modules 2404 by a preset method to notify the user. Interface failures can be notified in real time. At this time, the interlocking module container can select the most appropriate notification method according to the user's situation and needs and deliver failure information.

Through this, the interface governance platform (10000) of the present invention can quickly identify repeated failures of the connected computing system. In particular, through filtering and rules described later, unnecessary notifications can be reduced and only important notifications can be delivered quickly and accurately. Through this, users can accurately and reliably take action against repeated failures of connected computing systems.

Figures 61 to 63 are diagrams illustrating the notification management screen provided by the above-described failure notification module. We will explain the notification rule setting screen, duplicate notification suppression rule setting screen, and notification message template management screen, respectively.

Figure 61 is a diagram explaining the notification rule setting screen of the present invention.

This diagram explains the notification rule setting screen provided by the failure notification module. Here, the notification rule may indicate based on what conditions a notification will be sent. For example, if the CPU utilization of a specific system exceeds 90%, you can set a rule to send a notification as a notification rule. At this time, the notification rule can also define whether to send notifications only to specific users or specific groups, or to send notifications in different ways according to various levels of importance.

For example, the sequence for generating a notification for an interface failure associated with a specific work group is as follows:

(1) You can add a notification rule name. For example, you can set a notification rule name such as “Human Resources Management”.

(2) You can set the notification method. For example, you can set “Email” and “SMS”.

(3) You can set a notification message template for each notification method.

(4) You can set the recipient for each notification message. For example, you can search for and add personnel related to human resources management.

(5) You can set the type of failure you want to be notified of. For example, if you want to receive error information of an interface related to human resources management work, you can select “Error”.

(6) The associated target interface can be set. At this time, the associated target interface can be selected on an individual interface basis or on a target system basis. In addition, it is possible to apply rules according to different failure types and failure levels defined within the interface governance platform. Here, the type of failure may refer to the type of failure described above. For example, the fault level indicates the importance of the above-mentioned notification level and can be applied as one of INFO, FATAL, ERROR, and WARN.

The failure notification module may provide an add button for adding a notification rule and a delete button for deleting a notification rule. In one embodiment, a notification rule can be added upon receiving input from the user selecting an add button. For example, notification rules may include GC Work Ratio abnormality notification, EJB Session abnormality notification, etc. Here, GC Work Ratio represents the ratio of how often or for how long GC (Garbage Collection) operates. The GC Work Ratio abnormality notification corresponds to a notification that occurs when the GC work ratio exceeds a certain threshold. Additionally, EJB Session is a session bean in the component-based architecture of the Java Enterprise Edition platform, and EJB Session abnormality notifications respond to notifications that occur when abnormal behavior related to the EJB session is detected.

Likewise, the failure notification module may delete the selected notification rule upon receiving an input signal where the user selects the added notification rule and selects a delete button.

The fault notification module can save the rule filter of the selected notification rule. The failure notification module can receive notification rules and corresponding rule filters from the user, map the notification rules and corresponding rule filters, and store them.

At this time, the failure notification module can provide Message Error, Memory, Thread, CPU, Adapter Queue, Abap Queue, Channel Status, GC Work Ratio, and EJB Session as rule filter types of notification rules. At this time, the provided notification type is only an example, and the failure notification module may provide different notification types depending on the failure. Users can select one of the provided rule filter types as the rule filter for the notification rule. Accordingly, the failure notification module can set rule filters for each notification type.

In one embodiment, the failure notification module may add or delete a notification method for the selected notification rule through a user interface provided as shown in this figure. Additionally, the failure notification module can add or delete recipients for the selected notification rule through a user interface provided as shown in this figure.

Accordingly, users can select alarm rules, add or delete alarm methods, and add or delete recipients for alarm rules on the user interface provided through the interface governance platform.

Figure 62 is a diagram illustrating the duplicate notification suppression rule setting screen of the present invention.

When the same failure occurs continuously, it is inefficient to repeatedly send the same notification to the user. Accordingly, the present invention can be designed to identify the type or pattern of a failure and suppress duplicate failure notifications for a preset time.

The fault notification module may provide an additional button to add a duplicate notification suppression rule and a delete button to delete a duplicate notification suppression rule. In one embodiment, a rule to suppress duplicate notifications can be added as an input signal is received where the user selects an additional button. For example, rules for suppressing duplicate notifications include suppressing Garbage Collection (GC) duplicate notifications and suppressing Enterprise JavaBeans Session Duplicate Notification (EJB Session) duplicate notifications. For example, if a certain memory threshold is exceeded, a GC notification may occur multiple times.

Likewise, the fault notification module may delete the selected duplicate notification suppression rule upon receiving an input signal that the user selects the added duplicate notification suppression rule and selects a delete button.

The fault notification module can save the rule filter of the selected duplicate notification suppression rule. The fault notification module can receive input from the user for a duplicate notification suppression rule and a corresponding rule filter, and can map and store the duplicate notification suppression rule and the corresponding rule filter.

Here, the failure notification module can provide Message Error, Memory, Thread, CPU, Adapter Queue, Abap Queue, Channel Status, GC Work Ratio, and EJB Session as rule filter types for the duplicate notification suppression rule. Users can select one of the provided rule filter types as the rule filter for the duplicate notification suppression rule. Accordingly, the failure notification module can set rule filters for each notification type.

Additionally, the fault notification module can set a duplication suppression interval for messages filtered by rule filters. Accordingly, the failure notification module may not send a notification to the user when a failure occurs according to a rule set for the set duplication suppression interval.

Through this, the efficiency of failure management of the computing system can be improved by reducing unnecessary notifications.

Figure 63 is a diagram illustrating the notification message template management screen of the present invention.

In one embodiment, the notification message should be designed so that the user clearly understands the problem when notified. Accordingly, the notification management screen providing unit may provide a notification message template management function. For example, the template should include key information such as the type of failure, when it occurred, where it occurred, and the severity of the failure.

To this end, the notification message template management screen may provide an additional button for adding a notification template and a delete button for deleting a notification template in the first area. Additionally, the notification message template management screen may provide a template editing screen for inputting the title of the notification message and inputting and saving the content in the second area.

Accordingly, the user can enter and save the title and contents of the notification template, and the interface governance module can notify system failures using the notification template saved by the user.

Figure 64 is a flow chart disclosing the interface management method of the present invention.

In one embodiment, the interface management method may detect a failure that occurs through the interface of the computing system (S910). The interface management method can receive failure information from a connected computing system. The interface management method can determine whether there is a failure based on the received failure information, and if it is determined to be a failure, a notification rule can be applied to the failure information. For this, please refer to Figures 1 to 5 and Figure 60.

In one embodiment, the interface management method may apply preset notification rules and templates to the detected failure (S920). The interface management method can apply preset notification rules when a failure is determined based on received failure information. Here, the preset notification rule is characterized by including a notification rule and a duplicate notification suppression rule. When a notification rule is applied to a failure, a notification message template to generate a notification corresponding to the failure can be applied to the failure information. Additionally, preset notification rules and templates are characterized by being input by the user. For this, please refer to Figures 61 to 63.

In one embodiment, the interface management method may transmit a notification about a failure to which preset notification rules and templates are applied (S930). The interface management method can temporarily store failures to which preset notification rules and templates have been applied in a notification message queue. Thereafter, the interface management method may deliver a notification message corresponding to a failure loaded in the notification message queue to the interlocking module container according to a preset period and a preset method. For this, please refer to Figure 60.

Figure 65 is a diagram disclosing the interface governance platform of the present invention.

The interface governance platform (10000) may include a failure notification module (2300) and an AI module to provide the function of managing failures and accumulating action details in order to increase the stability and efficiency of the system in the enterprise. Here, the description will focus on the modules related to the present invention, but the above-described embodiments will be referred to for other components.

The failure notification module 2300 may include a user interface providing unit 2304, a failure detection unit 2302, and a failure processing unit 2305. Here, it is natural that the units included in the failure notification module 2300 are intended to distinguish functions performed by the specification definition module and are not physical components.

The user interface provider 2304 may provide a user interface screen for failure management. The user interface provider 2304 may include failure statistics information, failover procedure management, and failover search service screens. At this time, refer to FIGS. 39 to 64 for information on failure statistics, failover procedure management, and failover search service screens included in the user interface screen.

The failure detection unit 2302 can automatically register failure information when a failure occurs in the connected computing system. At this time, the failure detection unit 2302 can determine whether there is a failure by transmitting the failure information to the AI module. If it is determined that there is a failure, the failure detection unit 2302 can transmit the failure information to the notification generator. For this, please refer to the details described above in FIGS. 39 to 64.

The AI module 2500 can determine whether there is a failure based on the failure information received from the failure detection unit. At this time, the AI module 2500 may store information such as the cause of occurrence, action details, and recovery time in the database when a failure occurs. At this time, if the AI module 2500 determines that the received failure information is a failure, it can search for failure measures. For example, the AI module 2500 may search for a failure action based on the failure type included in the failure information. In particular, the AI module 2500 can collect failure information received from failure detection and failure action information subsequently processed by the failure processing unit, and then learn the data through machine learning.

In one embodiment, the AI module 2500 uses the collected information to classify classification algorithms such as Logistic Regression, Decision Trees, Random Forest, and Support Vector Machines. You can use to predict the cause or type of disability. Additionally, the AI module can predict the time of occurrence or duration of a failure using regression algorithms such as Linear Regression, Ridge Regression, Lasso Regression, and Polynomial Regression. Additionally, the AI module 2500 can be used to group disorders with similar characteristics using clustering algorithms such as K-Means and hierarchical clustering. Additionally, the AI module 2500 can predict failure occurrence patterns or frequencies using time series analysis algorithms such as ARIMA and LSTM.

When a first failure of the same type occurs based on learned data, the AI module 2500 uses the first failure measure with the highest hit rate (the hit rate will be described later) corresponding to the first failure as a failure handling guide. can be provided. At this time, the failure handling guide may include a failure search function and an API-linked service function, which will be described later. At this time, the guide may include a hit rate.

In one embodiment, the AI module 2500 may provide a failure handling guide including a hit rate to the user through a user interface.

The failure processing unit 2305 can resolve the failure using a method included in the failure handling guide received through the AI module. Alternatively, the user can review the failure handling guide and take steps to actually resolve the failure.

In one embodiment, the failure processing unit 2305 may receive information on measures to be taken regarding the failure from the user. In other words, the user can actually take action to solve the problem and then input the action details through the user interface. Additionally, the user can input an evaluation of the failure handling guide received from the AI module 2500. This will be explained in detail with the drawings described later.

The failure processing unit 2305 may transmit the received action details and evaluation details from the user to the AI module 2500.

The AI module 2500 can compare the failure handling guide provided to the failure handling unit, the action details received from the failure handling department, and the evaluation details from the user.

At this time, the AI module 2500 may newly reflect the hit rate according to the method initially provided in the failure handling guide and the degree of resolution of the received action content. To this end, the AI module 2500 can collect and analyze the content of actions entered by the user and scores for the actions.

Additionally, in one embodiment, the AI module 2500 may perform Natural Language Processing (NLP). For example, a user can enter natural language as an evaluation of a failure handling guide. In this case, the AI module 2500 may process the input natural language and reflect it in the hit rate included in the error handling guide.

Here, the hit rate may represent the probability that the first failure will be resolved with the first failure action for the first failure that occurred. The AI module 2500 learns the first failure, the received action contents, and the evaluation history from the user to obtain information about the first failure, the hit rate for the first failure, and the actual user action contents for the first failure. It can be indexed and stored. At this time, the AI module 2500 can perform indexing through key keywords related to the failure message.

In addition, if the action content and evaluation details received by the AI module 2500 from the failure processing unit 2305 include a new action (e.g., a second failure action), the AI module 2500 As a workaround, you can register a second failover. Likewise, the AI module 2500 may index and store the second failure action details for the first failure and the user evaluation details for the second failure action.

Accordingly, when the first failure is received again later, the AI module 2500 can provide a failure handling guide with a better hit rate. At this time, the AI module 2500 can use a deep learning-based recommendation system to present a guide to handling problems according to the hit rate through classification and indexing by failure type.

Figure 66 is a diagram explaining the failure handling method of the present invention.

This drawing is a diagram sequentially explaining the operation methods of the above-described failure notification module 2300 and AI module 2500.

In one embodiment, the failure notification module 2300 may provide a user interface screen to provide information related to the failure to the user.

When a failure is detected, the failure notification module 2300 may transmit the received failure information to the AI module 2500.

The AI module 2500 can determine whether there is a failure based on the received failure information. At this time, the AI module 2500 can determine whether there is a failure by learning the database held by the interface governance platform. Please refer to the above description for the algorithm that the AI module 2500 performs to determine whether there is a failure.

The AI module 2500 may provide the user with a failure handling guide for the determined failure. In one embodiment, the AI module 2500 guides the user in handling the failure in the case of a failure that does not require the user to take direct action (e.g., when a failover method with a 100% resolution, 100% hit rate, etc. exists). At the same time, it is possible to automatically handle failures through the failure notification module 2300. At this time, automatically handled failures are limited to preset failures.

The user can review the failure handling guide and actually register the details of the failure action and the evaluation details of the failure handling guide on the user interface screen provided by the failure notification module 2300. The AI module 2500 can reflect the details of the failure action processed by the user in the failure processing result and hit rate. The AI module 2500 can index the type of failure based on the received information and use it as reference material for the next failure registration.

At this time, the AI module 2500 may provide an external linked API service to the user. The AI module 2500 can provide not only integrated solutions but also a standard API that can collect various failure information from linked target systems and accumulate and utilize solutions to respond to failures.

Below, we will describe the failure handling screen that handles the occurred failure, the failure statistics screen that shows statistics on the failure, and the failure handling status monitoring screen that provides a service for searching for failure measures. As described above, if a problem occurs in the interface at the business level, it is referred to as a failure, and if a problem occurs in at least one of the specific systems or operations due to the problem, it may be referred to as a failure. Therefore, in the following embodiments, “failure” is used. It will be explained as follows.

Figure 67 is a diagram explaining the error handling screen of the present invention.

This diagram explains the failure processing screen provided by the failure notification module. The above-mentioned user interface providing unit may provide the user with a failure handling screen as shown in this figure.

Additionally, the failure handling screen may include failure type, failure history, and failure handling details.

Each error type may include, for example, DB_Error, FILE_Error, and SOAP_Error.

The failure history may include at least one failure information. Here, the failure information may include failure type, failure code, processing status, failure occurrence time, interface ID, interface name, failure group, transmission system name, etc.

Additionally, the fault processing screen may include a fault search function that can search fault history based on fault occurrence time, fault group, system name, interface ID, fault code, processing status, fault message, and fault level.

Additionally, the failure handling screen may include failure handling details. Failure handling details may include processing status, error message, and failure handling details input window. Users can directly enter action details in the processing status, error message, and error handling history.

In one embodiment, the user may select at least one failure information included in the failure history and then enter one failure handling detail. That is, the failure notification module can store failure processing details for a plurality of retrieved failure histories.

Afterwards, the failure notification module can transmit the failure processing details input from the user to the AI module.

Figure 68 is a diagram explaining the failure statistics screen of the present invention.

This diagram explains the failure statistics screen provided by the failure notification module. The above-described user interface providing unit may provide the user with a failure analysis screen as shown in this figure.

The failure statistics screen may include an occurrence distribution graph by failure type, an occurrence trend graph by failure type, a processing information graph by failure code, and detailed information by failure code. At this time, the failure statistics screen displays an occurrence distribution graph by failure type, an occurrence trend graph by failure type, a processing information graph by failure code, and details by failure code based on a set period (e.g., a month, a week, a day, or a preset period). Information can be printed.

The occurrence distribution graph by failure type corresponds to a graph showing whether the failure type is messaging, data, or default as a percentage of the total. In addition, the occurrence trend by failure type corresponds to a graph of the number of occurrences by date for error types such as messaging, data, and default. Additionally, processing information for each fault code corresponds to a graph of the number of processing times for fault codes (eg, JCO_001, TRAN_002, ETC_000, MAP_001, MSG_005, etc.). In addition, detailed information for each failure code may indicate each failure code for each failure type (messaging, data, default) and include the number of occurrences and occurrence ratio for each failure code.

Through this, users can check the statistical results of failures over a period of time.

Figure 69 is a diagram explaining the failure handling status monitoring screen of the present invention.

This diagram explains the failure processing status monitoring screen provided by the failure notification module. The above-mentioned user interface providing unit may provide the user with a failure handling status monitoring screen as shown in this figure.

The failure processing status monitoring screen may include a list of failures according to failure type classification.

Failure types may include Application type, Data type, Mapping type, Messaging type, Security type, System type, etc., and the list of failures included within the failure type can be classified based on the processing status of the failure. For example, processing status can be classified as ERROR CLOSE, ERROR OPEN, and ERROR PENDING.

In one embodiment, the user may select a failure list whose current processing status is ERROR OPEN among the first failure types (eg, Messaging) among the failure types. Accordingly, the failure notification module can output a failure list in which the failure type is Messaging and the current failure processing status is ERROR OPEN. At this time, the fault list may include fault code, fault type, status, fault occurrence time, interface name, transmitting system, receiving system, fault details, and fault level.

The user can change the failure handling details by selecting at least one from the failure list. Failure processing details may include processing status, failure details, and action details. Accordingly, the user can input, modify, and search the fault processing details for the first to nth faults.

Figure 70 is a flow chart disclosing the interface management method of the present invention.

In one embodiment, when a failure of the computing system is detected, the interface management method may provide a failure handling guide based on failure information about the detected failure (S1010).

In one embodiment, when a failure is detected, the interface management method can determine whether the failure has been detected through an AI module. For this, please refer to the content described above in FIG. 65.

Additionally, the interface management method can provide a guide to handling errors based on error information. Here, the failure handling guide may include a hit rate for failure actions corresponding to the failure. Additionally, the failure handling guide may include a failure search function and an API-linked service function.

In one embodiment, the interface management method may handle a failure based on a failure handling guide (S1020).

In one embodiment, the interface management method may handle failures based on a failure handling guide provided through an AI module. Additionally, in another embodiment, the user may handle the failure directly based on the failure handling guide. To this end, users can check the details of measures taken for existing failures through the failure search function.

In one embodiment, the interface management method may register the action details of the handled failure and the evaluation details of the failure handling guide (S1030).

In one embodiment, the interface governance platform may process failures based on a failure handling guide provided through an AI module, and register the action details of the handled failure and the evaluation details of the failure handling guide. For example, the evaluation details of the failure handling guide may include survey content such as “When the first failure action was performed for the first failure, the first failure was resolved 100%.” In one embodiment, the interface management method may update the failure handling guide for the failure based on the action content of the handled failure and the evaluation history of the failure handling guide. For example, in the interface management method, the existing hit rate of the first failure action for the first failure is 100%, and when the first failure occurs, the first failure action can be provided as a failure handling guide. However, as a result of actually performing the first failure action for the first failure, the AI module may receive survey content such as “Not a single failure was resolved.” At this time, the AI module can lower the hit rate of the first failure action for the first failure to 50%. Of course, this may change based on the number of populations.

In one embodiment, the interface management method may group or index at least one of failure information, failure handling guide, failure action details, and evaluation details of the failure handling guide by failure type.

10, 12, 15, 16~19: Distributed agent adapter
22, 25, 26~29: Integrated solution
100: control system
110: computer server
120: Storage/Database
1000: Interface standardization module
2000: Interface Monitoring Module
10000: Interface Governance Platform

Claims (7)

A platform that manages the interface of an application integration solution installed on at least one of the cloud or on-premise computing systems uses the API provided by the application integration solution based on the type of the log collector by a processor that processes data. Collecting at least one of standardized log data or non-standardized log data from a log collection agent included in the application integration solution;
receiving, by the processor, when the size of the collected log data is greater than a threshold, directly accessing a repository included in the application integration solution to receive the log data;
detecting, by the processor, a failure occurring through an interface related to the application integration solution based on the received log data;
When a failure is detected by the processor, providing a failure handling guide based on failure information about the detected failure;
processing, by the processor, the failure based on the failure handling guide; and
An interface management method comprising registering, by the processor, action details of the handled failure and evaluation details of the failure handling guide.
According to claim 1,
An interface management method comprising grouping, by the processor, at least one of the failure information, the failure handling guide, action details for the failure, and evaluation details of the failure handling guide by failure type.
According to claim 1,
An interface management method comprising, by the processor, indexing at least one of the failure information, the failure handling guide, the action details of the failure, and the evaluation details of the failure handling guide by failure type.
a database that stores data; and
Including a processor that processes the data,
The processor,
Standardized log data or the API provided by the application integration solution based on the type of log collector through a platform that manages the interface of the application integration solution installed in at least one of the cloud or on-premise computing systems Collect at least one of the non-standardized log data from the log collection agent included in the application integration solution,
If the size of the collected log data is greater than the threshold, receive the log data by directly accessing a repository included in the application integration solution,
The platform detects a failure occurring through an interface related to the application integration solution based on the received log data,
When a computing system failure is detected, a guide to handling the failure is provided based on the failure information about the detected failure.
Handling the failure based on the failure handling guide,
An interface governance system that registers the action details of the handled failure and the evaluation details of the failure handling guide.
According to claim 4,
The processor,
Grouping at least one of the failure information, the failure handling guide, the action contents of the failure, and the evaluation details of the failure handling guide by failure type,
Interface governance system.
According to claim 4,
The processor,
Indexing at least one of the failure information, the failure handling guide, the action contents of the failure, and the evaluation details of the failure handling guide by failure type,
Interface governance system.
Standardized log data or the API provided by the application integration solution based on the type of log collector through a platform that manages the interface of the application integration solution installed in at least one of the cloud or on-premise computing systems Collecting at least one of non-standardized log data from a log collection agent included in the application integration solution;
If the size of the collected log data is greater than a threshold, receiving the log data by directly accessing a repository included in the application integration solution;
detecting, by the platform, a failure occurring through an interface related to the application integration solution based on the received log data;
When a failure is detected, providing a failure handling guide based on failure information about the detected failure;
Handling the failure based on the failure handling guide; and
A computer-readable recording medium storing a computer program for executing on a computer an interface management method that performs the step of registering the action details of the processed failure and the evaluation details of the failure handling guide.

Images