Broker schemas

A broker schema is a symbol space that defines the scope of uniqueness of the names of resources defined within it. The resources include message flows and other optional resources such as ESQL files, Java™ files, and mapping files.

The broker schema is defined as the relative path from the project source directory to the flow name.

You can create new broker schemas to provide separate symbol spaces within the same integration project. A broker schema is implemented as a folder, or subdirectory, within the project, and provides organization within that project. You can also use project references to spread the scope of a single broker schema across multiple projects to create an application symbol space that provides a scope for all resources associated with an application suite.

If you create a new broker schema while in category mode, the empty schema is not visible in the Application Development view. To show the empty schema in the Application Development view, click Hide Categories on the toolbar.

A broker schema name must be a character string that starts with a Unicode character followed by zero or more Unicode characters or digits, and the underscore. You can use the period to provide a structure to the name, for example Stock.Common. A directory is created in the project directory to represent the schema, and if the schema is structured using periods, further subdirectories are defined. For example, the broker schema Stock.Common results in a directory Common within a directory Stock within the integration project directory.

If you create a resource (for example, a message flow) in the default broker schema within a project, the file or files associated with that resource are created in the directory that represents the project. If you create a resource in another broker schema, the files are created within the schema directory.

For example, if you create a message flow in the default schema in the integration project Project1, its associated files are stored in the Project1 directory. If you create another message flow in the Stock.Common broker schema within the project Project1, its associated files are created in the directory Project1\Stock\Common.

Because each broker schema represents a unique name scope, you can create two message flows that share the same name within two broker schemas. The broker schemas ensure that these two message flows are recognized as separate resources. The two message flows, despite having the same name, are considered unique.

If you move a message flow from one project to another, you can continue to use the message flow within the original project if you preserve the broker schema. If you do this, you must update the list of dependent projects for the original project by adding the target project. If, however, you do not preserve the broker schema, the flow becomes a different flow because the schema name is part of the fully qualified message flow name, and it is no longer recognized by other projects. This action results in broken links that you must manually correct. For further information about correcting errors after moving a message flow, see Moving a message flow or subflow.

Do not move resources by moving their associated files in the file system; you must use the IBM® Integration Toolkit to move resources to ensure that all references are corrected to reflect the new organization.

The following scope and reuse conditions apply when you create functions, procedures, and constants in a broker schema:

Functions

• Functions are locally reusable and can be called by module-scope subroutines or mappings within the same schema.
• Functions are globally reusable and can be called by other functions or procedures in ESQL or mapping files within any schema defined in the same or another project.

Procedures

• Procedures are locally reusable and can be called from module-scope subroutines in ESQL files within the same schema.
• Procedures are globally reusable and can be called by other functions or procedures in ESQL files within any schema defined in the same or another project.

Procedures cannot be used in mapping files.

Constants

• Constants are locally reusable and can be used where they are defined in any ESQL or mapping file within the same broker schema.
• Constants are not globally reusable; you cannot use a constant that is declared in another schema.

If you want to reuse functions or procedures globally:

• Specify the path of the function or procedure:
  • If you want to reuse a function or procedure in an ESQL file, either provide a fully-qualified reference, or include a PATH statement that defines the path.

    If you define the path, code the PATH statement in the same ESQL file as that in which the function is coded, but not within any MODULE.

  • If you want to reuse a function in a mapping file, take one of the following steps:
    • Qualify the function in the Composition Expression editor.
    • Select Organize Schema References in the outline view. This detects dependent PATHs and automatically updates the reference.
    • Select Modify Schema References in the outline view. You can then select the schema in which the function is defined.
    (You cannot reuse a procedure in a mapping file.)
• Set up references between the projects in which the functions and procedures are defined and used.