Separate nesting of the XHR actions individually

[Suryanto_1]

we have discovered that some applications will trigger multiple XHR Urls in a single click, The multiple XHR urls will then select one XHR as the main user action and the rest will be nested as a sub-action, and the ones registered as sub-actions can't be queried using the USQL.

This causes issues as the XHR url we are identifying to use as the end of transaction is not recorded as the main user action and cannot be queried using the USQL. We've managed to find a workaround which is to exclude certain URLs using XHR exclusions. But that might be an issue if there are 4-5 XHR urls triggered in a single click action.

How does Dynatrace detect and identify which XHR Url to use as the main user action? It may not be feasible to be excluding all the URLs in case we ever need the metrics for performance monitoring.

As the workaround may not be ideal as a long term solution, is there an alternative configuration/method that we can use to separate the XHR actions in the user sessions?

[marina_pollehn]

Can you show an example of a user action and the sub-actions? 

For example if they have different domains you can use the advanced configuration option and get different actions per domain.

[Suryanto_1]

The Multiple XHR Urls in a single click example is as follows.

It could be an external site not just an internal site.

Please advice how to configure the user actions in the specific application

XHR Request

/extensions
https://VWXYZ.ABCDE.FGH/TUVWXYZ/api/v1/extensions 

/Tealeaf?1234567890123
https://ABCDE.FGH/ABC/ABC-servlets/Tealeaf?1234567890123 

/new
https://Complete.new.unrelevant.site/ab.cdef/cs1 

[Julius_Loman]

Hi @Suryanto_1, 

you mention multiple XHRs in "a single click" - this pretty much means it's a single user action (XHR user action unless it does full page load), despite many XHR requests being triggered within the action. Real user monitoring's purpose is to capture user perception and experience, thus it's designed to capture the user activity (actions) and attach the individual requests. You need to distinguish between XHR user actions and XHR requests.

If for some reason to change the behaviour of how the user actions are structured, there are multiple methods depending on your goals and your application code, most likely you will need to use RUM JavaScript API. 

[Suryanto_1]

XHR user actions trgger multiple XHR requests. The request can be various internal or external links.

The multiple XHR urls will then select one XHR as the main user action and the rest will be nested as a sub-action.

How does Dynatrace detect and identify which XHR Url to use as the main user action?

Can those registered as sub-actions can be queried using the USQL? As per our testing this isnt possible.

We are trying to calculate the TCR. It causes issues as the XHR url we are identifying to use as the end of transaction

It is not recorded as the main user action and cannot be queried using the USQL. This is not something in-build? 

[Julius_Loman]

You define your user action name (this can be accomplished for example by the user action naming rules which @marina_pollehn mentions, by setting it explicitly from the RUM JS Api or also by other means). This is just a name of the user action, and typically it should describe the activity user is performing. (e.g. Purchase order) not the individual XHR request name, which can depending on the situation also fit.

With USQL you cannot query waterfall detail, it's designed for session data segmentation and analysis (more targeted for the business persona). For detailed request analysis there are other options within Dynatrace.

I don't know what do you mean by TCR, can you please elaborate more on the desired outcome? (Preferably including screenshots from your user actions).

[IzabelaRokita]

Thank you @Julius_Loman for your answers! Did you find the solution for your issue here @Suryanto_1 or do you require some further guidance? 🙂

[Suryanto_1]

Understand that USQL cannot query waterfall detail

Currently a single XHR action (user action name - internal1)

>> request (internal resource) internal1
>> request (external resource) wwww.aaaaa.com
>> request (external resource) bbbbb.xyz

We want it to become 3 XHR action so that we can query the action using USQL

XHR action (user action name - internal1)
XHR action (user action name - wwww.aaaa.com) (assuming e.g. Purchase order)
XHR action (user action name - bbbbb.xyz) (assuming e.g. Inventory)

Using the "User action naming rule" please advice what should we be configuring.

The following are all enable by default.

- Split user actions by domain
- Case insensitive naming
- Prioritize load actions and use value of last

[Julius_Loman]

As I stated previously - you are mixing XHR actions and XHR requests. RUM is designed for capturing activity, so it captures user actions. 

Your user performs one activity - a single click which results into 3 XHR requests. Probably the only way to separate that into 3 user actions would be to call the RUM API in your application code when those (at least two) XHR requests are fired. This cannot be accomplished by user action naming rules or standard RUM configuration.

[Suryanto_1]

This is what we have for now. Everything appears to be default.

Please give example on how to configure to meet the above requirements. Thanks!

[Suryanto_1]

The RUM API link you given point to "Create custom user action names for web applications"

https://docs.dynatrace.com/docs/platform-modules/digital-experience/web-applications/initial-setup/c...

The configuration above seems to be all in the GUI - application settings. Where does the JavaScript API come in place?

[Julius_Loman]

@Suryanto_1 you still don't get the point. You cannot "split" a single user action into multiple actions using just Dynatrace configuration. You need to use other means such as dtrum API to create multiple user actions if that is your goal. You need to change your application to use the JavaScript API to create custom actions from your code. 

RUM is based on user action. One click is a single user action unless you change the behaviour by calling the JavaScript API from your web application to modify how the action is detected and reported back.