PATH clause

The PATH clause specifies a list of additional schemas to be searched when matching function and procedure calls to their implementations. The schema in which the call lies is implicitly included in the PATH clause.

The PATH clause is used to resolve unqualified function and procedure names in the tools according to the following algorithm.

A single function or procedure must match the unqualified name, or the tools report an error. You can correct the error by qualifying the function or procedure name with a schemaId:
  1. The current module (if any) is searched for a matching function or procedure. Module-scope functions or procedures are visible only within their containing module. If functions or procedures with the same name are found in the current module and schema, module-scope functions or procedures take precedence over schema scoped functions or procedures.
  2. The <node schema> (but none of its contained modules) and the <SQL-broker schema> or schemas identified by the PATH clause are searched for a matching function or procedure.
Note: The schemaId must be a fully qualified schema name.

When you start a function or procedure, the name that you use must be qualified by the schema name. The behavior depends on the circumstances:

For a module routine:
  • If the schema is specified, the named schema routine is started. The scalar built-in functions, excluding CAST, EXTRACT, and the special registers, are considered to be defined within an implicitly declared schema called SQL.
  • If the schema is not specified, and the calling statement is in a module routine, and a routine of the given name exists in the local module, then that local routine is started.
  • If the schema is not specified, and the calling statement is in a module routine, and a routine of the given name does not exist in the local module, then all of the schemas in the schema path are searched for a routine of the same name.

    If a matching function exists in one schema, it is used. A compile-time error occurs if a matching function exists in more than one schema. If there is no matching function, then the schema SQL is searched.

    This rule and the preceding rule imply that a local module routine takes priority over a built-in routine of the same name.

For a schema routine:
  • If the schema is specified, the named schema routine is started. The scalar built-in functions, excluding CAST, EXTRACT, and the special registers, are considered to be defined within an implicitly declared schema called SQL.
  • If the schema is not specified, and the caller is a schema routine, and a routine of the given name exists in the local schema, that local routine is started.
  • If the schema is not specified, and the calling statement is in a schema routine, and a routine of the given name does not exist in the local schema, then all of the schemas in the schema path are searched for a routine of the same name.

    If a matching function exists in one schema, it is used. A compile-time error occurs if a matching function exists in more than one schema. If there is no matching function, the schema SQL is searched.

    This rule and the preceding rule imply that a local schema routine takes priority over a built-in routine of the same name.

The <node schema> is defined as the schema containing the node's message flow.

The <node schema> is specified in this manner to provide compatibility with earlier versions of IBM® Integration Bus.

When the <node schema> is the only schema referenced, the integration node XML message does not include the extra features contained in WebSphere® Message Broker Version 6.1.

Integration nodes in previous versions of IBM Integration Bus do not support multiple schemas, for example, subroutine libraries for reuse. To deploy to an integration node in a previous version of the product, put all of the ESQL subroutines into the same schema as the message flow and node that start the ESQL subroutines.

Eclipse tooling uses WebSphere Message Broker Version 6.1 ESQL syntax in content assist and source code validation.

The broker schema of the message flow must contain, at the schema level, any of the following in its ESQL files:
  • A schema level function
  • A schema level procedure
  • A schema level constant
  • A module level constant
  • A module level variable

Without the presence of any of the preceding items, the Eclipse tooling generates integration node ESQL without module and funtion Main wrappers.

Function and procedure names must be unique within their schema or module.

Examples

The following example adds a path to a schema called CommonUtils:
BROKER SCHEMA CommonUtils
PATH SpecialUtils;

MODULE ....
The next example adds a path to the default schema:
PATH CommonUtils, SpecialUtils;

MODULE ....