cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Help With Mobile Application Instrumentation and USQL

benjamin_mullan
Visitor

Help With Mobile Application Instrumentation and USQL

Hello.

This is a question about correct implementation for Mobile Apps and a USQL query about how we have currently implemented it.

We have an App that loads a dashboard which has a number of widgets that load inside it e.g

  1. Dashboard - Ok
    1. Widget 1 - Ok
    2. Widget 2 - Ok
    3. Widget 3 - Failed/Something went wrong

The Dynatrace detected user action is pretty good and will pick up the user action (but not the widgets as actions) so we only get failures in the useractions for network requests but not the UI components when they go into a failure state, and subsequently no telemetry around those widget loads times.

We then attempted a custom user action which starts a dashboard load and creates sub-useractions(?) for each widget. This also has named events for each action with a success or failure+message outcome. Progress!

dt2.png (couldn't embed this one)

However while the Dashboard_load actions is available in the useraction table in USQL the children actions are not. I had a chat to chat support and they provided a query joining usersession and useraction but the returned data was all arrays and didnt seem workable for me.

  1. What would be the appropriate implementation to record UI failure states regardless of the network calls response status
    1. Do/can we supplement the dynatrace detected user action with the child actions like the second screen shot.
    2. Can you stitch these sub actions to the associated network request
  2. How do we query the data we want in USQL. Ideally I want each widgets load times (avg) and the amount of errors vs success on a dash board.
1 REPLY 1

thomas_billi
Dynatrace Helper
Dynatrace Helper

Did you try to manually report an error for the widgets? What is the reason for the fail, a web request?

You could try to fully disable auto-instrumentation for the classes that are involved and only create User Actions for each widget, so that they are at the top-level of the session. This should make the investigation much easier.