What makes this minor update important is that most of these context properties are REST related, and will enable you to build flexible REST based integration solutions where you can dynamically set HTTP methods, URLs, or headers. The list of context properties added to the enumeration is below.

HttpHeaders

HttpMethodAndUrl

InboundHttpHeaders

InboundHttpMethod

InboundHttpStatusCode

InboundHttpStatusDescription

IssuerName

IssuerSecret

OutboundHttpStatusCode

OutboundHttpStatusDescription

StsUri

SuppressMessageBodyForHttpVerbs

VariablePropertyMapping

This new version is fully backwards compatible, and installing it will only require uninstalling the previous version from the add/remove programs control panel and then running the new installer. Please post any issues/feedback/comments to the CodePlex project discussions page.

Azure App Services and Logic Apps have now hit public preview, and they have generated a lot of excitement (including with this writer). It’s a bit like Microsoft has hit a reset button and now all the Microsoft integration specialists have to start from scratch (at least in the cloud, BizTalk Server isn’t going anywhere for awhile, thankfully since I would miss it), at least when it comes to tooling, concepts don’t really change…

One of the first proof of concepts I tried to work with (actually this was a team effort with a bunch of integration specialists excitedly fighting over the keyboard) was creating a Logic App that would pick up emails from a POP3 mailbox, and write the contents to a folder in my DropBox account, the file being named based on the subject of the email + .txt, and the contents of the file being based on the body of the email. This is easy enough to do with the POP3 and the DropBox connectors as below.

We had quite a lot of difficulty trying to figure out how to set the filename in DropBox since it required a combination of hardcoded strings and the email subject which flowed out of the POP3 connector. We tried a kazillion different combinations, and nothing seemed to work.

I reached out to the BizTalk Advisors Yammer forums hosted by Microsoft and got a helpful response from Stephen Siciliano at Microsoft in a snap (that’s Stephen!). His suggestion is that if you’re mixing string constants and functions then you should not surround your function with quotes, and you should not use the @ escape character before the function. Also, if you want to concatenate strings you must use the @concat function. My final function looked like the below.

@concat(‘jc\’, triggers().outputs.body.Subject, ‘.txt’ )

This resulted in the email body being written to a file in a folder in the root path called jc, with the filename being based on the email subject + .txt. Interestingly, if you view the code view you’ll notice that the slash after the folder name gets automatically escaped (so you don’t have to escape it, in fact if you do then you will end up with two escaped slashes).

I hope this helps others who are also struggling to learn the new syntax. Just like with any new language, once you understand the rules the learning curve is a lot less steep. Don’t take it for granted that this syntax will remain the same. I imagine that by the end of the public preview Azure App Services might be a very different beast.

A quick blog post to document a tough lesson learnt by myself so others can hopefully avoid making the same mistake. Changing a BizTalk WCF send port’s send handler (i.e. the host instance it is associated with) will remove all passwords that are currently configured on the send port. This includes credentials to access the target service as well as the proxy server password if there is one. This appears to be the case with WCF-SQL receive locations as well, however a quick test with the File adapter showed that this behavior might not be consistent with non-WCF adapters so it’s best to try your change on a development environment first.

How can you tell if your password has been wiped? Normally when you access the send port, if you have previously entered a password then you will see the black circles indicating a masked password is present. If the password has been wiped then the field will be totally blank as below.

As a practice I would encourage others to avoid hardcoding passwords on send ports and to use the SSO’s credential mapping facilities instead (a blog post on how to achieve this using the BRE Pipeline Framework soon). This isn’t applicable for proxy server credentials but those can typically be set on the send handler level so you don’t have to worry about associating then with your send ports.

Moral of the story, if you’re changing your adapter handler on a port and there are passwords associated with the port then re-enter them.