In einer Orchestration bekommt man es normalerweise nur noch mit den eigentlichen Daten einer Nachricht zu tun. So sind bei EDIFACT-Nachrichten z.B. die UNA- und UNB-Segmente nicht Teil des Schemas. Weiterhin fehlen auch die AS2-Header und eben alles, was nicht unbedingt benötigt wird. Das hat seine Vorteile (ist aufgeräumt), manchmal wird aber auch der Zugriff auf diese Daten benötigt.

Läuft eine Nachricht mal auf einen Fehler, so kann man in den "Message Details" erkennen, dass verschiedene "Context-Properties" aus eben diesen sonst nicht sichtbaren Segmenten (oder aus dem Protokoll) zu den einzelnen Nachrichten zugewiesen sind.

Auf diese Kontexteigenschaften kann man mittels Message(ContextProperty) innerhalb einer  Expression Shape zugreifen. Im Falle von EDIFACT-Eigenschaften muss aber - damit man die Auswahl der Context Properties überhaupt zu sehen bekommt - noch eine Referenz auf die DLL Microsoft.BizTalk.Edi.BaseArtifacts (oft zu finden unter C:\Program Files\Microsoft BizTalk Server 2006\Microsoft.BizTalk.Edi.BaseArtifacts.dll) zum Projekt hinzugefügt werden.

Mit dieser Referenz sind dann Kontexteigenschaften in den Namespaces EDI (für EDIFACT und X12 - Eigenschaften) und EdiIntAs (für AS2 - Eigenschaften) vorhanden.

Nach der Checkliste für das Empfangen von Nachrichten über AS2, muss quasi ja auch eine Checkliste für das Senden bereitgestellt werden ;) Diese Liste ist wesentlich kürzer, wenn es auch mehr Möglichkeiten gibt, als hier dargestellt...

1. Send Port
   - für asynchrone MDN: One-way
   - für synchrone MDN: Solicit-Response
   • Type: HTTP
     • Destionation URL: Die URL, die beim Partner eingerichtet wird (auf beiden Seiten sollte die URL exakt gleich angegeben werden - inkl. Groß-/Kleinschreibung)
     • Enabled chunked encoding deaktivieren
   • Send pipeline
     • AS2Send (für alle möglichen Daten),
     • AS2EDISend (für EDI-Daten) oder
     • eine eigene Send Pipeline, in der die AS2 Encoder-Component verwendet wird
2. Sender Party
   • General
     • Send Ports (den oben erstellen Port auswählen, alternativ geht die Zuweisung auch über einen Role Link oder wie unten beschrieben über den Alias-Namen)
   • AS2 Properties -> Party as AS2 Message Receiver (nicht verwirren lassen)
     • Einstellungen ab "Outbound AS2 Message" entsprechend der Vereinbarung mit dem Partner einstellen
     • AS2-From und AS2-To erscheinen wie hier angegeben im Head-Bereich der Nachricht und damit beim Partner
3. Asynchrone MDNs müssen - wie eine beliebig andere AS2-Nachricht - empfangen werden können. An welche Adresse die MDN geschickt wird, kann in den Party-Einstellungen angegeben (Receipt-Delivery-Option) werden. Um die Verarbeitung dieser Nachrichten kümmert sich allerdings der BizTalk-Server selbst.

Die Party Resolution für ausgehende Nachrichten (also das Finden der Party, die die Nachricht empfängt und bei der die entsprechenden Einstellungen vorgenommen wurden) kann auch anders erfolgen. Das zuweisen des Send-Ports zu einer Party wird aber (meiner Erfahrung nach) sehr häufig verwendet. Es sollte allerdings auch ausreichen, einer Party einen EDIINT-AS2-To - Alias und der ausgehenden Nachricht den AS2-To - Header zuzuweisen - getestet hab ich das noch nicht.

Für die Signierung und Verschlüsselung der Nachricht und der Signierung der MDN müssen zusätzlich Zertifikate installiert und an bestimmten Stellen ausgewählt werden, die in dieser kleinen Übersicht beschrieben werden.

Um über BizTalk-HTTP-Adapter AS2 Daten empfangen zu können, müssen gleich ein paar Einstellungen passen. Ein kleiner Überblick über die wichtigsten Einstellungen soll hiermit geschaffen werden:

1. Virtuelles Verzeichnis für den Empfang der Nachrichten über HTTP
   • Local Path: Verzeichnis, in dem die Datei BTSHttpReceive.dll liegt, z.B. C:\Program Files\Microsoft BizTalk Server 2006\HttpReceive\ bzw. C:\Program Files\Microsoft BizTalk Server 20009\HttpReceive\
   • Execute permissions: Scripts and Executables
   • Identität des zugewiesenen Application Pools muss ein Benutzer sein, der Zugriff auf die BizTalk-Datenbank hat, in der Regel wird hier BTSIsolatedHostUser verwendet
   • In welcher Web Site das virtuelle Verzeichnis liegt (es kann natürlich auch die Web Site direkt verwendet werden) ist dabei egal. Allerdings sollte man bei mehreren Web Sites darauf achten, dass der virtuelle Pfad über alle Web Sites hinweg eindeutig ist, da man innerhalb der Receive Location die betroffene Web Site nicht mit angeben kann.
2. Receive Port anlegen
   • Keine oder asynchrone MDN: One-Way
   • MDN synchron: Request-Response
3. Receive Location anlegen
   • Type: HTTP-Adapter
     • Virtual directory plus ISAPI extension: z.B. /virtualDirectory/BTSHttpReceive.dll.
       Wie oben erwähnt, können die Web Sites des IIS hier nicht angegeben werden. Nur der virtuelle Pfad (ausgehend vom root-Verzeichnis)
     • Es kann ein beliebiger QueryString an die DLL angehängt werden. Damit können - mit nur einem virtuellen Verzeichnis - für verschiedene Kunden und/oder Dokument verschiedene Receie Locations definiert werden (an sich braucht man damit nur ein virtuelles Verzeichnis im IIS einrichten).
       Dieser Querystring muss exakt genauso auch im sendenden Programm angegeben werden (mit exakt ist Reihenfolge, Groß-Kleinschreibung und Umfang gemeint...).
     • Die Einstellung Suspend failed requests aktivieren
   • Receive Pipeline
     • AS2Receive: Wenn beliebige Daten per AS2 empfangen werden sollen
     • AS2EdiReceive: Wenn EDIFACT-Nachrichten per AS2 empfangen werden sollen
     • oder eine selbst-erstellte Pipeline, die die AS2 decoder-Component verwendet
4. Sender-Party
   • Party Properties
     • Damit der Firmeneintrag beim Empfang der Datei gefunden werden kann, muss als EDIINT-AS2 From Value (AS2-From) der, zwischen den Partnern ausgemachte Name angegeben werden. Der Name sollte nur aus ASCII-Zeichen bestehen
   • AS2 Properties, Party as AS2 Message Sender
     • Hier kann man eigentlich alles auf Standard lassen (keine Checkbox aktiv). Damit gibt der Sender vor, wie die Datei zu behandeln ist.
     • Man kann den Sender auch zu bestimmten Einstellungen zwingen. Dazu die Checkbox Override inbound message properties aktivieren und die Einstellungen in der Gruppe Incoming AS2 message anpassen
     • Wenn die MDN signiert werden soll, dann kann das erreicht werden, indem die Checkbox Sign requested MDN if Disposition-Notification-Option header is not present or if Signed-Receipt-Protocol header is set to optional aktiviert werden. Der Sender darf das allerdings nicht ausschließen...
5. Empfänger-Party (aktueller Rechner)
   Beim Empfänger in diesem Fall nicht viel Einstellbar. Hier geht es primär um die MDN, die versendet wird
   • Party Properties
     • Damit die Einstellungen der Firma verwendet werden können, muss als EDIINT-AS2 To Value (AS2-To)-Wert der zwischen den Partnern ausgemachte Name für den Empfänger angegeben werden
6. Send Port oder Orchestration zum Verarbeiten der ankommenden Daten
   • Damit keine Fehlermeldung angezeigt wird, muss die Datei auch verabeitet werden - und das kann man nur erreichen, indem man entweder
     • den oben erstellen Receive Port einer Orchestration zuweist (Bindings -> Inbound Logical Port), oder
     • einen Send Port erstellt und den Filter so anpasst, dass die ankommenden Nachrichten über diesen Port verarbeitet werden (z.B. über die Eigenshaft BTS.ReceivePortName)

Zugegeben, wirklich kurz ist die Liste nicht ;) Dennoch sind nur die notwendigsten Einstellungen beschrieben.

Falls die Nachrichten und MDNs signiert und/oder verschlüsselt werden sollen, hab ich im Artikel BizTalk: Wohin mit den AS2-Zertifikaten entsprechende Einstellungen beschrieben.

Update: Punkt 6 hat zwar an sich nichts mehr mit dem Empfang der Daten zu tun, kam aber dennoch dazu, da der Punkt offenbar oft vergessen / übersehen wird (hat man mir berichtet).

Will man Nachrichten mittels AS2 verschlüsselt oder signiert versenden oder eine verschlüsselte oder signierte Nachricht empfangen, so muss man sich zwangsläufig mit Zertifikaten auseinandersetzen und diese an bestimmte Stellen (Zertifikatsspeicher) ablegen und an ebenso genau definierten Stellen in der BizTalk Administration Console auswählen.

Am Einfachsten macht man sich die Arbeit, wenn man das SDK-Tool "Certificate Wizard" (unter C:\Program Files\Microsoft BizTalk Server 2006\SDK\Utilities\Certificate Wizard\CertWizard.exe bzw. im Verzeichnis BizTalk Server 2009 zu finden) verwendet. Dieses Tool kopiert je nach Einstellung die Zertifikatsdateien in die entsprechenden Zertifikatsspeicher. Wer es manuell machen oder einfach nur überprüfen will, der kann sich an folgender Liste orientieren.

Das Auswählen des Zertifikats innerhalb der BizTalk Server Administration Console muss zudem auch noch an entsprechenden Stellen erfolgen. Auch hier hilft die Liste weiter.

Nachrichten

MDN

^* Für die ausgehende Signierung kann seit BizTalk Server 2006 R2 SP1 das Zertifikat anstatt bei der BizTalk Group auch bei der Party direkt angegeben werden.

Zertifikatsspeicher

Die Zertifikatsspeicher sind nicht ganz einfach zu finden. Man kann aber wie folgt vorgehen. Bestenfalls legt man sich eine eigene Administrationskonsole an.

• mmc.exe starten
• Menü "File" -> "Add/Remove Snap-In..."
• Button "Add..."
• "Certificates" auswählen und mit "Add" bestätigen
• "Computer Account" auswählen
• weiter bis Finish
• "Certificates" auswählen und mit "Add" bestätigen
• "My User Account" auswählen

Leider kann man keinen speziellen Benutzer auswählen. Die Datei kann aber als *.msc-Datei gespeichert werden und danach mit der rechten Maustaste mittels "Run as..." mit einem anderen Benutzer gestartet werden. Hier kann dann der BTSHostUser und der BTSIsolatedHostUser eingetragen werden. Nicht schön, aber hilfreich ;)

Heute stieß ich auf einen mir seltsam erscheinenden Fehler. Ich hatte AS2-Daten von einem Partner bekommen und habe diese eingerichtet. Beim ersten Test kam es dann gleich zum Fehler 404 "File not found" bzw. "Datei nicht gefunden". Das wollte ich prüfen und nachdem ich die URL in den Browser eingegeben hatte, erschien auch die selbe Fehlermeldung. Beim Aufruf des Verzeichnisses wurde die Datei allerdings noch - wie im Bild zu sehen - angezeigt.

Die Datei ist also vorhanden. Verwirrend.

Die Lösung ist ganz einfach, wenn man sie denn kennt ;) Innerhalb der Web Service Extensions im IIS Manager muss diese DLL eingetragen und die Ausführung erlaubt werden.