BizTalk User Group NL 28-11-2013

On 28-11-2013 the BizTalk User Group (LinkedIn group BTUG NL) meeting took place in Amsterdam, which was organized by Estreme. The purpose of the BizTalk User Group is to have regular meetings with members in the community on the topic of integration. Since Azure provides more and more integration capabilities, by means of the Azure Service Bus, and the Go-Live of Windows Azure BizTalk Services (WABS), the meetings are diverse and very interesting.

As Azure is very broad, the BTUG focuses on the following elements of the Microsoft Integration stack:

  • On Premise (WCF/SSIS/BizTalk/Windows Server Service Bus etc)
  • Cloud - Windows Azure (Windows Azure BizTalk Services / Service Bus etc).

Announcements

  • An upcoming event in January is the BizTalk Saturday, focused on Windows Azure BizTalk Services
  • Next year, a BTUG Beach event is organized, an informal community event
  • The next upcoming meeting will be held in March

Feedback BizTalk Summit - Steef - Jan Wiggers
Steef - Jan Wiggers provided a summary after attending the BizTalk Summit. This showed that BizTalk is here to stay with an improved release cadence:

  • Annual cumulative updates
  • 2 - yearly platform updates
  • Next year there will be a BizTalk 2013 R2
  • In 2015, a new version will be released
  • Improvements included in the upcoming releases are in the area of JSON support, HealthCare / SWIFT adapter-additions and an updated SB Adapter

Windows Azure BizTalk Services is now live and can be used in production and is improved in the areas of monitoring, archiving, EDI support and management by using PowerShell Command Let.

KAS Integrator - Johan Vrielink

At KAS Bank BizTalk has been implemented to handle transactions for stock exchanges. The KAS Integrator is a framework built on top of BizTalk which allows fully automated configuration of the environment. There are several services defined, on top of BizTalk, and a management portal which provides business rules, publish / subscription configurations, which has some similarities with the EDI partnering, which was pretty interesting. A customer with a clear vision and story was very great to have presenting a session. It showed some typical demands in the market; the automated configuration of middleware, ability to minimize development efforts for interfaces and gave great insight in how to think about challenges in future projects, e.g. by using PowerShell.

Integration Challenge : Custom Service Bus - Rob Kits
During the integration challenge, non-BizTalk products / solutions are shown and compared to BizTalk, which allows you to think about integration in a broader sense, where not every problem can be solved with a single tool. In this case it was a custom solution that used in locations where gas is distributed. In this environment, it is necessary that operators can configure/adjust/monitor the environment, and middleware such as BizTalk is too complex. It was based on PLC technology presented a solution that was brilliant in its simplicity. It again showed that an integration problem must be based on the needs and requirements, and not always with the potential features provided. I found that to be a nice analogy with cloud technology, where one of the advantages is that you pay for what you need, not necessarily what the technology can do.

Synchronous Service Bus - Martin Rienstra
BizTalk is not a golden hammer and certainly not suitable for all issues. At a client, about 80 interfaces were implemented in an intranet environment using a request-response pattern (synchronously). As BizTalk is designed with the principle of guaranteed delivery using the asynchronous pub/sub architecture (polling), BizTalk is not designed for low latency solutions. This does not mean BizTalk is not capable of handling these, this is possible, by using separate hosts, scaling out, separating the databases, however, there is due to the architecture, unpredictable latency.

The BizTalk product team has recognized this and stated that this is due to the architecture in BizTalk and will not be resolved, this kind of issues can be addressed by using different technologies.

Martin had previously looked at the Service virtualization platform MSE (Microsoft Service Engine), but this product is no longer developed (in this space there is only Sentinet). The requirements; configurable, manageable, and re-using the BizTalk maps. The solution consisted of an interesting mix of WCF custom behaviors allowing dynamic service to be generated using a configuration, which uses BizTalk artifacts (mappings / assemblies etc), with the great advantage that the existing BizTalk used solution could be reused. The disadvantage is that the services should run on BizTalk the machine because of the usage of BizTalk artefacts.

Summary

A great event and very interesting content, in future meetings we can expect a lot of great Integration Challenges, and I’m trying to arrange a session where one of my colleagues from Caesar will explain differences and comparisons between Sonic vs BizTalk vs Azure as I’ve seen a lot of interesting things after comparing BizTalk and Sonic;

  • Sonic has the choice between durable subscriptions and non-durable (using queues), where BizTalk always uses durable subscriptions, Azure provides in this context durable (Topic) and non-durable subscriptions (Queues)
  • Routing can be done schema based, where Sonic does this without enforcing a schema, where BizTalk requires a schema
  • Similarities between logical and physical separation of concerns (where Sonic works with an ESB Container and Broker concept) and BizTalk uses a Logical and Physical port)
  • And more….

 

Great to see everyone and I hope a lot of events like this will follow.

 

Regards,

Sander

Comments

Popular posts from this blog

Azure implementation guidelines

UK Connected Systems User Group – BizTalk Services questions

Setting up a build server with the BizTalk Deployment Framework