none
Subscription geht "verloren"

    Frage

  • Ein freundliches Hallo in die Runde!

    Ich habe ein seltsames Problem mit einer Subscription, die nach einer gewissen Zeit verloren geht. Das Problem tritt auf unserer Entwicklungsumgebung (BT 2009, 32-Bit) nicht auf, leider jeodch in der Test- (BT 2009, 32-Bit) und Integrationsumgebung (BT 2009, 64-Bit) eines Kunden. 

    Folgendes Szenario:

    Für den Empfang zweier zusammengehöriger Nachrichten (TIF Datei und XML Datei mit Informationen zum entsprechenden TIF-Dokument) in einer Orchestrierung verwende ich das Parallel Convoy Pattern (http://msdn.microsoft.com/en-us/library/ms942189). Hierbei wird ein Parallel Shape verwendet, das an zwei logische  Empfangsports (Physikalisch File Adapter) gebunden ist. Beide Dateien haben den gleichen Namen,  sie unterscheiden sich lediglich in der Endung ("12345.xml" und "12345.tif"). Um diese zusammen zu bekommen, korreliere ich auf den FileReceiveName und manipuliere hierzu in einer Custom Pipeline den Filenamen. In der Pipeline werden Pfad und Endungen entfernt und der manipulierte Filename über FileReceiveName in den Context geschrieben. Funktioniert grundsätzlich, wie bereits erwähnt, in der Entwicklungsumgebung.

    Auf der Test- und Integartionsumgebung funktioniert das ganze für eine gewisse Zeit auch. Dann kommt es jedoch irgendwann zu den klassischen "The published message could not be routed because no subscribers were found" Fehlern. Aus irgendeinem für mich unerklärlichen Grund gehen die Subscriptions flöten.

    Wenn man sich die Subscriptions auf den fehlerhaften Umgebungen genauer anschaut, sind folgende Angaben in den "Subscription Details" zu sehen: 
    http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {8C892C6A-F421-451D-8D5B-5F2AC47708CA}  And
    http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == http://SchemaXYZ#Root  And
    . Exists 

    Im dritten Filter müsste normalerweise http://schemas.microsoft.com/BizTalk/2003/file-properties.ReceivedFileName Exists stehen, aber scheinbar geht hier das Property verloren.

    Hatte hier schon jemand ähnliche Probleme?

    Beste Grüße,
    BartBuckel    

     

    • Bearbeitet BartBuckel Dienstag, 23. November 2010 17:19 Ergänzung
    Dienstag, 23. November 2010 17:14

Alle Antworten

  • Hallo BartBuckel,

     

    unabhängig von deiner fehlenden Subscription, ist sichergestellt, dass die TIF Datei nicht als erstes ankommt?

    Ich nehme an, die Pipeline für die XML Datei beinhaltet einen XMLDisassembler, die TIF der Datei nicht. Daher trifft die subscription oben immer nur auf die XML Datei zu. Oder setzt du in der Custom Pipeline auch den Messagetype? Wenn nicht, würde dieser Fehler immer auftauchen, wenn die TIF Datei zuerst im dem Verzeichnis liegt bzw. zuerst gefunden wird. Vielleicht kannst du uns noch sagen, warum Convoy und warum du die TIF Datei als normale Message mit in deine Orchestration aufnimmst (SMTP Attachment?)?

     

    Meine persönliche Meinung ist, dass ich hier das Pattern nicht anwenden würde. Ich weiss leider nicht, was genau du später mit den zwei Dateien vorhast, aber das Pattern nehme ich persönlich nur, wenn ich wirklich "sauber" auf zwei XML Dateien warte. Ich würde eine dieser zwei Alternativen wählen:

    1. Receive Shape für XML startet den Prozess und dann ein zweites Receiveshape mit Correlation dass auf die TIF Datei wartet (aber ohne Convoy)

    2. Einen WCF Service dem du den Pfad angibst und der dir den Dateiinhalt über MTOM zurückgibt.

     


    If you like my post or consider it as a valid answer, please use the buttons to show me - Oliver

    http://pi.hauth.me

    Donnerstag, 25. November 2010 06:22
  • Hallo Oliver,

    herzlichen Dank für Deine Antwort.

    Das Pattern wurde genau aus dem Grund gewählt, da es möglich ist, zwei zusammengehörige Dateien aufzunehmen. Wie bereits geschrieben, funktioniert das Szenario auf dem Testsystem problemlos. Auch völlig unabhängig davon, in welcher Reihenfolge die Dateien in den Empfangsordner eingespielt werden.

    Ja, die Pipeline für den Empfang der XML Datei verfügt über einen XML Disassembler, die der TIF Datei nicht. Die Korrelation bzw. Subscription wird duch die Manipulation der Dateinamen ("12345.tif" und "12345.xml" = "12345") sichergestellt, muss m.E. also in dem Fall nicht über den Messagetype erfolgen.

    Ich habe das folgende Szenario als Basis genommen: http://www.paulvanbrenk.com/blog/CategoryView,category,BizTalk.aspx

    Bevor ich das an sich funkionierende Szenario über den Haufen werfe, würde ich gerne verstehen, weshalb BizTalk hier so tickt. Ich befürchte auch dass die erste Alternative nicht funktionieren wird, da nicht sichergestellt werden kann, welche Datei als erste in das Verzeichnis kopiert bzw. von BizTalk aufgenommen wird. 

    Beste Grüße,

    BartBuckel

    Montag, 29. November 2010 11:10
  • Hallo,
     
    Parallel Convoys werden nach meiner Erinnerung nicht in den Subscriptions vollständig angezeigt. Ich würde hier eher eine Race Condition vermuten - wie gross ist die Batch Size der Receive Location? Setze diese mal auf "1" so dass die Dateien nicht zusammen in einer Transaktion einlaufen.
     
    Warum verwendest Du zwei Receive Ports in der Orchestration und nicht einen mit zwei Operations?
     
    Auch eingangsseitig würde ich einen Receive Port mit zwei Locations verwenden.
     
    Grüße
     
     
    Jörg
     
    "BartBuckel" schrieb im Newsbeitrag news:7adfbabc-807b-46a3-b765-813623520766...

    Hallo Oliver,

    herzlichen Dank für Deine Antwort.

    Das Pattern wurde genau aus dem Grund gewählt, da es möglich ist, zwei zusammengehörige Dateien aufzunehmen. Wie bereits geschrieben, funktioniert das Szenario auf dem Testsystem problemlos. Auch völlig unabhängig davon, in welcher Reihenfolge die Dateien in den Empfangsordner eingespielt werden.

    Ja, die Pipeline für den Empfang der XML Datei verfügt über einen XML Disassembler, die der TIF Datei nicht. Die Korrelation bzw. Subscription wird duch die Manipulation der Dateinamen ("12345.tif" und "12345.xml" = "12345") sichergestellt, muss m.E. also in dem Fall nicht über den Messagetype erfolgen.

    Ich habe das folgende Szenario als Basis genommen: http://www.paulvanbrenk.com/blog/CategoryView,category,BizTalk.aspx

    Bevor ich das an sich funkionierende Szenario über den Haufen werfe, würde ich gerne verstehen, weshalb BizTalk hier so tickt. Ich befürchte auch dass die erste Alternative nicht funktionieren wird, da nicht sichergestellt werden kann, welche Datei als erste in das Verzeichnis kopiert bzw. von BizTalk aufgenommen wird. 

    Beste Grüße,

    BartBuckel


    Jörg Fischer
    Montag, 29. November 2010 12:20
    Moderator
  • Hallo Jörg,

    vielen Dank für Deine Antwort.

    Ich habe die Batch Size entsprechend auf "1" konfiguriert, leider mit dem selben Ergebnis. Weshalb ich zwei Receive Ports in der Orchestrierung verwende anstatt einem Port mit zwei Operations? Um ehrlich zu sein gibt es hierfür keinen Grund. Zwei Operations auf einem Port ist natürlich eleganter und erspart einen Port.  

    Es gibt rein von der BizTalk Konfiguration her zwischen dem Entwicklungssystem und den anderen Systemen nur einen Unterschied. Auf dem Entwicklungssystem ist die Subscription in den "Subscription Details" folgendermaßen definiert:

    http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {8C892C6A-F421-451D-8D5B-5F2AC47708CA}  And
    http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == http://SchemaXYZ#Root  And
    http://schemas.microsoft.com/BizTalk/2003/file-properties.ReceivedFileName Exists

    Auf den anderen beiden Systemen dagegen folgendermaßen:

    http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {8C892C6A-F421-451D-8D5B-5F2AC47708CA}  And
    http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == http://SchemaXYZ#Root  And
    . Exists 

    Das Property "http://schemas.microsoft.com/BizTalk/2003/file-properties.ReceivedFileName" ist in den "Subscription Details" nicht existent. Wenn ich mir jedoch die Context Properties der suspendenten Nachrichten anschaue, ist zu erkennen, dass ReceivedFileName von der Custom Pipeline korrekt promoted und aufbereitet wurde, sowohl bei dem TIF- als auch bei der XML-Datei.

    Ich habe spaßeshalber noch zwei"Ersatz" Ports eingerichtet und die Konfiguration der Anwendung auf diese angepasst. Aktuell werden die Dateien wieder korrekt verarbeitet. Es ist nur eine Frage der Zeit, bis es wieder knallt und die Subscription sich wieder verflüchtigt.

    Ich falle langsam vom Glauben ab...

    Beste Grüße,

    BartBuckel

     


    Montag, 29. November 2010 15:40