Freigeben über

Speicher- und Weiterleitungsmodus des SWIFT-Empfangsadapter

  • Artikel

Der Empfangsadapter empfängt Nachrichten aus der SWIFT Store and Forward (SnF)-Warteschlange. Um Nachrichten aus der Warteschlange zu empfangen, muss der Adapter eine Sitzung mit der SnF-Warteschlange öffnen. Um die Warteschlange zu öffnen, muss sie über einen dedizierten Clientprozess verfügen, der die Sitzung mit der Warteschlange festlegt. Im Entwurf wird dieser Prozess als COM plus out-of-proc-Komponente implementiert.

Pushsitzungsspeicher und -Weiterleitungssequenz

In der folgenden Liste wird die Speicher- und Weiterleitungssequenz beschrieben.

  1. Starten Sie die Serveranwendung, die die Nachrichten verarbeitet.

  2. Der Serverprozess öffnet die erforderlichen Sicherheitskontexte beim ersten SwCallback mit sw:HandleInitRequest als Eingabegrundtyp.

  3. Der Server antwortet auf sw:HandleInitRequest, wobei entweder oder beide Sw:CryptoMode und Sw:FACryptoMode auf Erweitert festgelegt sind.

    Der Server kann nun mit der Verarbeitung eingehender Anforderungen beginnen.

  4. Um die Zustellung von Nachrichten aus einer Warteschlange zu starten, startet ein Clientprozess eine Pushsitzung. Basierend auf der Adapterkonfiguration (Pushmodus) erzeugt der Empfangsadapter einen Clientprozess namens SnFQueueManager.exe, um die Warteschlange im Pushmodus abzurufen.

  5. Ein SwCall() wird mit Sw:AcquireSnFRequest (innerhalb der Sw:ExchangeSnFRequest) als Eingabegrundtyp ausgeführt. Diese Anforderung startet eine Sitzung mit der angegebenen Warteschlange (wenn swSec:AuthorisationContext über die erforderliche RBAC-Rolle verfügt).

  6. Unmittelbar nach der Antwort mit "Accepted" in Sw:AcquireStatus beginnt SWIFTNet SnF mit dem Senden von Nachrichten an den Server, wie im Acquire angegeben. Wenn der Empfangsadapter noch nicht gestartet wurde, erhalten Nachrichten Ausnahmen. (Deshalb ist es wichtig, dass die Empfangsadapter bereits gestartet werden.)

  7. SWIFTNet SnF beginnt mit dem Pushen einer Anzahl von Nachrichten (bis zur Fenstergröße).

  8. Für jede bestätigte Nachricht wird eine neue Nachricht (falls vorhanden) gepusht.

  9. Der Clientprozess (SnFQueueManager.exe) hat seine Aufgabe erledigt und kann nun beendet werden. Der Prozess stellt SwSec:DestroyContextRequest aus, wodurch die offenen Sicherheitskontexte bereinigt werden. Nach sw:TermRequest wird der Prozess beendet.

Nachrichtenkorrelation

Das Feld RequestRef wird beibehalten und durch den Empfangsadapter in den Antwortnachrichten ersetzt. Dadurch wird eine End-to-End-Korrelation zwischen der eingehenden Nachricht und der Antwortnachricht sichergestellt.

Duplikatverarbeitung

Wenn eine FileAct-Anforderung empfangen wird und der Adapter instance eine Nachricht mit einem Knoten "Möglicher doppelter Indikator" empfängt, muss er überprüfen, ob die referenzierte Übertragung bereits erfolgreich abgeschlossen wurde oder ob ein Fehler aufgetreten ist, und die entsprechende Aktion ausführen. Wenn die Dateiübertragung bereits stattgefunden hat, aktualisiert der Adapter die Übertragung status als "Duplikat", andernfalls aktualisiert er sie als "Akzeptiert".

Danksagungen

Wenn der Absender eine Bestätigung für eine FileAct-Anforderung anfordert, überprüft der Adapter nach dem Abschlussereignis der Dateiübertragung und generiert die Bestätigung, nachdem der Wert des Datei digest überprüft wurde. Der Adapter sendet die Bestätigungsnachricht an BizTalk, damit der Sendeadapter sie abholt und an den Absender sendet.

Weitere Informationen

Architektur des SWIFT-Empfangsadapters
URI des SWIFT-Empfangsadapters
Initialisierung des SWIFT-Empfangsadapters
Sicherheitskontext des SWIFT-Empfangsadapters
Synchroner und verzögerter Modus des SWIFT-Empfangsadapters