Month of Achievements!

Month of Achievements!

“When it rains, it pours.”

Well, I must say I’ve had a pretty remarkable run the past few weeks! I can’t remember any point in my professional life where I’ve enjoyed so much reward and recognition in such a short time span.

mcsa-cloud-platform-certified-2017-smFor starters, after six weeks and probably 50-60 hours of study, I managed to pass my MS 70-533 Implementing Azure Infrastructure Solutions exam. Since I’d already passed the MS 79-532 Developing Azure Solutions exam a couple of month earlier, this earned me the coveted Microsoft Certified Solutions Associate (MCSA) qualification in Cloud Platform. I now have just one more exam to pass to earn the Microsoft Certified Solutions Expert (MCSE) qualification.

MVP_Logo_Preferred_Cyan300_RGB_72ppiThen just last week I was granted my first  Microsoft Most Valuable Professional (MVP) Award  in Azure! This is incredibly exciting to say the least, and not only a surprise to myself to have been identified with so many incredibly accomplished leaders in the industry, but also to many others because of the timing. Microsoft has revamped the MVP program so that now awards will be granted every month instead of every quarter, and everyone will have their review date on July 1st. I’m looking forward to using my newfound benefits to contribute more to the community.

And if that wasn’t enough, this week Mexia promoted me to the position of Principal Consultant! Aside from the CEO (Dean Robertson), I am the longest serving employee, and the journey over the last seven and a half years has been nothing short of amazing. Seeing the company grow from just three of us into the current roster of nearly forty has been remarkable enough, but I’ve also watched us become a Microsoft Gold Partner and win a plethora of awards (including ranking #10 in the Australia’s Great Place to Work competition) along the way. Working with such an awesome team has afforded me unparalleled opportunities to grow as an IT professional, and I will strive to serve both our team and our clients to the best of my ability in this role.

So what else is on the horizon? Well for starters, next week I join the speaker list at Ignite Australia for the first time delivering a Level 300 Instructor-Led Lab in Azure Service Fabric. I’m also organising and presenting for the first ever Global Integration Bootcamp in Brisbane on 25th March, and doing the same for the fifth Global Azure Bootcamp on 22nd April. And somewhere in there I need to fit in that third Azure exam… It’s going to be a busy year!

Busy Times…Again

Busy Times…Again

You may have noticed that I haven’t been too active on the social media / blogging front of late. It certainly isn’t because there isn’t much to write about…especially when you consider the release of BizTalk Server 2016 (including the Logic Apps Adapter), the General Availability of Azure Functions, and many other integration events leading up to these! And for those on the certification path, there’s news of the refresh of the Azure exams as well.

In fact, it is that very last item that accounts for a good deal of my scarcity in the blogging world of late. My employer is keen for as many of us as possible to earn the Microsoft Certified Solution Expert (MCSE) accreditation in Azure. I’ve already passed first of three required exams, MS 70-532 Developing Microsoft Azure Solutions after several weeks of after hours study (hours that might have been spent blogging). That accomplishment has earned me this nice little badge:

exam-532-developing-microsoft-azure-solutionsI’m now currently studying for the next exam, MS 70-533 Implementing Microsoft Azure Infrastructure Solutions. Passing this exam will earn me a Microsoft Certified Solutions Associate (MCSA) qualification in Cloud Platform. However, it won’t stop there as I’ll need to pass one more exam – MS 70-534 Architecting Microsoft Azure Solutions in order to attain the coveted MCSE in Cloud Platform and Infrastructure. All I can say is that I’ll be doing a lot of studying over the Christmas holidays…

Aside from studying for exams, I’ve also been heavily tasked at work as Mexia has had a profoundly successful sales year in 2016 – which translates into an overload of work! No wonder we’re heavily recruiting right now, looking for those “unicorns” that can help us remain as the best integration consultancy in Australia. There has been a fair amount of travel lately, and as Mexia’s only Microsoft Certified Trainer (MCT) I will continuing to deliver courses in BizTalk Server Development, BizTalk Server Administration, BizTalk360, and Azure Readiness. That means many more hours preparing all of that content.

But it hasn’t stopped me from speaking, at least not entirely. Aside from regular presentations at the Brisbane Azure User Group (including this one on Microsoft Flow), I’ve also been a guest presenter at Xamarin Dev Days in Brisbane where I talked about Connected and Disconnected Apps with Azure Mobile Apps.

Looking forward to writing posts more regularly again after this exam crunch is over. There’s a lot of exciting things happening in the integration world right now!

New Online API Mapping Tool

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):

biztalkmap

(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.

As a first step, the tool allows you to upload schemas (either JSON or XML) with the ability to display, edit and annotate them:

image

These schemas can then be used to define mappings, even providing automatic  hints along the way using very clever heuristics. You can specify direct mappings or indicate that a transformation is required – including a description of the necessary condition and/or logic that defines the transformation. You can also map multiple source elements to a single target, and specify constant values to be assigned where appropriate.

Once this is completed, you can then display the mapping in a clear visual diagram that is easily understood by any analyst. Even better, you can combine multiple diagrams into one composite “end-to-end” view – providing a traceability which you cannot achieve within BizTalk maps. This is incredibly useful in the situation where canonical business schemas are employed within an ESB (a common scenario for most of my projects). And by selecting any element involved in a mapping, you get an independent end-to-end view of all elements involved in a mapping:

SNAGHTML8a9568c

Finally, when everything has been sorted, you can export the mapping to a handy Excel spreadsheet, serving as documentation within a source repository for developers to work from:

image

A few other nifty features include the ability to tag items to make them searchable, join teams in order to share project artefacts, and an option to attach images of a user interface to clarify the association of an element with a system control.

Watch Joseph’s video to see a live demonstration of the tool. Still in beta, Joseph is continually adding new features, but already I believe this will be a handy utility on many of my upcoming projects!

User Group Presentation on Microsoft Flow

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:

[embedded content]

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!

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!

Integrate 2016 – What an Event!

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

Azure Service Bus Relays, SAS tokens and BizTalk Server

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.

“Flush failed to run” SQL error with BAM API

“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

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.

You will also see another error message recorded in the event log:

The Messaging Engine received an error from transport adapter “SB-Messaging” when notifying the adapter with the BatchComplete event. Reason “Object reference not set to an instance of an object.”.

And if you have message body tracking enabled on the receive port, you will also see this error message in the event log:

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: Cannot access a disposed object.
Object name: ‘CEventingReadStream’.

In the case of file based adapters, it  seems pointless enough to process a message with no content, which is possibly why BizTalk rejects these. However, unlike empty files which are unlikely to have any meaningful dynamic context information besides the file name, a Service Bus message comes with a number of Brokered Message properties which are automatically added to the BizTalk message context by the SB-Messaging receive adapter. Aside from several standard properties, Brokered Message publishers can introduce any number of custom properties (up to a limit of 64KB). The BizTalk SB-Messaging receive adapter even allows you to promote these properties to a custom namespace when it is published to the MessageBox. Sometimes, these properties are all that is required for the transaction, particularly if it is used as a notification. Remember that not all BizTalk messages have to be XML; they  can contain any content, including binary – as long as BizTalk is not expected to process the content. The MSDN documentation for XLANG message also says that it can have “zero or more message parts”.

So what exactly happens when BizTalk pops a message with no body off of a Service Bus queue? To test this out, I did the following:

  1. Created a Service Bus namespace and test queue in Azure and noted the ACS credentials. (Note: BizTalk Server 2013 R2 now also supports Shared Access Signatures for authorisation)
  2. Created a Receive Port and an SB-Messaging receive location in BizTalk and configured it to receive messages off of the queue
  3. Created a FILE send port that subscribes to messages from the Receive Port created in the previous step (to prevent persistence exceptions due to no subscription)
  4. Created a small console app to send a blank message to the queue; note that this only takes a couple of lines of code when using the Microsoft Azure Service Bus package available via Nuget:image
  5. Ran the console application and observed the resulting suspended message and event log entry. Note that the custom BrokeredMessage property was automatically placed in the message context:SNAGHTML23575df

Remember also  that once a message makes it through a receive adapter, it travels through a pipeline. A custom pipeline might contain components that process the context data in a message. In a recent case, we wanted to receive a message off a Service Bus queue that contained a timestamp and a BAM Activity ID within the Brokered Message properties and use it to finalise the BAM record. Our custom pipeline would read the properties from the message, close the BAM record, and then dispose of the message (as there was no need to persist it from this point on).  Curiously enough, the pipeline processing succeeded. However, we still saw the 2nd error mentioned above appearing in the event log. So this proves that the error occurs after the pipeline handles the empty message without issue (provided your pipeline doesn’t contain a disassembler or other component that relies on the presence of a message body).

We could have chosen to ignore the errors, since we know our mission was still being accomplished (BAM record closed, and message was popped off of the queue). However this would introduce noise within a monitoring solution like BizTalk360 and potentially cause confusion for the support team. In the end, since the integration platform was the publisher of the Brokered Message anyway, we chose to introduce some content in the message body which alleviated the issue. However, this isn’t a great story because:

  • Message sizes in Service Bus are limited to 256KB, so you need to take precautions that messages don’t exceed this length, and
  • Sometimes you are not the publisher of the message and won’t have the option to control the body content.

I suppose another solution would be to write a custom adapter based on the existing SB-Messaging adapter that would gracefully handle an empty message, perhaps something along the lines of Nino Crudele’s proposed changes to the custom file adapter included in the SDK.  But that’s a task for another day when there’s time to spare.

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

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.

You will also see another error message recorded in the event log:

The Messaging Engine received an error from transport adapter “SB-Messaging” when notifying the adapter with the BatchComplete event. Reason “Object reference not set to an instance of an object.”.

And if you have message body tracking enabled on the receive port, you will also see this error message in the event log:

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: Cannot access a disposed object.
Object name: ‘CEventingReadStream’.

In the case of file based adapters, it  seems pointless enough to process a message with no content, which is possibly why BizTalk rejects these. However, unlike empty files which are unlikely to have any meaningful dynamic context information besides the file name, a Service Bus message comes with a number of Brokered Message properties which are automatically added to the BizTalk message context by the SB-Messaging receive adapter. Aside from several standard properties, Brokered Message publishers can introduce any number of custom properties (up to a limit of 64KB). The BizTalk SB-Messaging receive adapter even allows you to promote these properties to a custom namespace when it is published to the MessageBox. Sometimes, these properties are all that is required for the transaction, particularly if it is used as a notification. Remember that not all BizTalk messages have to be XML; they  can contain any content, including binary – as long as BizTalk is not expected to process the content. The MSDN documentation for XLANG message also says that it can have “zero or more message parts”.

So what exactly happens when BizTalk pops a message with no body off of a Service Bus queue? To test this out, I did the following:

  1. Created a Service Bus namespace and test queue in Azure and noted the ACS credentials. (Note: BizTalk Server 2013 R2 now also supports Shared Access Signatures for authorisation)
  2. Created a Receive Port and an SB-Messaging receive location in BizTalk and configured it to receive messages off of the queue
  3. Created a FILE send port that subscribes to messages from the Receive Port created in the previous step (to prevent persistence exceptions due to no subscription)
  4. Created a small console app to send a blank message to the queue; note that this only takes a couple of lines of code when using the Microsoft Azure Service Bus package available via Nuget:image
  5. Ran the console application and observed the resulting suspended message and event log entry. Note that the custom BrokeredMessage property was automatically placed in the message context:SNAGHTML23575df

Remember also  that once a message makes it through a receive adapter, it travels through a pipeline. A custom pipeline might contain components that process the context data in a message. In a recent case, we wanted to receive a message off a Service Bus queue that contained a timestamp and a BAM Activity ID within the Brokered Message properties and use it to finalise the BAM record. Our custom pipeline would read the properties from the message, close the BAM record, and then dispose of the message (as there was no need to persist it from this point on).  Curiously enough, the pipeline processing succeeded. However, we still saw the 2nd error mentioned above appearing in the event log. So this proves that the error occurs after the pipeline handles the empty message without issue (provided your pipeline doesn’t contain a disassembler or other component that relies on the presence of a message body).

We could have chosen to ignore the errors, since we know our mission was still being accomplished (BAM record closed, and message was popped off of the queue). However this would introduce noise within a monitoring solution like BizTalk360 and potentially cause confusion for the support team. In the end, since the integration platform was the publisher of the Brokered Message anyway, we chose to introduce some content in the message body which alleviated the issue. However, this isn’t a great story because:

  • Message sizes in Service Bus are limited to 256KB, so you need to take precautions that messages don’t exceed this length, and
  • Sometimes you are not the publisher of the message and won’t have the option to control the body content.

I suppose another solution would be to write a custom adapter based on the existing SB-Messaging adapter that would gracefully handle an empty message, perhaps something along the lines of Nino Crudele’s proposed changes to the custom file adapter included in the SDK.  But that’s a task for another day when there’s time to spare.