BizTalk Server 2010 Cookbook

Steef-Jan Wiggers new book: BizTalk Server 2010 Cookbook

The book includes little over 50 recipes for BizTalk developers and administrators. It will demonstrate the out-of-the box capabilities BizTalk combined with capabilities from community- and Microsoft related BizTalk tooling.

You will learn more when you visit the Packt website: http://www.packtpub.com/biztalk-server-2010-for-developers-and-administrators-cookbook/book

Windows Server AppFabric Cookbook

Rick G. Garibay's new book: Windows Server AppFabric Cookbook

The book includes over 60 recipes ranging from fundamental to advanced techniques for
making the most of WCF 4+ and WF 4+ on the Microsoft platform with Windows Server AppFabric.

You can learn more by visiting this link: http://www.packtpub.com/microsoft-windows-server-appfabric-cookbook/book

BizTalk FILE Receive / Send with DFS network share

When using BizTalk to send and receive from a file share is usually pretty simple. However when you combine this with a DFS network file share, it gets a little bit more complex.

We found our receive location was not starting, and simply failing to work.

So we did mange to get this to work here is how:
You firstly need to have the right share, as some users will use \\machinesname1\share$ and others something else.

The correct share to use is the DFS defined share, so when the DFS storage moves the share is maintained, and not lost. Always find out what the main share name is for the DFS network.
Next you need to set the correct network file share permissions on the network folder. When connecting to a network file share using BizTalk File adapter just specifying "Modify" rights is not sufficient. In simple configuration terms, you would need to have a minimum of "Full Control" or the BizTalk Host Service Account.
Some system admins don’t like this, you need to make sure you have the permissions ONLY set on the folder you are actually reading/writing to.

For the FILE Receive Adapter
After you provide "Modify" rights, Click on "Advanced" button and on the Advanced Security Dialog, edit the permission entries for the BizTalk Service Account
Here you will notice that the "Delete Sub Folders and Files" option is not given by default. This is exactly the missing link for the receive adapter.
Simply set this property and you do not need to set "Full Control"

We had to set list access all the way up the file tree for us to even see the folder.
EG: Our share was: \\dfssharename\saa$\Folder1\Folder2\Folder3\Folder4\IN

We needed to set list permissions on Folder1, Folder2, Folder3 and Folder 4
Then full modify/delete rights, with the setting Delete Sub Folders and Files.
Only then did it work.

For the FILE Send Adapter
If you are NOT USING the "use temporary file while writing" attribute on your send port, only the following permissions are required on the permissions entry dialog
o Create Files / Write Data

If you are using the "use temporary file while writing" attribute on your send port, the following permissions are required on the permissions entry dialog
o Create Files / Write Data
o Delete Files
o Delete Sub Folders and Files
o Read Permissions

Could not create SSOSQL. To fix the problem, reinstall SSO or try 'regasm SSOSQL.dll' from a Visual Studio command prompt.Error Code: 0x80131700

You have installed BizTalk?

You have installed SQL server?

You have installed .NET4.0 ?

Everything is fine.

Then you reboot, or you restart SQL Server.

Enterprise Single Sign-on Does not want to start…. ???

It errors with:

Could not create SSOSQL. To fix the problem, reinstall SSO or try 'regasm SSOSQL.dll' from a Visual Studio command prompt.Error Code: 0x80131700

OR

Windows could not start the Enterprise Single Sign-On Service service on Local Computer.
Error 0x80131700: 0x80131700

OR you are getting:

Creation of Adapter FILE Configuration Store Entries failed.
An Error occurred while attempting to access the SSO database.

The problem is .NET 4 does something to break SSO.

This issue occurs after installing .NET Framework 4.0. The registration of the assembly used by ENTSSO to access SQL Server (SSOSQL.dll) does not specify the correct version of the .NET Framework. When .NET Framework 4.0 is installed, the assembly will try to use the newer framework and then fail to load

DO NOT do what it says in the event log it will NOT work fully.

The fix is: http://support.microsoft.com/kb/2252691

However you need to BE SURE you do it correctly.

Is your environment 64bit? Most are these days. Did you install 64bit SSO?

Is it in:

64bit: C:\Program Files\Common Files\Enterprise Single Sign-On
32Bit: C:\Program Files (x86)\Common Files\Enterprise Single Sign-On

If you have 64bit, follow the 64BIT instructions ONLY

1. Open a command window
2. Go to C:\Windows\Microsoft.NET\Framework64\v2.0.50727
3. Type each of the following and hit ENTER

32bit: regasm “C:\Program Files\Common Files\Enterprise Single Sign-On\win32\ssosql.dll”
64bit: regasm “C:\Program Files\Common Files\Enterprise Single Sign-On\ssosql.dll”

Note On a 64-bit server, regasm will need to be run for both the 32-bit and 64-bit versions of ssosql.dll.

Do both of these steps and you day will be brighter.

Dynamic SMTP Failure: Unknown Error Description

I was sending an email dynamically, from an orchestration.

I set up a nice payload message with all of these nicely distinguished fields, that contained the to/ from, subject and body of the email, so that other parts of my system could send an email, just by generating this message.

My message assignment shape had:

EmailSendMessage = EmailReceiveMessage;
EmailSendMessage(SMTP.EmailBodyText) = EmailReceiveMessage.Body;
EmailSendMessage(SMTP.CC) = EmailReceiveMessage.CopyTo;
EmailSendMessage(SMTP.From) = EmailReceiveMessage.From;
EmailSendMessage(SMTP.Subject) = EmailReceiveMessage.Subject;
EmailSendMessage(SMTP.MessagePartsAttachments) = 0;

EmailSendPort(Microsoft.XLANGs.BaseTypes.Address) = "mailto:" + EmailReceiveMessage.SendTo;


The message itself was not sent, just the properties of this message, so the message I was constructing as receive message didn’t matter, so I made it the same type of the EmailReceiveMessage. It compiled, and I deployed it.

First Try:


Event Type: Error
Event Source: BizTalk Server 2009
Event Category: (1)
Event ID: 5754
Date: 13/12/2011
Time: 1:16:31 PM
User: N/A
Computer: [computer]
Description:
A message sent to adapter "SMTP" on send port "XXX.Email.Orchestrations_1.0.0.0_XXX.Email.Orchestrations.SendEmail_EmailSendPort_43e93d0db20c465a" with URI "mailto:email@address.com" is suspended.
Error details: Unknown Error Description
MessageId: {B66F52BA-DFF0-4274-B4B2-3B1F51E862E0}
InstanceID: {C7A4CA9E-E606-4D04-9001-D34974B4D971}

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.


I then checked and you needed to have the body text charset:

EmailSendMessage(SMTP.EmailBodyTextCharset) = "UTF-8";


Second try, same error…

Several modifications later I get the message: Unknown Error Description

Which I must say is not a great deal of use when you are trying to figure out what’s wrong.

I then decided I’d make a different message type for sending, and used a transform. I used my send message and copied and pasted the schema, I changed the target name space of course.

SAME ERROR…..

I was annoyed, and tried a bunch of things, then EUREAKA! …

The send schema which I copied and pasted has the same properties promoted as distinguished fields.

This was BAD it seems, the instant I removed these properties from being promoted, and changing nothing else… everything worked….

BAD BAD BAD... schema properties, who would have thought…

DO NOT HAVE PROMOTED PROPERTIES ON YOUR SCHEMA WHEN SENDING TO THE SMTP ADAPTER.

ABA bank payment file format (Australian Bankers Association)

I'm currently working on an application for a un-named organisation. As part of this, I need to export files for processing in the Australian defacto standard for Electronic Funds Transfer (EFT) files - the ABA format.

I'm using BizTalk of course, and it can handle this weird format, however all I had was the sample file, which for a fixed width flat file is not great.

I found the format documented here: http://ddkonline.blogspot.com/2009/01/aba-bank-payment-file-format-australian.html

Apparently the banks have all agreed on this format, which is firstly Ancient in origin and format, and design Highlighting that it’s a flat file, of fixed field lengths..

If this was re-factored into a XML format, it would be much easier to generate, highly flexible, and they could expose an interface, via a simple web service to accept this format. All authentication could be done via a secure https web service, with encryption on the web service.

Let’s understand that this is used to effect payments from a company’s bank account to individuals, this is highly sensitive and needs to be secured.

This format of this file is NOT encrypted in anyway; it is open, readable, and modifiable. There are no check digits, no certificate of authentication or any of the modern features you would expect in such a file.

By Exposing a WCF endpoint, which had authentication via certificate, using an https/transport encryption/security would handle some of this requirement; the rest is in the detail of the message itself.

Currently what happens is we output this file to the file system, and then someone picks it up... and processes it...

If a WCF or web service endpoint was open by the bank, we could securely communicate with this, and send the payment file, someone could log onto their secure interface and approve the transfers still, however there would be zero chance of someone modifying this file before it got there....

Before we got involved, this was just popped onto the file system somewhere, generated via a different method…

I am not one to mess around when it comes to security, and this smells to me. The banks need to provide an interface. I’ll happily build it, securely and flexible enough for all platforms to communicate with it.

Handy Hint: BtsCompile

Are you looking for the build action on an orchestration, you know BtsCompile
For the uninitiated, it is great for having a BizTalk Artefact that’s broken, or not
complete and having it not form part of the compile. It works for maps, schemas,
you name it.

I generally use it to set it for some unfinished orchestrations not to include in the
build/compile, so it does not break things....

Well, as it happens, in BizTalk 2009, it can disappear, for some reason, however I have
discovered the way of making it re-appear.

Simple copy and paste ANY orchestration in your solution, and paste it back, now the
BuildAction property appears, not just for that orchestration, of ALL of them.

It’s as if it knows, if you are copying and pasting an existing orchestration you
are probably not going to want to have it build right away.

Fixed Field Settings on Map

On a map, you can set the value of a destination node to a fixed value, from within the mapper, simply by setting the value property when clicking the destination node on the right hand side schema. I’ve see people use the string functiods to pre-set a value, however you do not need to do this.

There is a catch I found in BizTalk 2009. If you set the fixed value on a map page other than the first page, it does not set, worse yet, if that field on the destination schema happens to be a promoted property, it does not promote the value, and will fail when you try and use the value inside your orchestration as desired.

You will not know why, the shape will just fail, with some weird exception.

Always use the first page.

DefaultPipelines.XMLReceive, Attempted to read or write protected memory

I got the error of death.... I mean we were this close to formatting the machine.

Event Type: Error
Event Source: BizTalk Server 2009
Event Category: BizTalk Server 2009
Event ID: 5719
User: N/A
Description:
There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "XML disassembler" Receive Port: "GetReferenceDelta" URI: "mssql://zz11aazz//My?" Reason: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

I thought that the xmlpipeline was broken, so I tried the passthrough...

There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.PassThruReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "Unknown "
Receive Port: "GetMyDelta" URI: "mssql://server/uri" Reason: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

I can no longer receive ANY messages into BizTalk from SQL...

I tried the file receive, I tried xml and pass-through pipelines, nothing works, and it all fails....

I can no longer receive ANYTHING at ALL into BizTalk.... Error of death...

I looked, I tried updates to the Adapter packs... nothing worked....

I was about to trash my environment and format and start again....

THEN!!! I thought, let me remove all updates I had done to BizTalk, I removed one, and tested, removed one and tested.

Finally finding that..... The offending update was cumulative update 1:

http://support.microsoft.com/kb/2429050

I removed it, and my BizTalk came back to life..... PHEW!

Encoded Multi Part Messages to SOAP adapter

I had one of those old/non conforming to the standards web service of kinds I needed to call.
The ones you really hate, and wish they’d just upgrade them to WCF... but hey thats 90% of integration, old rotten systems... so I persisted.

It did accept xml messages, however was very fussy as it seemed to employ the good old, no xml translator, the one that is more of a text base, string manipulation xml decoder, where if you send quite valid xml, it will fail because they didn’t support it.
This kind of set up is... sadly... quite common....
It would not handle xml tags that had no content, but had a closing tag.

EG: <salary currency="en-AU"></salary>
It needed to have them encoded differently:
<salary currency="en-AU"/>
Now both of these examples are valid xml, however good old string parser went the easy route and didn’t cater for an end tag.
The problem is that you can’t exactly tell biztalk to not put the end tag, it’s going to put xml, valid xml, and thats what it does....
Further more... it also complained about white space in my xml message.... ??? you say???
<salary currency=""><salary> <standout logoid="”1111"><standout>
The white space it didn’t like was between the tags, <salary>[--- white space ---]<standout>

Now how on earth do you cater for this?

A custom pipeline component to the rescue, just before it sends the message I would “FixUP” the xml by removing the end tags, and white space between tags, using my old favourite, c#.net .
So I go to the trouble of making a custom pipeline component, hook it up to a custom send pipeline, and then attach the pipeline to the send port.

BANG, nothing happens... it stil fails for the same reason.

At this point I’m a little annoyed, and more p’d off than i’d care to mention.
I spend the next hour trying to figure out why......

Firstly the web service is a SOAP web service, I have to use the SOAP adapter because it’s a multipart message, I check with Yossi. http://blog.sabratech.co.uk/2009/08/biztalk-wcf-adapter-and-multipart.html to discover that even if I went to WCF and fudged a wcf-http port to work it would not make much difference.

I then try and pump the message out to the file system, using a send port in the orchestration. I get a message, with only the first part. It throws me for a second, then I realise that the FILE adapter does not support multi part messages. Weird, considering all messages are multi part messages, most with one part, but I prevail.

How do I see what is going to the adapter? I really need to see the message, I mean I have tested by component, and it is good, it works and does the trick, its .net, so I of course have a .TEST project to test it...

How... Ah..ha... You can stop the send port, not unenlist it, but stop it, the message will still go to the port however sit there waiting for you.

I can then see the message from the admin console, ALL parts of the message, a much better way to debug messages BTW, I notice the message part has been encoded, the multi part message takes two strings, the second of which is my xml message. So the message is wrapped in a <string> tag, with the contents.... no longer in XML format, they are html encoded. My lovely <salary> tag is now a horrid, & lt;Salary& gt; the xml is hardly readable.... I cringe, it’s destroyed my lovely xml...

Now I can see what’s going on, before it even gets to my custom pipeline, my xml is encoded, therefor my pipeline which is looking for xml, does not find any, and does not work.... UGH!

Interestingly when I assign the value of the xml in the outbound message, I do it from a message assignment shape, I have the xml in my grasp...
I do a cheeky thing in BizTalk, turn the message into an xml document, which I can turn into text. Luckily I wrote the pipeline by using a separate class for the tagging and white space cleaning. So I can call the methods from the message assignment shape, and I process the xml, clean and massage it.

I then set the xml document back up by loading the NEW xml into to, and then set the value of the parameter of the outbound message to the xmldocument.

The message is now encoded before it goes to the port. I send the message to the port and wolla, response message, in xml... that tells me it worked.

This is a bit of a hack and a workaround, it does work, however I would have preferred the pipeline to work.

I do note with interest that only the SOAP adapter is able to process this multipart message, because it’s an OLD soap web service, I did hear of talk of scrapping the SOAP adapter, however multipart messages are VERY common on soap web services, and this would be foolish to scrap it. I’d like to see support for multi part messages in the WCF set of adapters, with more backwards compatible support, so I don’t have to use an out dated SOAP adapter.