Skip to Content

This is the 2nd part of the initial blog: How to troubleshoot Duet ESA WebServices which works for Duet as well as for Alloy.

We still assume that we are calling the getLeaveInfo WebService from the Leave Management facade, and that this WebService returns an error.

In the first part we have been using the J2EE Default Trace to find the Service Definition of the failing WebService, in order to put a suitable external breakpoint. This time we assume that the Default Trace does not provide that information (e.g. because we have not defined the right trace level, or we are not able to find the right entry in the log, …).

Another option to find out which ABAP class is processing the request is to run a SOA trace. For this we at first need to open up the SOA Manager by calling transaction SOAMANAGER

.

This opens up a browser window that allows us to navigate to the Logs and Traces tab, where we can open the Trace Configuration:

. 

In the Trace Configuration we can press Add New to create a new Trace entry, as we want to see a Full Trace for the current user. Therefore we put a filter on the user name and set the Trace level to Full Trace:

. 

Next thing we need to do is to execute the failing getLeaveInfo WebService again. Once this is done, we can use the Logs/Trace Viewer from the SOA Manager to display the trace:

.

And there we find again the generated Proxy Interface II_TIM_DEFEMPLEVREQ_OWNQR. The name of the ABAP class can be derived by replacing the “II” at the beginning of the Interface name with “CL”. So in this case the class name is CL_TIM_DEFEMPLEVREQ_OWNQR, as well as CL_PAD_WORKAGREEMENT_SIMPLEQR for the first entry in the trace list. In these classes we can put an external breakpoint in the method BUSINESS_LOGIC as we did in the first blog already.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply