Synchrone Messages
Synchrone Messages habe die Quality-of-Service-Ausprägung Best Effort. Die Anwendung hat auf der einen Seite dafür zu sorgen, dass keine doppelten Messages oder Datenverluste entstehen. Auf der anderen Seite erhält die Anwendung Error-Messages. Best Effort bedeutet darüber hinaus, dass keine transaktionalen Konzepte einbezogen sind.
● Wenn ein Adapter eine synchrone XI-Message empfängt, dann muss er entweder synchron eine Response-Message oder im Fehlerfall eine Exception schicken. Im Falle eines technischen Fehlers kann der Adapter ebenfalls einen Exception schicken. Die Exception wird vom Adapter-Framework Messaging-Service in eine SystemError-Message umgewandelt und an den Integration Server zurückgeschickt.

Synchrone Response-Message: Öffnen Sie hierzu XIAdapterCategories.java und suchen Sie nach der Zeichenkette CS_SYNCRESP.
Application Error: Öffnen Sie hierzu CCIInteraction.java und suchen Sie nach der Zeichenkette CS_SYNCAPPERR.
● Wenn ein Adapter eine synchrone Message an den Adapter-Framework Messaging-Service weiterleitet, dann wird die Response-Message auf dem genau umgekehrten Weg an den Adapter zurückgeschickt.
● Wenn Sie das Standardmodul ModuleProcessorExitBean verwenden, um den JCA-Adapter aufzurufen, dann verwendet das Modul XIInteractionSpec, um den synchronen Message-Transfer zu spezifizieren. Setzen Sie in diesem Fall den Funktionsnamen für XIInteractionSpec auf XIInteractionSpec.CALL.
Wenn ein Adapter solch ein XIInteractionSpec empfängt, dann muss er einen instanziierten und gefüllten XIMessageRecord (im Falle einer erfolgreichen Response-Message oder eines Application-Errors) in den Aufruf von XIInteractionSpec.execute() oder im Fehlerfall XIDeliveryException oder XIRecoverableException zurückgeben.
● Wenn Sie das Standardmodule ModuleProcessorExitBean nicht verwenden, dann können Sie für die Adapterimplementierung eigene Kommunikationsmuster definieren, die das CCI InteractionSpec ersetzen.
Ihr letztes eigenes Modul muss jedoch eine Response-Message an den aufzurufenden Modul-Prozessor zurückschicken, wie im Beispiel unten angegeben.
● Folgende Methoden stehen Ihnen zur Verfügung, um Fehlerinformationen in Form eines ErrorInfo-Objekts aus der Message zu lesen oder in einer Message zu setzen:
○ Message.getErrorInfo()
○ Message.setErrorInfo()
Sie können folgende ErrorInfo-Attribute lesen oder setzen:
Name |
Beschreibung |
ErrorCode |
Anwendungsfehlercode |
ErrorArea |
Sollte den Adapter-Namespace und den Adaptertyp enthalten. |
ErrorCategory |
Muss zwingend auf Application gesetzt sein. |
AdditionalErrorText |
Text zum Anwendungsfehler |
ApplicationFaultInterface |
Legt das Interface im Integration Repository fest, das Anwendungsfehler-Messages bearbeitet. |
ApplicationFaultInterfaceNamespace |
Namensraum des Interface |
Zum Lesen und Setzen der Attribute stehen Ihnen folgende Methoden zur Verfügung:
○ ErrorInfo.setAttribute()
○ ErrorInfo.getAttribute()
○ ErrorInfo.getSupportedAttributeNames()
…
try {
myRespMsg = myAdapter.call(myReqMsg);
if (myRespMsg != null) //synchronous
moduleData.setPrincipalData((Object) myRespMsg.getXIMessage());
else // asynchronous
moduleData.setPrincipalData(null);
…
catch(Exception e) {
{
//Assumption: All errors are temporarily
TRACE.catching(SIGNATURE, e);
RecoverableException re = new RecoverableException(xre);
ModuleException me = new ModuleException("Temporary error: Adapter call failed. Reason: " + e.getMessage(), e);
TRACE.throwing(SIGNATURE, me);
throw me;
}
…