Use Expressions in the HTTP Poke and Get External Data Handlers

Expression Language is supported in the HTTP Poke and Get External Data handlers in these fields:

Header

The Header section supports the following expression types:

  • Service variables
  • Service collection variables
  • User variables
  • User service collection variables
  • Any valid expression already supported in MEP

An entire Header cannot be defined using a single expression or variable. When using an expression in a Header, any of the following formats are supported:

  • Define every line with ${EL.expression}. Here the expression uses a expression/value pair to define the expression. For example, this might be ${servicecoll.contentX}, which defines the header as an expression for Content-type: application/xml. In the Header section this would appear as:

  • Using Header text and an expression in the format Header Name: ${EL.expression}. For example, this might be the Header text Content-type, and the expression $(servicecoll.type} for JSON support. This would then appear in the Header as:

  • Using an expression and a Header Name using the format ${EL.Header Name}: Value. In this example, the expression is ${servicecoll.contentT} , and the value : application/json added directly into the service:

  • Define the colon (:) , quotes surrounding a string (" "), or both, as part of the expression using the format Header Name$[EL.expression}. This example shows an expression with the Header name content-type, and the string ": application/json" represented by ${servicecoll.typeS}:

  • As two expressions using the format ${EL expression}: ${EL expression}. In this example, the Header is composed of the expressions ${servicecoll.contentT} and ${servicecoll.type}:

If an expression is not correct, the request will not be processed. In addition, if X-Request-ID is passed in the Header as a variable, the handler will ignore any passed value as the ID is auto-generated by the service.

Duplicate headers

If duplicate expressions are passed in the header, the value of the last expression is used. In the following example, an end point is defined for the service to expect JSON formatting. You add the variables ${service.headertype}, where the header type is application/json, but also add content-type: application/XML:

Because content-type: application/XML was added last to the header, this is the content-type that's sent. However, the service is expecting the format to be in JSON. The request then fails because of the mismatch between the format expected by the end point (JSON) and the format sent in the header (XML). If however, by reversing the information in the header, the request will succeed:

The end point expects JSON, and the request sends a JSON format since ${service.headertype} was processed last.

Note: For a list of the supported header fields, see "Supported header fields" in Creating an HTTP Poke or Get External Data Handler.

Body

The Body section supports the following expression types:

  • Service variables
  • Service collection variables
  • User variables
  • User service variables
  • User service collection variables
  • Any valid expression already supported in MEP

Mixing an expression and plain text is allowed.

Note: Because the space to define an expression in the Header and Body fields is limited, it is recommended to first write your expression using a text editor and then paste that expression in the applicable field. This allows you to more thoroughly review the expression for any possible errors.

User

You can use only one expression to define the User name. That is, you can only use one variable. For example, this could be ${userservicecoll.name}. If you attempt to pass more than one variable, an error message is returned: "This field only allows the use of one expression".

The User field also does not allow any beginning or ending characters to the expression. For example, if you precede the expression with any characters, like abcd${userservicecoll.name}, an error message is returned.

Custom Authorization

Custom Authorization can be defined within a variable. The length of a single variable can be up to 255 characters long; if the length is longer than this limit, you will need to split the custom authorization into multiple variables. For example, the following shows multiple custom authorization expressions for a Get External Data handler: $[service.custom]${servicecoll.long}${servcecoll.headerinvalid}.

Custom Authorization supports the following expression types::

  • Service variables
  • Service collection variables
  • User variables
  • User service variables
  • User service collection variables
  • Any valid expression already supported in MEP