Today, Windows Azure BizTalk Services was officially announced on TechEd US. (more information can be found here: http://blogs.msdn.com/b/windowsazure/archive/2013/06/03/announcing-new-offers-and-services-on-windows-azure.aspx and on the BizTalk blog soon: http://blogs.msdn.com/b/biztalk_server_team_blog/) From now on, a real preview is available through the Windows Azure portal of these new capabilities.
Codit is one of the few world wide launch partners for this service and we have been actively working together with the product team for more than a year now. With our online integration platform: Codit Integration Cloud, we are actively extending Windows Azure BizTalk Services (WABS) and are adding value for our customers. At this moment, we are already live on Windows Azure BizTalk Services.
Over the coming days, a set of blog posts will be posted to dive a little more deeper in these new services:
- Windows Azure BizTalk Bridges
- Building Custom pipeline components for Windows Azure BizTalk Bridges
- Windows Azure BizTalk Adapter Service
- Windows Azure BizTalk Mapper
- Windows Azure BizTalk Trading partner management
This first post gives a high level overview of the different components that are part of this release.
Bridges & Message itineraries
One of the most important concepts are Bridges (mostly XML bridges). These can best be compared with BizTalk pipelines. Bridges are always deployed in a Message itinerary. An itinerary can be activated through an bridge or through a configured sources (like an FTP/SFTP location). A bridge can perform the typical messaging/pipeline logic that we know from BizTalk Server: transformation, parsing (flat file and EDI support), property promotion, validation…).
The output of a bridge can then be sent to anther bridge or a destination, like a service bus queue/topic or relay endpoint.
Windows Azure BizTalk adapter service
It is perfectly possible to combine BizTalk Services from the cloud with a BizTalk Server on premises. But for a lot of scenarios or customers, it is well possible that there is no BizTalk Server installed locally. If these customers however want to have the possibility to expose some of their on premises systems or LOB applications to a bridge, they can leverage the Windows Azure BizTalk Adapter service.
This IIS-hosted service exposes local endpoints from the WCF LOB adapter pack to the cloud, using the Azure Service Bus Relay bindings. The nice thing is that it is perfectly integrated with the EAI bridges and the designer, so you can easily drop local endpoints to the canvas and generate their corresponding schemas in the project.
The following schema depicts the two biggest EAI parts of this release: a Bridge (cloud) with the Adapter Service (on premises)
Windows Azure BizTalk Services – Trading partner management
This it he full featured EDI and TPM portal that is part of this release. This component allows to configure Trading partners with all their specific settings. It is possible to configure everything through the portal and to process X12 and shortly EDIFACT messages, coming from your business partners.
The service support multiple protocols, including AS/2 and Bridge/Service Bus entities.
Expect more blog posts soon! (the next one on bridges in a few minutes)