Idea ID: 2878136

Allow more freedom in transaction definition for SLA calculation

Status: Waiting for Votes

For now LoadRunner allows to define SLA for static transactions declared in Actions only (in Controller) or any reported transaction during the test in Results Analysis.

Using Analysis approach is inconvinuent as SLA has to be redefined for each test. SLA definition mechanism in Controller is very limited as it doesn't allow to 
define static transactions in include files (so even we have an option to reuse same logic in multiple scripts, transactions have to be redefined each time) and dynamic transactions at all. 

I propose to allow new transactions creation in SLA window of Controller in addition to identification of the existing on script (Action) level.
In this way both static transactions from include files and dynamic transactions which might be flow dependent could be defined once in Controller and used by Results Analysis. 
It will require from the user to know in advance exact transaction names but it is much more convinuent way for SLA calculation comparing SLA redefinition for each test in Analysis  tool.

Tags:

  • I like this idea. It would even be better when you could define transactions based on pattern (like regular expression syntax). One has then the issue of an actual transaction that matches multiple descriptions. A top to bottom matching would do. So you could end your list with a default pattern like ".*" and catch with those all other not mentioned transactions. Also excluding transaction names might be needed in this case. E.g. we use transaction names to expose version information from the software stack. E.g. a pattern like "!_version_.*" would exclude each transaction starting with "_version_"

    , VuGen uses a simple syntax parser to identify transaction names and rendezvous points. We tricked the parser to add those names in the Action inside #if 0 ...#endif  code blocks and then use the names in the includes. (But maybe you discovered that already).

    How to ask questions

    Reward contributions via likes or 'verified answers'