Using CA Service Virtualization › Understanding CA Service Virtualization › Magic Strings and Dates › Magic Strings

Magic Strings

During the recording phase, VSE examines each request for arguments or parameters. For example, a weather forecasting web service call could include a city name or an airline booking system request could include a flight number. If the flight number is included in the recorded response, it is classified as a magic string.

For example, if VSE is in playback mode and a request comes in for a flight number that was never recorded, the correct flight number is included in the response.

In the following example, we recorded a request to set some "state" in the conversation, in this case the flight number (ABC53). The recorder recognized that the string ABC53 was also in the response, so it converted ABC53 to a magic string. The magic string is saved in the service image database as '=request_arg1;/ABC53/.

The {{ }} notation is a standard VSE property substitution syntax. This notation means "substitute the {{ }} text with the runtime value of the first argument of the request." If there is no first argument, use ABC53 as the default.

The practical significance is that if a future client requests flight ZZ99, the virtualized service responds with the correct flight number, ZZ99.

VSE detects magic strings not only in a simple request/response pair. If an argument is ever seen in any subsequent response in a conversation, VSE deems it to be magic and stores the argument value in the conversation state.

By default, VSE does not consider anything in an XML tag for magic strings. This exclusion includes XML tags, attribute names, and attribute values. You can change this behavior by setting lisa.magic.string.xml.tags=true in the local.properties file, in which case normal magic string rules apply.

In other words, if you have <foo bar="baz"/>, none of that is considered for magic strings. By contrast, if the structure is <foo>bar</foo>, then "bar" (but not "foo") is considered for magic strings.

The following example is later in the previous conversation. The request operation is "itko_seat" and the single argument is a name, in this case "Person1". The response contains the name in the request, the previously set flight number and a date.

This is the canonical example of conversational state over a stateless protocol, in this case SOAP over HTTP. If the VSE in playback mode sees a request to set the flight to ZZ99 and then a request to seat PersonSomeoneElse, then the correct string, "Seated PersonSomeoneElse on seat 1 of flight ZZ99" is included in the response, even though those details were never recorded.

VSE does not regard the seat number, 1 in this case, as a magic string. The seat number was never seen in the original series of requests that led to this response. Nor is it large enough to be regarded as a magic string. A magic string must be at least three characters long and optionally have whitespace on the left, right, or both sides of the string. You can adjust the length and whitespace parameters in the local.properties file.

The {{ }} property notation is powerful and flexible and is not confined to using magic strings. For example, we could change the "1" in the response in the example to "DataSetValue" and could define a data set in the virtual service model. Then that data set is used to generate the runtime response value. The data set could be a random string generator, a counter, a call to a database, a reference to an Excel spreadsheet row, or anything. }} can execute arbitrary Java code and even generate realistic "everyday" data such as a valid credit card number {{=[:Credit Card:].

For more information, see "Using BeanShell in DevTest" in Using.