Variables

A variable stores a value in MEP. Once a variable exists, the value can be read and updated. You can create your own variables, or use the built-in ones in MEP. For example, the following expression contains a built-in variable where the value is the end user’s mobile operator:

${user.identifiers.msisdn.network}

Variable syntax

Variables are comprised of a scope and key, separated by a dot:

scope.key

The scope defines what the variable relates to and where it is available. Depending on its scope, a variable’s value can be shared within a single service, or can be a different value for each user. The key gives the variable a name to reference it by.

For example, in these variables:

user.identifiers.msisdn
user.identifiers.msisdn.network

The scope, user, tells MEP that the variable is a property of the end user. The first example’s key, identifiers.msisdn, refers to an end user’s mobile phone number, while the second example’s key, identifiers.msisdn.network, refers to the mobile operator through which the phone number is connected.

Variables can use any character between A-Z, the underscore character "_", and hyphen character "-". Variables are not case-sensitive. The key can also include a dot, for example:

${session.initialKeyword.name}

The scope in the previous example is session, while the key is initialKeyword.name.

Scope

The scope defines the range of an individual instance of a variable and where it is available. It impacts how the variable works and determines how many instances of a variable could exist. Depending on its scope, a variable’s value can be associated with:

  • A single service or multiple services
  • Part of a session or request
  • Each individual end user
  • MEP generally

For example, if the scope is userservice, then each separate end user has their own value for the variable stored for their use of a particular service. However, if the scope is service then the entire service only has one value stored for the variable. The next diagram shows the range of three related scopes: service, session, and request.

Diagram showing how the service, session, and request scope relate to one another

Built-in variables

Built-in variables provide access to commonly used service and user information, such as a user's mobile number, the body of a text message, or a unique ID. Unlike custom variables, you do not define any properties of a built-in variable; they are ready for use in your service immediately.

The two variables, user.identifiers.msisdn and user.identifiers.msisdn.network, are both examples of built-in variables. You could use these variables to send an end user their own details in an SMS. The text in a service handler would look like:

Your mobile phone number is ${user.identifiers.msisdn} and your network is ${user.identifiers.msisdn.network}.

An end user in the UK would receive text similar to this:

Your mobile phone number is 447700900760 and your network is TMOBILEUK.

Other built-in variables do tasks such as provide time and date data, or identify content in the body of SMS messages.

Note that the scope and key combinations specifically work only for the built-in versions. For example, you cannot use "request.identifiers.msisdn" as a built-in variable as MEP does not recognize this combination.

Custom variables

Within a service, you can create and use custom variables. They enable you to:

  • Define your own values that you can dynamically change (e.g. the number of times a service is accessed)
  • Hold the value of another expression that you might want to reference later (e.g. a PIN generated by a function).
  • Reference data retrieved from another platform by the Get External Data handler

For example, to reference a PIN generated by the function generatePin(integer,Boolean) multiple times in a service, you will need to create a custom variable to hold the value.

You can also upload custom user variables in the Subscriptions tab and in the Broadcasts tab.

Reserved words

The following words are reserved by EL and should not be used as variable names:

and

div

empty

eq

false

ge

gt

lt

instanceof

le

mod

ne

not

null

or

true

Also note that you cannot create new variables that branch from the user.identifiers set of user variables (e.g. user.identifiers.xxx). When creating your own custom variables, make sure that you do not use the same name as an existing built-in variable — for a full list, see the Built-in Variables Index.