Prefix

In the first and second (not the third!) option, the variables of the calling profile are passed to the called profile. However, the prefix MSG_CALL_ is added. However, the prefix is added only once. A variable name with a prefix MSG_CALL_MSG_CALL_ will never be created.

In the third option (see there), variables can be set via HTTP request headers.

Variables are also passed to called sub profiles.

Access

The subsequent profile can only access these variables (from phase 1) if they have been defined there. If profile 1 has a variable var__Test, the variable MSG_CALL_var__Test is passed on and profile 2 must define a variable MSG_CALL_var__Test in order to be able to access the content of the variable. The variable names are case-sensitive.

If the mapping is deactivated in the subsequent profile, variables are not defined either. Thus, none of the values of the calling profile's variables can be accessed. If the variable values in the subsequent profile are needed nevertheless without a mapping being required there, the following steps should be taken.

• Activate the mapping in the subsequent profile.

• Create a dummy mapping (e.g. one field).

• Use the content type as received in the Response Routes of the subsequent profile. The target tree created in the mapping will then be ignored.

Name Conflicts

If a variable is to be forwarded via multiple profiles by Message, care should be taken to ensure that all subsequent profiles do not use any variable names that are used by one of the preceding profiles, since the prefix MSG_CALL_ can result in name conflicts and incalculable behaviour during the initialisation of variables in subsequent profiles.

Example: Profile 1 calls profile 2, which in turn calls profile 3. In profile 1, there is a variable Count, which is passed to profile 2 as MSG_CALL_Count. If there is also a variable Count in profile 2, the variable MSG_CALL_Count is passed on to profile 3 twice (and possibly with different values). Once the variable MSG_CALL_Count created in profile 2 (to access the passed on variable from profile 1) and then the variable Count created in profile 2 with the added prefix MSG_CALL_.

Profile Restart

If a profile that has received variables from another profile is restarted, these variables are available because they are stored in the metadata. See also section Metadata Editor.