I had a working piece of code doing exactly this but I had to redo it using a pipeline componentan instead of an orchestration.

Everything is straightforward. If you had set the context value in your orchestration like this:

EmailOut(SMTP.MessagePartsAttachments) = 2;

you would take a look in the msdn to get the values right and then translate it to the following code in your pipeline component:

inmsg.Context.Write(“MessagePartsAttachments”,
“http://schemas.microsoft.com/BizTalk/2003/smtp-properties”, 2);

I did this with every context value and tested it. It worked well but there was no attachment?! But there was also no error!

Finding the solution took me more time then I am willing to admit…

If you take a sharp look in the MSDN then you might find this:

[SerializableAttribute]
[GuidAttribute("9EE763F5-ECE7-42f6-BE97-38EA64FB7607")]
[IsSensitivePropertyAttribute(false)]
[PropertyGuidAttribute("9EE763F5-ECE7-42f6-BE97-38EA64FB7607")]
[PropertyTypeAttribute("MessagePartsAttachments",
"http://schemas.microsoft.com/BizTalk/2003/smtp-properties",
"unsignedInt", "System.UInt32")]
public sealed class MessagePartsAttachments : MessageContextPropertyBase

I was desperate at best and tried everything and this one worked:

inmsg.Context.Write(“MessagePartsAttachments”,
“http://schemas.microsoft.com/BizTalk/2003/smtp-properties”, (UInt32)2);

You cannot see any difference at all if you take a look at a suspended/tracked message but this was the cause of the missing attachments. I hope this might save you some time!

---
Unterstütze mich und meinen Blog und kauf dir was Nettes (über diesen Link)

Man kann die Startzeit nicht im Anfang und im Ende begrenzen, wie der Screenshot zeigt. Allerdings kann man den Anfang angeben und dann die Ergebnisse zeitlich aufsteigend sortieren lassen.

---
Unterstütze mich und meinen Blog und kauf dir was Nettes (über diesen Link)

Die anderen Überladungen von Match() tun dann aber ihren Job richtig…

---
Unterstütze mich und meinen Blog und kauf dir was Nettes (über diesen Link)

Der Geek hat gesprochen

---
Unterstütze mich und meinen Blog und kauf dir was Nettes (über diesen Link)

Folgendes Snippet erfüllt den Job aber als Einzeiler:

File.WriteAllText("c:\\streamOut.txt", new StreamReader(meinStream).ReadToEnd());

Zu beachten ist, dass je nach Typ von meinStream die Position anschließend zurück gesetzt werden muss oder auch, das dies gar nicht möglich ist und daher die weitere Programmausführung fehlerhaft wird.

---
Unterstütze mich und meinen Blog und kauf dir was Nettes (über diesen Link)

Ich hatte nun den Fall, dass ich neben dem schon existierenden Pfad(linker Teil der Grafik) einen zusätzlichen Fall hatte, bei dem ein Direct Receive aus der MessageBox nötig war. Kommt die Nachricht aus der MessageBox, ist (für diesen Fall) klar, dass es keine Folgenachrichten gibt.

Man kann eine Orchestration nun nicht nur über ein Receive-Shape starten lassen, sondern auch auch über mehrere Receives, die in einem Listen-Shape untergebracht wurden. Das hatte ich dann auch versucht.

Auch wenn aus logischer Sicht kein Pfad möglich ist, der vom Direct Receive zum “Receive Follower” führt, verwehrt BizTalk die Kompilierung dieser Orchestration.

Der Versuch, den Receive aus dem Receive Port durch einen Filter auf der MessageBox zu formulieren fruchtete ebenfalls nicht. Finales Ergebnis war, die gemeinsame Funktionalität in einer separaten Orchestration auszulagern und für den Direct Receive eine zusätzliche Orchestration zu bauen, die einen Call macht.

Außerdem ist die Fehlermeldung “unknown system error” auch sehr hilfreich beim Finden des eigentlichen Problems, denn eigentlich ist die Orchestration viel größer, als hier auf dem Screenshot zu sehen.

---
Unterstütze mich und meinen Blog und kauf dir was Nettes (über diesen Link)