BTUG meeting 2 december: BizTalk 2010

15 November 2010

nederlandse-vlag

Op 2 december a.s. geef ik samen met Steef-Jan Wiggers een presentatie over BizTalk Server 2010.

Wil je weten wat er allemaal nieuw is in BizTalk 2010 kom dan naar de BTUG meeting op 2 december.

Naast onze presenatie zijn er nog twee andere presentaties:

- BizTalk 2010 en Trading Partner Management  (Richard Sargeant)
- Extended and Scalable integration through the cloud (Gijsbert in ’t Veld)

Note to international readers of my blog:
The above post is aimed at the Dutch community and therefor only published in Dutch language. Unless you want to learn Dutch you can safely ignore it (I realize that is probably true for all my posts). Smile

Leave a Comment » | BizTalk | Tagged: , | Permalink
Posted by Randal van Splunteren

Setting the filename in send port (post number:1023054)

2 November 2010

This is probably the most blogged topic in the BizTalk community but I hope my attempt still adds something.

Let’s start with some simple questions:

Question1:
What syntax do you need to use to access the filename of a message you received using the file adapter in an orchestration?

In an expression shape you use something like this:

myVariable = myMessage(File.ReceivedFileName);

Question 2:
Ok, that one was easy! Now the same question for the a message received using the FTP adapter?

Again in an expression shape use:

myVariable = myMessage(FTP.ReceivedFileName);

Question 3:
Ok, makes sense. So what do you need to do when you wan to set the filename for a message that you send out using the file adapter?

Easy, two steps needed:

1). Set the filename property in the send port to use the macro %SourceFileName%.
2). Set the context property in the orchestration to the filename you want to use, like this:

myMessage(FILE.ReceivedFileName) = “MyFileName.xml”;

The file adapter will replace the macro with the value of the context property.

Question 4:
Last question; Same question for the FTP adapter. How do you set the filename for a message that you want to send out using the ftp adapter?

myMessage(FTP.ReceivedFileName) = “MyFtpFileName.xml”;

Wrong!!!!!!!! you also need to use the same syntax as with the file adapter:

myMessage(FILE.ReceivedFileName) = “MyFtpFileName.xml”;

This is something I encountered during development last week. I think this is a little confusing. It took me a while to find out what happened here. Also, by searching the internet, if found out this seems to confuse more people.

I think the idea behind this is an attempt to make an orchestration adapter agnostic and to create an abstraction layer between the logical process (orchestration) and the adapters which are bound to a certain technology or protocol. So whether you use the file or FTP adapter it is always ‘FILE.ReceivedFileName’ you need to use. This idea is good but my remarks are:

- This works different for receive side which makes it a little inconsistent.
- The word ‘FILE’ is (at least in my head) directly connected to the file adapter. The abstraction would be more clear if some other term was used.

Confusing!

4 Comments | BizTalk | Tagged: , , | Permalink
Posted by Randal van Splunteren

Artikel over BizTalk en PowerShell

2 November 2010

nederlandse-vlag

Dick Dijkstra en ik hebben een artikel geschreven over BizTalk en PowerShell. Het artikel is recent gepubliceerd in de gedrukte versie van TechNet magazine.

Het artikel is helaas nog niet online beschikbaar.

 

Note to international readers of my blog:
The above post is aimed at the Dutch community and therefor only published in Dutch language. Unless you want to learn Dutch you can safely ignore it (I realize that is probably true for all my posts). Smile

2 Comments | BizTalk, PowerShell | Tagged: , , | Permalink
Posted by Randal van Splunteren

Monitor BizTalk Server Job in BizTalk 2010

19 October 2010

When looking a the new features of BizTalk 2010 I noticed that the set of SQL Server Agent jobs has been extended. There is new job called ‘Monitor BizTalk Server’.

new sql job

This job is especially good news for those of us responsible for keeping BizTalk Server running and healthy.

The general idea behind the job is to check for errors and report that those errors exist in one of the message box databases, the management or the tracking database. A zombie message is an example of an error that will be detected. For a complete list of all the issues see the BizTalk 2010 help on this topic

The job consists of two steps. The first step is responsible for collecting error data from the different message box databases, the management database and the tracking database. The second step checks the collected data and raises an error if there is an issue in of the databases.

job steps

If any inconsistencies are found the job will fail and will write an error to the application event log. You can easily extend this by configuring other notifications for the job like e-mail, etc.

job notification

The job does not fix any issues it is just provides an alert mechanism. You can other tools like the BizTalk administration Console to fix any issues found.

When running the job on a healthy BizTalk server environment, the job succeeds:

job success

Now I use the following non uniform sequential convoy orchestration to generate a zombie message:

orchestration

I can easily do this by throwing in message 2 (destination receive shape 2) multiple times. The orchestration is only expecting one instance of message 2 which will lead to a zombie message. In the admin console this looks like this:

admin console error

When running the job the second time I now see the following result:

job outcome error

The job history gives me more detailed information of what is wrong:

error job history

This information is also in the event log:

eventlog error

Some final considerations:

  1. By default the job is scheduled to run once a week. You can of course change this schedule if you like.
  2. This seems to be a heavy job in terms of SQL resource usage. Microsoft recommends to run the job during low traffic.
  3. The will not detect if issues have already been reported. When the job runs for the second time and the issues have not been fixed they will be reported again.

I think this is a useful new feature in BizTalk Server 2010. I have seen many clients where issues in the BizTalk databases where not noticed for a long time.

4 Comments | BizTalk | Tagged: , , , | Permalink
Posted by Randal van Splunteren

Replacing functoids in BizTalk 2009

19 October 2010

A BizTalk developer recently learned me a great trick to replace funtoids in a map. It looks like a lot of BizTalkers, like me, are unaware of this handy feature.

When you accidentally used the wrong functoid in a map you can replace it by just dragging another functoid on top of it. The old functoid is replaced with the new one. The great part is that all the input and output parameters of the functoid are preserved.

The following video shows how to do this in BizTalk 2009:

BizTalk 2009 Mapper replacing functoids

I haven’t tried but this should also work in BizTalk 2006 (R2). I don’t know about BizTalk 2004.

When trying in BizTalk 2010 I was a little bit surprised to find out that this does not work. See video below:

BizTalk 2010 Mapper replacing functoids does not work

Fortunately there are many other productivity enhancements in the BizTalk 2010 mapper so I think I can live without this replace feature Smile.

2 Comments | BizTalk | Tagged: , , , | Permalink
Posted by Randal van Splunteren

« Previous Entries
Next Entries »
Follow

Get every new post delivered to your Inbox.