In Rich UI wird die Anweisung call verwendet, um einen Service asynchron aufzurufen:
call serviceName.operationName(argumentList)
returning to myCallbackFunction onException myExceptionHandler
{timeout = milliseconds};
- serviceName
- Der Name einer Variablen, der auf einem Schnittstellenabschnitt basiert.
- operationName
- Der Name des Funktionsprototyps für den Schnittstellenabschnitt.
- argumentList
- Eine Liste mit Argumenten, die jeweils durch ein Komma voneinander getrennt sind.
Einschränkungen in Bezug auf Argumente finden Sie in 'Einschränkungen bei den für den Servicezugriff
verwendeten Prototypen'.
- myCallbackFunction
- Der Name einer Callback-Funktion oder eines Stellvertreters, die bzw. der für die
Anweisung 'call' verfügbar ist. In den meisten Fällen befindet sich die Funktion oder der
Stellvertreter im selben Rich-UI-Handler oder in einer Bibliothek. Die Callback-Funktion wird weiter unten
in diesem Thema beschrieben.
- myExceptionHandler
- Optional. Der Name eines Ausnahmebedingungshandlers oder eines Stellvertreters, der für die
Anweisung call verfügbar ist. In den meisten Fällen befindet sich der
Ausnahmebedingungshandler oder der Stellvertreter im selben Rich-UI-Handler oder in einer
Bibliothek. Der Ausnahmebedingungshandler wird weiter unten
in diesem Thema beschrieben.
Wenn Sie über keinen eigenen Ausnahmebedingungshandler verfügen, können Sie den folgenden
Stellvertreter angeben:
serviceLib.serviceExceptionHandler.
Auswirkungen:
- Bei der Angabe dieses Stellvertreters wird standardmäßig eine Systemfunktion aufgerufen,
die den Inhalt des Ausnahmebedingungsnachrichtenfelds in die Standardausgabe
schreibt. Im Produkt ist die Konsolenansicht die Standardausgabe. In einem externen
Browser ist der untere Bereich der Webseite die Standardausgabe.
- Alternativ kann der Stellvertreter den Aufruf eines angepassten Ausnahmebedingungshandlers
veranlassen. Sie können mit diesem alternativen Handler sogar veranlassen, dass die angepasste Fehlerbehandlung für
eine Gruppe von Anwendungen konsistent ist.
Gehen Sie beispielsweise wie folgt vor:
- Erstellen Sie eine Bibliothek namens myLibrary und fügen Sie einen angepassten
Ausnahmebedingungshandler namens myExceptionHandler sowie eine Setup-Funktion ein.
- Fügen Sie in die Setup-Funktion die folgende Anweisung ein:
serviceLib.serviceExceptionHandler = myLibrary.myExceptionHandler;
- Rufen Sie die Setup-Funktion in jeder Rich-UI-Anwendung in der Funktion
on-construction auf.
Für jeden Service, der mit
einer Anweisung call aufgerufen wird (sofern die Anweisung
serviceLib.serviceExceptionHandler einschließt), reagiert der EGL-Laufzeitcode
auf Laufzeitausnahmebedingungen mit der Ausführung des angepassten Ausnahmebedingungshandlers; in diesem
Fall mit der Ausführung von myLibrary.myExceptionHandler.
- milliseconds
- Die maximal gültige Anzahl von Millisekunden zwischen dem Aufruf eines Web-Service durch den
EGL-Rich-UI-Proxy (auf dem Anwendungsserver) und dem Empfang einer Antwort auf dem Proxy. Bei einer
Überschreitung dieses Werts löst der EGL-Laufzeitcode eine Ausnahmebedingung vom Typ
ServiceInvocationException aus.
Beim Zugriff auf einen dedizierten Service ist jedoch kein
Zeitlimit erforderlich.
Gehen Sie wie folgt vor, um ein Zeitlimit festzulegen:
- Beziehen Sie verschiedene Faktoren wie den Datenaustausch im lokalen Netz, den Datenverkehr im Internet
und die Serverantwortzeit in Ihre Überlegungen ein. Aufgrund dieser Faktoren ist es wahrscheinlich, dass zwei
Aufrufe desselben Service unter verschiedenen Bedingungen unterschiedlich viel Zeit in Anspruch nehmen.
- Berücksichtigen Sie die Art der Anwendung. Wenn der Code auf eine Kreditzusage wartet, müssen Sie unter
Umständen einen hohen Zeitlimitwert definieren, damit der Benutzer die Gebühr nicht zweimal zahlen
muss. Wenn der Code ein Gebot bei einer Online-Auktion abgibt, müssen Sie unter Umständen einen niedrigen Zeitlimitwert
angeben, damit der Benutzer schnell weitere Gebote abgeben kann.
- Verwenden Sie Zeitlimitwerte, die sich um eine oder mehrere Sekunden voneinander
unterscheiden.
In der Builddeskriptoroption defaultServiceTimeout
kann ein Standardwert für milliseconds festgelegt
werden. Für die Builddeskriptoroption defaultServiceTimeout ist kein Standardwert
definiert. Wenn Sie für defaultServiceTimeout oder
milliseconds keinen Wert angeben, gibt es für den Serviceaufruf kein
Zeitlimit. Weitere Informationen finden Sie in 'defaultServiceTimeout'.
Unterstützung für Tastenbefehle bei call-Anweisungen
Die folgenden Arten von
Unterstützung für Tastenbefehle stehen zur Verfügung:
- Nach der Eingabe des Schlüsselworts returning to oder
onException in die Anweisung call können Sie mit
Strg+Leerzeichen die Inhaltshilfe anfordern. Daraufhin wird eine Liste mit Funktionen angezeigt, aus der Sie
eine Funktion auswählen können.
- Wenn die Anweisung call mit einem Semikolon
endet und einen Verweis auf eine nicht vorhandene Callback- oder eine onException-Funktion
enthält, können Sie veranlassen, dass die fehlende Logik von der Workbench erstellt wird:
- Drücken Sie Strg+1.
- Alternativ können Sie nach dem Semikolon mit der rechten Maustaste klicken und Rückruffunktionen
erstellen auswählen.
Callback-Funktion
Die callback-Funktion empfängt
gegebenenfalls die Werte, die in der vom Service gesendeten Antwort enthalten sind. Die Callback-Funktion
selbst verfügt über keinen Rückgabewert.
Wenn die callback-Funktion über einen
REST-Service eines anderen Herstellers aufgerufen wird, kann die Funktion keinen oder einen Parameter
aufweisen. Ist ein Parameter definiert, muss der Typ des Parameters mit dem Typ des Rückgabewerts übereinstimmen,
der im Schnittstellenabschnitt angegeben ist; der Parametermodifikator ist IN.
Wird die
callback-Funktion über einen SOAP-Service oder einen EGL-REST-RPC-Service aufgerufen,
kann die Beziehung zwischen den Funktionsparametern und den Serviceaufrufparametern am besten mit einem
Beispiel beschrieben werden:
- Betrachten wir den folgenden Funktionsprototyp in einem Schnittstellenabschnitt:
Interface EmployeeService {}
Function GetEmployeeDetail(employeeCode STRING IN,
employeeSalary FLOAT OUT,
employeeStatus STRING INOUT)
returns(myEmployeeRecordPart);
end
- Dieses Beispiel zeigt eine Schnittstellendeklaration und eine Anweisung call zum Aufrufen
des Service:
myInterface EmployeeService;
call myInterface.GetEmployeeDetail("A123", 25.8, "Full-time")
returning to myCallback onException myExceptionHandler;
- Im Folgenden ist ein Entwurf für eine callback-Funktion
aufgeführt:
Function myCallBack(salary FLOAT IN,
status STRING IN,
myRecord myEmployeeRecordPart IN)
// statements here
end
Die Funktion enthält für jeden Serviceoperationsparameter vom Typ
OUT oder INOUT einen Parameter. Die Reihenfolge dieser Parameter in der
Callback-Funktion entspricht der Reihenfolge in der Serviceoperation.
Der Rückgabewert der Serviceoperation wird in der Callback-Funktion als letzter Parameter
dargestellt.
Im Allgemeinen lauten die Regeln für den Entwurf einer
callback-Funktion für einen Web-SOAP-Service oder einen EGL-REST-RPC-Service wie folgt:
- Die Funktion verfügt über eine Reihe von Parametern, deren Reihenfolge der Reihenfolge der Parameter OUT und
INOUT im Serviceaufruf entspricht.
- Wenn der Serviceaufruf über einen Rückgabewert verfügt, enthält die callback-Funktion
einen zusätzlichen letzten Parameter, der den Rückgabewert akzeptiert.
- Jeder Parameter in der Funktion verfügt über den IN-Modifikator.
Funktion 'onException'
Die Funktion
onException weist
die folgenden Merkmale auf:
- Kein Rückgabewert
- Die Funktion akzeptiert einen Ausnahmedatensatz vom Typ AnyException;
dieser Datensatz kann getestet werden, um den empfangenen Typ zu bestimmen.
Im Folgenden ist
ein Entwurf für eine Funktion onException aufgeführt:
Function myExceptionHandler(exp AnyException)
case
when (exp isa ServiceBindingException)
;
when (exp isa ServiceInvocationException)
;
otherwise
;
end
end
Fehler können an den folgenden Stellen auftreten:
- In einem Service-Binding; das heißt, in welcher Weise der Servicezugriff in Ihrem Code definiert
ist. Dieser Fehler kann ein Problem im Implementierungsdeskriptor beinhalten.
- In der Kommunikation zwischen der Rich-UI-Anwendung und dem EGL-Rich-UI-Proxy.
- Im EGL-Rich-UI-Proxy.
- In der Kommunikation zwischen dem EGL-Rich-UI-Proxy und dem Service.
- Im Service.
Ein Problem in einem Service-Binding löst eine Ausnahmebedingung vom Typ
ServiceBindingException aus.
Andere Probleme lösen eine Ausnahmebedingung vom Typ ServiceInvocationException oder
(weniger wahrscheinlich) vom Typ RuntimeException aus.