Angepassten Fehlercode in Mulesoft

Question

Für die meisten Fehler in Mulesoft ist kein Fehlercode definiert. Wenn es nicht weiß, druckt Mule flach MULE_ERROR--2. Stattdessen möchte ich meinen eigenen Fehlercode eingeben, der aus der DB geholt und in die Ausnahme-Payload aufgenommen wird. Danach sollte die Ausnahmebedingung an einen Handler-Flow zur erneuten Übermittlung basierend auf dem Fehlercode gesendet werden. Daher muss ich bei der Fehlerbehandlung eines Teils des Flusses mehr als eine Komponente haben.

Erprobte benutzerdefinierte Ausnahmestrategie, Catch-Ausnahmestrategie, Java-Komponente und Flow-Refs verwenden, aber keine von ihnen funktioniert.

Auch ich baute einen Dummy-Code für diese (ohne den Fehlercode zu holen), um meine eigenen benutzerdefinierten Fehler msg und was ich bemerkte, ist es zweimal den gleichen Fehler, einmal standardmäßig zum ersten Mal und wieder wann Ich habe meinen Fehler msg gesetzt und den Fehler geworfen. Um dies zu unterdrücken, setze ich

<AsyncLogger name="org.mule.exception.CatchMessagingExceptionStrategy" level="FATAL"/> 

in log4j2.xml.

Wird dies zu Problemen führen?

Answer 1

Sie können immer Ihre eigenen Fehler definieren und anpassen. Folgen Sie folgenden Link für weitere Informationen,

http://blogs.mulesoft.com/dev/api-dev/api-best-practices-response-handling/

Unterhalb der Inhalt für die gleiche ist:

Verwenden HTTP-Statuscodes

Einer der am häufigsten missbraucht HTTP-Statuscodes 200 - ok oder Die Anfrage war erfolgreich. Überraschenderweise Sie feststellen, dass eine Menge von APIs 200 verwenden, wenn ein Objekt (Statuscode 201) zu schaffen, oder auch dann, wenn die Antwort ausfällt:

invalid200

Im obigen Fall, wenn der Entwickler allein setzt In dem Statuscode, um zu sehen, ob die Anfrage erfolgreich war, fährt das Programm damit fort, dass es nicht bemerkt, dass die Anfrage fehlgeschlagen ist, und dass es etwas falsch gemacht hat. Dies ist besonders wichtig, wenn Abhängigkeiten innerhalb des Programms vorhanden sind. Der richtige zu verwendende Statuscode wäre 400, um eine "Ungültige Anforderung" anzuzeigen.

Mithilfe der richtigen Statuscodes können Entwickler schnell sehen, was mit der Anwendung geschieht, und eine "schnelle Überprüfung" auf Fehler durchführen ohne auf die Reaktion des Körpers angewiesen zu sein.

Sie können eine vollständige Liste der Statuscodes in HTTP/1 finden.1 RFC, aber nur für eine schnelle Referenz, hier sind einige der am häufigsten verwendeten Statuscodes für RESTful APIs:

200 Ok

201 Erstellt

304 Nicht

Modified

400 Bad Request

401 nicht autorisiert

403 Forbidden

012.351.

Seite 404/Resource Not

405 Methode nicht

415 Typ Nicht unterstützte Medien erlaubt Gefunden

500 Internal Server Error

Natürlich, wenn Sie wirklich kreativ zu sein fühlen möchten, können Sie immer Nutzen Sie den Statuscode: 418 Ich bin eine Teekanne

Es ist wichtig zu beachten, dass Twitter berühmten 420 Status-Code - Enhance Your Calm, i s nicht wirklich eine standardisierte Antwort, und Sie sollten wahrscheinlich nur für zu viele Anfragen auf Statuscode 429 bleiben.

Verwenden Sie deskriptive Fehlermeldungen Auch hier helfen Statuscodes Entwicklern, das Ergebnis ihres Aufrufs schnell zu identifizieren, was schnelle Erfolgs- und Fehlerprüfungen ermöglicht. Aber im Falle eines Fehlers ist es auch wichtig, dass der Entwickler versteht, WARUM der Anruf fehlgeschlagen ist. Dies ist besonders wichtig für die anfängliche Integration Ihrer API (denken Sie daran, je leichter Ihre API zu integrieren ist, desto wahrscheinlicher ist es, dass Benutzer sie verwenden) sowie allgemeine Wartung, wenn Fehler oder andere Probleme auftreten.

Sie wollen, dass Ihr Fehlerkörper gut gebildet und beschreibend ist. Das bedeutet, dem Entwickler zu erzählen, was passiert ist, warum es passiert ist und - am wichtigsten - wie es zu beheben ist.

redx Ihre Anfrage konnte nicht abgeschlossen werden

RedX ein Fehler

redx

Ungültige Anforderung

Nachrichten Allgemeiner Fehler sind aufgetreten eines: Sie sollten über generische oder nicht-beschreibenden Fehlermeldungen wie vermeiden Die größten Hindernisse für die API-Integration, da Entwickler möglicherweise stundenlang damit zu kämpfen haben, herauszufinden, warum der Aufruf fehlschlägt, und sogar die Absicht der Fehlermeldung insgesamt falsch interpretieren. Und schließlich, wenn sie es nicht herausfinden können, hören sie vielleicht auf, alles zu versuchen.

Zum Beispiel kämpfte ich für ungefähr 30 Minuten mit einer API, die versuchte, herauszufinden, warum ich eine "Dieser Anruf ist nicht erlaubt" -Fehlerantwort erhielt. Nachdem ich meine Anfrage wiederholt umformatiert hatte und verschiedene Ansätze ausprobiert hatte, rief ich schließlich (in extrem frustrierter Stimmung) Unterstützung an, nur um herauszufinden, dass es sich um mein Zugriffs-Token handelte, das gerade wegen meiner Unfähigkeit zum Kopieren und Einfügen einen Brief entfernt hatte solche Sachen.

Genauso hätte eine "Invalid Access Token" -Antwort mir eine Menge Ärger erspart und mir das Gefühl gegeben, ein kompletter Idiot zu sein, während ich mit Support unterwegs bin.Es hätte ihnen auch wertvolle Zeit bei der Arbeit an echten Fehlern gespart, anstatt zu versuchen, die grundlegendsten Schritte zu beheben (übrigens - wenn ich einen Fehler erhalte, sind der Schlüssel und das Token die ersten Dinge, die ich jetzt überprüfe).

Hier sind einige weitere Beispiele für beschreibende Fehlermeldungen:

greencheckmark Ihre API-Key ungültig ist, generieren einen gültigen API Schlüssel unter http: // ...

greencheckmark Eine Benutzer-ID ist für diese Aktion erforderlich. Lesen Sie mehr unter http: // ...

greencheckmark Ihr JSON wurde nicht richtig gebildet. Siehe Beispiel JSON hier: http: // ...

Aber Sie können noch weiter gehen, denken Sie daran - Sie werden dem Entwickler sagen müssen, was passiert ist, warum es passiert ist und wie es zu beheben ist. Eine der besten Methoden hierfür ist die Antwort mit einem standardisierten Fehlerformat, das einen Code zurückgibt (für Support-Referenz), die Beschreibung dessen, was passiert ist, und eine Verknüpfung zur entsprechenden Dokumentation, damit sie mehr erfahren/beheben können:

{ "Fehler": { "Code": "e3526", "message": "Missing UserID", "description": "ein Benutzer-ID erforderlich ist, um einen Benutzer zu bearbeiten", "link" : „http://docs.mysite.com/errors/e3526/“ } }

auf einen Träger und Entwicklungsseite indem Sie diese können auch die Zugriffe auf diese Seiten verfolgen, um zu sehen, welche Bereiche zu neigen für Ihre Benutzer problematischer - Sie können eine noch bessere Dokumentation bereitstellen und eine bessere API erstellen.