BT for Web Service that is not showing up as a web service
Web services were developed using the spring framework v 3.1. This version is not in the web service sensor pack and as a result calls to the service are showing up as web requests. What I would like to do until support gets this fixed is to define a business transaction using the URI and add a method measure (filter) for the entry point of the web service in question. The method measure is used to identify the service. I'm hoping to get the URI response time as the time the service ran.
Does anyone have any ideas on how I could accomplish this?
Can you post a sample PurePath of yours? This will make it easier to understand your exact scenario and we can help you define that BT
Andreas,
The handlesearch is the method. This is is the entrypoint into the code. The URI being passed is: /ecmservices/index.jsp. I tried to actually export the purepath and upload it but I couldn't figure out how to attach it. There is a support case. It's number is 00739035. There are several exported purepaths in the case documentation.
Any and all help is appreciated as I just learned springframesowrks 3.x will not be supported in current and future sensor packs so I have to come up with a viable workaround. I can't dictate to development on what versions to use.
Thanks,
Jim
Hi
If you already have a support case open on this I suggest you let them know that you also posted this here. We want to avoid double work on the same issue.
Here is what I think you need to do to get this working. If this doesnt work then I suggest you continue your work with our guys from support:
What you need is a Business Transaction that filters on the Invocation of the handlesearch method and that splits by the URI. In order to achieve that you need a MEthod Invocation Measure for the handlesearch method and set the treshold to 1 (as we will use it as a filter measure in our BT). Then you can use the existing Web Request URI measure as a splitting.
Fortunately there is some help through the UI to make this a very easy task
#1: Right Click on the handlesearch node and say "Create Business Transaction"
#2: Select the Method invocation Measure, give the measure a meaningful name, e.g: "Is calling handlesearch" and click on "Filter"
#3: For Splitting select either select the existing "Web Request - URI Pattern Value" or create your own measure of the type Web Request URI Pattern
#4: If you only expect a small numbere of different URIs I suggest that you change the splitting options in the BT Dialog to "No Restriction" (thats true if you run dynaTrace 4.2+)
I think that should do the trick
Jim,
Are you looking specifically for this case only (the URI and the handleSearch method), or is this just an example - i.e. it could be that URI, and lots of different methods implementing your web services?
If it's specifically just this case, then I would think a BT with the URI filter applied, and returning as a result the TIME measure for the handleSearch method (it, and its subtree).
If this is just an example, then you would do that same thing (in new BTs) for the other methods that implement your web services.
Rob
Jim,
Andi and I just posted seconds apart, but with different interpretations of your scenario. I was assuming the URI was "general" and different methods (services) could spawn from that. It looks like Andi is thinking that handleSearch can come from many URIs, and that you want all those URIs that invoke handleSearch. Could you clarify which situation it is?
Rob
Rob and/or Andreas,
As Rob mentioned, the URI is general. The SOAP message contains the service to run. There will be a "handleXXXXXX for each of the web services being invoked.
Would I do an invocation or a time for handlSearch method measure when I define it? I just want to use it as an identifier to separate the different service calls.
What I was hoping to get was time and count of the URI call when the call contains handleSearch in the Purepath. I assumed I would need a business transaction for each of the services in question. Do you think this is possible?
Weblogic is also doing some stuff around the class for the handleSearch method since it is an entrypoint. For example: com.cinfin.ecm.services.endpoint.SearchEndpoint$$EnhancerByCGLIB$$d8d31455 shows up in the purepath. The developers defined: com.cinfin.ecm.services.endpoint.SearchEndpoint
Would it be more efficent to use a regex on the class or a starts with? Please advise. Since this will be going in production I want as little overhead as possible.
Thanks,
Jim
So to be clear: the time that you would have wanted from your screenshot above is the top line: 2180.74?
If this is the case, then I think this is straightforward. You would create a BT for each "handleXXX" that you have. The BT would have two "Filter" measures. One would be a WebRequest measure "count" with a threshold of 1 for the URI, and the other would be a Method measure on "invocation" with a threshold of 1 for the handleXXX method. If the above time is the one you are looking for (see your screenshot) then the default return values for the BT will be fine.
(NOTE: "sensors" are required for any method-based measures. There are many ways to organize and accomplish this. My recommendation: create a new sensor group called SpringWebServices (or something like that) and create a sensor in there for all of the handleXXX methods. Then make sure that sensor group is "placed" into the proper agent groups in your system profile. Then create the BTs as stated above.)
I'm worried I'm missing something with complication you add on the "SearchEndpoint$$Enhancer..." stuff. How is that relevant? Am I missing something?
Rob
Here is an alternative:
If you really are interested in that top-line number, and you are confident that anything that starts with "handle" will be one of your services, you could create a single BT that split on the method name.
In this case you would create one BT with a single filter, a WebRequest "count" on the URI with a threshold of 1. Then you could create a SPLIT Method measure on "method name" where the name starts with "handle". Or perhaps you could use a regex if there was some pattern that helped you really nail it down.
In this case that one BT would split across all the "handleXXX" methods for that one general URI.
Rob
hi Jim,
there's a way you can have the 'new' API
org.springframework.web.servlet.DispatcherServlet.doService()
handled the same way by the Web Service Sensor as the 'old' API
org.springframework.ws.transport.http.MessageDispatcherServlet.doService()
i just talked to our support and sent them the instructions, they will post it on your case.
the reason, i'm not posting it on this public forum is, that you should not do changes like that without consulting guys with dynatrace internal knowledge.
best,
Christian
Love all the suggestion and help. Let me speak about what I know so far. If you use just the method sensor you lose all overhead that weblogic uses to instantiate the service so you don't get a true picture of how long it took the service to run. That's why I'm trying to keep things at the top level URI call if possible.
Rob, I'm not sure I understand but I like the idea of one definition. Will I get differnt BT names based on the split? If I can't I'll define separare BT. There are currently 6 services. There will be more in the future. As an FYI I can attach a screen shot of the class explorer so you can get an idea of what weblogic is doing. Let me know if you want this.
To Christian's point - Support did have me modify the web services sensor pack and add a defintion to it to see if the web services would show up. I've attached the screen shot of the modified sensor pack definition. The call to the various services did not show up as web services and that's the whole point. That's when I went down the BT path so I can track the web service calls individually.
Thanks to all.
Chistian,
The fix worked perfectly. All out of the box dash boards work once configured and the services are now appearing as expected in the UI under web services. I like your response a lot better than what I saw in previous response to my case which was "it isn't supported". Our developers like you too since they want to keep current and the 3.x sring framework provides them with some functionality that makes their life easier.
Thank you so much.
Jim
