LoadRunner Protocols: Choosing the Right One for Your Application

LoadRunner’s protocol selection, made when creating a new VuGen script, has more lasting consequences than the equivalent decision in most open-source tools, because it determines the entire scripting API and recording behavior available afterward.

Web - HTTP/HTML: the default for web applications

Covers standard web applications, recording at either the HTML level (higher-level, more resilient to certain page changes) or URL level (lower-level, more granular). This is the right starting point for the large majority of modern web app and REST API testing — equivalent in scope to what JMeter, k6, or Gatling test by default.

Citrix

For applications delivered via Citrix virtual desktop/app infrastructure, where the client only receives screen updates rather than direct HTTP traffic. Citrix protocol scripts interact at the level of UI coordinates, bitmap recognition, or (where supported) accessible UI object identification — fundamentally different from HTTP scripting, and notably more fragile to UI layout changes since it’s often working with visual/positional matching rather than structured data.

SAP (GUI, Web, Click & Script)

SAP environments have their own protocol family depending on whether the SAP client is the classic SAP GUI, a web-based Fiori/NetWeaver interface, or another variant. Misidentifying which SAP delivery mechanism you’re actually testing is a common early mistake — confirm with whoever owns the SAP environment before scripting.

Database protocols (Oracle NCA, generic ODBC/JDBC-style testing)

For database-layer load testing rather than application-layer, similar in purpose to JMeter’s JDBC sampler covered earlier in this series, though LoadRunner’s specific protocol options vary depending on the target database technology.

Mainframe / terminal emulation

For applications still accessed via terminal emulation (3270/5250 style), a protocol category that has essentially no open-source equivalent — one of the clearest cases where LoadRunner’s protocol breadth alone justifies its use, since modern open-source tools have no comparable support.

Multi-protocol scripts

Some real-world flows span multiple protocols (a web front-end that triggers backend calls you also want to validate via a database protocol) — VuGen supports combining multiple protocols within a single script for these cases, rather than forcing every script to be strictly single-protocol.

A decision checklist

1. What does the client actually talk to — a web server directly, a virtual desktop, a specialized middleware? That answers the protocol family.
2. Is there a lower-level API/protocol underneath a thick client that would be more stable and more representative to script against than UI-level interaction (often true for Citrix-delivered web apps, where testing the underlying HTTP traffic the Citrix session itself generates may be more useful than testing screen-level interaction)?
3. Does the flow span multiple protocols, requiring a combined script?

Takeaway: getting the protocol choice right before recording avoids the much more expensive mistake of discovering, after significant scripting investment, that you recorded at the wrong layer for what you actually needed to test.