Tuesday, 31 March 2009

Hi all

Alister Whitford has a question today on the online forums about preserving white space in a map. He thought that the functionality has changed between BizTalk 2006 and BizTalk 2006 R2. He has done a great job looking into stuff and it appears he is right. You can check out he thread here: http://social.msdn.microsoft.com/Forums/en-US/biztalkgeneral/thread/7dd28a9b-16b5-4c0e-90db-843caf4689ee where he also shows how not to preserve white space in R2 and thus have the same functionality as in 2006 (non-R2).

Hope this helps someone

--
eliasen

Tuesday, 31 March 2009 23:05:41 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 

Hi all

Disclaimer: I do NOT encourage the usage of he information in this blog post. The post is merely about some silly experiment, he results thereof and a conclusion on it.

So, this friend of mine (and former colleague) mentions every now and then that he isn’t all that sure that the “No subscribers found” should be an error but maybe more a warning. His man argument is, that if I have two subscribers for something, say all incoming orders are put into an archive file drop and also sent to the ERP system, and the send port that sends to the ERP system is unenlisted, then no errors will occur in BizTalk, but from a business point of view, the system is definitely not working. So the fact that you don’t get the error that indicates something is wrong with routing is not actually very useful, because parts of the system may be down after all.

Anyway, we were discussing what to do about this in case you just don’t want that error to occur if no subscribers were found. We came up with two options:

  1. Add a send port that uses Tomas Restrepos /dev/null adapter. you can find it at http://winterdom.com/dev/bts/index.html – look for “BizTalk 2006 R2 Null Send Adapter”. Using this adapter in the send port will cause everything going through the port to magically disappear.
  2. Mostly for fun we came up with the idea to have an orchestration that only as one receive shape. This receive shape should receive a message of type System.Xml.XmlDocument – since this will let the orchestration receive any message types. Also, it would have to be a direct bound port, so the orhestration would get ALL messages that are published to the MessageBox, so we would never get the “No subscribers found” error. Now, naturally, this solution is extremely silly, since we would fire up an orchestration for all published messages. But we started thinking what the subscription would look like.

The rest of this post is to explore item 2 above to find out how the subscription would look like.

To do this, I created four scenarios – just to explain it to you.

The four scenarios are:

  1. An orchestration that receives a message of type ReceiveSchema.xsd and is linked to a “Specify Later” port. This is the normal and widely used scenario.
  2. An orchestration that receives a message of type System.Xml.XmlDocument from a “Specify Later” port. The common way of receiving binary files or any file without caring about what files they are.
  3. An orchestration that receives a message of type ReceiveSchema.xsd and is linked to a direct bound port. This is the common way to receive ALL published orders, no matter what receive port or orchestration they were published from.
  4. An orchestration that received a message of type System.Xml.XmlDocument and is linked to a direct bound port. This is not something I have ever seen used, but this is what I want to find out about :-)

So, to summon up the subscriptions:

Scenario Subsription Description
1

http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {C464C9C6-F4BB-4ADF-9322-B2E89E6C8885}  And
http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == http://ReceiveEverything.ReceiveSchema#ReceiveSchemaRoot

This is the most common subscription. It consists of both a ReceivePortID (Because the logical port is bound to a physical port) and the message type (Because I am using a strongly typed message).
2 http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {C464C9C6-F4BB-4ADF-9322-B2E89E6C8885} This subscription is partly like the first one. The ReceivePortID part is the same, but no message type is specified. This is because I am using System.Xml.XmlDocument as message type, and this is just a “catch all” message type.
3 http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == http://ReceiveEverything.ReceiveSchema#ReceiveSchemaRoot This subscription has the part of the first subscription that was missing from the second one and it doesn’t have the part that was actually in the second subscription. This is because I am now using a direct bound port, and therefore the port ID becomes irrelevant in the subscription. I am using a strongly typed message, though, so the message type is relevant.
4   Surprised? A completely empty subscription. Kind of makes sense, when you think about it, since we are using a direct port, so the port ID is irrelevant and we are using a untyped message, making the message type irrelevant.

Now then… As I wrote, it makes sense, but it wasn’t what I was expecting, actually. With this empty subscription, I STILL get the “No subscribers found” error when I pick up a message and publish it into the Message Box.

So instead of doing this, I started thinking about what else to do. So I created a receive port with a receive location and let a message go through it and get suspended. Looking at the details of the context of the message that was suspended I gor this:

ReceiveLocationSuspended

So… I need a subscription that is not empty, but that will make sure my orchestration gets EVERYTING that is published into the MessageBox. This is done by setting the filter on he receive shape of my orchestration in scenario 4. The filter will have to include one of he above properties that is promoted. But looking at them I really don’t expect a message created inside an orchestration and then sent to the messagebox to have any of those properties set. So I decided to create a small orchestration that will simply just send a message to the messagebox. The context of the message published to the MesageBox looks like this:

OrchesrationSuspended

As you can see, no overlap at all.

So, as I see it, a filter like “BTS.ReceivePortID exists OR BTS.Operation exists” should do the trick. Now, this subscription works in my small example, but I cannot guarantee it will work for all scenarios. I can’t think of an example right now where either the ReceivePortID or the Operation doesn’t exist, but there might be examples.

So… Basically, the whole idea about having an orchestration taking in ALL published messages to avoid errors about no subscribers is REALLY silly and should not be implemented. And if you choose to do it anyway, please remember that the above filter isn’t guaranteed to work in all scenarios… I was just playing around :-)

Not sure this will ever help anyone… but there goes :-)

--
eliasen

Tuesday, 31 March 2009 22:48:02 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 
Wednesday, 25 March 2009

Hi all

Someone at the online general BizTalk forum asked a question about combining two messages in a map. Now, he all ready knew about creating the map from inside an orchestration, but let me just quickly summon up for those not knowing this. If you have two messages inside an orchestration that you need to merge into one message in a map, what you do is that you drag a transformation shape into your orchestration like this:

DualInputOrchestration

In my example, I have a parallel convoy to get the two input messages into my orchestration. I then have two different ways of combining the two input messages into one output, and each is then output.

Anyway, after the transform shape is dragged onto the orchestration designer, you double-click on it to choose input and output messages like this:

DualInputCreateMap

You can add as many source messages as you want – I have chosen two messages. Make sure the checkbox at the bottom is selected. Then click “OK” and the mapper will open up. It will have created an input schema for you, which is basically a root node that wraps the selected source messages. At runtime, the orchestration engine will take your messages and wrap them to match this schema and use that as input for the map.

In my case, I have these two schemas:

DualInputSchemaHouseBill 

and

DualInputSchemaWayBill

My output schema looks like this:

DualInputSchemaOutput

The automatically generated map looks like this:

DualInputGeneratedMap

As you can see, the destination schema is just like my output schema, but the input schema wraps my two input schemas into one schema.

So… I have just briefly explained how two create the map that can combine two messages into one. Now for the functionality inside the map.

Most maps like this can be mapped like any other complex input schema. But sometimes you need to somehow merge elements inside the source messages into one element/record in the destination. This automatically becomes different, because the values will appear in different parts of the input tree.

The requirement that was expressed by the person asking the question in the online forum was that these two inputs:

DualInputSchemaHouseBillExample

and

DualInputSchemaWayBillExample

and combine them into this:

DualInputSchemaOutputExample

So basically, there is a key that is needed to combine records in the two inputs. My schemas above are my own schemas that roughly look like the schema that was in use in the forum.

My first map that will solve the given problem looks like this:

DualInputMapFunctoids

Quite simple, actually. I use the looping functoid to create the right number of output elements, and I use the iteration and index functoids to get the corresponding values from the WayBill part of the source schema. The index funtoid can take a lot of inputs. In my case the path to the element is always the first until the vey last step, where I need to use the output of the iteration functoid. So I have only two inputs: The element that loops and the index of the parent of this element because that is the only place where I need to go to a specific element.

This works very nicely, but it has one serious drawback (and a minor one, which I will get back to later): It requires that the elements appear in the exact same order in both inputs. If this restriction can be proven valid, then this is my favorite solution, since I am a fan of using the built-in functoids over scripting functoids and custom XSLT if at all possible. I didn’t ask the person who had the issue if this restriction is valid, but thought I’d try another approach that will work around this just in case. This requires some XSLT, unfortunately, and the map looks like this:

DualInputMapXSLT

Quite simple, really :-) The scripting functoid takes care of the job for me. It is an “Inline XSLT Call Template” functoid and the script goes like this:

<xsl:template name="BuildOutput">
<xsl:param name="ID" />
<xsl:element name="Output">
<xsl:element name="Number"><xsl:value-of select="$ID" /></xsl:element>
<xsl:element name="OriginPortId"><xsl:value-of select="/*[local-name()='Root' and namespace-uri()='http://schemas.microsoft.com/BizTalk/2003/aggschema']/*[local-name()='InputMessagePart_0' and namespace-uri()='']/*[local-name()='HousebillRoot' and namespace-uri()='http://DualInput.DualSchemaHouseBillInput']/*[local-name()='HouseBillsNode' and namespace-uri()=''][HouseBillNo = $ID]/*[local-name()='OriginPortId' and namespace-uri()='']" /></xsl:element>
<xsl:element name="ShippingAddress"><xsl:value-of select="/*[local-name()='Root' and namespace-uri()='http://schemas.microsoft.com/BizTalk/2003/aggschema']/*[local-name()='InputMessagePart_1' and namespace-uri()='']/*[local-name()='WayBillRoot' and namespace-uri()='http://DualInput.DualSchemaWayBillInput']/*[local-name()='WayBillInfo' and namespace-uri()=''][WayBillNo = $ID]/*[local-name()='ShippingAddress' and namespace-uri()='']" /></xsl:element>
<xsl:element name="ContainerAddress"><xsl:value-of select="/*[local-name()='Root' and namespace-uri()='http://schemas.microsoft.com/BizTalk/2003/aggschema']/*[local-name()='InputMessagePart_1' and namespace-uri()='']/*[local-name()='WayBillRoot' and namespace-uri()='http://DualInput.DualSchemaWayBillInput']/*[local-name()='WayBillInfo' and namespace-uri()=''][WayBillNo = $ID]/*[local-name()='ContainerAddress' and namespace-uri()='']" /></xsl:element>
</xsl:element>
</xsl:template>

Now this looks complex, but really it isn’t. Let me try to shorten it for you to be more readable:

<xsl:template name="BuildOutput">
<xsl:param name="ID" />
<xsl:element name="Output">
<xsl:element name="Number"><xsl:value-of select="$ID" /></xsl:element>
<xsl:element name="OriginPortId"><xsl:value-of select="XXX/*[local-name()='HouseBillsNode' and namespace-uri()=''][HouseBillNo = $ID]/*[local-name()='OriginPortId' and namespace-uri()='']" /></xsl:element>
<xsl:element name="ShippingAddress"><xsl:value-of select="YYY/*[local-name()='WayBillInfo' and namespace-uri()=''][WayBillNo = $ID]/*[local-name()='ShippingAddress' and namespace-uri()='']" /></xsl:element>
<xsl:element name="ContainerAddress"><xsl:value-of select="YYY/*[local-name()='WayBillInfo' and namespace-uri()=''][WayBillNo = $ID]/*[local-name()='ContainerAddress' and namespace-uri()='']" /></xsl:element>
</xsl:element>
</xsl:template>

Here XXX is the XPath from the root node down to the HouseBillsNode node and YYY is the XPath from the root node down to the WayBillInfo node.

Basically, the script is fired by the map for each HouseBillNo element that appears (3 in my example) and the script will create an Output element with the HousebillNo value and i will then use the number to look up the values that correspond to the key in the other parts of the input.

There are some drawbacks to this solution as well, and I will just try to summon up the drawbacks here:

Drawbacks for first maps

  1. If the elements do not appear in the exact same order in both inputs, the map will fail.

Drawbacks for the second map

  1. The script has not been adjusted to handle optional fields. So it will create the output fields no matter if the input fields exist in the source.

Drawbacks for both maps

  1. If the HouseBill input has more elements than the other, then the output will be missing values for the elements that would get there values form the second input.
  2. If the HouseBill input has fewer elements than the other, then the output will simply not have records corresponding to these extra elements in the WayBill input.
  3. Both scenarios can be handled in the XSLT, naturally, if needed.

There are probably other drawbacks – most of them related to the fact that I was too lazy to handle all exceptions that might occur. But you should get the idea anyway :-)

The solution can be found here

.

Hope this helps some one…

--
eliasen

Wednesday, 25 March 2009 23:26:40 (Romance Standard Time, UTC+01:00)  #    Comments [5]  | 
Tuesday, 10 March 2009

Hi all

I decided that it was time to put my functoid library which was earlier hosted at http://www.eliasen.eu/DownloadSoftware.aspx to Codeplex.

You can find them along with the documentation at http://eebiztalkfunctoids.codeplex.com/ from now on.

Cheers

--
eliasen

Tuesday, 10 March 2009 21:36:19 (Romance Standard Time, UTC+01:00)  #    Comments [0]  | 
Monday, 09 March 2009

Hi all

A couple of months ago, while trying to solve the If-Then-Else issue within a map in a nice way, a fellow BizTalk MVP suggested to me that I could just have the script inside a custom scripting functoid and then copy the script from custom scripting functoid to custom scripting functoid.

Naturally (as I assumed it was, back then) I told him that this was impossible, because BizTalk wouldn't let me have two custom scripting functoids which contains the same method, ie. the two methods have the same signature.

"Sure you can", he replied.... So I had to check it out... I fired up my BizTalk 2006 R2 virtual machine, and sure enough: He was right. I was in chock, because I was totally sure i was right. so I fired up a BizTalk 2006 virtual machine and again; He was right and I was wrong.

Now... those who know me will know that when I am convinced I am right, I will usually go to great lengths to prove it :-) So I stepped down a version and tried BizTalk 2004. Again no luck.

But FINALLY, when trying it on BizTalk 2002, it turned out that I was right. Back in BizTalk 2002, scripts were in VBScript and here you can not have multiple custom scripting functoids with methods with the same signature. In versions after BizTalk 2002, the compiler will collapse those methods into one, but in BizTalk 2000 and 2002, this is not done, and therefore an error occurs.

So all in all, I discovered this limitation back in 2003 and never questioned it again since. So let this be a lesson to all (especially me, because I always think I am right :-) ) - that sometimes we need to reevaluate what we think we know.

Hopefully this post will:

  1. encourage people to reevaluate opinions and knowledge
  2. inform others like me, who thinks that you cannot have the same method signature twice in a map, that this is wrong :-)

--
eliasen

Monday, 09 March 2009 21:51:43 (Romance Standard Time, UTC+01:00)  #    Comments [0]  | 
Sunday, 08 March 2009

Hi all

So, I have written two previous posts about how to solve the If-Then-Else problem in a map. The first post discussed the way to use built-in functoids to solve the issue. The second post discussed the issues I had creating a custom functoid to do the job.

Well, I now have a new way of doing it, which is not just one functoid, but still it's prettier than what I can do with the built-in functoids.

Basically, as discussed in my post about the issues with the different functoid categories, a functoid that is in the String category cannot accept a logical functoid as input. A scripting functoid can accept a logical functoid as input, but I can't create a custom scripting functoid where I decide what script to appear inside the scripting functoid at design time.

So the solution I am describing in this post is a combination of the two.

This screenshot describes a map that solves the If-Then-Else problem:

IfThenElse

The blue functoid with the crappy icon is programmed by myself. It is a simple functoid, which takes in three parameters, which are all strings. First, it tries to convert the first parameter to a boolean. If this fails, a "false" is assumed. Then, if the boolean was true, the second parameter is returned and if it was false, the third parameter is returned.

Now, since a string functoid cannot take a logical functoid as an input, I use a custom scripting functoid that is very simple:

public string Same(string str)
{
return str;
}

Which is really annoying to have to do, since... well... I take in a string and return the exact same string. Oh well...

You can find my functoid and the project that uses it as file downloads at the bottom of this post. Note, that the functoid library contains a whole bunch of functoids, of which only one is relevant. The library contains all the functoids I built trying to solve the If-Then-Else issue. The only needed functoid will be included in my downloadable functoid library at a later point.

Now, the advantages of this solution is, that it only requires three functoids all together. The best I could do with the built-in functoids were four, and five were sometimes the prettiest solution.

Functoid library: here

Project that uses the functoid: here

--
eliasen

Sunday, 08 March 2009 22:02:37 (Romance Standard Time, UTC+01:00)  #    Comments [2]  | 

Theme design by Jelle Druyts