NAME and NAMESPACE

NAME

Use NAME to define an alias (an alternative name) by which a variable can be known.

Example 1:

-- The following statement gives Schema1 an alias of 'Joe'.

DECLARE Schema1 NAME 'Joe'; 

-- The following statement produces a field called 'Joe'.

SET OutputRoot.XMLNS.Data.Schema1 = 42;

-- The following statement inserts a value into a table called Table1

-- in the schema called 'Joe'.

INSERT INTO Database.Schema1.Table1 (Answer) VALUES 42;

Example 2:

-- At Module scope define ColourElementName and set it external

-- so that its default value of 'black' can be overridden as a UDP 

DECLARE ColourElementName EXTERNAL NAME 'black';

-- Use the ColourElementName in a function

CREATE FIRSTCHILD OF OutputRoot.XMLNSC.TestCase.ColourElementName

                     Domain('XMLNSC')

                     NAME 'Node1' VALUE '1';

If the owning message flow has been configured with a UDP named ColourElementName of type String, which has been given the value red, the following output message is generated:

<xml version="1.0"?>

<TestCase>

  <red>

    <Node1>1</Node1>

  </red>

NAMESPACE

Use NAMESPACE to define an alias (an alternative name) by which a namespace can be known.

Example:

This example illustrates a namespace declaration, its use as a SpaceId in a path, and its use as a character constant in a namespace expression:

       DECLARE prefixOne NAMESPACE 'http://www.example.com/PO1';

       -- On the right hand side of the assignment a namespace constant

       -- is being used as such while, on the left hand side, one is

       -- being used as an ordinary constant (that is, in an expression).

       SET OutputRoot.XMLNS.{prefixOne}:{'PurchaseOrder'} =

                      InputRoot.XMLNS.prefixOne:PurchaseOrder;

SHARED

Use SHARED to define a shared variable. Shared variables are private to the flow (if declared within a schema) or node (if declared within a module), but are shared between instances of the flow (threads). No type of variable is visible beyond the flow level; for example, you cannot share variables across execution groups.

You can use shared variables to implement an in-memory cache in the message flow; see Optimizing message flow response times. Shared variables have a long lifetime and are visible to multiple messages passing through a flow; see Long-lived variables.

Shared variables exist for the lifetime of the:

• Execution group process
• Flow or node, or
• Node ESQL code that declares the variable

(whichever is the shortest). They are initialized when the first message passes through the flow or node after each broker startup.

You cannot define a shared variable within a function or procedure.

The advantages of shared variables, relative to databases, are that:

• Write access is much faster.
• Read access to small data structures is faster.
• Access is direct; that is, there is no need to use a special function (SELECT) to get data, or special statements (INSERT, UPDATE, or DELETE) to modify data. You can refer to the data directly in expressions.

The advantages of databases, relative to shared variables, are that:

• The data is persistent.
• The data is changed transactionally.

These read-write variables are ideal for users who are prepared to sacrifice the persistence and transactional advantages of databases in order to obtain better performance, because they have a longer life than only one message and perform better than a database.

Because SHARED variables can be updated by multiple additional instances, you must ensure that you do not change SHARED variables that might cause unexpected results, for example, if the variable is being used as a counter.

As SHARED variables are initialized once on the first message through a node, it is possible to initialize a SHARED ROW variable once with the results from a Database query. The following code shows an example of this:

      CREATE SCHEMA testSchema

         DECLARE mySharedRow SHARED ROW;

         DECLARE initialized SHARED BOOLEAN myINIT();

 

         CREATE COMPUTE MODULE testModule

       

         CREATE FUNCTION Main() RETURNS BOOLEAN

         BEGIN

         SET OutputRoot.XMLNSC.Top.TEST.Result1 VALUE = initialized;

         SET OutputRoot.XMLNSC.Top.TEST.Result2 = mySharedRow;

       END;

     END MODULE;

     CREATE FUNCTION myINIT( ) RETURNS BOOLEAN

     BEGIN

         LOG EVENT VALUES('myINIT CALLED');

         SET mySharedRow.Top[] = SELECT A.MyCol1, A.MyCol2 from Database.Test AS A;

         RETURN TRUE;

     END;

You can prevent other instances seeing the intermediate stages of the data by using a BEGIN ATOMIC construct; see BEGIN ... END statement.

Your user program can make an efficient read, or write, copy of an input message in the input node by using shared-row variables, which simplifies the technique for handling large messages.

Restriction:

Subtrees cannot be copied directly from one shared row variable to another shared row variable. Subtrees can be copied indirectly by using a non-shared row variable. Scalar values extracted from one shared row variable (by using the FIELDVALUE function) can be copied to another shared row variable.