Yossi Dahan [BizTalk]


Wednesday, April 28, 2010

Calling .net 3.5 assemblies from BizTalk 2006

This is one of those - “you don’t know for sure until you try” – things….

Couldn’t think of any reason why this would not work, but had to try to be sure.

BizTalk 2006 uses VS 2005 and .net framework 2.0 (so does BizTalk 2006 R2) and so every c# (ok, or VB) project you wish to reference from your, say, orchestration, is limited to these.

The main downside of this for me these days is the lack of support for LINQ, which I’ve grown to love.

Fortunately – as the CLR targeted by .net 3.0 and 3.5 hasn’t changed (unlike .net 4.0!) BizTalk would quite happily, it turns out, execute code built on VS 2008 targeting .net framework 3.5 if you lazy load it (Activator.CreateInstance).

Don’t think I’d want to lazy load any reference used from now on (and haven’t yet checked the impact of this on, for example assembly caching (or the lack thereof), but I have a bit of code that requires lazy loading anyway coming up, and given that – I’m definitely using VS2008 for that!

Does Visual Studio 2010 breaks BizTalk?

This suggests it may have, and I’ve had the same experience – after installing VS2010 my SSO service failed to start with the error -

Windows could not start the Enterprise Single Sign-On Service service on Local Computer.
Error 0x80131700: 0x80131700

Interestingly – repairing BizTalk did not solve it, neither did reinstalling it – when trying to configure the SSO service, after a fresh installation, I got the error

 Failed to connect to the SQL database 'SSODB' on SQL Server '…'
> > > 0x80131700

Luckily Richard Broida had posted about this (I’m on Windows 7, but it works just the same) which saved me a lot of time.



Tuesday, April 27, 2010

Application Infrastructure: Cloud Benefits Delivered

Apologies for playing parrot a little bit, but it was suggested that I’d publicize the event below, and I do think it’s going to be really interesting, so – here you go -

Want to bring the benefits of the cloud to your current IT environment? Cloud computing offers a range of benefits, including elastic scale and never-before-seen applications. While you ponder your long-term investment in the cloud, you can harness a number of cloud benefits in your current IT environment now.

Join us on May 20 at 8:30 A.M. Pacific Time to learn how your current IT assets can harness some of the benefits of the cloud on-premises-and can readily connect to new applications and data running in the cloud. As part of the Virtual Launch Event, Gartner vice president and distinguished analyst Yefim Natis will discuss the latest trends and biggest questions facing the Application Infrastructure space.

He will also speak about the role Application Infrastructure will play in helping businesses benefit from the cloud.  Plus, you'll hear some exciting product announcements and a keynote from Abhay Parasnis, GM of Application Server Group at Microsoft.  Parasnis will discuss the latest Microsoft investments in the Application Infrastructure space aimed at delivering on-demand scalability, highly available applications, a new level of connectivity, and more. Save the date!


Monday, April 26, 2010

Small gotcha when reading the Message Flow of a process

I’ve been diagnosing an issue in a process today, and got bitten by a small gotcha in the message flow view of a process in HAT (in this case – BizTalk 2006) -

When you’re looking at the message flow of a process you see a list of boxes, each representing a flow of a message from or to the process to either another process or a messaging port-


If you follow a link to a send port, you are presented with the message flow in the send port, generally listing which message was sent, using which adapter and what URI -


The important thing to note is that the port listed in the process flow is the name of the logical port in the orchestration, whilst the port listed in the send port’s view is the physical send port name.

Quite obvious when I think about it, but as the name ‘port’ is used to represent such different things, but the HAT UI looking so similar in both cases, this can get confusing.

I’ve spend 5 minutes chasing the wrong port as, unfortunately for me, we’ve had an old send port matching the name of the logical orchestration port, but it was not the one actually bound to it….


Tuesday, April 13, 2010

Inbound map fails due to nulls in incoming file

I’ve bumped into this scenario today -

A file, created by a third party, is being receiving by BizTalk using the file adapter (the file is being FTP uploaded by the third party).

Turns out that the file contains nulls (hex 0x00) in some of the fields, in some of the records.

This is evident when looking at the file in a hex viewer, although – to my surprise – when we opened, and then saved, the file in notepad (without making any changes) all nulls are replaced with spaces, which mostly meant we could only test this using the files supplied by the original creator, presumably a non-windows system.

Anyway - flat file disassembler happily processes the file and spits xml (we’re actually debatching the files in the disassmebler, so we’re getting lots of small xmls) where the attributes corresponsing to the fields with the null value, now how the escaped representation of a null. so far so good – the xml accurately represents the flat file.

At the end of the pipeline, however, we’ve got an inbound map, which then fails with the error -

The Messaging Engine failed while executing the inbound map for the message coming from source URL:"D:\Projects\BizTalk\Files\IN\*.csv" with the Message Type "<some message type>". Details:"An error occurred when parsing the incoming document: "'.', hexadecimal value 0x00, is an invalid character. Line 1, position 275.". "

Looks like the value was correclty identified as null, but that the mapper is very unhappy about that fact; the map was never actualy executed (the problem is not in any of our mapping logic as far as I can tell, but in the ‘engine’ itself); I was not aware of any restriction about the use of nulls, but it seems the maps refuse to execute.

A similar error is received when trying this in VS (test map)

We’ve scratched our heads a little bit, but eventually found a work around of kind in the BizTalkGurus.com forums - http://www.biztalkgurus.com/forums/p/6535/12594.aspx where Mark answers he’s own question and suggests that configuring the fields in question with null as the padding character will instruct the disassembler to remove any nulls it finds.

Works like a charm.

Of course this can only work if the schema is not going to be used by an assembler delivering the message, as it would happily pad the very same fields with quite a few nulls on the way out, which has to be counter productive!