Hi all

Just to let you know, I am now listed on http://www.biztalkblogs.com along with lots of other cool BizTalk bloggers

--
eliasen

Hi all

I have just released version 5 of my pipeline components library.

It has the following additions:

• SuspendAfterMap. In BizTalk 2009 (which is the only supported BizTalk version for this pipeline component) there has been added support for recoverable interchanges for errors occurring during mapping on receive ports after disassembling. This is achieved by setting a specific promoted property to “true”. I have created a pipeline component that will do this for you.
• WriteProperties. This pipeline component serves almost NO purpose at all, except I used it for debugging to see what properties existed on a message going through BizTalk. It will write out all context of a message to the eventlog, one event at a time.

It has the following new features:

• Promote. The pipeline component used for promoting a value based on an XPath expression and thereby enabling you to promote a specific instance of a reoccurring element has been enhanced by a “constant”. So instead of having to set the value of some property to the result of an XPath expression you can just enter a constant instead. If you enter both a constant and an XPath expression the constant wins. This new feature is quite handy if you need to set the value of for instance MIME.FileName to a specific value or any other property for that matter.

You can find the newest versions at http://eebiztalkpipelinecom.codeplex.com/

--
eliasen

Hi all

I have just released version 9.1 of my functoid library. Actually, nothing much new has appeared. I had accidentally left out the functoid I described at http://blog.eliasen.dk/2009/03/08/SolvingTheIfThenElseProblemInAMapPartIII.aspx from version 9, so now it is reintroduced – and it has also been added to the documentation.

Find the newest version of the functoids library at http://eebiztalkfunctoids.codeplex.com – thanks.

--
eliasen

Hi all

I have been running into too many issues with BizTalk 2009 on VS.NET 2008 lately. This post is just to mention them and let everyone else know that they are not the only one – and that they will be reported to MS and hopefully fixed quickly.

Build action of schemas
Some times the “build action” of a schema in your BizTalk project is set to “None” instead of “BtsCompile”. When this happens, the schema is not compiled into the assembly and can therefore not be used for pipeline components, maps, orchestration messages, and so on. It happens if you drag a schema from your explorer into your project, but it also happens sometimes when you drag a schema between two projects inside VS.NET.

More build action of schemas
The above error could be more easy to live with, if it weren’t absolutely impossible to know when the “Build action” property of the schema in visible in VS.NET – some times the property is visible and you can change the value. Other times it is not. Quite confusing. I have found that if I add a schema to a project, then the property is suddenly visible for all schemas in the project. Change the ones that need changing and delete the schema you added.

Auto save a map before schemas are chosen
When you add a new map then at some point VS.NET auto saves the map, but if this happens before you have chosen both the source and destination schema you suddenly get an error, which you really do not expect, because you weren’t doing anything at the time of the error. This also occurred in previous versions of BizTalk.

Map looses information about schemas
I have seen several times, that even after choosing source- and destination schema for a map and dragging a couple of links in the map and saving it, then at compile time, I get an error about the map not having source- and destination schemas. So I need to choose them again, and redo all the links, because they have magically disappeared. This happens for maps that uses both schemas from the same project as schemas from referenced projects.

Output window
The output window seems to not always show all information when compiling/deploying. Some times the information comes all at the end instead of being written to the output windows as it happens. Other times, I can rebuild my entire solution and the output windows will only show me the one warning that occurred during compilation.

Dragging elements in Schema Editor
Dragging elements inside the schema editor has had me baffled since BizTalk 2002. Some times, I need more than 20 tries to get an element to be dragged – and sometimes it just works. Annoying? Indeed it is!

Copy local fails
If I have a project (P2) that references another project (P1), then after I have added an item to P1 and recompiled it, everything seems OK. BUT, if I then deploy from within V.NET, things start to go wrong. From then on, it seems that the “Copy local” property of the project reference is ignored. Whenever I recompile P2, I do NOT get the P1.dll copied to the local folder of P2. This causes all sorts of stuff as also explained here by Ryan: http://dotnet.org.za/ryancrawcour/archive/2009/07/17/biztalk-2009-amp-visual-studio-2008-annoyance-2.aspx

Setting properties for more than one project at the same time
See here: http://dotnet.org.za/ryancrawcour/archive/2009/07/15/biztalk-2009-feature-missing.aspx for Ryans thoughts on this.

--
eliasen

Hi all

Microsoft have finally released some pricing information about Azure. Find it here: http://www.microsoft.com/azure/pricing.mspx

--
eliasen

Hi all

I did a follow up to my old post about how to loop around the elements of a message a couple of days ago.

As you can se from the comments to my followup, Thiago mentions that there isn’t any performance hit because everything is done inside an atomic scope. Now, Thiago is naturally correct when he states, that no persistence occurs inside an atomic scope. But as you can also see from the comments, I wondered about what to do about using a request-response port – so I just had to test it.

For BizTalk 2009, just as the previous versions, you CAN’T have both the send shape and corresponding receive shape used for a request-response port in the same atomic scope. At compile time you will get this error: “an atomic scope may not contain or call a service or scope that contains both the send and the corresponding receive of a requestresponse operation on a 'uses' port or servicelink”.

This may seem odd at first glance, but it is due to the fact, that in order to make sure the ACID properties are respected at runtime the orchestration engine submits messages that are sent out to the messagebox, but it doesn’t release them for the messagebox to route until the atomic scope has finished. This way, if an error occurs inside the atomic scope, no messages have actually been sent, and therefore, BizTalk can guarantee a consistent state.

So basically, if the message isn’t released until AFTER the atomic scope, then there is no way you can receive the reply inside the same atomic scope. Makes sense.

SO, if you want to loop around elements in a message by calling a receive pipeline inside your orchestration, you can’t use request-response ports, as you can with other patterns. Sorry, but that is the way it is.

Conclusion:
If you want to loop around elements inside an orhestration, use a receive pipeline if possible since this is done in an atomic scope and therefore no persistence points occur. If not possible, use the pattern described here.

Thanks, Thiago for pointing out that my post needed some more details…

--
eliasen

Hi all

Today I faced a very peculiar problem. I was helping a customer split a BizTalk project into two projects, because some of the schemas that were in the original project needed to be common for other projects.

So this is what i started out with:

which is: Two schemas and a map between them.

And this is what I would like:

So basically, the common schema has been transferred to a common project. Now, naturally, I need to reference the CommonProject from the OriginalProject and then reload the schema in my map to make it work. But this is where the weird part starts. After compiling the NewCommonProject and adding the reference, this is what showed up in the schema browser when I wanted to reload the schema in the map:

Basically, my new project didn’t have any schemas inside it. After much troubleshooting, thinking that the issue was something with the newly compiled dll didn’t get copied to the bin folder of the OriginalProject and trying lots of stuff with that, I finally figured it out.

I just happened to notice that the file size of the NewCommonProject.dll was only 5kb which seemed to small. So I browsed the dll in the object browser and it was totally empty. Weird. Then I went and looked at the properties of the schema, and didn’t see anything unusual. So I added a new schema to the project just to see what would happen with that. This new schema showed up in the schema browser. Even weirder. But then I went and looked at the properties of the schemas again and that’s when this new property suddenly showed up:

I changed the build action on the schemas to be “BtsCompile” and this did the trick. Now all the schemas showed up in the schema browser.

Now, another strange side to this story is, that by now, the Build Action property has disappeared again… I haven’t quite figured out when it appears and when it does not.

BUT, if you ever run into issues where your schemas just don’t show up anywhere… this might be your issue.

Hope this helps someone.

--
eliasen

Hi all

2 and a half year ago, I wrote a blog post about looping around elements, which can be found here: http://blog.eliasen.dk/2006/11/05/LoopingAroundElementsOfAMessage.aspx. In this post, I mention two ways to do something per element in a message. One is to use the XML (or flat file) disassembler to split the message into lots of messages and have them handled individually, and the other is to do it inside an orchestration.

Since then, BizTalk has been updated such that you can now call a receive pipeline from within your orchestration, which gives you the another way of looping through elements inside an orchestration.

Often times, in the forums, users are suggested to loop through elements of a message inside an orchestration. It is a fairly common approach if you want the subelements of a message handled in the correct order, for instance.

This post is to make sure people know that looping around a message inside an orchestration can have a serious performance impact.

Say you receive a large message – 100MB. You start looping around it inside an orchestration and split it up into, say, 1000 messages of 100k each. Then, for each message you call a web service or send out the message to some system. What will happen is, that the orchestration will persist its state after each send shape, meaning that the 100BM is written 1000 times to the messagebox. Persistence points are something you always need to be aware of when designing your orchestrations, and with messages of 100MB, even more so.

SO, don’t just loop around a message inside an orchestration because you can… do it when you absolutely have to.

Thanks

--
eliasen

Hi all

Upon reading a forum post today, I stopped to think about the usage of custom XSLT to completely replace the mapper, custom scripting functoids and the built-in functoids.

Some people can’t be bothered using the mapper and go straight to custom xslt whenever a mapping is to be created. Others use the built-in functoids whenever possible. And the rest go for some path in the middle, with functoids and the occasional scripting functoid whenever the built-in functoids either can’t get the job done or seem to be too troublesome to use.

The advantages of custom XSLT

1. Performance. It seems rather obvious that automatically generated XSLT can’t perform as well as custom XSLT. So if you really need high performance, use your own XSLT.
2. Maintainability. I will be using this argument against custom XSLT as well but in essence, some people think that having a map with perhaps 200 functoids is too difficult to maintain. Sometimes you need lots of functoids in order to complete some mapping task that can be easily done in XSLT. In that case, the XSLT can be more readable and hence maintainable than using functoids.

The advantages of using the built-in functoids

1. Overview. Using the functoids can give a developer an overview of what functionality a map provides, whereas custom xslt needs to be gone through and “parsed” by a developer before he can understand what is happening.
2. Maintainability. (See, there it is again – in the opposite direction). A BizTalk developer knows about maps and functoids. He does snot necessarily know about xslt – and even if he does, he is not guaranteed to very proficient in it. By staying with the functoids you give a BizTalk developer the best possible opportunity to understand a new map he is going to maintain.

The advantages of using functoids and the scripting functoids

1. Everything is possible . Basically you can do what you want. Use built-in functoids as much as you prefer and throw in scripting functoids if you think the solution either can’t be done with the built-in functoids or is too troublesome to do.

My preference

Well, those that read my blog regularly wont be surprised when I say that my preference is to use the built-in functoids whenever possible. I turn to XSLT only when I cannot solve my problem with the built-in functoids. And when I need XSLT, I always use custom scripting functoids to supplement the other functoids, so I let as much of the job as possible be handles by built-in functoids. I never use custom XSLT to replace the map. My main reasons for this are:

1. Maintainability. I truly believe that it is easier for a new BizTalk developer to troubleshoot and/or change an existing map if only built-in functoids are used.
2. Overview. If a BizTalk developer opens up a map and sees lots of scripting functoids, he needs to open them all up and examine the code inside it in order to know what the map does. And after looking at 5 different scripting functoids, he needs to go back and look at the first again. Really annoying!

If I am doing a rally complex map where the number of custom scripting functoids is larger than the number of built-in functoids, I might consider using a custom XSLT script… but this haven’t happened yet And also, if i run into really serious performance issues, I will consider it as well, off course.

Just my thoughts.

--
eliasen

Hi all

When trying to help the guy I wrote about in http://blog.eliasen.dk/2009/07/07/DistinguishedFieldNotWorking.aspx getting his distinguished field working, another guy suggested that he just used he xpath function instead of trying to get the distinguished field working. Now, he actually ended up using the xpath function because he had a reserved word in the xpath statement to the field he needed to access the field, but I thought I’d just write a post about why the xpath function should be avoided and perhaps generalize the post to the usage of promoted properties, distinguished fields and the xpath function. When to use what and why…

Why use distinguished fields over the xpath function

1. Readability. Inside an expression shape, it is much easier for a BizTalk developer to look at “Message.MyElement.MyField” than it is to look at “xpath(Message, “string(/*[local-name()=’MyElement’ and namespace-uri()=’http://mynamespace.com/something/somethingmore’]/*[local-name()=’Myfield’ and namespace-uri()=’’])”)”
2. Maintainability. If you need to change a schema at some point, the distinguished field is automatically updated to correspond to the new xpath expression that points to the relevant field (if you are using the BizTalk Editor, that is). If you use the xpath function, you need to find ALL occurrences of the xpath function in your entire solution that has an xpath expression that needs to be updated.
3. Performance. If you use the xpath expression to get values form a message, then the entire message needs to be loaded from the database and the xpath expression is then evaluated. Distinguished fields, on the other hand, are kept in the context of the message and is therefore loaded quickly at runtime.

Why use promoted properties over distinguished fields

1. Routing. Only promoted properties can be used for routing in the internal publish/subscribe engine if you need to route based on the content of a message.
2. Correlation. If you need to correlate a received message into a specific instance of your orchestrations, then you need to do this using promoted properties, as these are the only properties that can be added to a correlation type. This makes sense when you think of it, because correlation is really just runtime routing - setting up the correct subscriptions at runtime that will make the message hit the correct orchestration instance. And routing can only be done with promoted properties, hence these are needed for correlation.
3. Tracking. You cannot track distinguished fields – for tracking, you need promoted properties.

Why use the xpath function

1. Distinguished fields cannot be used because there is a reserved word in the path of the xpath expression
2. Distinguished fields cannot be used because you need to set or read a value from a reoccurring element

Why use distinguished fields over promoted properties

1. Performance. You want to keep the number of promoted properties as low as possible, since the messaging engine really needs as few promoted properties as possible to evaluate when finding out which subscriptions match an incoming message that is published to the MessageBox.

So, to sum up: Use distinguished fields whenever possible, switching only to xpath function or promoted properties if really needed.

--
eliasen