Does anyone have a solution for getting a list of the parameters on a web request from Dynatrace. We had that in APM, before Dynatrace, but web request parameters were lost in the transition. Yes I know that I can configure session and action properties, or request attributes but I need to find them in the app first. that's not easy now without using another utility or the source. Maybe there is an easy way that I am missing, welcome any suggestions.
thanks in advance.
Solved! Go to Solution.
hey @Bill_Demsky can you expand a bit more on what you are targeting? The Application page in dynatrace gives a great synopsis of what is being done on the app, as you dig deeper you can see a list of user action for the app by selecting "Analyzing Performance" on any given segment of the page. You can even move to user sessions and see actions for a given user.
For a post to a webserver there are parameter include in the post. Those provide specifics on what the page has requested and was used to diagnosis things like search, or processing issues based on the actual content of the parameter. Since the source of the app is not normally available, the names of these parameters is not known without using some other tools like fiddler to capture the actual HTTP post content. Providing these post parameters simplifies the process of diagnosing a single request or creating a request attributes or action/session properties if longer term analysis is needed
You can get URL query parameters in the PurePath/Trace view.
Post Parameters are only visible though if you capture them via a request attribute, so you need to know which ones you want to capture beforehand.
Yes that's the current state, previously, Dynatrace would provide the post parameters when you expanded the detail on a post web request as part of the trace. You could then select those post parameters that you wanted to make a request attribute to be captured for all future web request. I am asking for this detail screen back, so that I don't need to use another tool to see the post parameters to get the name to use to capture the request attribute. This detail for the web request was very useful for diagnosis of specific user sessions that reported issues without having to capture the post parameter for all web requests. In many cases, the application source code is not available, and it was much quicker to just get it directly from the actual user request in the trace. this detail doesn't need to be retained for more than 48hrs since this typically used for diagnosis of user issues while in a support session with the user.
@Bill_Demsky great, maybe you could link it here, so if someone finds this in the future he can vote without looking for it 🙂