Tuesday, 18 September 2007

Hi

An old collegue of mine asked me if there wasn't anyhow he could overwrite the folder of a send port using the FILE adapter, so that he could decide the entire path of a file that was to be written from within his orchestration.

After all, you can overwrite many things, like SMTP server to be used in the send port or the username and password for an FTP connection. So why not the file folder?

Well, I have investigated it a little bit, and I can't get around to making BizTalk do it.

I tried:

  1. Set the folder on the send port blank, and use the %SourceFileName% as filename and set its value (The FILE.ReceivedFileName property of the message) inside the orchestration. This isn't valid, since the folder path can not be empty.
  2. Set the folder to c:\ and set the FILE.ReceivedFileName property to be <directory> + "\\" + <filename>. This didn't work either. When writing the file, BizTalk strips all folder names from the FILE.ReceivedFileName value and just wrote the file with filename in c:\

Off course, you can use a dynamic port to do it, but this customer wanted to avoid seeing all those subscriptions in the subscription viewer.

So I don't see a way around it. And basically, when you know it works like this, it makes sense that the administrator who has decided what folder files go into also gets to decide that you can not overwrite this. Oh well, that's life.

Hope this helps someone at some point...

--
eliasen

Tuesday, 18 September 2007 22:29:23 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 
Sunday, 16 September 2007

Today, I discovered, that google groups can tell me how many posts I have made to newsgroups.

I switched profile at some point in my newsgroup career, so there are two profiles to watch:

This one (my first) and this one (my current).

Quite a lot of posts, actually - no wonder I get tired every now and then :-)

--
eliasen

Sunday, 16 September 2007 23:26:30 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 

Well, I suppose we have all been there – in order to get the business process running, a specific element from a schema needs to be promoted in order to route on it, correlate on it, and so on.

 

Unfortunately, elements that can occur more than once can not be promoted. This, off course, makes perfectly sense, since the property can only hold one value, and how would BizTalk know which one of the many occurring elements to take the value from at runtime? So we agree with the limitation, but hope for a nice solution. :-)

 

If you try to promote a reoccurring element, you get this error when adding it to the list of promoted properties:

“This node can occur potentially multiple times in the instance document. Only nodes which are guaranteed to be unique can be promoted.”

 

Right. Now, some people have found the editor for the XPath describing the element that one wants to promote. If you have promoted some element, you can click on it like this:

Then you can click on the dot at the right of the line, and get into the editor like this:

 

Now, wouldn’t it be lovely, if you could just change this expression to include for instance an index on the reoccurring element? In my example from this screenshot, the “ReoccuringRecord” record can occur multiple times. So it would be nice, if I could just change the XPath to be like this:

 

/*[local-name()='ExampleRoot' and namespace-uri()='http://PromotingReoccuringElement.ExampleSchema']/*[local-name()='ReoccuringRecord' and namespace-uri()=''][1]/*[local-name()=’ElementWhereNumber1IsPromoted’ and namespace-uri()='']

 

By setting the “[1]” into the XPath, I state that I will be needing the first occurrence of the ReoccuringRecord and therefore, this XPath expression will always give me exactly one node. Unfortunately, the engine can not see this, so the error will be the same, only difference being that this error doesn’t occur until compile time:

 

Node "ElementWhereNumber1IsPromoted" - The promoted property field or one of its parents has Max Occurs greater than 1. Only nodes that are guaranteed to be unique can be promoted as property fields.

 

Bummer!

 

So how do we get this working? If I really need to promote a value that occurs in an element that might occur multiple times, I see four options:

 

  1. Map to a schema on receive port
  2. Custom pipeline component
  3. Orchestration to do it and then publish to MessageBox
  4. Call pipeline from orchestration

I will go these options in more detail here:

 

Option 1: Map to a schema on receive port.

When a map is executed on a receive port, some extra magic functionality is performed by BizTalk. After the map has been executed, the message is sent through some code that promotes properties that are specified inside the destination schema. If you execute a map inside an orchestration, this doesn’t happen.

 

So you can create a schema that has an extra field, in which you place the value that needs to be promoted. This element must not be able to occur multiple times. Promote this new field, and after the map on the receive port has been executed, you have your value promoted.

 

Option 2: Custom Pipeline Component.

It isn’t that difficult to create a custom pipeline component, that can promote a field for you. Your Execute method might look just like this:

 

public Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(IPipelineContext pContext, Microsoft.BizTalk.Message.Interop.IBaseMessage pInMsg)

{

    pInMsg.Context.Promote("MyProp", "http://ReoccuringElement.PropertySchema", "MyValue");

    return pInMsg;

 }

 

Of course, you will probably want to load the body stream of the IBaseMessage somehow, in order to find the value inside the body to promote and then replace "MyValue" with the value form within the XML.

 

Just use the pipeline component inside a custom receive pipeline, and you are all set.

 

Option 3: Orchestration to do it and then publish to MessageBox

Create a intermediate orchestration, that gets the input message. Then, it should create a new message of the same type in a message assignment shape like this:

NewMessage = InputMessage;

NewMessage(*) = InputMessage(*);

NewMessage(MyNewProperty) = xpath(InputMessage, xpathexpression);

 

Then, use a direct bound port to publish the message to the MessageBox. In order for the new property to follow the message, you need to initialize a correlation set on the send shape that is based on this new property.

 

Let other orchestrations and send ports subscribe to this message and let then do their work.

 

Option 4: Call pipeline from orchestration

The last option is to call a receive pipeline from within your orchestration. This requires a new schema, that has a field for the value to be promoted, just as in option 1. Inside your orchestration, map the input message to this new schema, and call a receive pipeline with this new message as a parameter. Remember to promote the field in this new schema. There is an article on MSDN about calling a pipeline from within an orchestration, which can be found at http://msdn2.microsoft.com/en-us/library/aa562035.aspx

 

Upsides and downsides

In order to choose which way to go in a specific solution, several things need to be considered.

 

Basically, I'd go for option 1 almost anytime. This is because it is best practices to map anything incoming into a canonical schema anyway. So instead of promoting values inside all your partners schemas - schemas they might change, you should promote from within your own canonical schema.

 

Reasons not to choose option 1 include: The canonical schema also has a reoccurring element, so it hasn't provided extra functionality with regards to getting this specific value promoted. Or perhaps, we aren't using canonical schemas, because there was no time for this when the project was started.

 

If we can't go for number 1, I'd go for number 3. Number 2 requires programming of a pipeline component, which can be a bottleneck, unless done correct. Also, the pipeline component is a whole new component to maintain, document and test. Number 4 requires a new schema and therefore also a map to be built. If I am ready to do this, I'd go for number 1 instead.

 

If I don't like number 3, for unknown reasons, I'd go for option 2 - the custom pipeline component. Allthough it is custom code, and must be done right, and testet and everything... I still feel that creating a new schema and map in order to call the pipeline in option 4 is overkill, since I'd go for option number 1 instead, which would also require the new schema and map.

I hope this explains some details about this issue, and that it helps someone in the future.

--
eliasen

Sunday, 16 September 2007 23:22:51 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 
Monday, 27 August 2007

Well well - a week ago, I finally decided it was time to start running again. In my earlier days, I was quite the runner, but the last 10 years or so, I have really been lazy :-S

Anyway, I ran 4,82 kilometers last tuesday, and 4,82 kilometers last thursday. Things went faily well, so yesterday it was time to run just a little bit faster.

BUT, after 4 kilometers or so, I teared a muscle :-(

So now I am not running... I am not even walking like a man :-(

I hope to be able to run again in a couple of weeks :-S

--
eliasen, who isn't running anymore.

Monday, 27 August 2007 11:02:09 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 
Thursday, 23 August 2007

Hi

The other day, I suddenly found myself in a situation, where I needed to use the "Find message" functionality and HAT to find a message, and I needed to filter on a promoted property.

My problems started appearing, when there were no promoted properties to select in the Message properties filter view. I had chosen my schema, but still, the dropdowns for promoted properties were empty.

So I checked that tracking of both message bodies and promoted properties were enabled in the receive port. Yes, they were... so I started wondering what might be the cause of this. And then I though: Oh yeah, you need to enable tracking of these individually in HAT. But in HAT I couldn't find anywhere to enable this. That stunned me for a couple of minutes. Turns out, that was in BizTalk 2004 :-S

Whoops :-)

And the I remembered that I needed to do two things in order to get the tracking of promoted properties to work:

The first is to enable the tracking in the receive port:

And the second thing is to enable tracking of each specific promoted property - and now I remembered it isn't in HAT anymore, it is in BizTalk Server Administration for each schema. So open BizTalk Server Administration. Go to the application that has the schema, for which you need to track promoted properties. Go to the schemas collection of this application, double click on the appropriate schema, go to the tracking pane, and here you must select the properties to track.

I googled this a lot, but had great difficulty finding any information... that's the reason for this post.

I hope others will find it useful in the future.

Comments are welcome

--
eliasen

Thursday, 23 August 2007 21:46:55 (Romance Daylight Time, UTC+02:00)  #    Comments [4]  | 
Friday, 20 July 2007

Hi

A couple of weeks ago, I switched from using web10 to using needhost as my web hotel provider. The primary reason for this was, that the mail service at web10 was incredibly instable. Half of the time, I couldn't connect with my pop3 server, and then suddenly, my mailbox was frozen somehow, so no new mail arrived for me for 6-7 days. That did it, and I switched to needhost.

I am very happy being at needhost - and everything seems to work well right now.

So hopefully, the blog will now be up and running for a looooong time :-)

--
eliasen

Friday, 20 July 2007 09:30:38 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 
Tuesday, 19 June 2007

Hi

Recently, I decided it was time for me to start looking for a new job. Luckily, I found a new one, and as of August 1'st, I am no longer employed at WM-data. I have been at WM-data since June 23'rd 2003 - just after I got my masters degree in computer science. I have been very happy with the job, but lately, I started wondering if another job might be even better.

I found this job at thy:data, where I have been hired as a solution architect for their integration projects. I will still be using BizTalk Server and I will still be the same me - just at another company.

Also, as a little side effect, I have decided to start a very small freelance company with just me in it. the company will be called eliasen.eu and the homepage with more information will be available soon, I hope.

--
eliasen

Tuesday, 19 June 2007 20:16:52 (Romance Daylight Time, UTC+02:00)  #    Comments [4]  | 
Monday, 09 April 2007

Hi

I have just written a blog post about using the SQL Adapter Wizard and during my tests for this post, I found the cause of an error that I saw someone in the newsgroups ask about. So I will just post the answer here.

I got these errors when compiling my project, in which I have used the SQL Adapter Wizard twice to create a schema for me:

Error 1 illegal name-hiding: 'Orchestration_1' hides 'SQLAdapter.Orchestration_1' on line 101 C:\Projects\BTS 2006\BlogEntries\SQLAdapter\BizTalk Orchestration_1.odx 102 23 

Error 2 symbol 'Orchestration_1' is already defined; the first definition is in file C:\Projects\BTS 2006\BlogEntries\SQLAdapter\BizTalk Orchestration.odx on line 101 C:\Projects\BTS 2006\BlogEntries\SQLAdapter\BizTalk Orchestration_1.odx 102 23

It turns out, that when you use the SQL Adapter Wizard to automatically create schemas for you, then an orchestration is also created for you. Yes, I knew that, you say? Well, so did I :-) What I didn't know was that the Wizard is clever enough to give the two orchestrations different filenames, but stupid enough to give them both the .NET type name "Orchestration_1". So when compiling the project, you have two orchestrations with the same fully qualified typename, which off course will fail.

See this screenshot:

As you can see at the lower right vorner of the picture, the "BizTalk Orchestration_1.odx" has "Orchestration_1" as its typename. Well, "BizTalk Orchestration.odx" has the same.

"So I just change one of them, no problem", you say? Well, there is another problem... If you look at the port types and multi-part message types in each orchestration, they are also given the same names. So changing the typename of one of the orchestrations removes the compilation error, but it will just give you the next set of errors, as more things are given the same name, and therefor more illegal name-hiding is taking place. Se the post here about what you can do to rename things.

I hope this helps someone.

--
eliasen

Monday, 09 April 2007 23:40:56 (Romance Daylight Time, UTC+02:00)  #    Comments [1]  | 

Hi

When using the SQL Adapter wizard to generate schemas for updategrams, queries or calling stored procedures, the wizard will create an orhestration and a schema for you in your project. The orchestration is named BizTalk Orchestration.odx (or if this allready exists, then it will add _1, _2 and so on) and the xsd will be called SQLService_<chosen_rootnode_in_wizard>.xsd

These names are of course not useful in most scenarios, since most projects have naming conventions that must be followed. Moreover, the orchestration is often just annoying, since the database read/update usually must happen in an allready existing orchestration.

What you should do is this:

  1. Rename the xsd to follow your naming conventions
  2. Rename the typename of the schema to match the filename
  3. Open the automatically created orchestration, and:
    • Update the parts of the two created multi-part messages to point to the new typename of the schema
    • Rename the port type that is created to something meaningful
    • Rename the multi-part message types that are created to be more meaningful.
    • The last two steps are very important, if you plan to use the SQL Adapter more than once in the same orchestration, since otherwise you will get type names in both generated orchestrations that are the same. And this isn't allowed, off course.
  4. Cut and paste the port type and multi-part message types from BizTalk Orchestration.odx to the orchestration where you actually need them.
  5. Delete the BizTalk Orchestration.odx file, since it is no longer needed.

So basically, the automatically created names of things when using the SQL Adapter Wizard are useless. And also, the created orchestration is useless after moving the automatically created types away from it.

I hope this is useful for someone at some point.

--
eliasen

Monday, 09 April 2007 23:27:38 (Romance Daylight Time, UTC+02:00)  #    Comments [3]  | 
Sunday, 04 March 2007

Hi

I had post some time ago, which explained how to promote fields from a schema generated by the SQL Adapter. This post contains some information that could be useful for people searching the net for information about changing the records in the generated schema into elements. A search for those words wouldn't have my post in the top 1000 hits, though :-)

So I thought just to have this simple post with a title that will hopefully match what people search for, and let them find the information.

That's it :-)

--
eliasen

Sunday, 04 March 2007 22:01:32 (Romance Standard Time, UTC+01:00)  #    Comments [0]  | 

Theme design by Jelle Druyts