Sending attachments through a Dynamic Send Port

I spent a bit of time getting a Dynmic Send Port to email a message to a recipient as a text attachment (regardless of the filename suffix).  The following documents the properties that need to be set on the message, and corresponding send port.

1. Create the message (“msgEnvelope”) as a Multi-Part message, with the required message in the Message Body Part (“Attachment”)
2. Set the following properties of the Envelope Message:
   msgEnvelope(SMTP.Subject) = <Email Subject>;
msgEnvelope(SMTP.From) = <Sender Email>;
msgEnvelope(SMTP.SMTPHost) = <Email Host name>";
// This is the default value
msgEnvelope(SMTP.SMTPAuthenticate) = 0;
// Set the message text included in the email
msgEnvelope(SMTP.EmailBodyText) = <Text in body of email>;
// Important - This is required if the EmailBodyText is set
msgEnvelope(SMTP.EmailBodyTextCharset) = "utf-8";
// A value of '1' means include Message Body Part as email attachment
msgEnvelope(SMTP.MessagePartsAttachments) = 1;
3. Set the following properties of the Message Body Part (“Attachment”):
   // Important - Change this MIME type if not sending a Text file
msgEnvelope.Attachment(Microsoft.XLANGs.BaseTypes.ContentType) = "text/plain";
// Set the Filename of the attachment
msgEnvelope.Attachment(MIME.FileName) = <Physical name of the attachment>;

4. Set the following property on the Dynamic Send Port:
   // We set the Email Address on the Port itself
Dynamic_Send_Port(Microsoft.XLANGs.BaseTypes.Address) = <recipient email address>;


The Send Port is then configured to use a custom Send Pipeline containing a Flat File assembler for the message schema to convert the message into the flat file.

PersistenceException

I finally managed to work out why I was receiving the dreaded “PersistenceException”.  There’s not a lot of helpful information surrounding this one, you just get:

Microsoft.XLANGs.Core.PersistenceException: Exception occurred when persisting state to the database

Most of the posts I Googled for were incorrectly diagnosing it as occuring due to no subscription being set up in the Message Box.  However, this was on a late bound Send-Receive port, and the subscription appeared good in the Group Hub.

Finally, I worked it out!  It was being caused due to a duplicate subscription in the Message Box.

I had another Orchestration that was direct bound on the same Message Type that I was trying to send via the Send Port.  Somehow, this causes BizTalk to get in a huff, but not really give any worthwhile error information.

So, whenever you find yourself with a “PersistenceException”, try looking for a duplicate subscription.

Calling the Business Rules Engine from .Net code

I recently had a chicken-and-egg request from a customer.

They wanted to be able to see how their data would appear after being processed by their BizTalk orchestration, but without actually passing the data through the orchestration (as this would change the state in their database).  Complicating this, the outgoing data is processed by a set of Policies using the Business Rules Engine (BRE).

Here’s the steps I undertook:

• Generate a strongly-typed version of the target schema.  This is done using the xsd.exe tool included in the Visual Studio SDK.
  

  xsd.exe biztalktalk.targetschema.xsd /class /namespace:http://biztalktalk.targetnamespace/1.0.0.0/

  Include the resultant .cs file in your project.

• First thing is to apply the Business Rules to the source document.  This mirrors the approach we’ve taken through the Orchestration.
• In code, we create an instance of the Rules Engine:
  

  TypedXmlDocument typedDoc = new Microsoft.RuleEngine.TypedXmlDocument(document, docType);
  Policy pol = new Policy(ruleName);
  pol.Execute(typedDoc);
  pol.Dispose();

  Where document is the source document, and docType is the fully qualified document type (i.e. AssemblyName.ClassName) of the source document.

• If you have multiple rules in multiple policies, you will need to set-up (and dispose) a new Policy object for each rule-set.
• The above step makes changes directly to the wrapped “document” XML document.  After this step, you can use the old document with the Business Rule changes applied.

Now we want to format the source document according to the destination schema.  We currently do this in BizTalk using a map, so rather than replicate our development efforts, and possibly introducing errors, we will “re-use” the BizTalk map from our .Net code.

• Right click on your map file in Visual Studio, and select “Validate Map”.  In the output pane, there will be a link saying “… The output XSLT is stored in the following file: <file://…“  The file at this location contains the valid XSLT representation of your BizTalk map.
• Copy the .xsl file into the same directory as your solution, and include it in your project.
• Next, use the XSLT to transform the initial document into the format defined by the XSD in the first step.  I’ll write more about this later, but for now, this site is your friend.

Now we have an Xml Document in the expected destination format, with all BRE rules applied.  You can bind to this document in an ASP.NET DataGrid, and away you go.

Activate = True

Well, here I plan on documenting my technical hints and tips, experiments, and other stuff around BizTalk Server, BizTalk Services and other SOA paraphernalia.

So here’s the first post.

Oh, just so I’ve got some technical content, here’s the error message you get when you forget to toggle the “Activate” status on an initial Receive shape in an Orchestration:

Error 32 – “you must specify at least one already-initialized correlation set for a non-activation receive that is on a non-selfcorrelating port”

Not exactly self-evident, is it?  I would have thought the compiler writers could think of something like:

Error 32 – “your initial Receive shape should be set to ‘Activate = True’, dummy”