Variables in DataPower

Variables

To use a variable, you can create it with an XSLT extension function or a script (such as the set variable action) or with GatewayScript programming. This action creates a variable in a specific context and assigns a value.

You can use variables in most context, except PIPE.

Note: You can view the variable values for a transaction with the probe. Edit the DataPower® service to enable the probe. After you enable the probe and recording transactions, you can view variables and their values.

There are the following distinct variable types, each expressed in the var://URL format and GatewayScript format, as appropriate.

var://local/variable

A local context variable to address a variable that is called variable in the default (current) context. The following example transforms the document in the tmp1 context with a style sheet. The style sheet is referenced by the stylesheet-1 variable (also in the tmp1 context) and stores the transformed document in the tmp2 context:

xform tmp1 var://local/stylesheet-1 tmp2

The local context does not persist beyond the scope of the transaction. A transaction can include both a request component and a response component. The local context cannot be accessed by any object outside the scope of the transaction. In other words, a service cannot read and use the variable.

A local context variable can be user-defined or based on an extension variable.

var://context/context/variable

Addresses a variable that is called variable in a context called context. The following example transforms the document in the tmp1context with a style sheet. The style sheet is referenced by the stylesheet-1 variable (in the apple context) and stores the transformed document in the tmp2 context:

xform tmp1 var://context/apple/stylesheet-1 tmp2

A named context does not persist beyond the scope of the transaction. A transaction can include both a request component and a response component. The local context cannot be accessed by any object outside of the scope of the transaction. In other words, the service cannot read and use the variable.

Note: Creating variables in a named context is the preferred approach. This form decouples the variable from the input and output contexts and allows the variable to be accessed from any step in a scope.

A named context variable can be user-defined or can be based on an extension variable.

var://service/variable

Addresses a variable that is made available to a DataPower service that is attached to a session.

Many service variables are supported in XSLT and GatewayScript . For example, the variable skip-backside has the XSLT formvar://service/mpgw/skip-backside and the GatewayScript form mpgw.skipBackside. The term "slash notation" refers to the XSLT name form and the term "dot notation" refers to the GatewayScript name form. GatewayScript variables that are not supported do not appear in the syntax section of the description of the variable.

Calls to GatewayScript variables support both forms of names. A program that uses the dot notation form establishes access to the service variables in two steps: requiring the module that holds the service variables (service-metadata) and setting a variable to access the variables. For example:

 var serviceVars = require ( 'service-metadata' ); // import the service variables functions
 serviceVars.mpgw.skipBackside = true;             // write to the skipbackside service variable

In the information for each variable that is supported by GatewayScript, the specifications assume a require statement (var serviceVars=require ('service-metadata')) already established access. You must establish access to the service metadata by using a require statement in your code (naming serviceVars or other variable) to manipulate the use service variable. The skipBacksidevariable call uses serviceVars.

A GatewayScript program establishes access to an XSLT service variable by using the slash notation name form in getVar and setVarfunction calls. For example:

var genPattern = serviceVars.GetVar("var://service/wsa/genpattern");

Both these name forms are listed in the function information where both are supported. When the GatewayScript name form is not in the list, the GatewayScript form is not supported. GatewayScript checks the data type when a new value is assigned to a service variable. The gettermethod returns a value with the correct data type.

var://system/variable

Addresses a global variable that is available in all contexts. System variables persist beyond the scope of request-response processing and can be read by other objects on the appliance. If the content of a variable needs to be read or set outside the scope of request-response processing, use a system variable.