21 Sep 2018
05:07 PM
- last edited on
30 Aug 2022
11:38 AM
by
MaciejNeumann
Hi everybody,
I'm having trouble setting up requests attributes on services requests which content a JSON payload or XML content.
I tried to setup a request attribute that captures HTTP Post parameter, but I don't know what to put in the parameter name field.
Here is an example of the payload I'm working on:
{"tdddTypeDemaDero":{"ntypeDemaDero":3,"ddeval":1456786800000,"itypeDemaDero":"Dérogation tarifaire","ltypeDemaDero":"Dérogation tarifaire","vlistMatDestFormu":"XXXXX;YYYYY;ZZZZZ;"},"lnomraPivotDemaDero":"XXXXX"}
How should I configure Dynatrace to get the values for the lnomraPivotDemaDero field?
Thanks in advance.
Regards,
Gilles
Solved! Go to Solution.
I don't know enough about it to explain in great detail but POST Parameters are different from a json or xml payload. They usually have a content type such as application/x-www-form-urlencoded and are simple key-value pairs like you would see in the query of a GET.
parameter=value&also=another
So even though they are also technically passed in the body it is much simpler and less costly than trying to look into and parse through a more complicated body like json or xml which would introduce significant overhead and so we do not do and so you cannot create request attributes off of them.
James
Post parameters are being send as part of the request header, while JSON/XML payload is sent as part of the body itself. This is why request attributes (until changed and I'm not aware of any plan to do so) will not work on post parameters for you. What you should do, is capture these values on the server side processing.
Hope this helps.
Gil
Hello all.. since this is an older forum post, I"m just wondering if it is still the case that a request attribute cannot be based off of a JSON or SOAP/XML request body?
It still applies to this day - and likely will for the foreseeable future. I guess this is a deliberate design decision as to limit the OneAgent overhead on the monitored process because that would mean it would have to parse the request body (which could be potentially huge).
Request bodies are still a performance issue, so we still do not support this. The best option is (still) to find a method that accesses the data of interest and capture the argument or return value.
Hi,
You may want to investigate business events to solve your use case
Blog:
https://www.dynatrace.com/news/blog/the-value-of-business-events-how-it-can-increase-business-agilit...
Observability clinic
https://www.youtube.com/watch?v=a5Kp3WJ8NHU&list=RDCMUCcYJ-5q_AfmjQ4XTjTS0o3g&index=4
FYI: @DanielMarschnig