Anweisung CREATE FUNCTION

Die Anweisung CREATE FUNCTION definiert eine aufrufbare Funktion oder Prozedur.

Zur Definition einer aufrufbaren Funktion oder Prozedur, die auch als Routine bezeichnet wird, kann auch die Anweisung CREATE PROCEDURE verwendet werden.

SYNTAX

Anmerkungen:
  1. Hat die Routine den Typ FUNCTION (Funktion), ist der Richtungsanzeiger (IN, OUT oder INOUT) optional für jeden Parameter. Zu Dokumentationszwecken wird jedoch dringend empfohlen, einen Richtungsanzeiger für alle neuen Routinen festzulegen. Wenn Sie keine Richtung angeben, wird der Standardwert IN verwendet.
  2. Wenn die NAMESPACE- oder NAME-Klausel verwendet wird, lautet ihr Wert implizit CONSTANT, und sie gehört dem Typ CHARACTER (Zeichen) an. Weitere Informationen zur Verwendung von CONSTANT-Variablen finden Sie im Abschnitt DECLARE-Anweisung.
  3. Hat die Routine den Typ FUNCTION, kann für LANGUAGE nicht DATABASE angegeben werden.

Übersicht

Die Anweisungen CREATE FUNCTION und CREATE PROCEDURE definieren eine aufrufbare Funktion bzw. Prozedur, die auch als Routine bezeichnet wird.

In früheren Produktversionen wurden die Anweisungen CREATE FUNCTION und CREATE PROCEDURE unterschiedlich eingesetzt und hatten verschiedene Funktionen. Durch spätere funktionale Erweiterungen sind die zuvor in den Hinweisen 1 und 3 aufgeführten Unterschiede zustande gekommen.

Routinen sind bei der Erstellung wiederverwendbarer Codeblöcke hilfreich, die unabhängig mehrere Male ausgeführt werden können. Sie können als Reihe von ESQL-Anweisungen, als Java-Methode oder als in einer Datenbank gespeicherte Prozedur implementiert werden. Diese Vielfalt der Implementierungsmöglichkeiten bedeutet, dass einige der Klauseln im Syntaxdiagramm nicht für alle Routinetypen zutreffen (oder nicht zulässig sind).

Jede Routine hat einen Namen, der innerhalb des Schemas, der die Routine angehört, eindeutig sein muss. Routinennamen können daher nicht überlappen. Wenn der Broker einen überlappenden Routinennamen findet, gibt er eine Ausnahme aus.

Die LANGUAGE-Klausel gibt die Sprache an, in der der Hauptteil der Routine geschrieben wird. Folgende Optionen stehen zur Verfügung:
DATABASE
Die Prozedur wird als eine in einer Datenbank gespeicherte Prozedur aufgerufen.
ESQL
Die Prozedur wird als eine ESQL-Routine aufgerufen.
JAVA
Die Prozedur wird als statische Methode in einer Java-Klasse bezeichnet.
Nicht angegeben
Wenn Sie die LANGUAGE-Klausel nicht angeben, lautet die Standardsprache ESQL, es sei denn, Sie geben die EXTERNAL NAME-Klausel an. (In diesem Fall wird als Standardsprache DATABASE verwendet.)
Die Verwendung der LANGUAGE-Klausel unterliegt Einschränkungen. Folgende Verwendungen sind nicht möglich:
  • Die ESQL-Option mit einer EXTERNAL NAME-Klausel
  • Die Optionen DATABASE oder JAVA ohne eine EXTERNAL NAME-Klausel
  • Die DATABASE-Option mit dem Routinetyp FUNCTION

Geben Sie den Namen der Routine mit der Klausel Routinenname und die Parameter der Routine mit der Klausel Parameterliste an. Wenn die LANGUAGE-Klausel ESQL angibt, muss die Routine unter Verwendung einer einzelnen ESQL-Anweisung implementiert werden. Diese Anweisung ist sehr nützlich, wenn es sich um eine Verbindungsanweisung handelt (BEGIN ... END), da sie dann so viele ESQL-Anweisungen wie zur Ausübung ihrer Funktion erforderlich enthalten kann.

Alternativ können Sie in der LANGUAGE-Klausel eine andere Sprache als ESQL angeben, anstatt einen ESQL-Hauptteil für die Routine bereitzustellen. Auf diese Weise sind Sie in der Lage, mit der EXTERNAL NAME-Klausel auf den tatsächlichen Hauptteil der Routine zu verweisen, wenn er extern zum Broker lokalisiert ist. Weitere Informationen zur Verwendung der EXTERNAL NAME-Klausel finden Sie im Abschnitt Gespeicherte Prozeduren aufrufen sowie unter Java-Routine aufrufen.

Routinen mit beliebigem LANGUAGE-Typ können die Parameter IN, OUT und INOUT haben. Der Aufrufende kann mehrere Werte in die Routine einstellen und mehrere aktualisierte Werte zurückempfangen. Diese zurückgegebenen Parameter kommen zu den für die Routine definierten RETURNS-Klauseln hinzu. Die RETURNS-Klausel definiert die Werte, die von der Routine an den Aufrufenden zurückgegeben werden.

Für in verschiedenen Sprachen implementierte Routinen gelten eigene Einschränkungen bezüglich der Datentypen, die eingestellt oder zurückgegeben werden können. Diese Einschränkungen sind weiter unten in diesem Abschnitt dokumentiert. Der Datentyp des zurückgegebenen Wertes muss mit dem Datentyp des Wertes übereinstimmen, der laut Definition von der Routine zurückgegeben werden soll. Wenn eine Routine laut Definition einen Rückgabewert haben soll, kann ihn der Aufrufende der Routine nicht ignorieren. Weitere Informationen hierzu finden Sie unter CALL-Anweisung.

Routinen lassen sich in einem Modul oder in einem Schema definieren. In einem Modul definierte Routinen liegen im lokalen Bereich des aktuellen Knotens, d. h. sie können nur mit Code aufgerufen werden, der demselben Modul (bzw. Knoten) angehört. Für den Aufruf von Routinen, die in einem Schema definiert sind, stehen dagegen folgende Möglichkeiten zur Auswahl:
  • Code in demselben Schema
  • Code in einem anderen Schema, wenn eine der folgenden Bedingungen zutrifft:
    • Die PATH-Klausel des anderen Schemas enthält den Pfad zu der aufgerufenen Routine
    • Die aufgerufene Routine wird unter Verwendung ihres vollständig qualifizierten Namens (bestehend aus ihrem Namen, dem ihr Schemaname, durch einen Punkt getrennt, vorangestellt ist) aufgerufen.
Wenn Sie also dieselbe Routine in mehreren Knoten aufrufen möchten, definieren Sie sie in einem Schema.

Bezüglich der Sprache oder des Routinetyps muss die Methode des Aufrufens der Routine der Methode ihrer Deklaration entsprechen. Wenn die Routine eine RETURNS-Klausel besitzt, verwenden Sie entweder die Aufrufsyntax FUNCTION oder eine CALL-Anweisung mit einer INTO-Klausel. Umgekehrt gilt: Hat eine Routine keine RETURNS-Klausel, muss eine CALL-Anweisung ohne INTO-Klausel verwendet werden.

Parameterrichtungen

Parametern, die an Routinen übergeben werden, ist stets eine Richtung zugeordnet. Es gibt folgende Richtungsarten:
IN
Der Wert des Parameters kann nicht von der Routine geändert werden. Ein NULL-Wert für den Parameter ist zulässig und kann an die Routine übermittelt werden.
OUT
Der in die Routine eingestellte Parameter hat, wenn er von der aufgerufenen Routine empfangen wird, immer den Wert NULL des korrekten Datentyps. Dieser Wert wird gesetzt, unabhängig von dem Parameterwert vor dem Aufruf der Routine. Die Routine darf den Wert des Parameters ändern.
INOUT
INOUT ist sowohl ein IN-Parameter als auch ein OUT-Parameter. Er stellt einen Wert in die Routine, der dann von dieser geändert werden kann. Ein NULL-Wert für den Parameter ist zulässig und kann sowohl in die Routine eingestellt als auch aus ihr heraus übermittelt werden.

Hat die Routine den Typ FUNCTION (Funktion), ist der Richtungsanzeiger (IN, OUT, INOUT) für jeden Parameter optional. Wir empfehlen jedoch dringend, aus Dokumentationsgründen einen Richtungsanzeiger für alle neuen Routinen mit beliebigem Typ festzulegen.

ESQL-Variablen, die als CONSTANT deklariert sind (oder Verweise auf als CONSTANT deklarierte Variablen) dürfen nicht die Richtung OUT oder INOUT haben.

ESQL-Routinen

ESQL-Routinen sind in ESQL geschrieben, und ihre LANGUAGE-Klausel gibt die Sprache ESQL an. Als Hauptteil einer ESQL-Routine wird gewöhnlich eine Verbindungsanweisung in der Form BEGIN … END verwendet, die mehrere Anweisungen zur Verarbeitung der Parameter enthält, die an die Routine übermittelt werden.

ESQL-Beispiel 1

In dem folgenden Beispiel sehen Sie dieselbe Prozedur wie in Beispiel 1 einer Datenbankroutine, allerdings als ESQL-Routine und nicht als gespeicherte Prozedur implementiert. Die CALL-Syntax und Ergebnisse dieser Routine sind mit denen in Einschränkungen bei Java-Routinen identisch.
CREATE PROCEDURE swapParms (
  IN parm1 CHARACTER,
  OUT parm2  CHARACTER,
  INOUT parm3 CHARACTER )
BEGIN
   SET parm2 = parm3;
   SET parm3 = parm1;
 END; 

ESQL-Beispiel 2

Diese Beispielprozedur zeigt die rekursive Verwendung einer ESQL-Routine. Sie analysiert die Syntax einer Baumstruktur an sämtlichen Stellen am und unterhalb des angegebenen Ausgangspunkts und dokumentiert anschließend das Ergebnis:

SET OutputRoot.MQMD = InputRoot.MQMD;

  DECLARE answer CHARACTER;
  SET     answer = '';

  CALL navigate(InputRoot.XMLNS, answer);
  SET OutputRoot.XMLNS.Data.FieldNames = answer;


  CREATE PROCEDURE navigate (IN root REFERENCE, INOUT answer CHARACTER)
  BEGIN
    SET answer = answer || 'Reached Field... Type:' || CAST(FIELDTYPE(root) AS CHAR)||
    ': Name:' || FIELDNAME(root) || ': Value :' || root || ': ';

    DECLARE cursor REFERENCE TO root;
    MOVE cursor FIRSTCHILD;
    IF LASTMOVE(cursor) THEN
      SET answer = answer || 'Field has children... drilling down ';
    ELSE
      SET answer = answer || 'Listing siblings... ';
    END IF;

    WHILE LASTMOVE(cursor) DO
      CALL navigate(cursor, answer);
      MOVE cursor NEXTSIBLING;
    END WHILE;

    SET answer = answer || 'Finished siblings... Popping up ';
  END;

Lautet die Eingabenachricht wie folgt:

<Person>
  <Name>John Smith</Name>
  <Salary period='monthly' taxable='yes'>-1200</Salary>
</Person>

dann erstellt die Prozedur die folgende Ausgabe, die manuell formatiert wurde:

  Reached Field... Type:16777232: Name:XML: Value :: Field has children... drilling down 
  Reached Field... Type:16777216: Name:Person: Value :: Field has children... drilling down 
  Reached Field... Type:16777216: Name:Name: 
  Value :John Smith: Field has children... drilling down 
  Reached Field... Type:33554432: Name:: 
  Value :John Smith: Listing siblings... Finished siblings... Popping up
  Finished siblings... Popping up 
  Reached Field... Type:16777216: Name:Salary:
  Value :-1200: Field has children... drilling down 
  Reached Field... Type:50331648: Name:period: 
  Value :monthly: Listing siblings... Finished siblings... Popping up
  Reached Field... Type:50331648: Name:taxable: 
  Value :yes: Listing siblings... Finished siblings... Popping up 
  Reached Field... Type:33554432: Name:: 
  Value :-1200: Listing siblings... Finished siblings... Popping up 
  Finished siblings... Popping up 
  Finished siblings... Popping up 
  Finished siblings... Popping up

Java-Routinen

Eine Java-Routine wird als Java-Methode implementiert und hat die LANGUAGE-Klausel JAVA. Bei Java-Routinen muss der Name_der_externen_Routine den Klassennamen und den Namen der aufzurufenden Java-Methode enthalten. Geben Sie den ExterneRoutineName wie folgt an:
>>--"-- Klassenname---.---Methodenname--"--------------><
dabei steht Name_Klasse für die Klasse, die die Methode enthält, und Name_der_Methode gibt die Methode an, die aufgerufen werden soll. Wenn die Klasse Teil eines Pakets ist, muss der Teil mit der Klassen-ID das komplette Paketpräfix einschließen, z. B. "com.ibm.broker.test.MyClass.myMethod".

Für die Suche nach der Java-Klasse verwendet der Broker die im Abschnitt Implementierung von Java-Klassen beschriebene Suchmethode.

Die Java-Methoden, die aufgerufen werden sollen, müssen die folgende Basissignatur aufweisen:
public static <Rückgabetyp> <Methodenname> (< 0 - N Parameter>)

Dabei muss der <Rückgabetyp> in der Liste der Java-Datentypen IN in der Tabelle in der Zuordnung von ESQL zum Java-Datentyp enthalten sein (ausgenommen REFERENCE, da dieser Typ als Rückgabewert unzulässig ist) oder dem Java-Datentyp 'void' entsprechen. Die Parameterdatentypen müssen ebenfalls aus der Tabelle der Zuordnung von ESQL zum Java-Datentyp stammen. Zudem darf die Java-Methode keine exception throws-Klausel (Ausnahmeauslöser) in ihrer Signatur haben.

Die Signatur der Java-Methode muss der Deklaration der ESQL-Routine der Methode entsprechen. Außerdem sind folgende Regeln zu beachten:
  • Stellen Sie sicher, dass der Name der Java-Methode, einschließlich des Klassennamens und der Paketqualifikationsmerkmale, dem externen Namen (EXTERNAL NAME) der Prozedur entspricht.
  • Ist der Java-Rückgabetyp 'void' ist, sollten Sie in die Definition der ESQL-Routine keine RETURNS-Klausel aufnehmen. Umgekehrt gilt: Lautet der Java-Rückgabetyp 'not void' muss in die Definition der ESQL-Routine eine RETURNS-Klausel gestellt werden.
  • Stellen Sie sicher, dass alle Parametertypen und -richtungen gemäß den in der Tabelle in der Zuordnung von ESQL zum Java-Datentyp aufgelisteten Regeln der ESQL-Deklaration entsprechen.
  • Stellen Sie sicher, dass der Rückgabetyp der Methode dem Datentyp der RETURNS-Klausel entspricht.
  • Setzen Sie den EXTERNAL NAME (externen Namen) in Anführungszeichen, da er mindestens "class.method" enthalten muss.
  • Wenn Sie eine überlastete Java-Methode aufrufen möchten, müssen Sie eine separate ESQL-Definition für jede überlastete Methode erstellen und jeder ESQL-Definition einen eindeutigen Routinenamen geben.

Sie können in der Java-Methode die API des benutzerdefinierten Java-Knotens verwenden, sofern Sie die in Einschränkungen bei Java-Routinen dokumentierten Einschränkungen beachten. Weitere Informationen zur Verwendung der Java-API finden Sie im Abschnitt Benutzerdefinierten Java-Knoten kompilieren.

Beispiel 1 einer Java-Routine

Diese Routine enthält drei Parameter unterschiedlicher Richtungen und gibt eine Ganzzahl zurück, die dem Java-Rückgabetyp java.lang.Long entspricht.

CREATE FUNCTION  myProc1( IN P1 INTEGER, OUT P2 INTEGER, INOUT P3 INTEGER )
 RETURNS INTEGER
 LANGUAGE JAVA 
 EXTERNAL NAME "com.ibm.broker.test.MyClass.myMethod1";

Sie können für den Aufruf von myProc1 folgenden ESQL-Ausdruck verwenden:

CALL myProc1( intVar1, intVar2, intVar3) INTO intReturnVar3;
-- oder
SET intReturnVar3 = myProc1( intVar1, intVar2, intVar3);

Beispiel 2 einer Java-Routine

Diese Routine enthält drei Parameter unterschiedlicher Richtungen und hat den Java-Rückgabetyp void (typenlos).

CREATE PROCEDURE myProc2( IN P1 INTEGER, OUT P2 INTEGER, INOUT P3 INTEGER )
 LANGUAGE JAVA 
 nEXTERNAL NAME "com.ibm.broker.test.MyClass.myMethod2";

Sie müssen für den Aufruf von myProc2 folgenden ESQL-Ausdruck verwenden:

CALL myProc2(intVar1, intVar2, intVar3);

Die folgende Java-Klasse bietet eine Methode für jedes der Java-Beispiele:

package com.ibm.broker.test;

class MyClass {
public static Long myMethod1( Long P1, Long[] P2 Long[] P3) { ... }
public static void myMethod2( Long P2, Long[] P2 Long[] P3) { ... }

 /*  Wenn eine dieser Methoden aufgerufen wird:
    P1 kann den Wert NULL haben oder nicht (abhängig vom Wert von intVar1).
    P2[0] hat stets den Wert NULL (unabhängig vom Wert von intVar2).
    P3[0] kann den Wert NULL haben oder nicht (abhängig vom Wert von intVar3). 
    Alles entspricht der Verwendung von LANGUAGE ESQL-Routinen.     Wenn diese Methoden Werte zurückgeben:
         intVar1 ist unverändert
         intVar2 kann immer noch den Wert NULL oder einen anderen Wert haben
         intVar3 kann denselben Wert oder einen anderen Wert haben
     Alles entspricht der Verwendung von LANGUAGE ESQL-Routinen.
     
    Wenn myMethod1 Folgendes zurückgibt: intReturnVar3 ist entweder NULL (wenn die
    Methode NULL zurückgibt) oder enthält den Wert, den die 
    Methode zurückgegeben hat.
 */
}

Zuordnung von ESQL zum Java-Datentyp

Die folgende Tabelle enthält eine Zusammenfassung der Zuordnungen zwischen ESQL und Java.
Anmerkungen:
  • Nur die Java-Skalarwrapper werden an Java übergeben.
  • Die ESQL-Skalartypen werden Java-Datentypen je nach Richtung des Prozedurparameters als Objektwrapper oder Objektwrapperbereiche zugeordnet. Jeder Wrapperbereich enthält genau ein Element.
  • Durch die Verwendung von Skalarobjektwrappern können NULL-Werte an Java-Methoden übermittelt und von dort abgerufen werden.
ESQL-Datentypen 1 Datentypen Java IN Datentypen Java INOUT und OUT
INTEGER, INT java.lang.Long java.lang.Long []
FLOAT java.lang.Double java.lang.Double[]
DECIMAL java.math.BigDecimal java.math.BigDecimal[]
CHARACTER, CHAR java.lang.String java.lang.String[]
BLOB byte[] byte[][]
BIT java.util.BitSet java.util.BitSet[]
DATE com.ibm.broker.plugin.MbDate com.ibm.broker.plugin.MbDate[]
TIME 2 com.ibm.broker.plugin.MbTime com.ibm.broker.plugin.MbTime[]
GMTTIME 2 com.ibm.broker.plugin.MbTime com.ibm.broker.plugin.MbTime[]
TIMESTAMP 2 com.ibm.broker.plugin.MbTimestamp com.ibm.broker.plugin.MbTimestamp[]
GMTTIMESTAMP 2 com.ibm.broker.plugin.MbTimestamp com.ibm.broker.plugin.MbTimestamp[]
INTERVAL Wird nicht unterstützt Wird nicht unterstützt
BOOLEAN java.lang.Boolean java.lang.Boolean[]
REFERENCE (auf eine Nachrichtenbaumstruktur) 3 4 5 6 com.ibm.broker.plugin.MbElement com.ibm.broker.plugin.MbElement[] (Wird für INOUT unterstützt, nicht für OUT)
ROW Wird nicht unterstützt Wird nicht unterstützt
LIST Wird nicht unterstützt Wird nicht unterstützt
  1. Variablen, die als konstant deklariert werden (bzw. Verweise auf Variablen, die als konstant deklariert werden), dürfen weder die Richtung INOUT noch OUT haben.
  2. Die in der Java-Variablen eingestellte Zeitzone ist nicht relevant; die erforderliche Zeitzone erhalten Sie in der ausgegebenen ESQL.
  3. Bei der Übergabe an eine Java-Methode kann der Verweisparameter nicht den Wert NULL haben.
  4. Bei der Übergabe an eine Java-Methode kann der Verweis nicht die Richtung OUT haben.
  5. Wenn ein MbElement von Java als INOUT-Parameter an ESQL zurückgegeben wird, muss es auf eine Position in derselben Nachrichtenbaumstruktur verweisen, auf die auch das MbElement verwies, welches an die aufgerufene Java-Methode übergeben wurde.

    Wenn beispielsweise ein ESQL-Verweis auf OutputRoot.XML.Test als INOUT-MbElement an eine Java-Methode übergeben wird, jedoch bei Rückkehr des Aufrufs ein anderes MbElement an ESQL zurückgegeben wird, muss dieses andere Element ebenfalls auf eine Position in der OutputRoot-Baumstruktur verweisen.

  6. Ein MbElement kann nicht mit der RETURNS-Klausel an eine Java-Methode zurückgegeben werden, da ESQL-Routinen keine Verweise zurückgeben können. Dagegen kann ein MbElement als INOUT-Richtungsparameter zurückgegeben werden, wobei die unter Punkt 5 aufgeführten Bedingungen gelten.

Ein Verweis auf eine Skalarvariable kann im Aufruf einer Java-Methode verwendet werden, wenn der Datentyp der Variablen, auf die verwiesen wird, dem entsprechenden Datentyp in der Java-Programmsignatur entspricht.

Einschränkungen bei Java-Routinen

Für Java-Routinen, die aus ESQL aufgerufen werden, gelten folgende Einschränkungen:
  • Die Java-Methode muss threadsicher sein (simultan verwendbar).
  • Es müssen Datenbankverbindungen vom JDBC-Typ 2 oder 4 bestehen. Zudem sind Datenbankoperationen nicht Teil einer Brokertransaktion und daher nicht durch einen externen Ressourcenkoordinator steuerbar (wie dies in einer XA-Umgebung der Fall ist).
  • Die API des benutzerdefinierten Java-Knotens darf nur von dem Thread verwendet werden, der die Java-Methode aufgerufen hat.

    Innerhalb der Methode können Threads erstellt werden. Erstellte Threads dürfen die Java-APIs jedoch nicht verwenden, und die Steuerung muss wieder an den Broker zurückgegeben werden.

    Alle Einschränkungen hinsichtlich der Verwendung der Java-API gelten auch für Java-Methoden, die aus ESQL aufgerufen werden.

  • Aus ESQL aufgerufene Java-Methoden dürfen die MbNode-Klasse nicht verwenden. Sie können also keine Objekte vom Typ MbNode erstellen oder Methoden für ein vorhandenes MbNode-Objekt aufrufen.
  • WebSphere MQ- oder JMS-Aufgaben innerhalb einer Java-Methode, die aus ESQL aufgerufen wurde, müssen den Richtlinien für die Ausführung von WebSphere MQ- und JMS-Aufgaben in einem benutzerdefinierten Knoten entsprechen. Beginn der ÄnderungWeitere Informationen hierzu finden Sie unter Planung für benutzerdefinierte Empfangsknoten.Ende der Änderung

Implementierung von Java-Klassen

Mit einer der beiden folgenden Methoden können Java-Klassen auf einem Broker innerhalb einer Java-Archivdatei (JAR-Datei) implementiert werden:
  1. Fügen Sie die JAR-Datei zur Brokerarchivdatei (BAR-Datei) hinzu.

    Die effizienteste und flexibelste Methode zur Implementierung auf dem Broker besteht darin, die JAR-Datei zur BAR-Datei hinzuzufügen. Sie können diese Aufgabe manuell oder automatisch mithilfe der Workbench ausführen.

    Wenn die Workbench die korrekte Java-Klasse in einem geöffneten referenzierten Java-Projekt im Arbeitsbereich findet, wird die Java-Klasse automatisch in eine JAR-Datei kompiliert und zur BAR-Datei hinzugefügt. Diese Prozedur ist mit der Prozedur zur Implementierung eines JavaCompute-Knotens in einer JAR-Datei identisch (siehe Klassenladen für benutzerdefinierte Knoten.

    Wenn Sie eine JAR-Datei über die Workbench implementieren, lädt der erneut implementierte Fluss die in der BAR-Datei enthaltene JAR-Datei.

    Ebenso werden die Dateien erneut geladen, wenn der Nachrichtenfluss, der auf eine Java-Klasse verweist, gestoppt und erneut gestartet wird. Stellen Sie sicher, dass Sie alle Flüsse, die auf die zu aktualisierende JAR-Datei verweisen, stoppen und neu starten (bzw. erneut implementieren). Auf diese Weise verhindern Sie, dass einige Flüsse mit der alten Version der JAR-Datei und andere Flüsse mit der neuen Version ausgeführt werden.

    Mit der Workbench werden nur JAR-Dateien, nicht jedoch eigenständige Java-Klassendateien implementiert.

  2. Speichern Sie die JAR-Datei an einer der folgenden Speicherpositionen:
    1. im Ordner Arbeitspfad/shared-classes/ auf der Maschine, auf der der Broker ausgeführt wird
    2. in der Umgebungsvariablen CLASSPATH auf der Maschine, auf der der Broker ausgeführt wird

    Diese Aktion muss manuell durchgeführt werden, die Workbench kann hierfür nicht verwendet werden.

    Bei diesem Verfahren werden bei einer erneuten Implementierung des Nachrichtenflusses die Java-Klassen, auf die verwiesen wird, nicht erneut geladen, und der Nachrichtenfluss wird nicht gestoppt und neu gestartet. In diesem Fall können die Klassen nur neu geladen werden, indem Sie den Broker stoppen und neu starten.

Damit der Broker eine Java-Klasse finden kann, muss sich diese in einem der oben genannten Verzeichnisse befinden. Wenn der Broker die angegebene Klasse nicht finden kann, löst er eine Ausnahme aus.

Zwar stehen Ihnen bei der Implementierung der JAR-Datei die zuvor genannten Möglichkeiten zur Verfügung, die Verwendung der Workbench bei der Implementierung der BAR-Datei bietet jedoch die größte Flexibilität bei der erneuten Implementierung der JAR-Datei.

Datenbankroutinen

Datenbankroutinen werden von der Funktion CREATE FUNCTION nicht unterstützt. Verwenden Sie CREATE PROCEDURE zum Definieren einer Datenbankroutine.

Zugehörige Konzepte
Übersicht zu ESQL
Zugehörige Tasks
ESQL erstellen
Gespeicherte Prozeduren aufrufen
Benutzerdefinierten Java-Knoten kompilieren
Dateien zu einem Brokerarchiv hinzufügen
Zugehörige Verweise
Syntaxdiagramme: Verfügbare Typen
ESQL-Anweisungen
CALL-Anweisung
Anweisung CREATE PROCEDURE
Tabelle für die Zuordnung von ESQL- zu Java-Datentypen
Zugehörige Informationen
Benutzerdefinierte Java-Erweiterungs-API
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Letzte Aktualisierung : 2009-02-17 15:29:26

ak04960_