New Online API Mapping Tool

One of the many challenges with an integration project is typically the mapping of messages from one API to another. The difficulty most often lies not with the technical implementation (although some former projects mapping SAP iDocs to EDI X12 are still giving me nightmares), but rather with forming the specification of the mapping itself, including understanding the semantical meaning behind each element. This is difficult because it requires expert knowledge of both the source and target system, as well as an analysts who can correct “draw the connecting line” between the two. The correct end result is only achieved through significant collaboration amongst the relevant parties.

The BizTalk Mapper goes a long way to facilitating this task with it’s graphical mapping interface. Aside from providing the developer a means of rapidly implementing a transformation, it also servers as a visual representation of the mapping that can be understood by a business analyst (if not too complex):

(image courtesy of MSDN)

There are two problems with this approach, however:

  1. It requires BizTalk Server, which is not only expensive, but also may be overkill for a solution that can easily be implemented in WCF, REST, or another platform;
  2. The mapping must be implemented by a developer before it can be shown to analysts and business users for discussion and validation. This usually entails a number of iterative cycles until the mapping is correct.

Enter api-map.com – a new free online tool created by my colleague Joseph Cooney specifically to address these particular challenges. api-map provides a medium to formulate, display and share mapping documentation which can eventually be handed over to a developer for implementation on any chosen platform.

Read more of this post

User Group Presentation on Microsoft Flow

Last week I had the privilege of presenting a short session on Microsoft Flow to the Brisbane Azure User Group. The group meets every month, and at this particular event we decided to have an “Unconvention Night” where instead of one or two main presentations, we had several (four in this case) shorter sessions to introduce various topics. This has been a popular format with the group and one that we will keep repeating from time to time.

Wrapping up the evening was my session, called Easy Desktop Integration with Microsoft Flow.  Flow is a new integration tool built into Office365; it allows business users (yes, I really mean “business users” – no code required) to build automated workflows using 35+ connectors to popular SaaS systems like DropBox, Slack, SharePoint, Twitter, Yammer, MailChimp, etc.  The full list of connectors can be found here.

Even better is that Flow comes with over 100 pre-built templates out of the box, so you don’t even need to construct your own workflows unless you want to do something very customised! All you need to do is select a template, configure the connectors, publish the workflow – and off it goes!  In fact, it is so simple that I built my first Flow during Charles Lamanna’s presentation at the Integrate 2016 conference in London; I decided to capture all tweets with the #Integration2016 hashtag to a CSV file in DropBox.

Flow is built upon Azure Logic Apps, and it uses the same connectors as PowerApps – so you can leverage both of these great utilities to create simple but powerful applications:

image

Because it is built on Logic Apps, this means you can easily migrate a Flow workflow to an Azure Logic App when it becomes mission critical, requires scalability, or begins to use more sensitive data that requires greater security and auditing.

Feel free to view the recording of my session at https://youtu.be/sd1AhZpPsBw:

Microsoft Flow presentation to the Brisbane Azure User Group

 

You can also download the slides (which came mostly from Charles Lamanna’s deck– used with permission of course). But most importantly, get started using Flow! I’m sure you’ll find plenty of uses for it.

Integrate 2016 – What an Event!

Last week I had the privilege of attending the world’s largest integration event this year, Integrate 2016 in London. A big thanks to my employer Mexia for sending me. As is typical for events organised by BizTalk360, it was on an especially grand scale (27 sessions with 25+ speakers) and did not disappoint in the content presented by members of the Microsoft product team and the MVP community.

Day 1 of the three day event featured a number of announcements from Microsoft that clarified their vision and direction for integration, even more so than the Integration Roadmap delivered at the end of last year. Showing their commitment to BizTalk Server as the on-premises integration platform and Logic Apps as the cloud platform provided some much-needed reassurance and comfort to the community. “BizTalk and Logic Apps better together” is the mantra underpinned by the addition of a Logic Apps adapter in the upcoming BizTalk 2016 CTP2 release and the new BizTalk Connector soon to be introduced in Logic Apps.

Without explicitly stating it, it also became rather apparent as to what is “on the outs” in the integration space:

    • Microsoft Azure BizTalk Services (MABS) is likely to be deprecated as both the VETER pipelines and the EDI/B2B functionality moves into Logic Apps by way of the Enterprise Integration Pack;
    • Azure Stack is no longer being touted as the on-premises integration platform; rather BizTalk Server will continue to be king of that domain.

I’ve already posted an article on Mexia’s blog giving my rundown on all the sessions presented by Microsoft and the  significant announcements. Soon after I followed up with a summary of the many MVP sessions that rounded out the conference.  In addition, there are plenty of other blog posts from the community giving their thoughts and recaps of the event; here are just a few:

Besides Microsoft’s clear roadmap message and the excellent presentations, perhaps the best thing about this conference was the opportunity to catch up with colleagues and friends from around the world – and meet new ones as well!

Kickoff Dinner
(photo by Thomas Canter)

 

Saravana&Dan
(photo courtesy of BizTalk360)

 

GreenwichKitchen
(photo by Tara Motevalli)

Dinner_with_MVPs
(photo by Steef-Jan Wiggers)

Kudos again to Saravana Kumar, BizTalk360, Microsoft and all the sponsors for making this such an outstanding event! Looking forward to Integrate 2017!

Azure Service Bus Relays, SAS tokens and BizTalk Server

Great article by Mark Brimble. SAS support is now available across all WCF adapters in BizTalk Server 2016 CTP1!

Connected Pawns

Many people have written about Azure Service Bus Relays in the past and a summary can be found here. Dan Rosanova recently tweeted “….We’re trying to discourage ACS for security. SAS is our preferred model.”. The ACS security pattern is described here and the SAS pattern is described here. This article attempts to summarise BizTalk adapter support for using SAS tokens.

Most BizTalk Server examples use ACS tokens rather than SAS tokens, probably because the BizTalk Adapters only allowed configuration with ACS tokens when service bus relays were first released with BizTalk 2013. BizTalk 2013 R2 has limited support for configuration of SAS tokens and most adapters only allow use of ACS tokens out of the box (OOTB). If you want to use a SAS token you have to be very inventive. I hope that BizTalk vNext will add SAS token support for all WCF adapters.

View original post 411 more words

"Flush failed to run" SQL error with BAM API

Today I encountered an unusual error when executing a pipeline component that utilises the EventStream API to write to BAM. The failure that showed up in the event log looked something like this:

A message received by adapter "WCF-SQL" on receive location "MyReceivePort" with URI "mssql://MyDatabaseInstance/MyDatabase?InboundId=Employee" is suspended.
Error details: There was a failure executing the receive pipeline: "MyReceivePipeline, MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1a2b345c67d89e0f" Source: "Log Message To BAM Receive" Receive Port: "MyReceivePort" URI: "mssql://MyDatabaseInstance/MyDatabase?InboundId=Employee" Reason: Flush failed to run. 

A quick Google search pulled up this helpful post by Yossi Dahan, which pointed me in the right direction. I knew that the connection string was all right, and I was using the BufferedEventStream rather than the DirectEventStream that Yossi referred to. (Incidentally, when using the BufferedEventStream your connection string actually points to the BizTalkMsgBoxDb database rather than the BAMPrimaryImport database.)

However, the clue was really in the second part of Yossi’s suggestion (and also in an anonymous comment), "…and related permissions…".  I could see that the BizTalk Application Users domain group had been assigned all of the appropriate roles in SQL Server, and I knew that all the host accounts had been dutifully added to this group when BizTalk was installed.

Er… hang on a moment. I double checked and found that the SQL Adapter was running under a new dedicated host account that had been created specifically for the data warehouse. A simple check on the account using the "net user /domain" command prompt unveiled the culprit. This account had not be granted membership in the BizTalk Application Users domain group.

Once that was accomplished, everything worked smoothly.

It would be nice to actually see an error that hinted towards permission issues. Perhaps the detail was buried somewhere in an inner exception, but the logging does not go past the first level.

BizTalk SB-Messaging Receive Adapter Suspends Brokered Messages Without a Body

When it comes to processing zero-byte messages, the built-in receive adapters in BizTalk Server are somewhat inconsistent (see this recent post by Mark Brimble for more information). However, it seems that most receive adapters do not successfully process messages without body content. For example, the File adapter will delete an empty file and kindly put a notification to that effect in the event log. The HTTP adapter will reject a POST request with no content and return a 500 “Internal Server” error. So it probably isn’t any real surprise that the Azure Service Bus Messaging adapter introduced in BizTalk Server 2013 also obstructs bodiless messages. The difference here though is that the message will be successfully received from the queue or topic (and therefore removed from Service Bus), but will immediately be suspended with an error like the following:

A message received by adapter “SB-Messaging” on receive location “SB-ReceivePort_Queue_SB” with URI “sb://<namespace>.servicebus.windows.net/TestQueue” is suspended.
Error details: There was a failure executing the receive pipeline: “Microsoft.BizTalk.DefaultPipelines.PassThruReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” Source: “Pipeline ” Receive Port: “SB-ReceivePort” URI: “sb://<namespace>.servicebus.windows.net/TestQueue” Reason: The Messaging Engine encountered an error while reading the message stream.

Read more of this post

Why Did My BizTalk Services Stop Working? Check Expired ACS Credentials…

So… let’s say you were one of the early adopters of Microsoft Azure BizTalk Services (MABS) and actually put a solution in production. Everything goes swimmingly for about a year. Then one day your interfaces stop working. Moreover, you will see no error entries in tracking (actually, no entries at all for that interface), although you might see some errors from the client trying to send messages to MABS.

Although the error messages you see may not be very helpful, the length of time that the service has been deployed and running should lead you to suspect some expired credentials. As it turns out, there are multiple levels of credentials and places that they are managed. The SSL certificate might be an obvious one, but many folks forget about the ACS credentials behind the service. Read more of this post

User Group Presentation on Integration Roadmap

Dan PresentingLast night at our Brisbane Azure User Group meetup, I had the privilege of delivering a short presentation on the Microsoft Integration Roadmap that was revealed on Christmas Eve last year, and which I previously blogged about. I couldn’t find any “official” slide deck from Microsoft yet, so I put together a rough deck of my own incorporating some screenshots from the roadmap PDF, a few slides from previous Microsoft decks, and a couple of handmade ones of my own. Feel free to download this from SlideShare and use it if you like.

My presentation was preceded by an excellent session on Azure Application Insights given by Microsoft Solution Architect Todd Whitehead. Amazing to see how easy it is to get so much telemetry from Azure! Looking forward to using this feature more & more.

More photos and details of the Meetup can be found here.

Following the Roadmap to Microsoft Integration

Microsoft has just released a document detailing their roadmap to integration. With all of the recent activity in the cloud around integration – including the release of Microsoft Azure BizTalk Services two years ago, followed by a seemingly different change of direction with Azure App Service announcement earlier this year – there has been much confusion about where Microsoft was headed in the integration space. This has been challenging for partners and customers who want to ensure that they invest in the “right” technology when building out their enterprise integration capability.

I am pleased to say that this document finally delivers some much-needed clarification in this respect. Aside from reinforcing that “BizTalk is not dead” and confirming some key new features in the much-anticipated BizTalk Server 2016 release, it also shows how Microsoft is aiming to close the gap between traditional on-premises integration afforded by the server product and the modern API-based approach offered in Azure:

convergence

Read more of this post

Load Balancing with the Azure App Service File Connector

The File Connector is one of the built-in protocol apps that are available in the Marketplace when you go to provision and API App. Through configuration only, this app allows you to perform file-based operations from a Logic App in Azure, bridging the boundaries of your corporate network:

image

The documentation from Microsoft clearly explains how you can configure the app and then download a listener agent to install on your on-premises server associated with the file(s). In most cases, this would be a single server – but I got to wondering what would happen if you installed the agent on multiple servers? So I tried it out using both  the “Get File” and “Upload File” operation.

Turns out that the File Connector will talk to all of those servers, provided that you have set up the same base directory path on all of them. This path is configured at the time you provision the API App – not when you use it within a Logic App. The configuration of the “File Path” property within the instance of this app only defines the sub-directory within the base path, as well as the file name. Incidentally, if this sub-directory does not exist at runtime, it is automatically created for you in the case of the “Upload File” operation.  Unfortunately, this is not the case with the base directory – if that doesn’t exist you get a rather meaningless 500 error recorded in the tracking log:

The requested page cannot be accessed because the related configuration data for the page is invalid.

In any case, I set up a simple Logic App and decided to test using the “Get File” and ‘Upload File” methods respectively to fetch and store files from assorted VMs hosted on my laptop. Once I had the syntax down for specifying the file path (this post by Saravana Kumar proved very helpful), then I was amazed at how easy it was to get this working! Here is my Logic App:

Read more of this post

John Glisson - Geek of the Cloth

Thoughts on integration, technology and what-not...

prashantbiztalkblogs

My BizTalk Experiences

The CRUCIBLE

THINK: It's not illegal....yet.....

paulbouwer.com

life and technology

Abdul Rafay's BizTalk Blog

My experiences with BizTalk related to architecture, development and performance in my enterprise.

Mike Diiorio

Connected Systems and other thoughts

BizTalk musings

Issues, patterns and useful tips for BizTalk development

EAI Guy.net

Enterprise Applicaiton Integration and SOA 2.0

Connected Pawns

Mainly BizTalk & Little Chess

Man Vs. Machine

Why can't we all just get along?

Adventures inside the Message Box

BizTalk, Azure, and other tools in the Microsoft stack - Johann Cooper

Biz(Talk)2

Talk, talk and more talk about BizTalk

Richard Seroter's Architecture Musings

Blog Featuring Code, Thoughts, and Experiences with Software and Services

Sandro Pereira BizTalk Blog

My notes about BizTalk Server 2004, 2006, 2006 R2, 2009, 2010, 2013 and now also Windows Azure BizTalk Services.

BizTalk Events

Calendar of BizTalk events all over the world!

WordPress.com News

The latest news on WordPress.com and the WordPress community.

Mind Over Messaging

Musings on BizTalk, Azure, WCF, and Enterprise Integration

Follow

Get every new post delivered to your Inbox.