Well folks – the appfabric labs have come out with a real gem recently.

In CTP we have:

• EDI + EAI processing
• AS2 http/s endpoints
• ‘Bridges’
• Transforms

and of course the latest version of

• ServcieBus, Queues and Topics.

To get the real benefit from this ‘sneak peek’ there’s a bit of setup required. To those familiar with BizTalk there’s a few EDI screens declaring parties/partners and agreements you’ll have seen before.

To get cracking:

1. Update your local bits with the latest and greatest - Installing the Windows Azure Service Bus EAI and EDI Labs - December 2011
   Part of this install is to install the Service Bus Connect component, which installs the BizTalk 2010 LOB Adapter pack.
   
   
   So this is really quite interesting. As the WCF LOB Adapter SDK provides a framework for developers to build out ‘adapters’ to connect systems/endpoints through a sync/async messaging pattern.
   
   The BizTalk Adapter Pack 2010 is the BizTalk Team set of adapters built on top of the WCF Adapter Framework. The BizTalk Adapter pack includes:
   - SQL Server Adapter. Hi performance sql work, notifications, async reads, writes etc.
   - SAP Adapter – uses the SAP Client APIs (under the hood) to talk directly to SAP. Very powerful
   - SIEBEL Adapter
   - Oracle DB Adapter
   - Oracle ES Adapter
   
   These adapters are exposed as ‘WCF Bindings’ with BizTalk or a small amount of code, allows you to expose these adapters as callable WCF Services.
   
   What does this mean in our case here?
   If you think about your on-premise Oracle system, we now have a local means of accessing Oracle and we can then push the message processing (e.g. a new order arrived) into our ‘cloud’ bridge where we have the immediate benefit of HA + Scale. Do some work there, and spit the result out any which way you want. Maybe back down to on-premise, or in a Queue or to Azure Storage.
   
   
2. Sign up to AppFabricLabs – http://portal.appfabriclabs.com and provision your ‘servicebus’ service.
   This provides your EDI/EAI relay endpoints and also provides a way for you to listen/send requests to/from the cloud.
   
3. Here I have used mickservices as my ServiceBus namespace.
   
   (I created a Queue and a couple of Topics for later use – not really needed here)
   Note: grab your HIDDEN KEY details from here – owner + <key#>
   
4. From within the Portal Create a Queue called samples/gettingstarted/queueorders
   
   
   
5. Register at the EDI Portal – http://edi.appfabriclabs.com
   Even though this says ‘EDI’ think of it as your sandpit. It’s where all your ‘widgets’ live that are to run in Azure Integration Services.
   
   The registration form had me stumped for a little bit. Here’s the details that work.
   
   
   
   Notice my servicebus namespace – just the first word. I previously had the whole thing, then variations of it.
   Issuer Name: owner
   Issuer secret: <the hidden key from above>
   
   Click save/register and you should be good here.
   
6. Once this is done – click on Settings –> AS2 and Enable AS2 message processing (which is EDI/HTTP – you might be lucky enough to get the msgs as XML, but most times no). This will create some endpoints for you b2bgateway… style endpoints.
   
   
   
7. At this stage, have a look under Resources and you’ll notice that it’s empty. But…they have Schemas, Transforms and Certificates. We’ll come back to that later.
   
8. Let’s head to Visual Studio 2010 with the updates installed and open up the Sample Order Processing project.
   
   I installed my samples under c:\samples
   
   
   If all opens well you should see:
   
   
   Note: there’s a couple of new items here: (expand out artifacts)
   *.bcs – Bridge. There’s a MSDN Article describing these – I was like ‘what???’. Basically these are a ‘processing pipe’ of which various operations can be performed on a message in stages. These stages are ‘atomic’ and they also have ‘conditions’ as to whether they *need* to be applied to the said message. So a bridge could take a message, convert it to XML and broadcast the message out to a Topic.
   
   Opening up the designer – it gets pretty cool I must say!!!
   
   
   Note the ‘operations’ on the LHS. I must have a play with these guys  
   Another thought – how extensible is this? I’d bet we could write our own widgets to throw on the design surface as well.
   
   By double clicking on the BridgeOrders component, you can see the designer surface come up with the ‘stage processing’.
   
   
   
   Here you can see the ‘bridge’ (I wonder if that term will last till the release) will accept only 2 types of message schemas – PO1 + PO2. Maps them out to a more generic PO format.
   The map – XMLTransform from my initial testing only applies one map, the first one that matches the source schema (this is the same as BizTalk).
   
   Close the bridge view down and leave the BridgeConfiguration open.
   
9. Click anywhere on the white surface of the BridgeConfiguration and set your Service Namespace property from the Properties window (this guy was hard to find!!)
   Put <your service namespace> you created originally.
   
   
10. Save and click Deploy and a Deployment window comes up – put your details in from above.
    
    
    After deployment completes, keep an eye on the Output window as this has all the URLs you’ll need for the next step. In particular the BridgeOrders.
    
    Feel free to go back to your Azure Portal –> Resources and see your deployed bits in there, Schemas, Transforms etc.
    
    
11. Running what you’ve built – sending a message to the ‘bridge’ (here I’ve borrowed info from the ‘Readme.html’ in the sample project folder)
    We don’t need to setup the whole EDI Trading partner piece. – just send messages to a restful endpoint – aka the bridge.
    
1. From the samples folder locate the Tools\MessageSender project. (you may have to build it in VS.NET first)
2. from a command prompt run messagesender.exe
   
   
   In my case it looks like this:
   
   
   
   Took me a little to get this originally, make sure all your VS.NET stuff is deployed properly.
   
   So effectively we have sent PO1.xml to our ‘Bridge’ and it’s been accepted, validated and transformed into ‘something else’ and popped onto a Queue called Samples/gettingstarted/QueueOrders.
   
   We will now get the message Reader to Read it.
   
12. From under the Samples\Tools folder locate the MessageReceiver project and build if required.
13. From a command prompt at that location, run the following to Listen to the queue
    
    

Wrapping up -

Here is obviously a quick walk through of what’s possible, performance, scale and throughput are other measures that we haven’t got here – given it’s CTP/Labs we’re not quite ready for that conversation.

BizTalk adapter pack will expose out for e.g. your SAP system to a wider audience and imagine having restful WCF services to call that provide you customer data in the format you want…or better still…deliver it straight to you!
(currently in BTS 2010, the adapter pack is licensed separately, it’s part of BTS standard or enterprise. BTS2009 it *was* licensed separately for RRP $5K. Maybe we’ll see this as a separate component again.)
Or you could do like the SharePoint team and write a brand new WCF Adapter (‘connector’ in their terms) – ‘Duet’ and spend 18 months doing so.

Some things I’d like to see here is a Rules Processor or Engine – being a long long BizTalk fan, the rules engine is a massive strength of any loosely coupled solution. The majority of BizTalk solutions I come across don’t employ any rules engines…or better still, Windows Workflow 2,3+ (but not 4 or 4.5) has a rules ‘executor’ which is very powerful in it’s own right. Who’s heard or used the Policy shape?

Given that this is a sneak peak at what is on the horizon, this is definitely a space not to miss.

Get those trial accounts going and enjoy!

In particular I’d like to call out Rick’s Article (well done Rick!) for a great read on this space also.

Mick.