KR101528071B1 - Method for gathering error context information of application software and middleware - Google Patents

Method for gathering error context information of application software and middleware Download PDF

Info

Publication number
KR101528071B1
KR101528071B1 KR1020130163200A KR20130163200A KR101528071B1 KR 101528071 B1 KR101528071 B1 KR 101528071B1 KR 1020130163200 A KR1020130163200 A KR 1020130163200A KR 20130163200 A KR20130163200 A KR 20130163200A KR 101528071 B1 KR101528071 B1 KR 101528071B1
Authority
KR
South Korea
Prior art keywords
service
execution
information
error
request
Prior art date
Application number
KR1020130163200A
Other languages
Korean (ko)
Inventor
김도훈
신기영
박영복
Original Assignee
주식회사 포스코
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 포스코 filed Critical 주식회사 포스코
Priority to KR1020130163200A priority Critical patent/KR101528071B1/en
Application granted granted Critical
Publication of KR101528071B1 publication Critical patent/KR101528071B1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

A method for collecting error status information of an application software and a middleware according to an embodiment of the present invention is a method for collecting error status information of application software and middleware in which at least one history The method of claim 1, further comprising the steps of: generating one or more transactions from the at least one history information when an error occurs during generation of the service request information, wherein the configured transaction is provided to an automatic analysis module, And is displayed on the screen of the automatic analysis module and used for error analysis.

Figure R1020130163200

Description

METHOD FOR GATHERING ERROR CONTEXT INFORMATION OF APPLICATION SOFTWARE AND MIDDLEWARE

The present invention relates to a method for collecting error status information of application software and middleware, and more particularly, to a method for collecting error status information of application software and middleware for collecting error status information of application software and middleware for use in error analysis.

In the steel process middleware system, tasks are developed using middleware services. Here, the service provided by the middleware may be interrupted due to a user's erroneous use or an error caused by the system (hardware, operating system, network, etc.) or an error in the service itself. In this case, the error value of the error of the middleware service is delivered to the task, and since the task developer can not know the internal operation of the middleware for providing the service, the error processing code Should be. However, since there is not enough information to analyze the cause of the error and the avoidance method of the error situation, it takes a long time for the task developer to develop the error handling code. Therefore, an environment capable of providing sufficient information on an error situation is required.

Also, since the middleware service determines whether the entire task is operated, it is necessary to guarantee the stability / performance of the developed middleware service. To this end, a middleware service developer develops a code that assumes a middleware service usage pattern by a task developer, and based on this, ensures the stability of the middleware service. The middleware service thus developed is applied to a task development site. However, in task development, task developers use middleware services in unexpected patterns, often resulting in service failures. In order to analyze such errors, it is necessary not only the error situation information generated by the middleware itself, but also information on the usage pattern of the middleware service by the task developer. Accordingly, when the task developer does not separately manage the information on the usage pattern of the middleware service, the middleware service developer has difficulty in analyzing the error. Accordingly, regardless of whether the task developer separately manages the information on the middleware service use pattern, the middleware itself generates information about the usage pattern of the middleware service by the task developer, and the information is automatically generated An environment that can be correlated and analyzed is required.

There is a need in the art for a method for collecting error situation information of application software and middleware for collecting error situation information of application software and middleware for use in error analysis.

In order to solve the above problems, a first aspect of the present invention provides a method for collecting error situation information of application software. The method comprising the steps of: generating at least one history information during generation of service request information according to a request for a middleware service of a task; and generating, when an error occurs during generation of the service request information, And configuring a transaction with at least one history information, wherein the configured transaction is provided to an automatic analysis module and displayed on a screen of the automatic analysis module and used for error analysis.

A second aspect of the present invention provides a method for collecting error status information of a middleware. The method includes the steps of generating at least one piece of history information while processing service request information of a task, and generating at least one piece of history information that is generated when an error occurs during processing of the service request information And configuring one transaction, wherein the configured transaction is provided to an automatic analysis module and displayed on a screen of the automatic analysis module and used for error analysis.

In addition, the solution of the above-mentioned problems does not list all the features of the present invention. The various features of the present invention and the advantages and effects thereof will be more fully understood by reference to the following specific embodiments.

The time required for task developers and middleware service developers to develop or review task and middleware services is provided by collecting error status information of application software and middleware and providing error status information collection method of application software and middleware for error analysis. Can be reduced.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram showing the configuration of a steelworking middleware system according to an embodiment of the present invention;
FIG. 2 is a flowchart illustrating a method for collecting error status information of application software according to an embodiment of the present invention;
3 is a flowchart illustrating a method of collecting error status information of a middleware according to an embodiment of the present invention; and
4 is a flowchart illustrating a method of analyzing error situation information of an automatic analysis module according to an embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings. However, the embodiments of the present invention can be modified into various other forms, and the scope of the present invention is not limited to the embodiments described below. Further, the embodiments of the present invention are provided to more fully explain the present invention to those skilled in the art. The shape and size of elements in the drawings may be exaggerated for clarity.

Hereinafter, a method of collecting error status information of application software and middleware, which is an embodiment of the present invention, will be described.

In the following description, each component may be constituted by a software module.

FIG. 1 is a block diagram showing an apparatus configuration of a steel processing middleware system according to an embodiment of the present invention.

1, the steel processing middleware system includes an application software 100, a middleware 130, and an automatic analysis module 160. The application software 100 includes a plurality of tasks 101, an application programming interface (API) 103, an API launcher manager 105, an API launcher pool 107, a request execution ID manager 111, A request execution ID pool 113, an API executor-request execution ID mapper 117, a request execution error context pool access coordinator 119, a request execution error context pool 121, an error context manager 123, Value manager 125. < / RTI > The middleware 130 includes a service agent 131, a service manager 132, a service executor 133, a service executor pool 135, a service execution ID manager 139, a service execution ID pool 141, A service execution error context pool 149, an error context manager 151, and an error level value manager 153. The execution service ID mapping unit 145, the service execution error context pool access coordinator 147, the service execution error context pool 149, The automatic analysis module 160 includes an error context collector 161, an integrated synchronizer 163, and an analysis screen provider 165.

First, the detailed configuration of the application software 100 will be described.

Each of the plurality of tasks 101 calls an API 103 dedicated to executing the corresponding middleware service in order to receive the requested middleware service.

The API 103 is a set of programming functions called by the task 101 to receive a service of the middleware 130. The task 101 calls the API 103 to send a message transmission / Middleware services such as related services, task registration / termination related services, communication related services, database function related services, and shared memory related services can be provided.

The API launcher manager 105 assigns to the task 101 one API executor 109 to manage the generation of service request information among a plurality of API launchers in the API launcher pool 107.

The request execution ID manager 111 assigns to the task 101 one request execution ID 115 among a plurality of request execution IDs in the request execution ID pool 113. [ The request execution ID includes a service request time, a task number, a thread number for performing a task, and a random number generated according to a probability.

The API launcher-request execution ID mapper 117 maps the assigned API launcher 109 and the request execution ID 115.

The requested execution error context pool access coordinator 119 solves the simultaneous access problem when the assigned API executor 109 and the error context manager 123 access the request execution error context pool 121 to ensure data integrity .

The assigned API launcher 109 starts generating service request information using the API library module and generates at least one history information during the generation of the service request information according to the middleware service request of the task 101 And stores the generated at least one history information in the request execution error context pool 121 through the request execution error context pool access coordinator 119. [ The history information includes intermediate input data required for executing the current library module, intermediate output data after execution, descriptive text for execution contents, description text for errors generated during execution, code values for errors, and error level values for errors do.

In addition, the assigned API executor 109 checks whether or not an error occurs during the generation of the service request information. If an error occurs during generation of the service request information, the API runner 109 assigns the error context manager 123 ), And stores the history information stored in the request execution error context pool 121 in the disk 170. The history information stored in the request execution error context pool 121 includes history information of the desired error level value, . The transaction is divided into the request execution IDs, and the history information of the desired error level values are arranged and connected in order according to the order of generation.

If an error does not occur until the generation of the service request information is completed, the assigned API executor 109 transmits the service request information of the task 101 to the middleware 130. Thereafter, the assigned API executor 109 checks whether the service completion information including the code value for service success is received from the middleware 130, and transmits the service completion information including the code value for the service success The history information stored in the request execution error context pool 121 is deleted through the error context manager 123. [ If the service completion information including the code value for the service failure is received, the assigned API executor 109 notifies the error context manager 123 of a desired error among the history information in the request execution error context pool 121 Level information, and stores the history information in the disk 170, and deletes the history information stored in the request execution error context pool 121. FIG.

The error context manager 123 manages the history information in the request execution error context pool 121 on a transaction-by-transaction basis and controls the history of the execution error context pool 121 according to the control of the assigned API executor 109 One transaction is constructed from the history information of the desired error level value and stored in the disk 170, and the history information stored in the request execution error context pool 121 is deleted.

The error level value manager 125 manages the error level value set in advance by the system manager so that the transaction can be configured based only on the history information of the error level value. For example, a transaction can be configured by excluding only the history information generated for debugging purposes, or the transaction can be configured with only the history information of a serious error level.

Next, the detailed configuration of the middleware 130 will be described.

The service agent 131 receives service request information of the task 101 from the application software 100.

The service manager 132 is responsible for initializing the service providing environment of the middleware 130 and initializing the service launcher manager 133.

The service launcher manager 133 assigns one service executor 137 for managing the service request information among a plurality of service executors in the service executor pool 135 to the task 101, The API executor 109 and the service executor 137. [

The service execution ID manager 139 assigns the service execution ID 143 of one of a plurality of service execution IDs in the service execution ID pool 141 to the task 101. [ The service execution ID includes a service request information processing time, a request execution ID assigned to the task 101 by the application software 100, and a thread number responsible for service execution.

The service launcher-service execution ID mapper 145 maps the assigned service launcher 137 and the service execution ID 143.

The service execution error context pool access coordinator 147 solves the concurrent access problem when the allocated service executor 137 and the error context manager 151 access the service execution error context pool 149, .

The allocated service launcher 137 starts processing the service request information using the service related module, generates at least one history information while processing the service request information of the task 101, And stores the generated at least one history information in the service execution error context pool 149 through the context pool access coordinator 147. The history information includes at least one of intermediate input data required for executing a current service-related module, intermediate output data after execution, descriptive text for execution details, explanatory text for errors generated during execution, code values for errors, .

In addition, the allocated service executor 137 checks whether an error occurs during the processing of the service request information. If an error occurs during the processing of the service request information, the allocated service executor 137 transmits service completion information To the API executor 109 of the task 101 through the communication channel and transmits the history information of the desired error level value among the history information in the service execution error context pool 149 through the error context manager 151 as one The transaction is constructed and stored in the disk 170, and the history information stored in the service execution error context pool 149 is deleted. The transaction is identified by the service execution ID, and the history information of the desired error level value is arranged and connected in order according to the order of generation.

If an error does not occur until the processing of the service request information is completed, the allocated service executor 137 transmits service completion information including a code value for service success to the task 101 via the communication channel. And deletes the history information stored in the service execution error context pool 149 through the error context manager 151. [

The history information in the error context manager 151 and the service execution error context pool 149 is managed on a transaction basis and the history information in the service execution error context pool 149 under the control of the assigned service executor 137 And records the history information on the disk 170 and deletes the history information stored in the service execution error context pool 149.

The error level value manager 153 manages the error level value preset by the system manager so that the transaction can be configured based only on the history information of the error level value. For example, a transaction can be configured by excluding only the history information generated for debugging purposes, or the transaction can be configured with only the history information of a serious error level.

Next, a detailed configuration of the automatic analysis module 160 will be described.

The error context collector 161 collects transactions configured by the application software 100 and the middleware 130 on the disk 170 periodically or in real time.

The integrated synchronizer 163 synchronizes with the application software 100 based on the request execution ID 115 of the transaction configured by the application software 100 and the service execution ID 143 of the transaction configured by the middleware 130 ) And the transaction configured by the middleware 130 into a single transaction. Accordingly, the application software 100 generates a service request of the task, and the middleware 130 can provide information on an error situation in which an error occurred due to the execution of the task.

The analysis screen provider 165 displays the integrated synchronized transaction on a console or a GUI screen for use in error analysis.

 2 is a flowchart illustrating a method of collecting error status information of application software according to an embodiment of the present invention.

Referring to FIG. 2, in step 201, the application software calls an API of a middleware service required by a task.

Then, in step 203, the application software assigns one API executor for managing the generation of service request information among the plurality of API executors to the task.

Then, in step 205, the application software assigns a request execution ID to the task. In order to connect and manage information on a series of processes, it is necessary to provide a new task for each task of the middleware service whenever a request for a middleware service is requested or a request result is received. Assign a request execution ID. The request execution ID includes a service request time, a task number, a thread number for performing a task, and a random number generated according to a probability.

In step 207, the application software maps the assigned API launcher to the request execution ID.

In step 209, the application software starts to generate service request information using the API library module through the assigned API launcher. The API executor uses various modules included in the API library in a specific order to generate service request information.

Then, in step 211, the application software generates at least one history information during the generation of the service request information according to the middleware service request of the task, and stores the generated at least one history information in the request execution error context pool . The API library module includes a plurality of codes including at least one history information generation code, and the history information can be generated when the processing order of the history information generation code among the codes in the API library module comes. The history information includes intermediate input data required for executing the current library module, intermediate output data after execution, descriptive text for execution contents, description text for errors generated during execution, code values for errors, and error level values for errors do.

In step 213, the application software checks whether an error occurs during the generation of the service request information. For example, when an error occurs internally (for example, memory allocation failure) while using various modules included in the API library, an error occurs in a service provided by the middleware, and error information is received from the middleware , It checks whether a communication channel with the middleware is broken or a communication related error occurs. Here, if an error occurs during the provision of the service, the middleware may analyze the corresponding error, convert it into error information of a type that can be determined by the application software, and provide the application software with the error information.

If an error occurs during the generation of the service request information in step 213, the application software, in step 215, transmits one piece of history information of the desired error level value among the pieces of history information in the request execution error context pool, The transaction is constructed and stored in the disk, and the history information stored in the request execution error context pool is deleted. Also, the configured transaction can be displayed on the screen. The transaction is divided into the request execution IDs, and the history information of the desired error level values are arranged and connected in order according to the order of generation. The transaction stored in the disk is provided to the automatic analysis module, and the transaction provided to the automatic analysis module is displayed on the console of the automatic analysis module or a graphical user interface (GUI) screen for error analysis.

On the other hand, if no error occurs during the generation of the service request information in step 213, the application software checks in step 217 whether the generation of the service request information is completed.

In step 217, if the generation of the service request information is not completed, the application software returns to step 211 and repeats the following steps.

On the other hand, if it is determined in step 217 that the generation of the service request information is completed, that is, no error occurs until the generation of the service request information is completed, the application software transmits the service request information of the task to the middleware do.

In step 221, the application software checks whether service completion information including a code value for service success is received from the middleware.

In step 221, when the service completion information including the code value for the service success is received, the application software deletes the history information stored in the request execution error context pool in step 223.

On the other hand, if the service completion information including the code value for the service failure is received in step 221, the application software proceeds to step 215 and stores the history information of the desired error level value in the history information in the request execution error context pool One transaction is constructed and stored on the disk, and the history information stored in the request execution error context pool is deleted. Also, the configured transaction can be displayed on the screen. The transaction stored in the disk is provided to the automatic analysis module, and the transaction provided to the automatic analysis module is displayed on the console of the automatic analysis module or the GUI screen to be used for error analysis.

Thereafter, the application software terminates the algorithm according to the present invention.

According to the embodiment, the request execution ID assigned to the task is transmitted to the middleware when the service request information of the task is transmitted to the middleware, and the service execution ID assigned to the task by the middleware is transferred to the request execution ID May be included. In this case, a transaction configured by the application software and a transaction configured by the middleware due to an error generated during the processing of the service request information are collected periodically or in real time by the automatic analysis module, Integrated by the service execution ID, and displayed on the console or GUI screen of the automatic analysis module.

Alternatively, according to another embodiment, the service completion information including the code value for the service failure further includes a service execution ID assigned to the task by the middleware, and the service completion information including the code value for the service failure Information on the service execution ID may be further included in the request execution ID of the transaction when the application software configures the transaction according to the reception of the information. In this case, a transaction configured by the application software and a transaction configured by the middleware due to an error generated during the processing of the service request information are collected periodically or in real time by the automatic analysis module, Integrated by the service execution ID, and displayed on the console or GUI screen of the automatic analysis module.

3 is a flowchart illustrating a method of collecting error status information of a middleware according to an embodiment of the present invention.

Referring to FIG. 3, in step 301, the middleware receives service request information of a task from application software.

Then, in step 303, the middleware assigns one service executor for managing the service request information among the plurality of service executors to the task, and performs the communication between the task (in particular, the API executor allocated to the task) Create a channel.

In step 305, the middleware assigns a service execution ID to the task. To provide middleware service to a task, a series of processes for preparing the middleware service are required. In order to connect and manage the information about the series of processes, a new service execution ID is assigned to the task each time a middleware service is provided do. The service execution ID includes a service request information processing time, a request execution ID assigned to the task by the application software, and a thread number responsible for service execution.

In step 307, the middleware maps the service execution ID and the service execution ID.

In step 309, the middleware starts processing the service request information using the service related module through the assigned service launcher. The service executor uses the service related modules in a specific order for processing service request information.

In step 311, the middleware generates at least one piece of history information while processing the service request information of the task, and stores the generated at least one piece of history information in the service execution error context pool. The service related module includes a plurality of codes including at least one history information generating code, and the history information may be generated when a processing order of the history information generating code among the codes in the service related module comes. The history information includes at least one of intermediate input data required for executing a current service-related module, intermediate output data after execution, descriptive text for execution details, explanatory text for errors generated during execution, code values for errors, .

In step 313, the middleware checks whether an error occurs during the processing of the service request information. For example, it is checked whether an error occurs internally (for example, memory allocation failure) during the use of the service-related modules, a communication channel with the task is broken, or a communication-related error occurs.

In step 313, if an error occurs during the processing of the service request information, the middleware transmits service completion information including a code value for the service failure to the task on the communication channel in step 315.

In step 317, the middleware configures one transaction with history information of a desired error level value among the history information in the service execution error context pool, stores the transaction on the disk, and deletes the history information stored in the service execution error context pool. Also, the configured transaction can be displayed on the screen. The transaction is identified by the service execution ID, and the history information of the desired error level value is arranged and connected in order according to the order of generation. The transaction stored in the disk is provided to the automatic analysis module, and the transaction provided to the automatic analysis module is displayed on the console of the automatic analysis module or the GUI screen to be used for error analysis.

On the other hand, if an error does not occur during the processing of the service request information in step 313, the middleware checks whether the processing of the service request information is completed in step 319.

If the process of the service request information is not completed in step 319, the middleware returns to step 311 and repeats the following steps.

On the other hand, if an error does not occur until the process of the service request information is completed, that is, until the process of the service request information is completed in step 319, the middleware performs a service including a code value for service success in step 321 And transmits completion information to the task via the communication channel.

In step 323, the middleware deletes the history information stored in the service execution error context pool.

Thereafter, the middleware ends the algorithm according to the present invention.

According to the embodiment, the request execution ID assigned to the task by the application software is received by the middleware together with the service request information, and the service execution ID assigned to the task by the middleware is the information about the request execution ID . In this case, the transaction configured by the middleware and the transaction configured by the application software are collected periodically or in real time by the automatic analysis module, and are integrated synchronously by the request execution ID and the service execution ID, Console or GUI screen.

Alternatively, according to another embodiment, the service completion information including the code value for the service failure further includes a service execution ID assigned to the task by the middleware, and the service completion information including the code value for the service failure Information on the service execution ID may be further included in the request execution ID of the transaction constituted by the application software when the transaction is configured by the application software according to the reception of the information. In this case, the transaction configured by the middleware and the transaction configured by the application software are collected periodically or in real time by the automatic analysis module, and are integrated synchronously by the request execution ID and the service execution ID, Console or GUI screen.

4 is a flowchart illustrating a method of analyzing error situation information of an automatic analysis module according to an embodiment of the present invention.

Referring to FIG. 4, in step 401, the automatic analysis module collects transactions configured by application software and middleware on a disc periodically or in real time.

In step 403, the automatic analysis module analyzes the transaction configured by the application software and the transaction configured by the middleware based on the service execution ID of the transaction configured by the middleware and the request execution ID of the transaction configured by the application software in step 403, Synchronize with transaction.

To this end, in one embodiment, the request execution ID assigned to the task by the application software is transmitted to the middleware when the service request information of the task is transmitted to the middleware, and the service execution information The ID may include information on the request execution ID. In this case, the automatic analysis module collects the transaction configured by the middleware and the transaction configured by the application software, acquires the information on the request execution ID from the service execution ID of the transaction configured by the middleware, The history information in the transaction and the history information in the transaction corresponding to the request execution ID can be integrated synchronously.

Alternatively, the service completion information including the code value for the service failure may further include a service execution ID assigned to the task by the middleware, and the service completion information including the code value for the service failure When a transaction is configured by the application software according to reception, information on the service execution ID may be further included in a request execution ID of a transaction constituted by the application software. In this case, the automatic analysis module collects the transactions constituted by the middleware and the transactions constituted by the application software, acquires information on the service execution ID from the request execution ID of the transaction configured by the application software, The history information in the transaction corresponding to the request execution ID and the history information in the transaction corresponding to the request execution ID can be synchronously integrated.

Then, in step 405, the automatic analysis module displays the integrated synchronized transaction on a console or GUI screen to be used for error analysis. For example, when a transaction sorting or a search request is input from the user in chronological order or in the order of a request execution ID or a service execution ID, the automatic analysis module can perform the request and display the execution result on the console or the GUI screen .

Thereafter, the automatic analysis module terminates the algorithm according to the present invention.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments, but, on the contrary, It will be obvious to those of ordinary skill in the art.

100: Application Software
101: Task
103: API
105: API Launcher Manager
107: API launcher pool
111: Request execution ID manager
113: Request execution ID pool
117: API Launcher - Request Execution ID Mapper
119: Request execution error Context pool access coordinator
121: Request Execution Error Context Pool
123: Error Context Manager
125: Error Level Value Manager
130: Middleware
131: Service Agent
132: Service Manager
133: Service Launcher Manager
135: Service launcher pool
139: Service execution ID manager
141: Service execution ID pool
145: Service Launcher - Service Execution ID Mapper
147: Service execution error Context pool access coordinator
149: Service Execution Error Context Pool
151: Error Context Manager
153: Error Level Value Manager
160: Automatic analysis module
161: Error Context Collector
163: Integrated Synchronizer
165: Analysis screen provider

Claims (14)

Generating at least one piece of history information while generating service request information according to a middleware service request of the task;
Configuring one transaction with the generated at least one history information when an error occurs during generation of the service request information;
Invoking an application programming interface (API) of a middleware service required by a task,
Assigning an API executor to the task;
Assigning a request execution ID to the task;
Mapping the assigned API launcher to the request execution ID; and
And starting generation of service request information using the API library module through the assigned API launcher,
Wherein the configured transaction is provided to an automatic analysis module and displayed on a screen of the automatic analysis module and used for error analysis.
The method according to claim 1,
The generating of the history information includes generating at least one history information during generation of the service request information and storing the generated at least one history information in the request execution error context pool,
Wherein the request execution ID includes at least one of a service request time, a task number, a thread number for performing a task, and a random number generated according to a probability.
3. The method of claim 2,
When an error occurs during the generation of the service request information, one transaction is configured with the history information of the desired error level value among the history information in the request execution error context pool and transmitted to the disk without sending the service request information, The history information stored in the pool is deleted,
Wherein the transaction is identified by the request execution ID, And the history information is arranged in accordance with the generation order.
3. The method of claim 2,
The API library module includes a plurality of codes including at least one history information generation code. When the processing order of the history information generation code among the codes in the API library module comes, the history information is generated,
The history information includes at least one of intermediate input data required for executing the current library module, intermediate output data after execution, explanatory text for the execution details, explanatory text for the error generated during execution, code value for the error, Wherein the error information includes at least one of the following:
3. The method of claim 2,
Transmitting the service request information of the task to the middleware if an error does not occur until generation of the service request information is completed;
Checking whether service completion information including a code value for service success is received from the middleware;
Deleting the history information stored in the request execution error context pool when the service completion information including the code value for the service success is received,
When the service completion information including the code value for the service failure is received, one transaction is configured with the history information of the desired error level value among the history information in the request execution error context pool and stored in the disk, and the request execution error context pool Further comprising the step of deleting the stored history information.
6. The method of claim 5,
The request execution ID assigned to the task is transmitted to the middleware when the service request information of the task is transmitted to the middleware, and information on the request execution ID is included in the service execution ID assigned to the task by the middleware ,
The transaction configured and configured by the middleware due to an error generated during the processing of the service request information is periodically collected by the automatic analysis module and is integrated synchronously by the request execution ID and the service execution ID, And displaying the error condition information on the screen of the module.
6. The method of claim 5,
Wherein the service completion information including a code value for a service failure further includes a service execution ID assigned to a task by the middleware, and upon receipt of service completion information including a code value for the service failure, , The request execution ID of the transaction further includes information on the service execution ID,
The transaction configured and configured by the middleware due to an error generated during the processing of the service request information is periodically collected by the automatic analysis module and is integrated synchronously by the request execution ID and the service execution ID, And displaying the error condition information on the screen of the module.
Generating at least one piece of history information while processing service request information of the task;
Configuring one transaction with the generated at least one history information when an error occurs during processing of the service request information;
Receiving service request information of the task from application software;
Assigning a service executor to the task and creating a communication channel between the task and the service executor;
Assigning a service execution ID to the task;
Mapping the assigned service executor to a service execution ID;
And starting the processing of the service request information using the service related module through the assigned service launcher,
Wherein the configured transaction is provided to an automatic analysis module and displayed on a screen of the automatic analysis module and used for error analysis.
9. The method of claim 8,
Generating the history information includes generating at least one history information during processing of the service request information and storing the generated at least one history information in the service execution error context pool,
Wherein the service execution ID includes at least one of a service request information processing time, a request execution ID assigned to a task by an application software, and a thread number for performing a service.
10. The method of claim 9,
The service related module includes a plurality of codes including at least one history information generating code. When the processing order of the history information generating code among the codes in the service related module comes, the history information is generated,
The history information includes at least one of intermediate input data necessary for executing the current service related module, intermediate output data after execution, descriptive text of the execution details, explanatory text of the error generated during execution, code value of the error, The method of claim 1,
10. The method of claim 9,
If an error occurs during the processing of the service request information, one transaction is configured with the history information of the desired error level value among the history information in the service execution error context pool and stored in the disk, and the history information stored in the service execution error context pool is deleted However,
Wherein the transaction is divided into the service execution IDs, and the history information of the desired error level values is arranged according to a generation order.
12. The method of claim 11,
Transmitting service completion information including a code value for a service failure to a task via the communication channel if an error occurs during processing of the service request information;
If an error does not occur until the processing of the service request information is completed, service completion information including a code value for service success is transmitted to the task through the communication channel, and history information stored in the service execution error context pool is deleted The method of claim 1, further comprising the steps of:
13. The method of claim 12,
Wherein the service completion information including a code value for a service failure further includes a service execution ID assigned to the task, and wherein upon receipt of service completion information including a code value for the service failure, The information about the service execution ID is further included in the request execution ID of the transaction constituted by the application software,
Wherein the configured transaction and the transaction configured by the application software are periodically collected by the automatic analysis module and are integratedly synchronized by the request execution ID and the service execution ID and displayed on the screen of the automatic analysis module A method for collecting error situation information.
10. The method of claim 9,
Wherein the request execution ID assigned to the task by the application software is received together with the service request information, and the service execution ID assigned to the task includes information about the request execution ID,
Wherein the configured transaction and the transaction configured by the application software are periodically collected by the automatic analysis module and are integratedly synchronized by the request execution ID and the service execution ID and displayed on the screen of the automatic analysis module A method for collecting error situation information.
KR1020130163200A 2013-12-24 2013-12-24 Method for gathering error context information of application software and middleware KR101528071B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020130163200A KR101528071B1 (en) 2013-12-24 2013-12-24 Method for gathering error context information of application software and middleware

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020130163200A KR101528071B1 (en) 2013-12-24 2013-12-24 Method for gathering error context information of application software and middleware

Publications (1)

Publication Number Publication Date
KR101528071B1 true KR101528071B1 (en) 2015-06-10

Family

ID=53505821

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020130163200A KR101528071B1 (en) 2013-12-24 2013-12-24 Method for gathering error context information of application software and middleware

Country Status (1)

Country Link
KR (1) KR101528071B1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017069468A1 (en) * 2015-10-21 2017-04-27 주식회사 포스코 Event service method of steel process middleware, and framework system
CN109885419A (en) * 2019-02-21 2019-06-14 广东电网有限责任公司信息中心 A kind of automatic management method for middle wound middleware Fault Isolation and reparation

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20050055240A (en) * 2003-12-05 2005-06-13 제노시스 주식회사 Integrated management system for matadata and method thereof
KR101271821B1 (en) * 2011-12-23 2013-06-07 주식회사 포스코 Steel process middleware application error analysis system and error analysis method using the same

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20050055240A (en) * 2003-12-05 2005-06-13 제노시스 주식회사 Integrated management system for matadata and method thereof
KR101271821B1 (en) * 2011-12-23 2013-06-07 주식회사 포스코 Steel process middleware application error analysis system and error analysis method using the same

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017069468A1 (en) * 2015-10-21 2017-04-27 주식회사 포스코 Event service method of steel process middleware, and framework system
CN109885419A (en) * 2019-02-21 2019-06-14 广东电网有限责任公司信息中心 A kind of automatic management method for middle wound middleware Fault Isolation and reparation

Similar Documents

Publication Publication Date Title
CN104536899B (en) A kind of software deployment and its maintaining method based on Intelligent cluster
US20150100829A1 (en) Method and system for selecting and executing test scripts
US12007866B2 (en) System and method for database replication benchmark testing using a pipeline-based microservices model
US20150100832A1 (en) Method and system for selecting and executing test scripts
US8584079B2 (en) Quality on submit process
US10430172B2 (en) Re-configuration in cloud computing environments
US20150100830A1 (en) Method and system for selecting and executing test scripts
US20150100831A1 (en) Method and system for selecting and executing test scripts
CN111125444A (en) Big data task scheduling management method, device, equipment and storage medium
CN111800354B (en) Message processing method and device, message processing equipment and storage medium
US8046638B2 (en) Testing of distributed systems
CN110474822A (en) A kind of block chain link point detecting method, device, equipment and medium
CN108694118A (en) A kind of application testing method and device
US20140067886A1 (en) Information processing apparatus, method of outputting log, and recording medium
CN113778486A (en) Containerization processing method, device, medium and equipment for code pipeline
CN111506358B (en) Method and device for updating container configuration
JP6615071B2 (en) Computer system and test case management method
CN109885612A (en) The synchronization take-effective method and device of block chain intelligence contract
KR101528071B1 (en) Method for gathering error context information of application software and middleware
JP2015049876A (en) Test system and method
CN114218072A (en) Test script generation method and device, storage medium and computer equipment
CN109002305A (en) A kind of update method and its system of device program
CN111209125B (en) Multi-process command line implementation method
JP6642024B2 (en) Management device, management method and management program
KR20150030297A (en) Verification apparatus, terminal device, system, method and computer-readable medium for verifying application

Legal Events

Date Code Title Description
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20180605

Year of fee payment: 4