The Live Mesh adapter is part of the recently released BizTalk Azure Adapters SDK 1.0 July CTP. It was first shown at TechEd 2009 North America by Danny Garber. But as someone who didn’t attend the conference, it passed me by. It didn’t surface for me until it made it’s way to codeplex and Richard Seroter made a note of the fact a week ago or so. If you have TechEd Online access you can find the original video demoing it here.
How to use it
- Register for an account on Azure services development portal, if you don’t have one already. Specifically you want access to Live Services.
- Install the pre-requisites.
- The WCF LOB Adapter SDK.
- The Live Framework SDK. You don’t need the tools, but you need the SDK.
- There might be other pre-requisites though that I already had in place. So your experience might vary.
- You have to give it an URI of “mesh://?actions=LiveFX/OnReceiveFeed“, it’s hard coded in the adapter. If it isn’t given that then it does nothing. To make it unique and be able to have more then one mesh receive location you can add to it, like you would a querystring. It will be accepted, but not handled, only the value of actions is retrieved and used by the adapter. A smart thing here would be to move something into the URI that would make it naturally unique. When you configure other adapters it’s the name of a service, or a procedure or something like that. In a scenario where you are listening to a mesh folder for example, then the name of that would be appopriate, or when listening to notifications from an application, then the name of that; the name of the MeshObject is perhaps a common denominator?
- At the moment it receives notifications about changes to all resources and then when it gets a notification retrieves all feeds for that MeshObject and tries to read the userdata of the DataEntries associated with each DataEntry as a string, and if it succeeds initializes an XmlReader over that string and creates a message. Thus the userdata must conform with the rules of xml and also a couple of other things built into the adapter today. Like the name of the first node, and an attribute in that node must match those in configuration of the adapter, as must the title of the MeshObject. The attributes value must be equal to the name of the DataFeed that contains the entry which we received a notification for.
The logic is a little unclear to me, and has lots of room for improvement, but admittedly – I’m no expert on the mesh resource model, nor do I know what the application it was built for sent across or how it stored it – and, it’s an early CTP. Sample (matching the config seen above, and produced by my sample app):
<myXmlElement myFeedNameXmlAttribute=“MeshAdapterFeed”>This is my data</myXmlElement>
First thing to note about the adapter is that at the moment it seems very tightly coupled to the demo. Judging from the “vision slide” at codeplex, the idea is for it to eventually expand into other areas as well. It isn’t to hard to change it or update it to for example read files out of a mesh folder. The Live Framework is pretty straight forward once you get used to it. But right now it’s just a glimpse into a future where BizTalk is the server product to bridge on-premises with the cloud – and doing so effortlessly and seamlessly with the use of the artifacts that we as BizTalk Developers are used to.
Install note 1:
If the adapter install complains about not being able to find Microsoft.ServiceModel.Channels you haven’t got the WCF LOB Adapter SDK. The exception message (for completeness and search-engines, was: “Could not load file or assembly ‘Microsoft.ServiceModel.Channels, Version=184.108.40.206, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.“.
Install note 2:
If you get a message when running the installer that “Please wait while the installer finishes determining your disk space requirements” – try to run the installer from the commandline using the command msiexec /i <name_of_installer.msi>, or msiexec /package <name_of_installer.msi> /qr.
Install note 3:
I got the message that “Machine.config doesn’t contain system.servicemodel node”. First of all – yes it did, secondly – I could see that the adapter had added it’s bindings to the section – so it must be due to something else. When “binging” (do we call it that now 😉 the exception message I got this post. It didn’t help much, but it did point me in the right direction, becauseit made me remember seeing a custom action in the solution. Sure enough, looking at the code for the custom action revealed the issue. At line 106, the installer is trying to apply the config for the 64-bit machine.config as well as 32-bit, not finding it since I’m on a 32-bit environment. Commenting out that line and rebuilding the install does the trick. Note: I’m not trying to do a fancy works-for-all-scenarios solution. I just wanted to fix my specific problem.
Install note 4:
I can swear on the fact that just before beginning the process of installing the adapter I could create BizTalk projects. After the adapter (and WCF LOB Adapter SDK) was installed – I can’t. Project creation fails and I get the message “One or more templates do not match any installed project packages.”. I can’t really point a finger or lay the blame on any particular point, install, configuration or other entity. It did however stop working. Reinstalling BizTalk Server 2009 Developer Tools and SDK resolved the issue.