LoadRunner Correlation Techniques: Handling Dynamic Values

Just like JMeter, a LoadRunner script recorded against an application that generates session tokens, CSRF tokens, or dynamic IDs will fail on replay unless those values are correlated — captured from one response and substituted into later requests instead of being replayed as the stale, hardcoded values the recorder captured.

Automatic correlation during recording

VuGen can attempt automatic correlation during recording, using built-in or custom correlation rules that recognize common patterns (e.g. ASP.NET VIEWSTATE, common session ID patterns) and substitute them automatically. This catches a meaningful chunk of cases for well-known frameworks, but rarely catches everything — application-specific dynamic values (an order ID returned from a “create order” call, a custom token) usually need manual correlation.

Correlation Studio

LoadRunner’s Correlation Studio scans a recorded session, highlights values it suspects are dynamic (by comparing repeated recordings or by pattern heuristics), and lets you apply correlation rules visually rather than hand-writing web_reg_save_param calls for every case. This is the more approachable entry point for less experienced scripters, though it’s still worth understanding the manual approach underneath it.

Manual correlation with web_reg_save_param

The core manual technique uses web_reg_save_param (registered before the request whose response contains the value) to capture a value into a parameter, using left/right boundary strings or a regular expression to locate it:

web_reg_save_param("sessionToken",
    "LB=\"token\":\"",
    "RB=\"",
    LAST);

web_submit_data("login", ...);

// later requests reference {sessionToken}
web_submit_data("getProfile",
    "Body=token={sessionToken}",
    LAST);

The captured value is referenced later as {sessionToken} (curly braces, distinct from JMeter’s ${...} syntax but conceptually identical).

JSON responses: web_reg_save_param with JsonPath

For JSON APIs, the same web_reg_save_param function supports JSON path-based extraction (depending on LoadRunner version, sometimes via a dedicated JSON-aware variant) rather than relying purely on left/right boundary text matching — more robust against formatting differences, same principle as preferring JSON Path extractors over regex in JMeter.

Validating correlation worked

After applying correlation, always re-run Replay and check the generated log for the parameter’s captured value — VuGen’s execution log shows what each parameter resolved to at runtime, which is the fastest way to confirm a correlation rule actually captured the right value rather than silently capturing nothing (and falling through to whatever default/empty value masks the failure).

Handling correlation across multiple possible matches

If a value could appear multiple times in a response, web_reg_save_param’s Ordinal parameter (similar to JMeter’s Match Number) selects which occurrence to capture — explicit about this rather than assuming the first match is always the right one.

Takeaway: Correlation Studio automates the common cases, but understanding web_reg_save_param directly is what lets you fix the application-specific dynamic values it won’t catch on its own — exactly the cases that matter most for your specific application.