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

Post a Comment

Popular posts from this blog

Azure implementation guidelines

In My post ‘ Service Bus Management ’ I pointed out a way of implementing a DTAP strategy for managing the Service Bus environment. There’s now a great post available from Microsoft which goes into more detail about other aspects of managing the Azure subscriptions and other artefacts which is quite useful when setting up your Azure environments. Follow this link to the ‘Azure Implementation Guidelines’ HTH, Sander
Read more

Focus and innovation - recap of the last 2 years

It's been a long time since my last post. Hereby a partial explanation for that, with the note that this blog will remain active for the purpose of being a resource for historical references. My IT career started with programming, and adventures within holland, as well as overseas. When I realised programming is something you can specify, I figured that providing added value is crucial for a long term career and decided to focus on process centric roles. I started with webservice integration and eventually from that to process integration using BizTalk. The great feeling when discussing high level processes and implementing solutions within days, even highly scalable and interfacing with LOB systems is great. After several years of implementing solutions like these, I started questioning if all of this work was justified by the business case, if the solution was actually contributing, if the choices had been valid. In other words, I needed to understand the choices made. When...
Read more

BizTalk Pub/sub vs Topics based routing–discussion

My colleagues and I had a brief discussion about the subject ‘Topics’ and what it brings… Do you all agree/disagree with the following statement: topic-based pub-sub messaging doesn’t really exist in BizTalk “In my opinion; I disagree, as BizTalk offers the following 'out-of-the-box' • Message Routing (f.e build in context properties like message type, trading partner, operation etc) • Content Routing (f.e. promoted properties, message inspection in orchestrations/pipelines icw orchestration logic)” My colleague Rene Brauwers Here my 2 cents…. I agree that it exists...however the current offerings in BizTalk are tightly coupled, making the usage far from perfect. When doing content based routing on custom fields (promoted properties), you will be making the solution message-coupled; Your custom message property schema is deployed, and the message filter on these fields have a direct relationship with this property schema. Making any change to this schema will g...
Read more