WS-M does not capture Multi Protocol Gateway services payloads
This limitation is derived from a limitation of the monitored device.
Known workarounds: The customer can manually modify the services to include a formatter, or use DPOD's custom logging mechanism to add payload data to the transaction details. Please contact support for more details.
Time zone differences between the browser and the server result in unexpected time displayed in UI Console
When the time zone of the browser is not the same as the server, time displayed in UI Console might belong to either time zone, resulting in inconsistent display. For example, a user might select a time range of 09:00-10:00 but see a chart that displays the data of 11:00-12:00 instead.
Known workarounds: Use the same time zone in the browser and the server.
Transactions under Default domain are not monitored
This limitation is derived from a limitation of the monitored device. Log targets defined at the Default domain collect all logs from all domains, and currently there is no available filter on the log targets to filter out logs from other applicative domains.
Known workarounds: There is a workaround, but it only applies if the customer is willing to duplicate all network traffic or alternatively run transactions only on the Default domain. Please contact support for more details.
Payload size does not include response size (only request size)
At present, monitored devices do not report the front end response payload size. Nor do they report on the backend request and response.
Known workarounds: None.
Error is not displayed in "Extended transactions"
The extended transaction is the only feature of DPOD that involves instrumentation of XSLT transformation to the Web Service Proxy policy (request / response and error rules).
The instrumentation is integrated by the system only when initiated by the system administrator and not by default.
when an error is being raised but the service (WS-Proxy) the following situation are possible :
- No error rule in the service that the error is being raised on and previous services are configured with "Process HTTP errors = on"
Since there is no error rule, an extended transaction log record is not being generated and there for the error is not displayed in "extend transactions" screen.
The extended transaction will look similar to the following (you can see that one record is missing) :
- No error rule in the service that the error is being raised on but previous services do have error rule configured
Since there is no error rule, an extended transaction log record is not being generated and there for the error is not displayed in "extend transactions" screen.
Previous services do have error rule so the "extend transactions" screen will look similar to the following :
