IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

EVAL function

The EVAL function takes a character value and interprets that value as an ESQL expression that returns a value.

For details of the EVAL statement, see EVAL statement.

Syntax


>>-EVAL--( SQL_character_value )-------------------------------><

EVAL takes one parameter in the form of an expression, evaluates this expression, and casts the resulting value to a character string if it is not one already. The expression that is passed to EVAL must therefore be able to be represented as a character string.

User defined functions cannot be defined within an EVAL function but EVAL can be used to call a user-defined function that is in scope where the EVAL function is used.

If you use the EVAL function to call out to a user-defined function that is not called from anywhere else in the ESQL for a given node, you need to add the following code to your ESQL, to ensure that the user-defined function being called is included when the code is compiled:

   IF (FALSE) THEN CALL function(<parameters>) INTO Environment.temp; END IF;

Note, that in the preceding example, you must replace function() with the name of the function in question.

In the following examples, A and B are integer scalar variables, and scalarVar1 and OperatorAsString are character string scalar variables.

The following examples are valid uses of EVAL:

SET OutputRoot.XMLNS.Data.Result = EVAL(A+B);
The expression A+B is acceptable because, although it returns an integer value, integer values are representable as character strings, and the necessary cast is performed before EVAL continues with its second stage of evaluation.
SET OutputRoot.XMLNS.Data.Result = EVAL('A' || operatorAsString || 'B');
EVAL('SET ' || scalarVar1 || ' = 2;');
The semicolon included at the end of the final string literal is necessary, because if EVAL is being used in place of an ESQL statement, its first stage evaluation must return a string that represents a valid ESQL statement, including the terminating semicolon.

The real power of EVAL is that it allows you to dynamically construct ESQL statements or expressions. In the second and third examples above, the value of scalarVar1 or operatorAsString can be set according to the value of an incoming message field, or other dynamic value, allowing you to effectively control what ESQL is executed without requiring a potentially lengthy IF-THEN ladder.

However, consider the performance implications in using EVAL. Dynamic construction and execution of statements or expressions is necessarily more time-consuming than simply executing pre-constructed ones. If performance is vital, you might prefer to write more specific, but faster, ESQL.

The following are not valid uses of EVAL:

SET EVAL(scalarVar1) = 2;
In this example, EVAL is being used to replace a field reference, not an expression.
SET OutputRoot.XMLNS.Data.Result[] = EVAL((SELECT T.x FROM Database.y AS T));
In this example, the (SELECT T.x FROM Database.y) passed to EVAL returns a list, which is not representable as a character string.

The following example is acceptable because (SELECT T.x FROM Database.y AS T) is a character string literal, not an expression in itself, and therefore is representable as a character string.

SET OutputRoot.XMLNS.Data.Result[]
 = EVAL('(SELECT T.x FROM Database.y AS T)');

ak05025_.htm |

Last updated Friday, 21 July 2017