Ein Endpunkt kann bei der Arbeit mit dem Enterprise Integrator als Ziel für einen Proxy-Dienst oder eine API definiert werden. Es kann so etwas Einfaches wie diese URL sein: http://localhost:8280/services/AcmeProxy oder es kann eine URL sein, die zu einem anderen Ort im Internet oder irgendwo in Ihrer IT-Landschaft zeigt, es spielt wirklich keine Rolle.
In den Beispielen von WSO2 sehen wir oft eine einfache Endpunktdefinition, d.h. einfach die URL, ohne die erweiterten Einstellungen zu konfigurieren, die mit Endpunkten zu tun haben, die nicht verfügbar sind oder nicht rechtzeitig reagieren.
In diesem Blog über Endpunkte werde ich mich mit der Konfiguration von Endpunkten innerhalb von WSO2 EI beschäftigen und wie wir Fehlermeldungen bearbeiten können.
Ein einfacher Proxy
Ich erstelle einen einfachen Proxy, der eine Meldung entgegennimmt und sie an einen Endpunkt sendet. Dieser Endpunkt wird mit WireMock erstellt, einem einfachen Java-basierten Service-Mocking-Tool, das wir auch in unseren WSO2-Schulungen verwenden.
Für das Proxy verwende ich ein Windows-basiertes Setup von Developer Studio und WSO2 EI 6.4.0, die reguläre Open-Source-Version des Produkts. Es wird alles auf Windows getestet, aber für Linux und Mac ist es so ziemlich das Gleiche.
Ich zeige nicht im Detail, wie wir den WSO2 Enterprise Integrator und Developer Studio/Eclipse entpacken und konfigurieren, denn das würde diesen Blog ziemlich lang machen.
Die Einrichtung ist folgendermaßen: ein Enterprise Integrator 6.4.0 läuft mit dem Port-Offset von Null. In der Entwickler-Studio-Umgebung gestartet und bereit, mit der Erstellung von Proxies zu beginnen.
Wiremock
Wir erstellen einen Mock-Backend-Dienst, den wir verwenden können. Dazu werden wir die Möglichkeit nutzen, einen Mock-Dienst mithilfe einer JSON-Datei zu erstellen. Erfassen Sie z. B. in Notepad++ eine Datei mit dem folgenden Inhalt. Nennen Sie die Datei service.json und speichern Sie sie im Verzeichnis mappings, das unter dem Ort erstellt wird, an dem WireMock gestartet wird.
"request": {
"method": "GET",
"url": "/yenlo/api/test"
},
"response": {
"status": 200,
"body": "Service is respondingn"
}
}
So wird es aussehen:
Da Wiremock auf Port 8080 läuft, müssten wir jetzt in der Lage sein, über den Browser eine Anfrage an den Dienst zu senden, den wir gerade definiert haben. Falls Sie keinen Dienst sehen, starten Sie WireMock bitte neu. Das, was wir hier definiert haben, ist eigentlich eine API, denn wir definieren die Methode, in diesem Fall ist es ein „GET“, sowie die URL, die in diesem Fall /yenlo/api/test verwenden wird.
Wir haben also jetzt ein Backend, das wir aufrufen können, also lassen Sie uns das tun, lassen Sie uns eine API in Developer Studio erstellen.
Ich nehme an, dass Sie mit Developer Studio/Eclipse vertraut sind. Das ist die Entwicklungsumgebung, die häufig für die Entwicklung von EI-Artefakten verwendet wird. Falls Sie damit nicht vertraut sind, schlage ich vor, dass Sie an einer unserer Schulungen zum Enterprise Integrator teilnehmen, in denen wir Ihnen die Verwendung von developer studio beibringen und Ihnen natürlich auch vieles über den Enterprise Integrator beibringen werden.
In SoapUI ruft dies direkt den Endpunkt auf:
Und das ist der Proxy, den wir erstellt haben, und die Antwort.
Ich habe Wire mock gestoppt, so dass es keine Antwort geben wird.
Das ist die Konsolenausgabe, wenn es keine Antwort gibt.
[2019-04-26 15:44:27,476] [EI-Core] WARN - ConnectCallback Connection refused or failed for : localhost/127.0.0.1:8080
[2019-04-26 15:44:27,482] [EI-Core] WARN - EndpointContext Endpoint : AnonymousEndpoint with address http://localhost:8080/yenlo/api/test will be marked SUSPENDED as it failed
[2019-04-26 15:44:27,483] [EI-Core] WARN - EndpointContext Suspending endpoint : AnonymousEndpoint with address http://localhost:8080/yenlo/api/test - current suspend duration is : 30000ms - Next retry after : Fri Apr 26 15:44:57 CEST 2019
[2019-04-26 15:47:26,530] [EI-Core] INFO - SourceHandler Writer null when calling informWriterError
[2019-04-26 15:47:26,531] [EI-Core] WARN - SourceHandler Connection time out after request is read: http-incoming-2 Socket Timeout : 180000 Remote Address : /127.0.0.1:62473Jetzt werden wir ein Protokoll zur FaultSequence hinzufügen
<?xml version="1.0" encoding="UTF-8"?>
<api context="/test" name="EPTest" xmlns="http://ws.apache.org/ns/synapse">
<resource methods="GET"> <inSequence>
<send>
<endpoint>
<http method="get" uri-template="http://localhost:8080/yenlo/api/test"/>
</endpoint>
</send>
</inSequence>
<outSequence>
<send/>
</outSequence>
<faultSequence>
<log description="" level="custom">
<property expression="get-property('ERROR_CODE')" name="Error"/>
</log>
</faultSequence>
</resource>
</api>Wir werden diese API auf dem Server neu bereitstellen und die API erneut aufrufen, ohne dass WireMock läuft.
[2019-05-08 12:40:12,130] [EI-Core] INFO - LogMediator Error = 101503Die faultSequence gibt einfach den Fehlercode zurück, der der Situation „Verbindung fehlgeschlagen“ entspricht. Wir können Folgendes hinzufügen:
<property expression="get-property('ERROR_MESSAGE')" name="MSG"/>Wir erhalten nun den folgenden Fehler:
[2019-05-08 12:56:33,991] [EI-Core] INFO - LogMediator Error = 101503, MSG = Error connecting to the back endDiese Situation ist zwar etwas besser, aber was Sie wirklich zurückgeben würden, ist ein richtiger 404-Code und vielleicht eine Meldung als Antwort (wie ‚Ressource kann nicht gefunden werden‘). Wir setzen den Antwortcode tatsächlich in der FaultSequence.
Wir werden die FaultSequence ein wenig umschreiben. Wir lassen einen Log Mediator eine Ausgabe für die Konsole erzeugen und eine formale Nachricht, die an den Client gegeben wird, der den Proxy aufruft. In der Entwurfsansicht sieht das so aus:
In der Quellansicht sehen wir mehr über die eigentliche Konfiguration. Wir zeigen nur die FaultSequence an.
<faultSequence>
<log description="" level="custom">
<property expression="get-property('ERROR_CODE')" name="Error"/>
<property expression="get-property('ERROR_MESSAGE')" name="MessageSG"/>
<property expression="get-property('ERROR_DETAIL')" name="Detail"/>
<property expression=="get-property('ERROR_EXCEPTION’)" name="Exception"/>
</log>
<property name="HTTP_SC" scope="axis2" type="STRING" value="404"/>
<payloadFactory media-type="json">
<format>{ 'Error':'Connection cannot be made',
'Error Code' : $1,
'Error Message' : $2,
'Error Detail' : $3}</format>
<args>
<arg evaluator="xml" expression="get-property('ERROR_CODE')"/>
<arg evaluator="xml" expression="get-property('ERROR_EXCEPTION')"/>
<arg evaluator="xml" expression="get-property('ERROR_MESSAGE')"/>
</args>
</payloadFactory>
<respond/>
</faultSequence>Die Ausgabe ist:
[2019-05-08 15:02:17,424] [EI-Core] INFO - LogMediator Error = 101503, MSG = Error connecting to the back end, Trace = Error connecting to the back end, exception = nullUnd auf der Client-Seite:
HTTP/1.1 404 Not Found
Host: localhost:8280
Accept-Encoding: gzip,deflate
Content-Type: application/json; charset=UTF-8
Date: Wed, 08 May 2019 13:02:17 GMT
Transfer-Encoding: chunked
Connection: Keep-Alive { 'Error':'Connection cannot be made',
'Error Code' : 101503,
'Error Message' : ,
'Error Detail' : Error connecting to the back end}
Wir haben nun eine API, die mit einer 404 und einer benutzerdefinierten Nachrichtenantwort antwortet. Im folgenden Blog der Endpoint-Serie beschäftigen wir uns mit der Art und Weise, wie man die Fehlerbehandlung für mehrere Fehlercodes einrichtet.
Möchten Sie mehr über WSO2 Enterprise Integrator erfahren? Nehmen Sie an unserer WSO2 Enterprise Integrator Training teil.
