We have a front-end that cannot be instrumented connecting to a back-end that is instrumented. A single 'user action' can generate many requests to the back-end, but dT treats every request that is part of that transaction exactly the same. When dT aggregates information about a LR transaction, it treats EVERY request equally. So I could have one backend request that takes 100ms, and another that takes 900ms, and the average for that tagged transaction is 500ms.
I thought that setting the ID in the Request Header would resolve this issue (see Grouping Multiple Tagged Requests Together) but it seems that the ID isn't used for anything other than linking specific transactions between tools.
Am I correct in assuming that setting the ID won't help me, or does DT actually use it to determine what a single transaction really is?
The ID field by default will only show up in the details of the purepath. But - what you can do is create a Business Transaction that splits by the ID Field. Simply create a Business Transaction and use the Tagged Web Request Measures as split measure. This measure allows you to specify which value of the incoming tag (ID, NA, PC, ...) it should return which is then used for the split
Thanks firstname.lastname@example.org. We did this working with our support guy. It isn't quite what we were asking for, since DT doesn't really treat that set of related PurePaths as a unique entity; and is limited to the max # of splits of a business transaction.
It does, however, provide a way to view the top x slow unique transactions, which is very helpful.
Looking at our conversation on RFE - Generic Performance API, there is the possibility that we can use the UEM API to create Page Actions that correspond directly to 'user action', and then correlate the individual requests to that Page Action.
I will continue to investigate the UEM API that is exposed and see if it can help us out.