Category name:Azure

Integrate 2016

I already knew it was quite some time ago since my last blog post, but man, more than 9 months since! Shame on me.

The main reason I picked up blogging again is because there is so much going on in the integration space. This became especially visible during lasts weeks conference, which is the largest integration focused and Microsoft oriented conference in the world: Integrate 2016 in London, organised by the BizTalk 260 team.

There are so many recaps available, like from Steef-Jan Wiggers, Rob Fox, Eldert Grootenboer, Kent Weare and of course BizTalk360 itself, so I won’t go into that. The purpose of this blog post is to add new insights, or rather my insights based on the sessions and discussions during the conference.

BizTalk Server 2016

First of all the session on BizTalk Server 2016 (scheduled for RTM in Q4 of 2016). Microsoft clearly mentions their on-premise tool for integration is BizTalk Server and that they will continue to invest in it, but the (only!) session about BizTalk 2016 was quite disappointing. While 45 minute time slots were available, the talk only took 32 minutes. True, some demos were shown as part of the keynote, but if there is so much love for BizTalk Server, it shouldn’t be a problem to talk for hours about it. Main take aways from this session:

  • SQL Server AlwaysOn support
  • Platform alignment (Windows Server 2016, Visual Studio 2015, SQL Server 2016, Office 2016)
  • New adapter for interfacing with LogicApps (available in CTP2), which is cool by the way
  • Lots of customer asks and pain points solved (which ones remain quite unclear, besides “the BizTalk mapper Schema dialog window is now resizable”)
  • Nothing mentioned on ESB

I would expect to get to see the ‘lots of customers asks and resolved pain points’, but I guess it still isn’t possible to generate a multi-input message map from the map creation wizard……
Sorry for being sarcastic but this really didn’t show a lot of love for the product.

Microsoft Flow

One thing that couldn’t be skipped is the recently introduced competitor of Zapier and IFTTT: Microsoft Flow
This is a lightweight version of Logic Apps and is meant for business users. It won’t be directly part of the integrators toolkit, but it contains some easy to do integrations you should know about. Rule of thumb would be to use Microsoft Flow ‘when you can do development in production’. This means no need for source control etc. Although this is very conventient for business users, I fear the management around this as long as there is no tooling available to maintain the endless integrations the business users will create. Microsoft said that when this goes GA there will be tooling available to maintain, monitor, limit and create blue prints of company flows.

Azure Functions

One topic that really caught my eye is the power of Azure Functions which was demonstrated by Chris Anderson. You can do great things with it! It allows for creating (preferably) small logic components exposed as HTTP endpoints, for example functions to convert currency or perform calculations. Besides other things like triggers and schedulers, it is easy to create small API’s with it without having to host them yourself. From that perspective you can look at it as API Apps light and like with Flow I think some best practices are needed for the ALM part of this integration option.

Digital Transformation

This session on the role of the integration expert by Michael Stephenson was outstanding in my view. He clearly showed the fact that we as integration experts can no longer be on an island and need to transform into integration coaches. We passed the times where the ‘integration team ruled the company’ (or blocked the company!) and we need to be aware that other (.NET) developers will do integration work as well. This doesn’t mean we’re obsolete, but it means we have to adjust and take up the role of integration coaches and take care of the governance as we have great expertise and experience in that area. For complex integrations we’ll still be needed, but buiding API Apps or even Logic Apps will also be done by non-integration people. We have to define the blue prints and govern the integrations in the company.

Nick Hauenstein

I really don’t know where to start: with his performance or his session content. Man, both where awesome! He had a great story on the tools we have and that we should look outside our boundaries because there is a lot of greatness out there. BizTalk isn’t the only tool to do integration, so get out of your comfort zone. He demonstrated a solution where he built a BizTalk like solution (including correlation) in Logic Apps and API Apps. The well known BizTalk Pipeline is just another Logic App where we have full flexibility on the content and are no longer bound to the stages (nor be limited to a single component in a stage!). You can download the entire solution here. Last but certainly not least his performance. He was by far the most enthousiastic speaker at the conference. His energy blew me away!

Hello Logic App!

During INTEGRATE 2014 last November in Seattle Microsoft gave a sneak preview of what today is known as API apps and Logic apps. Back then it was all fuzzy and no preview to play with. Right before the BizTalk Summit in Londen in April, Microsoft released the big news regarding their new App Service platform, including the existing Web apps (Azure websites) and Notification services, combined with the new API apps and Logic apps.

For us BizTalk developers the most interesting of all are the Logic apps. Although you can’t use Logic apps without having API apps, because they are (also) the new adapters to receive and send messages.

I was inspired by this blog post from the BizTalk360 team, in which is described how to read messages from one on-premise location and write them to another using Logic apps and hybrid connections. That blog post saved me from quite some research as there are some tricky things to know. At the end of the post I had the Logic app below.


For me that was the first step, but in a real BizTalk scenario there at least has to be one map! My scenario is to read from my local laptop ‘inbox’ folder, transform the message and write to the same laptop to an ‘output’ folder.

So I installed the Microsoft Azure BizTalk Services SDK to have mapping functionality in Visual Studio without the need for any BizTalk assembly. I created a small schema and a map to be used for the Logic app.


Next step is to have an API app to perform the transform, because everything is an API on the platform. To create a new BizTalk Transform Service, you can also use this Azure documentation as reference.


Select BizTalk Transform Service and click ‘Create’. The Azure portal start page will open and show the API app to be created. When the API app is created, click it to open the details. The next step is to add a map to the Transform Service.


Now the BizTalk Transform API service is ready, we need to put it between the two file connectors in the existing Logic app. This is a challenge in itself, because currently it isn’t possible to re-organize the API apps within a Logic app. So just dragging the Transform Service in between the two file connectors is a no-go. I tried to add the Transform Service to the Logic app and then use the code view to re-organize but it appeared not to be that simple (although the design of the Logic app is described in a plain readable JSON file). This will be possible in the future, but for this case I removed the sending file connector, added the Transform Service and then added the file connector again. This results in the Logic app below.


The complexity at the moment is the expression you need to provide as parameter in the API apps. At the moment there is no validation, intellisense or syntax highlighting which complicates development. In the near future this will be possible, there is demand from the community for this as well.

Logic apps is in fact chaining API apps together and using (a part of) the output of one as the input for the next API app. For the BizTalk Transform Service we need to take the output of the first File Connector, which is the body of the message, as input for the map. We can use this expression for this: @triggers().outputs.body.Content

It is pretty easy to read: take the content of the body of the output of the previous API app.

Next is to take the output of the Transform Service and use that in the sending File Connector. To determine the file name to use for the File Connector we can use this: @concat(‘/Outbox/’, triggers().outputs.body.FileName)

The name is appended to the default folder. The content of the message is grabbed from the Transform Service, but has a different expression compared to the one used as input to the Transform Service: @body(‘transformservice’).OutputXml

Like a typical ‘hello world’ with BizTalk, I throw in this message in the Logic app:

<ns0:SourceSchema xmlns:ns0=””>

This is the output and as expected the map has been executed.

<?xml version=”1.0″ encoding=”utf-8″?>
<ns1:TargetSchema xmlns:ns0=”” xmlns:ns1=””>
<ns1:FullName>Indiana Jones</ns1:FullName>

Hurray, my first Hello Logic app!

It was a very interesting exercise to play with these basic components of the App Service platform. Logic apps currently are certainly not a replacement for BizTalk and that is also not what it’s meant to be. Integration MVP Michael Stephenson has a nice blog post about it.

Currently the Logic apps are in preview and a lot still needs to be done before it is mature enough to build enterprise solutions. For example the entire ALM needs to be figured out and also the designer should be available in Visual Studio and not only via the browser. Microsoft is betting big on this so it will be a matter of time before these topics will be covered.

It is great playing with new stuff!

The status of the Windows Azure Pack

Until now my focus was not really on the private cloud, but I was triggered by the fact that it was mentioned at Integrate 2014 conference in Seattle which I attended. During the conference I realized I didn’t know a lot about the Azure pack, while it will become very important. The current on-premise BizTalk version will eventually be replaced by what Microsoft is building at the moment. The future Azure version of BizTalk (orchestration engine, connectors, BizTalk microservices, etc) will be deployed on-premise by means of the Azure Pack. By the way the product team indicated a preview will be released around the BizTalk summit in London on 13/14 April 2015.

Then the blog post from Sven van den Brande about this topic came by and that was the trigger to actively take a look at it. I started my 6 year old server to take the first step, install Windows Server 2012 R2.

There are quite some blog posts about installing the Azure Pack like:


I took the ‘express route‘ to quickly install Azure Pack. This installation is meant for single server installs, where a typical Azure Pack production install requires multiple servers to host features you find in Azure like IIS for websites, SQL servers for databases, Active Directory servers for authentication and Hyper-V servers for VM’s.

Especially this blog post I found very helpful for guidance:

I followed this blog post to install everything necessary to run Azure pack on a single server, using SQL Server 2014 Express edition. Installing the Azure pack via the Web Platform Installer is pretty simple. You can check all screenshots in the blog post, as it wouldn’t make sense to add them here again.

After installing and configuration you get this interface (after a bit of playing around), which is pretty familiar but also far behind in features compared to Microsoft Azure today.

Azure Pack

The documentation is dated October 17, 2013 and the Azure Pack feature installers are from October 21, 2014. Also for example the Windows Service Bus hasn’t been updated since October 2013.

So why would you install Azure Pack in a production environment at the moment, if it is so behind in features and it doesn’t get regular updates?

Asking the question is answering it. I think the private cloud is going to become very important as replacement for current Windows Server farms, but for now it is not an option. It is fun to play with but that’s about it. I wouldn’t advise a customer to use this in production.

It is my guess that Microsoft is putting no effort in the current Azure Pack anymore, but is building a new Azure Pack for Windows vNext Server, which is scheduled to be release in 2016, even after Windows 10 server. Or even better, Windows vNext Server will be build to support a private cloud. The timeline for this will be aligned with other Azure features like Servicebus, API Management and BizTalk micro services. Like with the new BizTalk developments, the private cloud will just be an instance of Microsoft Azure which results in feature parity between the two.

We have interesting times ahead!

Integrate 2014 – Impact on Integration Consultants

Like a lot of fellow integration consultants I attended Integrate 2014, the integration summit on the Microsoft campus in Redmond. The event was organized by BizTalk360 and they did a great job.

It was the first time I attended a BizTalk event abroad, but I heard something new was to be announced so I registered early. Although it is quite a trip, for a couple of days, all the way from Amsterdam to Seattle, it definitely was worth the jetlag.

I’m not going to describe the sessions, because that has already been done, for example in these great posts:

Like with many such events, the sessions are interesting but the most interesting part is meet new people and discuss with fellow enthusiasts what the impact of the announcements is. Besides the discussions, it is away nice to shake hands with community leaders. Sometimes I only knew them from Twitter or Blogs.

Although some very interesting new things were announced, we as integration consultants mainly need to work with what’s available today. So in this post I’ll focus on the impact on our day-to-day work and the near future.

My takeaways from Integrate 2014, regarding this topic are mainly that:

  • BizTalk is going to stay around
  • There is a real and major shift towards the cloud
  • It will take some time for Microsoft to be feature complete
  • Microsoft Windows Azure BizTalk Services (MABS) will be discontinued, but migration will be possible

Although the announced changes have huge impact for the BizTalk community, BizTalk itself will stay around for many years. Microsoft pointed out again their release cadence regarding BizTalk with a major release every 2 years and a platform alignment every alternate year. For 2015 there is a major release scheduled, but the worrying thing is that Microsoft has not shown a clear picture on what the ‘major’ enhancements will be. Actually I think Microsoft will only do platform alignment (make BizTalk ready for latest Windows/SQL/Visual Studio versions) and maybe add one or two features to improve cloud connectivity or adapt new standards (like happened with REST) but nothing new and innovative will be added to the current BizTalk platform. This in fact means a stand-still from an innovation point of view, so don’t expect any new investments in for example BAM or the workflow engine.

After one of the sessions I had a chat with one of the Program Manager on the BizTalk team and he explained that all of their 800 developers are working on the new stuff to get it ready for the announced preview. This leaves with few resources to do work on BizTalk Server 2015 and also makes very clear where Microsoft’s focus is at the moment. He also mentioned there will be a shared codebase between BizTalk on-premise and BizTalk-in-the-cloud. Later during Integrate it became clear that this actually meant that Microsoft will only build for the cloud and make that available on-premise in form of a private cloud (delivered via Azure Pack for Windows Server). Looking at it from that perspective, it makes sense there will be a single codebase and feature parity between on en off-premise because they’re exact the same product. The only difference is the datacenter it will be deployed, public cloud of private cloud. One important thing regarding private cloud though. Like mentioned before Microsoft will provide Azure BizTalk via the Azure Pack for Windows Server, but this pack currently doesn’t provide what’s available in Azure. So a lot of work needs to be done there as well.

This focus on the cloud leads to the conclusion that there will be minimal development on the current on-premise version of BizTalk Server, and that it will become a different track in the integration space. By that I mean we’ll see exactly the same as happened with ASP and ASP.NET: There will be developers doing ‘classic’ BizTalk and others doing ‘Azure’ BizTalk. Although they functionally do the same work, the technology is way different. This also means different design skills will be needed. In case of Azure, for the first time BizTalk developers will need to really include cost efficiency in their considerations.

I don’t think this separation will happen in the next few years, but it will eventually. The preview of Azure BizTalk (which isn’t an official term by the way) is scheduled for Q1 2015. The demo’s shown on Integrate made me think the first preview is nice to play with, but far from feature complete. For the Azure Integration Services (which is an official term from the slides) in an update cadence of 3 months new features will be added, starting with the features to be able to implement some content/context based routing scenarios. For enterprise solutions with complex orchestrations this will be a different story. Microsoft actually hopes these orchestrations can be broken down into a (large) set of (BizTalk) microservices, but we’ll have to see whether that is actually the case. This is also one of the concerns I have regarding migration of existing solutions. Some solutions will need to be redesigned, because they can’t be migrated.

One of the sessions was about cloud integration at Microsoft itself. They currently heavily invest in moving their integration to MABS, although they know that MABS will be discontinued in favor of the new platform. That means that they’re very confident in the migration path; like Kannan C. Lyer answered on the same question from the audience. As far as I know here in The Netherlands MABS isn’t used very often (if at all?), but in the USA it is used mainly for B2B where it is a suitable solution looking at the current capabilities.

To conclude my view on the new announcement: these are exciting times for integration consultants. For the first time in about 10 years things are really going to change for us and you have to decide for yourself whether you want to stay the ‘classic’ BizTalk consultant or add ‘Azure’ BizTalk to your skillset. The classic BizTalk consultant will be around for at least 10-15 years (lots of customers still use BizTalk 2006 or older, and the end-of-life of BizTalk 2013 R2 is in 2023), so plenty of time to make up your mind.

Didago IT Consultancy

Book review Getting Started With BizTalk Services

Recently I was invited to take a look at the Packt Publishing book ‘Getting Started with BizTalk Services’ by Karthik Bharathy  and Jon Fancey.

This is the first available book on Microsoft Azure BizTalk Services and for that reason alone an interesting read. I’ve already played with BizTalk Services so I was curious to measure my knowledge against the book, moreover because the book assumes no prior BizTalk knowledge. The Microsoft Azure platform is expanding at a tremendous rate so I was also interested to see how up to date this book is, as it was published in March 2014 (although that’s only 3 months ago, the release rate of Azure features is quarterly).

To start with the last question, the book is still very up to date. No major changes or new features have been announced that directly impact BizTalk Services. So from that point of view it is still a reliable source of information (besides that WABS is called MABS now J).

The book is organized like this. It starts with a generic overview of what Azure is and for what scenarios it would be useful. It also covers the basics of BizTalk Services.

Next chapter is about the Mapper and from a on-premise BizTalk Server perspective it has been seriously improved. One thing the book briefly touches is the fact that the mapper is not based on XSLT behind the scenes anymore; it’s using XAML. One other thing is the ability to have some sort of exception handling in the map. This has been one of the missing pieces of integration regarding to BizTalk Server. For each operation you can specify what to do in case of an exception, fail or continue and output a null value. Of course this is not really exception handling, but it’s better than nothing.

Then a chapter about Bridges. I knew a bridge was comparable to a BizTalk pipeline but I was surprised to read that behind the scenes a bridge is using Windows Workflow Foundation. This is an indication that the announced workflow engine for BizTalk Services most probably will be Workflow Foundation as well.

Other chapters cover topics like

  • EAI scenarios
  • B2B scenarios (EDI with X12/EDIFACT)
  • Using the BizTalk Adapter Service to connect to on-premise LOB systems
  • Using custom code in bridges
  • Maintaining BizTalk Services using the API via PowerShell or REST service
  • Tracking and Troubleshooting
  • Moving current BizTalk Server investments to BizTalk Services (and when not to)

Especially the chapter about B2B is comprehensive. The X12 standard is used quite often in the US so it makes sense to dive deeper in that part (european customers are using EDIFACT). Besides that the B2B market is the most suitable to move to the cloud first, because it involved integration with other companies which is typically a cloud-scenario.

Everything in the book is described in clear language and doesn’t only scratch the surface. Some topics are explained in more detail including some background as well.

For anyone interested in BizTalk Services and wishes to be quickly up to speed, this is a perfect start.

Didago IT Consultancy

Dutch BTUG meeting with the BizTalk product team

Yesterday we had a special Dutch BizTalk User Group meeting. The guys from the BizTalk product team were in The Netherlands because of the BizTalk summit tour and they came by to talk about BizTalk.

Three presentations were given about the upcoming release of BizTalk Server 2013: one overview and two deep dives. Much of the overview stuff was already known. If you’re curious about the features and want to download the BizTalk 2013 beta, you can take a look here. One important take-away is that BizTalk will be available as Azure virtual image, and pay-per-use will bring BizTalk closer to smaller companies because the licensing costs will no longer be a barrier.

The other presentations were deep-dives about BizTalk 2013 adapters and the Azure BizTalk Services.

The adapters talk discussed the new SharePoint 2013 adapter, which is using the SharePoint Client Object Model (COM Winking smile ). No longer do we need to install something on the SharePoint server if we want to use the WSS adapter. Also the cloud adapters were discussed and demoed. More details can be found in this blog post. It is clear that the focus will be more and more on cloud connectivity.

The next deep-dive covered Azure BizTalk Services. This was formerly known as Servicebus EAI/EDI. Like discussed in this blog post it is the next step to bring BizTalk to the cloud. It is clear that BizTalk and Servicebus still are separate products. Both have transformation capabilities, but BizTalk is focused on XML-to-XML transformations using XSLT, where the Servicebus is capable of much more. It is likely that both products will merge.

The evening ended with Q&A. Some nice discussions about the direction of BizTalk. I asked a question about a long time rumor of replacing BizTalk’s XLANG/s engine with Workflow Foundation. Answer: currently there is nothing that you can’t do with the XLANG/s engine that you can do with WF, but the developer experience of WF is much better. It is unlikely that the XLANG/s engine will be replaced by WF soon, but the product team is working on enhancing the developer experience in future versions of BizTalk. Another question from the audience was about low latency scenarios. Because every message travels through the messagebox, it is difficult to implement a low latency scenario. The response of the product team was clear. BizTalk is designed with guaranteed delivery in mind, not low latency. Of course they’re working on improving performance, in BizTalk 2013 and SQL 2012 the team managed to improve performance of for example ordered delivery with 700%, but the motto is guaranteed delivery over guaranteed performance.

It was great talking to the guys that actually build the product and know every edge of the product!

Didago IT Consultancy

BizTalk Server 2013 beta announced

Tonight Microsoft announced the public download of BizTalk Server 2013 beta.

I’m not going to relist the features because, they are perfectly described here on the blog of the Microsoft BizTalk server team.

Formerly this release was known as BizTalk Server 2010 R2, but it was rebranded with a more future proof name.

Since a few months it was already available for testing purposes on the Windows Azure platform as a Virtual Machine. Testing with Azure Virtual Machines is still possible and the fastest and easiest way to try out the bits.

For our on-premise friends: you can download BizTalk Server 2013 beta here.

The system requirements are picked from the download page and show a platform alignment with the new 2012 series of products.

Supported operating systems: Windows Server 2008 R2 SP1, Windows Server 2012

To run BizTalk Server 2013 Beta you need:

    • 32-bit (x86) platforms: Computer with an Intel Pentium-compatible CPU that is 1 GHz or faster for single processors; 900 MHz or faster for double processors; or 700 MHz or faster for quad processors
    • 64-bit (x64) platforms: Computer with a CPU that is compatible with the AMD64 and Extended Memory 64-bit Technology (EMT64T), 1.7 GHz or faster processor recommended for BizTalk Server 2013 Beta
    • 2 GB of RAM minimum (more recommended)
    • 10 GB of available hard-disk space
    • VGA monitor (1024 x 768) or higher-resolution monitor
    • Microsoft Mouse or compatible pointing device

To use BizTalk Server 2013 Beta you need the following software:

    • SQL Server 2012 or SQL Server 2008 R2 SP1
    • Microsoft .NET Framework 4.5
    • Microsoft Visual Studio 2012 [Required for selected features only]
    • Microsoft Office Excel 2010 [Required for selected features only]
    • SQL Server 2005 Notification Service [Required for selected features only]
    • SQLXML 4.0 with Service Pack 1 [Required for selected features only]
    • Internet Information Services (IIS) Version 7.5 and 7.0 [Required for selected features only]

Interesting to see you can install BizTalk on SQL Server 2012, but still need 2005 Notification Services. Also there is a new enhanced SharePoint adapter (for SharePoint 2013?), but BAM still needs Excel 2010. I assume this will also be aligned with the RTM version.

Another interesting thing is that in previous versions you can install BizTalk on a client version of Windows like Windows XP or Windows 7. Although not recommended, it is possible. In this list only server products are mentioned, does that mean that there won’t be support for Windows 8? In the installation documentation which can be found here, is stated the following Windows versions are supported: Windows Server 2008 R2 SP1, Windows Server 2012, Windows 7 SP1, Windows 8.

If you need a Windows Server 2012 machine to install BizTalk on, you can pick a 180-day trial version on VHD from here. An evaluation version of SQL Server 2012 can be found here.

Have fun!

Didago IT Consultancy

Azure Service Bus EAI/EDI April 2012 Refresh, What’s new?

Back in December 2011 Microsoft released the first CTP of the Azure Service Bus EAI/EDI. It showed what direction Microsoft is heading with bringing BizTalk like functionality to the cloud. Or to quote Microsoft:

“Windows Azure Service Bus EAI and EDI Labs provides integration capabilities for the Windows Azure Platform to extend on-premises applications to the cloud, provides rich messaging endpoints on the cloud to process and transform the messages, and helps organizations integrate with disparate applications, both on cloud and on-premises. In other words, Service Bus EAI and EDI Labs provides common integration capabilities (e.g. bridges, transforms, B2B messaging) on Windows Azure Service Bus”

If you want to read more about this, please take a look at my two previous blog posts about this topic:

BizTalk in the Cloud, one step closer (part 1)

BizTalk in the Cloud, one step closer (part 2)

Now Microsoft has released the second preview:

Service Bus EAI and EDI Labs – April 2012 Release

Download the April 2012 Release

So what’s new in this April 2012 release?

Regarding the EAI Bridges, we’ve got the following enhancements. BizTalk developers will recognize parts that currently only are available in BizTalk….

  • FTP Source Component. In the December 2011 release it was already possible to connect WCF endpoints via the publish/subscribe pattern. In this refresh another endpoint type has been added: FTP, which can be used as a source component on the configuration bridge. In the BizTalk world this would be the FTP adapter, but so far it is reading only.
  • Flat File Support. This is also a familiar concept in the BizTalk world. Combined with the FTP source component, flat files for example can be read and converted into XML now. But also via HTTP flat files can be read and processed. The available flat file wizard looks quite the same as currently can be found in BizTalk Server.
  • Schema Editor. Previously only available in BizTalk, now also part of the Service Bus EAI/EDI release. Used to create and edit XSD and flat file schemas
  • Service Consuming Wizard. Also straight from BizTalk Server, the possibility to generate the necessary artifacts to be able to consume WCF services. The difference with EAI is that it only generates an XSD and no other output files like binding info and an orchestration.
  • Operational Tracking of messages processed by the bridge. This is also something from BizTalk Server. Within a bridge, a message undergoes processing under various stages and can be routed to configured endpoints. Specific details of the message such as transport properties, message properties, etc. can be tracked and queried separately by the bridge developers to keep a track of message processing.

For Service Bus Connect, there are the following enhancements.

  • Support for Windows Authentication while connecting to on-premise SQL Servers
  • User Interface enhancements
  • Support for SSL

The transforms also have been improved.

  • New map operations. In BizTalk this is called ‘Functoids’ but are named operations here. Added are:
    • Number format operation, to format an input number using a given format
    • Date/Time operation, to manipulate date/time
    • Generate ID operation, to generate a unique ID of a given length
  • Runtime behavior configuration. This is also interesting for BizTalk developers, because like Microsoft says:”In this release, users can configure the runtime behavior for how the transform handles exceptions, errors, null values, and empty data input. This configuration can be done for each transform”. This sounds exciting and probably something we’ll be seeing in the next version of BizTalk Server.

Finally the EDI or Business to Business Messaging, which now has support for:

  • Processing batched EDI messages. You can now use the TPM portal to configure agreements that can process batched messages coming from trading partners
  • Tracking and archiving EDI messages. You can now use the TPM portal to track messages as they are processed using the agreements

I’m looking forward dive into the details! BizTalk Server in the cloud again one step closer!

Didago IT Consultancy