KR20130067959A - Method and appratus for processing error of application - Google Patents

Abstract

PURPOSE: An application error processing method and a device thereof are provided to easily confirm related script information and an exception and to accurately perform services and applications defined according to user definition. CONSTITUTION: A recording unit(710) records service state information during the application service performance of a client connected through a network. A monitoring unit(712) periodically monitors an error generation situation through the service state information. A control unit(718) sets an error by type according to the monitoring result and generates and stores the service state information as a file written with XML(Extensible Markup Language). The control unit renders the XML file to replay a thread having an error. [Reference numerals] (710) Recording unit; (712) Monitoring unit; (714) Replay unit; (716) Viewer interface unit; (718) Control unit; (720) Markup language file generating unit

Description

METHOD AND APPRATUS FOR PROCESSING ERROR OF APPLICATION

The present invention relates to an HSF (Healthcare Software Framework) base framework, and relates to an application error processing method and apparatus for reproducing an exception occurrence status by recording and using an associated script generated by an application server.

In the past, network application and service performance measurement is a simplified method of measuring and analyzing based on logs acquired from a specific port or unit system. The organic performance between systems or applications in a network is not only impossible to measure and test. It was not suitable for service or software development, and after the product development was completed, errors were found after initial operation or commercial service.

In particular, many demand organizations that operate mission-critical healthcare systems that deal with human life have a lower reliability because of the lack of the ability to immediately reproduce exceptions in addition to general information about exceptions. There is a problem.

In addition, when an exception occurs, general exception information exists, but it is difficult to identify the exact point of failure by the exception information alone, and it is difficult to reproduce the same exception information. There is an increasing demand for recording the detection of exceptions and reproducing them immediately for faster troubleshooting.

The present invention records services and applications that are variously defined according to user definitions by recording exceptions generated by an application server and storing related scripts to reproduce the exception occurrence status in order to test the performance of an application or service of an arbitrary system. To provide a technique that performs exactly the performance of the.

In addition, the present invention is to provide a technique for easily checking the exception and the associated script information through the immediate playback of the exception occurred, and to perform a quick bug fix and disaster recovery through the exception reproduction.

In addition, the present invention can continuously manage the recording information of the exception to provide a recyclable technology for regression test and system stability test.

According to an aspect of the present invention, in the application error processing method, calling an application service from at least one client connected through a network, and recording service state information when performing the application service to the client; Periodically checking the error occurrence state of the application during recording, setting the generated error by type, and generating the recorded service state information in a file described in an Extensible Markup Language (XML). Storing and replaying a thread in which an error occurs by rendering the XML file.

According to another aspect of the present invention, in the application error processing apparatus, the recording unit for recording the service state information when performing the application service to the client connected via the network, and the error occurrence situation through the service state information output from the recording unit A monitoring unit for periodically monitoring and setting an error for each type according to the monitoring result, and controlling to generate and store the recorded service state information in a file described in an Extensible Markup Language (XML); It is characterized in that it comprises a control unit for controlling to replay the thread in error by rendering the XML file.

The present invention not only accurately performs the performance of various defined services and applications according to the user definition, but also makes it easy to check exceptions and related script information through instant reproduction of generated exceptions, and to quickly reproduce the exceptions. Bug fixes, failovers, and ongoing management of exceptions can be reused for regression testing and system stability testing.

1 is a flowchart illustrating an application error processing method according to an embodiment of the present invention.
2 is an exemplary view showing a unit test at the source level according to an embodiment of the present invention.
Figure 3 (a) is an exemplary view showing a screen for the test filtering option according to an embodiment of the present invention, (b) is an illustration showing a screen debugging the test results.
Figure 4 is an exemplary view showing a test result TEST Class creation according to an embodiment of the present invention.
Figure 5 is an exemplary view showing the environment setting in the storage management-console recording according to an embodiment of the present invention.
FIG. 6A is a table of a data entity specification used for recording and replaying according to an embodiment of the present invention, and (b) is a table of an HSFServiceAccessStore.
7 is a detailed block diagram of an application error processing apparatus according to an embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. It will be appreciated that those skilled in the art will readily observe that certain changes in form and detail may be made therein without departing from the spirit and scope of the present invention as defined by the appended claims. To those of ordinary skill in the art.

The present invention is provided in the Healthcare Software Framework (HSF) base framework, and more specifically, a plurality of systems interoperate with each other, and a network configured to provide a predetermined service by delivering a message packet between applications performed in each system. In order to test the performance of an application or service of any system, the performance of services and applications that are variously defined according to the user definition is recorded by recording exceptions generated from the application server and storing related scripts to play back the exception occurrence status. In addition to accurate execution of the exceptions, it is easy to check exceptions and related script information through instant replay of the exceptions generated, to perform bug fixes and disaster recovery quickly through the exceptions reproduced, and to continuously record the exceptions. Regression testing and system To provide a technology capable recycling gender test

Hereinafter, an application error processing method according to an embodiment of the present invention will be described in detail with reference to FIG. 1.

1 is a flowchart illustrating an application error processing method according to an embodiment of the present invention.

Referring to FIG. 1, first, an application service is called by at least one or more clients connected through a network in step 110. At this time, the client is a remote middleware application component using different protocols in the same host.

In step 112, the service state information is recorded when the application service is performed by the client. Step 112 is performed on a server providing a service to the remote clients. The user interface layer is called according to a protocol stack including a physical layer, a MAC layer, a control layer, and a stream layer of the server. Recording of the application service state information from the time point until the return time to the server is performed.

The recording refers to information necessary for reproducing the corresponding application service, and the information uses .NET reflection technology that enables dynamic invocation of a service.

In performing the recording operation, first, the façade handling the service of all the servers is transmitted through the TSS Manager to start recording the service state information of the corresponding application for error reproduction, and the server facade manager receives the set value. Prepares the recording of necessary information regarding the occurrence of service exceptions.

Afterwards, the HSF test client tool monitors the HSF call agent that handles the server call in the UI client and performs logging on the service history called by the server. The above operation is an option of the HSF test client and is selected only when the exception replay is performed directly by the client module. In general, the replay of the exception is not required because it is performed by the server.

Subsequently, the HSF Service Call Agent calls the HSF Server Facade using the WCF Call Library and delivers the run-time information and caller's own information required for the service call.

The HSF server facade sends the received service request packet information to the Log Publisher, and if an exception occurs during the invocation of the designated service, the business component sends the exception call stack and detailed information to the server facade manager according to the exception bubbling mechanism of the HSF. To pass.

The server Facade manager that receives the exception passes to Log Publisher with the unique context ID used in the previous call, the Log Publisher publishes the event in the COM + event system, and the COM + queues the event, and the exception fails. Log Subscribers, which choose to receive events asynchronously, receive them through COM + and, depending on the configuration value, are stored in memory in the HSF console in real time or in RDB in non-real time.

In step 114, the error occurrence state of the application during the recording is periodically checked, and in step 116, the generated error is set for each type.

The generated error may be an abnormal syntax or an exception processing may not be performed normally when the application service is executed, and the error type may include a general exception or a specific exception that is a standard of service performance and quality performed by the corresponding application. User definable conditional exception.

In step 118, the recorded service state information is generated and stored in a file described in an Extensible Markup Language (XML). In step 120, the XML file is rendered, and in step 122, an error occurs. do.

Here, referring to FIG. 6, FIG. 6A is a table of a data entity specification used for recording and replay, and (b) is a table of an HSFServiceAccessStore.

Renders the XML file, changes measurement parameters according to the contents of the corresponding script, obtains the resulting packet, and performs editing.

In step 124, if the replay is checked and completed, the process proceeds to step 126 to display a viewer interface for an error when the replay is completed using a load of a thread in which the error occurs and a script language.

In addition, by dynamically loading the XML file for execution of the XML file, the application supports scenario testing and integration testing.

Here, referring to FIG. 2, a screen example of unit testing at a source level is illustrated. The platform of the test includes unit test and scenario test in four ways: test recording, test reproduction, test editing, and test recording of TSS. It is possible.

Through the test case management in the management tool configured as above, it is possible to record all Caller Service accessing the server, and to query the current status and results.

In addition, as shown in (a) of FIG. 3, the recorded result may be stored as an XML file, and then used as an integrated test and separate unit test data.

3 (b) is an exemplary view showing the debugging of the test result according to an embodiment of the present invention, as shown in (b) of FIG. Test, unit and integration test support is available.

In addition, it is possible to create a test project such as Nunit by creating a class file.

4 illustrates an example of a screen for creating a test result test class. The recorded test information may be generated as a new test class by converting and deleting a parameter.

Performing and recording such a test provides a function of recording and reproducing a service call unit through a middleware, and the recorded information allows editing of call parameters through a related mechanism and provides a function of converting to a test object class.

FIG. 5 is a diagram illustrating a configuration of a storage management-console recording according to an embodiment of the present invention. As shown in FIG. 5, in the configuration, the TSS database access information is opened by opening a TestSupportDBConnectionString item among environment variables. Modify and press [Apply] to reflect.

At this time, environmental information is managed in HSF.Tech2008.Product.Console.exe.config.

The console record registers the execution history and the result value with the Event through the Publisher () method from the ServiceEventClass through the ServiceEventPublisher and is processed by the ServiceSubscriber.

The storage management-DBMS record registers the execution history and the result value with the Event (Service) method from the ServiceEventClass through the Publisher () method and receives the ServiceSubscriber and records it in the DBMS.

At this time, the start details of the execution event are not received and the TSS listener is responsible for recording only with the result information. By generating TestObject Class based on the recorded TEST information, exception processing can be re-executed and TEST Class can be managed.

The application error processing method according to an embodiment of the present invention has been described above.

Hereinafter, an application error processing apparatus according to an embodiment of the present invention will be described with reference to FIG. 7.

7 is a detailed block diagram illustrating an application error processing apparatus according to an exemplary embodiment.

The application error processing apparatus includes a recording unit 710, a monitoring unit 712, a replay unit 714, a viewer interface unit 716, a control unit 718, and a markup language file generation unit 720.

The recording unit 710 records service state information when performing an application service to a client connected through a network.

The monitoring unit 712 periodically monitors an error occurrence state through service state information output from the recording unit 710.

The controller 718 sets an error for each type according to the monitoring result, controls to generate and store the recorded service state information in a file described in an Extensible Markup Language (XML), and the XML file. Render to control the replay of the thread where the error occurred.

The markup language file generator 720 generates a file described in a markup language under the control of the controller 718.

The replay unit 714 replays a thread in which an error occurs in the XML file under the control of the control unit 718.

The viewer interface 716 is a viewer for an error when the replay is completed in the replay unit 714 using a log of a thread in which the error occurs and a script language under the control of the controller 718. Print the interface.

As described above, an operation related to an apparatus and method for processing an error of an application according to the present invention can be performed. Meanwhile, the above-described description of the present invention has been described in detail. However, various modifications can be made without departing from the scope of the present invention. have. Accordingly, the scope of the present invention should not be limited by the illustrated embodiments, but should be determined by equivalents of the claims and the claims.

710: recording unit 712: monitoring unit
714: replay unit 716: viewer interface unit
720: markup language file generation unit

Claims (8)

In the application error handling method,
Calling an application service from at least one client connected through a network;
Recording service state information when an application service is performed by the client;
Periodically checking an error occurrence situation of an application during the recording, and setting the generated error for each type;
Generating and storing the recorded service state information in a file described in an Extensible Markup Language (XML);
And replaying a thread in which an error occurs by rendering the XML file. The method of claim 1,
And displaying a viewer interface for an error upon completion of the replay by using a log of a thread in which the error occurred and a script language. The method of claim 1, wherein the generated error is
Application error handling method characterized in that the abnormal syntax occurs or exception processing is not normally performed. The method of claim 1, wherein the error type is
And a user-definable conditional exception including a general exception or a specific exception that is a criterion of service performance and quality performed by the application. The method of claim 1,
Dynamically loading the XML file for execution of the XML file, the application error processing method further comprising the step of supporting the scenario test and integration test of the application. The method of claim 1, wherein the recording,
Application error handling method, characterized in that performed from the time of the UI layer call from the client to the return to the server. The method of claim 1,
And rendering the XML file, changing measurement parameters according to the contents of the corresponding script, acquiring and editing a packet generated as a result, and performing editing. In the application error processing apparatus,
A recording unit for recording service status information when performing an application service to a client connected through a network;
A monitoring unit periodically monitoring an error occurrence state through service state information output from the recording unit;
Set an error for each type according to the monitoring result, control to generate and store the recorded service state information in a file described in Extensible Markup Language (XML), and render the XML file to generate an error. And a control unit for controlling to replay the reserved thread.

Images