Browse Prior Art Database

Mechanism to trace Webservice Faults

IP.com Disclosure Number: IPCOM000235443D
Publication Date: 2014-Feb-28
Document File: 3 page(s) / 53K

Publishing Venue

The IP.com Prior Art Database

Abstract

It can sometimes be difficult to determininethe cause of a web service fault in an integation environment. A mechanism is described that allows for context information to be added to fault reporting. This facilitates debugging by providing the insight needed to resolve a problem.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 3

Mechanism to trace Webservice Faults

Webservices are a specialized form of remote procedure call. Under abnormal circumstances, such as when a processing error occurs, a webservice may return a fault. The fault itself may not contain all of the information required to adequately describe the problem and hence debugging the issue and retrying the request becomes difficult. In this case it becomes necessary to access the data that was used to invoke the webservice.

A known solution to this problem is to log all invocation data irrespective of whether the request was successful or unsuccessful. This is an expensive method as in production the chances of fault is rare and unnecessarily it would result in logging all the invocation data.

Our technique provides a mechanism to trace back the transaction and retrieve the request when a fault occurred. This will enable logging the webservice request data only when a fault occurs.

Prior to making the webservice call, the details of the request is stored locally. When a fault occurs, the webservice invoking program will accept the fault and mark the transaction as a fault and this will be the beginning point to start the trace back. Control is passed back to the start of the transaction where the request was stored. Webservice request data can now be logged into a log file and can be used for debugging the issue. After the issue is fixed the websrevice request can be retried.

There will be 2 types of logging which would be used here

1. Error log: log the fault message along with unique transaction id and transaction time in a error log file

2. Request data log: Actual webservice request along unique transaction id and transaction time will be logged in a queue kind of repository so that it can be used for retry

Unique transaction id and transaction time are used to correlate the error log file and webservice request logs.

Below given is how the mechanism works

1


Page 02 of 3


1. An input request is received by the webservice invocation program an...