Batchverarbeitung von Nachrichten für die Empfangsverarbeitung

Batch-Rückrufe

Batches, die von Empfangsadaptern an das Messagingmodul übermittelt werden, werden asynchron verarbeitet. Daher benötigt der Adapter einen Mechanismus, um einen Rückruf an einen bestimmten Zustand im Adapter zu binden, damit er über Erfolg oder Fehler benachrichtigt werden kann und alle erforderlichen Bereinigungsaktionen ausführen kann. Die Rückrufsemantik ist flexibel, sodass Adapter eine oder eine Kombination aus drei Ansätzen verwenden können. Diese lauten wie folgt:

• Alle Rückrufe werden in derselben Objektinstanz ausgeführt, die IBTBatchCallBack implementiert.

• Das an das Modul übergebene Cookie beim Anfordern eines neuen Batches wird verwendet, um den Rückruf mit dem Status in den Adaptern zu korrelieren.

• Es gibt ein anderes Rückrufobjekt für jeden Batch, der IBTBatchCallBack implementiert. Hier enthält jedes Objekt einen eigenen privaten Zustand.

  Sobald das Batch verarbeitet wurde, wird der Adapter über seine Implementierung von IBTBatchCallBack.BatchComplete zurückgerufen. Der Gesamtstatus des Batches wird durch den ersten Parameter, den HRESULT-Status, angegeben. Wenn dieser Wert größer oder gleich Null ist, war der Batch erfolgreich, sodass das Modul über den Besitz der Daten verfügt und der Adapter diese Daten aus dem Draht löschen kann. Ein negativer Status gibt an, dass der Batch fehlgeschlagen ist: Keine der Vorgänge im Batch war erfolgreich, und der Adapter ist für die Behandlung des Fehlers verantwortlich.

  Wenn der Batch fehlgeschlagen ist, muss der Adapter wissen, in welchem Element ein Fehler aufgetreten ist. Angenommen, der Adapter liest 20 Dateien vom Datenträger und übermittelt sie mithilfe eines einzigen Batches an BizTalk Server. Wenn die zehnte Datei beschädigt war, müsste der Adapter diese Datei anhalten und die verbleibenden 19 erneut übermitteln. Diese Informationen sind für den Adapter in den zweiten und dritten Parametern verfügbar – opCount (Vorgangsanzahl) des Typs short und operationStatus, das vom Typ BTBatchOperationStatus[] ist.

Die Vorgangsanzahl gibt an, wie viele Arten von Vorgängen im Batch vorhanden waren (die Größe des BTBatchOperationStatus-Arrays ). Jedes Element im Vorgangsstatusarray entspricht einem bestimmten Vorgangstyp. Mithilfe des BTBatchOperationStatus-Arrays kann der Adapter ermitteln, welches Element in einem bestimmten Vorgang fehlgeschlagen ist, indem er das BTBatchOperationStatus.MessageStatus-Array auf negative HRESULT-Werte untersucht, die einen Fehler melden. Im obigen Szenario erstellt der Adapter einen neuen Batch, der 19 Nachrichtenübertragungen und eine Nachrichtenaussetzung enthält.

Das folgende Codefragment zeigt, wie ein Adapter einen neuen Batch vom Modul über seinen Transportproxy anfordert und eine einzelne Nachricht mithilfe des Cookie-Ansatzes an das Modul sendet. Das Messagingmodul ruft die BatchComplete-Methode als Batchrückruf auf, wenn die Verarbeitung des gesamten Batches von gesendeten Nachrichten abgeschlossen wurde.

using Microsoft.BizTalk.TransportProxy.Interop;  
using Microsoft.BizTalk.Message.Interop;  
  
public class MyAdapter :   
                  IBTTransport,   
                  IBTTransportConfig,   
                  IBTTransportControl,  
                  IPersistPropertyBag,   
                  IBaseComponent,  
                  IBTBatchCallBack  
{  
      private IBTTransportProxy _tp;  
  
      public void BatchComplete(      
            Int32                         status,   
            Int16                         opCount,   
            BTBatchOperationStatus[]      operationStatus,   
            System.Object                 callbackCookie)  
      {  
            // Use cookie to correlate callback with work done,  
            // in this example the batch is to submit a single  
            // file the name of which will be in the  
            // callbackCookie  
            string fileName = (string)callbackCookie;  
            if ( status >= 0 )  
                  // DeleteFile from disc  
                  File.Delete(fileName);          
            else  
                  // Rename file to fileName.bad  
                  File.Move(fileName, fileName + ".bad");  
      }  
  
      private void SubmitMessage(  
            IBaseMessage                  msg,   
            string                        fileName)  
      {  
            // Note: Pass in the filename as the cookie  
            IBTTransportBatch batch =   
                  _tp.GetBatch(this, (object)fileName);  
  
            // Add msg to batch for submitting   
            batch.SubmitMessage(msg);   
  
            // Process this batch  
            batch.Done(null);  
      }  
}  

Das BizTalk Server SDK enthält Beispiele für die folgenden Adapter: Datei, HTTP, MSMQ und der Transaktionsadapter. Alle diese Adapter basieren auf einem allgemeinen Baustein namens BaseAdapter. Version 1.0.1 des BaseAdapter enthält den gesamten relevanten Code, um den Vorgangsstatus zu analysieren und einen neuen Batch neu zu erstellen, der übermittelt werden soll.

Racebedingung

Die beiden Aufgaben zum Beheben von Fehlern und die Entscheidung des endgültigen Ergebnisses eines übermittelten Batches scheinen einfach genug zu sein, aber tatsächlich verlassen sie sich auf Informationen aus verschiedenen Threads:

• Der Adapter verarbeitet Fehler basierend auf Informationen, die von BizTalk Server an die BatchComplete-Rückrufmethode des Adapters übergeben werden. Diese Callback-Funktion wird im Thread des Adapters ausgeführt.

• DTCCommitConfirm ist eine Methode für das IBTDTCCommitConfirm-Objekt . Eine Instanz des IBTDTCCommitConfirm-Objekts wird vom Batch-IBTTransportBatch::Done-Aufruf zurückgegeben. Diese Instanz befindet sich im gleichen Thread wie der IBTTransportBatch::Done-Aufruf, der sich vom Callback-Thread des Adapters unterscheidet.

  Für jeden Aufruf, den der Adapter an IBTTransportBatch::Done macht, führt die Messaging Engine einen entsprechenden Aufruf der Rückrufmethode BatchComplete in einem separaten Thread durch, um das Ergebnis der Batchübermittlung zu melden. In BatchComplete muss der Adapter die Transaktion übernehmen oder zurücksetzen, je nachdem, ob der Batch übergeben oder fehlgeschlagen ist. In beiden Fällen sollte der Adapter dann DTCCommitConfirm aufrufen, um den Status der Transaktion zu melden.

  Eine mögliche Racebedingung ist vorhanden, da die Implementierung von BatchComplete davon ausgehen kann, dass das von IBTTransportBatch::Done zurückgegebene IBTDTCCommitConfirm-Objekt immer verfügbar ist, wenn BatchComplete ausgeführt wird. BatchComplete kann jedoch in einem separaten Messaging Engine-Thread aufgerufen werden, auch bevor IBTTransportBatch::Done zurückkehrt. Wenn der Adapter versucht, als Teil der BatchComplete-Implementierung auf das IBTDTCCommitConfirm-Objekt zuzugreifen, besteht eine Zugriffsverletzung, da dieser Aufrufthread nicht mehr vorhanden ist. Verwenden Sie die folgende Lösung, um diese Bedingung zu vermeiden.

  Im folgenden Beispiel wird das Problem mithilfe eines Ereignisses gelöst. Hier wird auf den Schnittstellenzeiger über eine Eigenschaft zugegriffen, die das Ereignis verwendet. Der Vorgang wartet immer, bis der Satz abgeschlossen ist, bevor der Vorgang fortgesetzt wird.

protected IBTDTCCommitConfirm CommitConfirm  
{  
      set  
      {  
            this.commitConfirm = value;  
            this.commitConfirmEvent.Set();  
      }  
      get  
      {  
            this.commitConfirmEvent.WaitOne();  
            return this.commitConfirm;  
      }  
}  
protected IBTDTCCommitConfirm commitConfirm = null;  
private ManualResetEvent commitConfirmEvent = new ManualResetEvent(false);  

Batchstatuscodes

Der Gesamtbatchstatuscode gibt das Ergebnis des Batches an. Der Vorgangsstatus gibt den Übermittlungsstatuscode für einzelne Nachrichtenelemente an. Batches können aus verschiedenen Gründen fehlschlagen. Möglicherweise liegt ein sicherheitsbezogener Fehler vor, oder die Nachricht wurde übermittelt, während die Engine heruntergefahren wurde. (Typischerweise, wenn der Motor heruntergefahren wird, akzeptiert er keine neue Arbeit, lässt aber die laufenden Arbeiten abschließen.) In der folgenden Tabelle sind einige allgemeine HRESULT-Werte aufgeführt, die entweder im Batchstatus oder im Vorgangsstatus zurückgegeben werden. Außerdem wird angegeben, ob es sich um Erfolgs- oder Fehlercodes handelt. Die ordnungsgemäße Behandlung dieser Codes wird in der Behandlung von Adapterfehlern ausführlicher beschrieben.

Batchvorgänge

In der folgenden Tabelle werden die Membermethoden und -vorgänge des IBTTransportBatch-Objekts beschrieben, das der Adapter zum Hinzufügen von Arbeit zu einem bestimmten Batch verwendet.

Batchverwaltung

Batches werden im systemeigenen Code im Messagingmodul implementiert. Aus diesem Grund sollte ein in verwaltetem Code geschriebener Adapter den laufzeitaufrufbaren Wrapper (RCW) für den Batch freigeben, nachdem er mit dem Batch fertig gestellt wurde. Dies erfolgt in verwaltetem Code mithilfe der Marshal.ReleaseComObject-API . Es ist wichtig zu beachten, dass diese API in einer While-Schleife aufgerufen werden soll, bis die zurückgegebene Referenzanzahl null erreicht.

BizTalk Server verarbeitet Nachrichten synchron innerhalb eines Batches. Viele Batches können gleichzeitig verarbeitet werden, was eine Möglichkeit für eine Optimierung im Adapter bietet, indem die Batchgröße in der Anwendungsdomäne angepasst wird. Sie können z. B. alle Dateien auf einer FTP-Website verarbeiten (bis ein Grenzwert erreicht ist). Bei SAP können Sie einen einzelnen Datenstrom in eine Reihe von Nachrichten verarbeiten, die dann als Batch übermittelt werden.

Der Batch, der von einem Adapter zum Übergeben von Vorgängen an BizTalk Server verwendet wird, muss nicht exakt der Liste der Nachrichten entsprechen, die BizTalk Server dem Adapter gibt. Anders ausgedrückt: Beim Senden von Transaktionen müssen Sie die Vorgänge MoveToNextTransport und MoveToSuspendQ in separate Batches aufteilen. Viele Adapter sortieren einen Batch von Nachrichten, die für mehrere Endpunkte übermittelt wurden, in separate Listen von Nachrichten zur weiteren Verarbeitung.

Der Punkt besteht darin, dass es keine Regeln (außer denen, die der Transaktion zugeordnet sind) mit dem Nachrichtenbatching in BizTalk Server verknüpft sind. Die Batchverarbeitung ist einfach eine implementierungsspezifische Methode, mit der der Adapter Nachrichten in und aus BizTalk Server aufteilen kann.

Ein Adapter kann Nachrichten aus mehreren kleineren Batches, die vom BizTalk Server bereitgestellt wurden, in einen größeren Batch für die Antwort an den BizTalk Server stapeln. Dies kann eine erhebliche Optimierung bei Transaktionsadaptern sein, die mit einer großen Anzahl von sehr kleinen Nachrichten zu tun haben. Dadurch wird das Verhältnis "Gesamtanzahl der Transaktionen pro Nachricht" minimiert.

In der Regel erzeugt BizTalk Server Sendebatches von zwischen 5 und 10 Nachrichten. Wenn es sich hierbei um sehr kleine Nachrichten handelt, kann ein Adapter bis zu 100 Nachrichten oder mehr sammeln, bevor er einen transaktionalen Löschbatch an BizTalk Server sendet. Eine Optimierung wie dies ist nicht einfach zu implementieren; Sie müssen sicherstellen, dass Nachrichten niemals im Adapterspeicher hängen bleiben, und warten endlos, bis ein Schwellenwert erreicht wird.

Die Bedeutung der Batchverarbeitung lässt sich in den Leistungsnummern für BizTalk Server für die Adapter mit hohem Durchsatz wie MQSeries erkennen. In diesen Adaptern werden Nachrichten mindestens doppelt so oft empfangen, wie sie gesendet werden. Standardmäßig verwendet der Empfangsadapter Batches von 100 Nachrichten, und der Sendeadapter verwendet den standardmäßigen BizTalk Server-Batch, der angegeben wird.

Transaktionschargen

Wenn Sie einen Adapter schreiben, der ein Transaktionsobjekt erstellt und an BizTalk Server übergibt, übernehmen Sie die Verantwortung für das Schreiben von Code, der die folgenden Aktionen ausführt:

• Entscheidet das endgültige Ergebnis des Batchvorgangs: ob die Transaktion übernommen oder beendet wird. Dies kann von anderen Transaktionszweigen im Rahmen dieser Transaktion abhängen, die nicht von BizTalk Server abhängig sind, z. B. das Schreiben in eine Message Queuing (MSMQ)-Warteschlange oder einen Transaktionsdatenbankvorgang.

• Informiert BizTalk Server über das endgültige Ergebnis, indem die IBTDTCCommitConfirm.DTCCommitConfirm-Methode aufgerufen wird. Die Rückgabe von true zeigt einen erfolgreichen Commit der Transaktion an; die Rückgabe von false signalisiert einen Fehler und das Rollback der Transaktion.

  Der Adapter muss BizTalk Server über das endgültige Ergebnis der Transaktion informieren, um die internen Nachverfolgungsdaten beizubehalten. Der Adapter informiert BizTalk Server über das Ergebnis durch Aufrufen von DTCCommitConfirm. Wenn der Adapter dies nicht tut, tritt ein erheblicher Speicherverlust auf, und es können Zeitüberschreitungen auftreten und die MSDTC-Transaktion fehlschlagen, selbst wenn ihre Vorgänge erfolgreich abgeschlossen wurden.