BT for Web Service that is not showing up as a web service

Hi Richard,

I just want to verify you have the fix in place for the spring framework that was suggested in this thread. We had to modify the out of the box sensor pack to get the services to show up. Unfortunately you lose the sensor pack fix on just about every patch and release Dynatrace shoves out the door. It would be nice if Dynatrace put the fix in the sensor pack going forward so Spring 3 is supported out of the box. 

Let me know if you have modified the sensor pack.

Thanks,

Jim

Hi All,

Sorry I know this is an old thread but seemed like the most relevant place to be asking this question.

We are having an issue where the webservice invoked by springframework 3 is correctly being detected however the namespace and method is giving either invoke or execute however there are multiple different dynamic classes generated upon invoking/executing the webservice which we are unable to create measure for splitting by the actual operation being performed on the webservices as the contexualised operation name is part of the dynamic classes.

For example we have a webservice named /webservice1/web-service.wsdl and this wsdl will be generated dynamically upon invocation of the wsdl presenting the client multipe methods that can be invoked on this webservice however dynatrace has no visibility of these different classes and methods.

Is there a way to get these different dynamic operations into dynatrace so we can split specific calls based on these dynamically created classes?

Thanks in advance!

Richard

My pleasure Jim. Christian's solution is the better one for you, though the BT would have worked too. I always prefer updating the sensor packs if that is a viable option.

Please do yourself a favor and make a note about the change that you made to our internal Sensor Pack. I do not want you to lose that functionality in an upgrade!!

Hi Rob,

I am fuzzy on the splitting part. I've developed BTs around URI pattern matches but nothing with methods. The services we are working with just went live so this is an issue that I needed to address ASAP.

I appreciate your help. I went down the BT path because it looked as the web service path was blotto. (My support case) Luckily Christian stepped in otherwise I would have had to implement the BT.Your solution looks like it is a viable work around. It's nice to know there are multiple paths to a solution.

Thanks again,
Jim

Hi Jim,

I had the impression that you wanted to treat the services separately which is why I first made the "separate BT" suggestion. But I offered the "split" solution in case you wanted to keep BT creation to a minimum.

If you did the split solution, you would have one BT. When you executed the BT, you would see separate lines in the resulting BT dashlet for each handleXXX method. This would look similar to the "Web Services by Method" built in BT.

If you went with the one-BT-per (filter) method, you would have (naturally) one BT per handleXXX method.

Plusses and Minuses: the split method is simpler in that you only need to define one BT, and you will get results for any handleXXX method. However, all of those results are what we call "dynamic measures" meaning they don't have any configuability on their own. So, for example, you could set a response time threshold of 2 seconds for the BT, meaning that this threshold would apply to each handleXXX method. You could not set handleSearch to have a threshold of 2 seconds for alerting, handleSomethingElse to have a threshold of 3 seconds.

The filter method (one BT per handleXXX method) means that you will be creating a separate BT for each desired method. This will make it a little more "obvious" in the dT GUI, since you will see "handleSearch" as a BT, "handleSomethingElse" as a BT, and so on (as opposed to "handleXXX webservices by handler" as a single BT). Good news is that you could set up different thresholds for each one individually. Also, you will get just what you want. with the Split method you will get one line in the BT output for any handleXXX method. If you had 20 but only cared about 6 you'd still see all 20.

Either approach is fine - just depends on what you want to accomplish.

It sounds like you may be a little fuzzy on BTs, so let me know if this makes sense.

Rob

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

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.

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

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

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