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.

Ein Kunde kam heute mit einer Orchestration zu mir, die folgende Fehlermeldung beim kompilieren erzeugte:

Error X2016: unexpected token ';'

Wie so oft führt auch hier eine eigentlich extrem kleine Ursache zu dieser Auswirkung. Die Fehlermeldung sagt leider nicht viel aus. Nach kurzer Suche im .odx-Quelltext findet man dann aber zum Glück schnell ein Konstrukt wie

Das sieht nicht nur seltsam aus, sondern ist natürlich auch falsch... Grund war in diesem Fall ein einzelnes Leerzeichen als "Initial Value" der System.String-Variable. Das ist fast schon "fies", da man den Fehler nicht einmal auf den ersten Blick auf die Eigenschaften der Variable erkennen kann (wie im Screenshot zu sehen).

Für string-Variablen muss jeder Initialwert also stets in doppelten Anführungsstrichen stehen.

Die Lösung ist unglaublich einfach - die Frage danach klingt aber alles andere als das *g*. Folgende Fehlermeldung kann beim kompilieren eines BizTalk-Projekts erscheinen.

Error 3: you must specify at least one already-initialized correlation set for a non-activation receive that is on a non-selfcorrelating port.

Die Macher dieser wortgewaltigen Fehlermeldung haben durchaus recht. Damit eine Nicht-aktivierende Receive-Shape (wie übersetzte man das *g*?) auf einem nicht-Selbst-Korrelierenden Port (Anschluss) funktioniert, muss mindestens ein initialisierter Korrelationssatz vorgegeben werden... Das klingt kompliziert - und das ist es auch.

Die andere Seite hätte man - meiner Meinung nach - aber auch dazuschreiben können. Will man keine Korrelationssätze definieren oder braucht man diese erst gar nicht, reicht es auch aus, von einem Nicht-aktivierenden auf einen aktivierenden Port umzustellen. D.h. dass man die Eigenschaft "Activate" des ersten Receive Ports auf "True" stellen muss. Dies dürfte in vielen Fällen auch das gewünschte Verhalten sein...

Was das ist? Ein aktivierender Receive Port initialisiert die Orchestration, sobald eine Nachricht diesem Anschluss zugeordnet wird. D.h. die Orchestration wird nach dem Empfang auf diesem Port ausgeführt. Daher darf es nur einen solchen Receive Port geben (Ausnahmen gibt's mittels Listen- und Parallel-Shape auch hier) und dieser aktivierende Receive Port muss ganz am Anfang stehen (sonst würde man die Orchestration ja zu einem Zeitpunkt aktivieren wollen, zu dem sie bereits läuft).