Die PATH-Klausel spezifiziert eine Liste mit zusätzlichen Schemas, die beim Abgleich von Funktions- und Prozeduraufrufen mit ihren Implementierungen durchsucht werden kann. Das Schema, in dem der Aufruf liegt, ist implizit in der PATH-Klausel eingeschlossen.
Die PATH-Klausel wird verwendet, um nicht qualifizierte Funktions- und Prozessnamen in den Tools entsprechend dem folgenden Algorithmus aufzulösen.
Es muss eine einzige Funktion oder ein einziger Prozess vorhanden sein, der mit dem nicht qualifizierten Namen übereinstimmt, andernfalls melden die Tools einen Fehler. Dieser kann behoben werden, indem der Funktions- oder Prozessname mit einer
SchemaId qualifiziert wird:
- Das aktuelle Modul (falls vorhanden) wird nach einer passenden Funktion oder einem passenden Prozess durchsucht. Die Bereichsfunktionen oder Prozesse für Module sind nur innerhalb ihres enthaltenden Moduls sichtbar. Wenn im aktuellen Modul und Schema gleichnamige Funktionen oder Prozeduren enthalten sind, haben die Modul-Bereichsfunktionen oder -Prozeduren Vorrang vor den Schema-Bereichsfunktionen oder -Prozeduren.
- Das <Knotenschema> (jedoch keines der darin enthaltenen Module) und das <SQL-Brokerschema> oder Schemas, die von der PATH-Klausel bestimmt wurden, werden nach einer passenden Funktion oder Prozedur durchsucht.
Anmerkung: Die Schema-ID muss ein vollständig qualifizierter Schemaname sein.
Wenn Sie eine Funktion oder Prozedur starten, muss der verwendete Name durch den Schemanamen qualifiziert werden. Der Ablauf hängt von den Umständen ab:
Für eine Modulroutine gilt:
- Wenn das Schema angegeben ist, wird die benannte Schemaroutine gestartet.
Die integrierten Skalarfunktionen, ausschließlich der CAST-, EXTRACT- und der Spezialregister, sollten innerhalb eines implizit deklarierten Schemas namens SQL definiert werden.
- Falls das Schema nicht angegeben ist, die aufrufende Anweisung sich in einer Modulroutine befindet und eine Routine des gegebenen Namens im lokalen Modul vorhanden ist, so wird diese lokale Routine gestartet.
- Falls das Schema nicht angegeben ist, die aufrufende Anweisung sich in einer Modulroutine befindet und keine Routine des gegebenen Namens im lokalen Modul vorhanden ist, so werden alle Schemas im Schemapfad nach einer Routine mit demselben Namen durchsucht.
Falls eine passende Funktion in
einem Schema vorhanden ist, wird diese verwendet. Ein Kompilierzeitfehler tritt auf, wenn eine passende Funktion in mehr als einem
Schema vorhanden ist. Falls keine passende Funktion vorhanden
ist, wird die Schema-SQL durchsucht.
Diese Regel und die vorhergehende Regel setzen voraus, dass eine lokale Modulroutine Vorrang vor einer integrierten Routine mit demselben Namen hat.
Für eine Schemaroutine gilt:
- Wenn das Schema angegeben ist, wird die benannte Schemaroutine gestartet.
Die integrierten Skalarfunktionen, ausschließlich der CAST-, EXTRACT- und der Spezialregister, sollten innerhalb eines implizit deklarierten Schemas namens SQL definiert werden.
- Falls das Schema nicht angegeben ist, der Aufrufer eine Schemaroutine ist und eine Routine mit demselben Namen im lokalen Schema vorhanden ist, wird diese lokale Routine gestartet.
- Falls das Schema nicht angegeben ist, die aufrufende Anweisung sich in einer Modulroutine befindet und keine Routine des gegebenen Namens im lokalen Schema vorhanden ist, so werden alle Schemas im Schemapfad nach einer Routine mit demselben Namen durchsucht.
Falls eine passende Funktion in
einem Schema vorhanden ist, wird diese verwendet. Ein Kompilierzeitfehler tritt auf, wenn eine passende Funktion in mehr als einem
Schema vorhanden ist. Falls keine passende Funktion vorhanden
ist, wird die Schema-SQL durchsucht.
Diese und die vorhergehende Regel setzen voraus, dass
eine lokale Schemaroutine Vorrang vor einer integrierten Routine mit demselben Namen hat.
Das <Knotenschema> ist als das Schema definiert, das den Nachrichtenfluss des Knotens enthält.
Das <Knotenschema> wird auf diese Weise angegeben, um Kompatibilität mit früheren
Versionen von WebSphere Message
Broker bereitzustellen.
Wenn das
<Knotenschema> das einzige angegebene Schema ist, enthält die Broker-XML-Nachricht nicht
die zusätzlichen Funktionen, die in WebSphere Message
Broker Version 6.1 enthalten sind.
Broker vorheriger Versionen von WebSphere Message
Broker unterstützen
keine mehrfachen Schemas, wie zum Beispiel Subroutinenbibliotheken zur Wiederverwendung. Um einen
Broker in eine vorherige Version des Produkts einzusetzen, setzen Sie alle ESQL-Subroutinen in
dasselbe Schema ein wie den Nachrichtenfluss und den Knoten, der die ESQL-Subroutinen startet.
Eclipse-Tools verwenden in der Inhaltshilfe und
der Quellcodeprüfung die ESQL-Syntax von WebSphere Message
Broker Version 6.1.
Das Brokerschema des Nachrichtenflusses muss auf der Schemaebene eines der folgenden Elemente in seinen ESQL-Dateien enthalten:
- Eine Schemastufenfunktion
- Einen Schemastufenprozess
- Eine Schemastufenkonstante
- Eine Modulstufenkonstante
- Eine Modulstufenvariable
Wenn keines der vorangehenden Elemente vorhanden ist,
generieren die Eclipsetools eine Broker-ESQL ohne Modul- und Funktions-Wrapper.
Funktions- und Prozedurnamen müssen innerhalb ihres Schemas oder Moduls eindeutig sein.
Beispiele
Im nachfolgenden Beispiel wird einem Schema namens CommonUtils ein Pfad hinzugefügt:
BROKER SCHEMA CommonUtils
PATH SpecialUtils;
MODULE ....
Im nächsten Beispiel wird dem Standardschema ein Pfad hinzugefügt:
PATH CommonUtils, SpecialUtils;
MODULE ....