APM 10.1 Backend Webservice URN not URL

[Legacy User]

Currently using version 10.1 APM.  We have an application that utilizes webservices to connect with about 80 backend customers. (These are client webservices calls from our application).  These show up as a single URN under the backends. We would like to see the actual customer URL webservices call listed in the backend, along with the new "path" functionality so that we can determine the appropriate webservices call being sent to the customer and understand what the average response time, or if any errors or stalls occur.

 

Why do some webservices client calls show up under the backends with the associate URL and other webservice client calls just show up as a single URN, giving no indication as to what it's calling (ie...an IP address or FQDN).  Is there something in the configs that can be set or a custom pbd created to insure that the backends webservice call(s) show up as a URL, and not just a single URL, but all the associated URL's that the webservices calls;  instead of a URN.

 

Thanks, JKW

[uhljo01]

Hi JKW,

 

    There is no way of getting URLs instead of URNs by changing just the configuration. It is a limitation. If you open the webservice.pbd then you will observe that the resource metrics are written as “Webservice at {namespace}” which is  generic for all. This namespace comes from the nameformatter module. If a change is needed in the naming convention, or if we want a different name, then we would need to write an alternate nameformatter, which would be a customization to the product, and would likely be handled by the CA Professional Services team.

 

Hope this helps!

-John

[Legacy User]

Thanks for the information, but just to be clear. Primarily, I'm talking about the backends. how does backends integrate with the webservices, and how does the agent identify URN vs URL backends.  As an example, on the backends, I can see "Webservice at http_//www.google-analytics.com". I know that the system made a backend webservice call to google-analytics.  If I open up the google-anlytics backends, I can get "Paths" information (if configured)

 

Verses......"WebService at urn_xps-b_2009" on the backends, which provides me no real value. Instead I want the URL that the backend is connecting to, which is about 80 customers. I want: http_customer1.com, http_customer2.com, along with the "Paths" information.

[Viruvaibhav_apm]

Hi JKW,

 

If I understand your requirement correctly, backends will give you till URL details only for webservice.

If you want the specific webservice detail or END-Point of webservice, you need to check udner "WebServices" node in Investigator. [Obviously you need to enable Webservices.pbd]

 

So if you have three webservice endpoints say -

www.XYZ.com/Webservice1/ABC

www.XYZ.com/Webservice1/DEF

www.PQR.com/Webservice2/GHI

 

Then Backends will show you details of "www.XYZ.com/Webservice1" and "www.PQR.com/Webservice2" only.

 

But under Webservices node, you will find individual details of each end-point i.e. three data points.

 

Hope it helps.

 

Regards,
Vaibhav

[Anon Anon]

Hey JKW,

 

I agree there’s a bit of a confusing behaviour here.

 

Historically, we only traced “SOAP WebServices” with the “SOA Performance Management” extension (webservices.pbd).

This created metrics under “WebServices” (Client and Server) and also under “Backends”.

To do that, we basically instrumented various soap java libraries, which allowed us to instrument both http or jms based soap calls.

 

Now in 10.0, we have added instrumentation for the major http client libraries. When we did that, we only added metrics under “Backends” and not under “WebServices”, as most users use the info under Backends and not so much under WebServices.

 

So now under “Backends”, you will find 2 different kind of “WebService at” nodes.

 

1)      The first ones come from SPM, and show you the URN

 

2)      The other ones come from this new http client instrumentation, and show you the path and eventually the path details if you configure them.

 

We still haven’t had time to rationalize these 2 different behaviours. I understand you like the second one best?

 

If getting this new behaviour is a priority for you, can I trouble you with the creation of an Idea on the Community? This is our best place to track enhancement requests.

 

Thx a lot,

 

Florian.

[Legacy User]

Florian,

Thanks, very nice explanation. I've looked at the httpbackendmetrics.pbd file, and it appears that the file could be adjusted to add additional classes to track outgoing webservices that utilize http protocol for backend requests. Is it possible if someone is using JAXWS webservices, to add the classes into the httpbackendmetrics.pbd file?

 

JKW

[Legacy User]

So, I have some additional information. I looked closer at our application and analyzed some traces to our customers. When we make an http connection (using webservices), the application uses the "sun.net.www.protocol.http.HTTPURL.Connection" java class. I then looked in the httpbackendmetrics.pbd file and found that the "sun.net.www.protocol.http.HTTPURL.Connection" java class is supported.  The Agent Autoprobe log shows that java class is being processed, and a transaction trace shows that the java class above is being called.

 

So, if the class is in the httpbackendmetrics.pbd file, why are we not seeing the http calls on the backend? Instead we are seeing just the associated webservices urn that uses the "sun.net.www.protocol.http.HTTPURL.Connection".  With that class in the httpbackendmetrics.pbd, should we be seeing the associated http requests along with the "path" (default)?

 

Thanks, JKW

[Anon Anon]

Hi James,

 

You’re right, we do not create “duplicate” backends as that would be confusing, so the “httpbackends” tracers actually do nothing if they realize that the spm tracers are already present.

 

I’m investigating if we have a way to change that behaviour through configuration.

 

Something that will work for sure is to entirely get rid of SPM. If you remove the spm.pbl, webservices.pbd and their associated jar files, you should start seeing the HTTP backends appear.

 

Regs,

 

Florian.

[Anon Anon]

Hey James,

 

So we looked at this, and we think that if you actually edit the webservices.pbd and comment out all the lines ending with "WebService at " (with the double quotes), that should deactivate the spm backend tracers and the http backends should start appearing.

 

And you would preserve all the metrics under “WebServices”.

 

Let me know if that works,

 

Florian.

[Legacy User]

Florian,

 

Worked great. I commented all the "WebService at" in the webservices.pbd, then restarted the instance. We now have all the outgoing customer "WebService at HTTP" URL's on the backend.  I am now working on configuring the backend URL path groupings for them.

 

Thanks for the assistance in getting this working.

 

JKW