WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

PATH-Klausel

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:
  1. 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.
  2. 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 ....
Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:21:30


ReferenzthemaReferenzthema | Version 8.0.0.5 | ak05105_