Is there a way to mark User Actions that execute certain update DB statement ?

[Yosi_Neuman]

Hi guys,

Customer asks to mark user actions that eventually execute a certain BD update.

We can see from DB statement back-trace the UA but this UA sometimes call the update and sometimes not, and customer wants to track down only the UA that do call to the DB update statement.

The question is if we can create a RA from the service perspective that is calling the DB or some other way you think of?

Thanks in advance

Yos

[zietho]

Do I understand you correctly that you want to more or less tag a PurePath when a logical services and RUM (user actions) combination occurs. Both individually are possible. And yes request attributes (RA) can be used on both sides. So whenever you DB request results in an update setting the RA to "true" would (at least on the RUM side I know) provide you with a respective tag on RUM screens that can be used to segment user actions accordingly.

I.e, you should then be able to see only aggregated data for e.g., user action: abc where update the action property with true was applied - i.e., where update statements happened.

[Yosi_Neuman]

Hi @Thomas Ziegelbecker

Your over view is correct, but we have some obstacles on the way.

In our case the very same UA can some times fire web request to server side (i.e. service) just with select DB actions and some times also update DB actions are added.

Is there a way to create RA on server side that will split the service calls by "select with out update" and "select with update"?

Thanks in advance for your input

Yos

[zietho]

Asked my server side counterpart. He told me that might be feasible by setting/defining an "object value" for the RA, since SQL queries aren't supported as an input.

[AntonioSousa]

@Thomas Z.,

Does this mean I can make an USQL query about certain User Actions, where in their Purepath exists a certain service call that has a specific Request Attribute?

[zietho · Accepted solution]

you can make a USQL with a user action having a certain action property. That action property can have a "server-side request attribute" defined as a source. Which can be the same as the one assigned on the service request for the DB. The only thing that I don't see here is how you can easily drill down from USQL in particular to PP.

But the information would then reside both, on the user action and the service, which allows you to drill down as soon as you have found an action/service with such attributes assigned. And it allows you - again I can only speak for the RUM side - filter your actions to only look at the ones where a flagged DB statement happened, given that you defined the server-side request attribute properly.