There are situations in which you might need to use or send a message in an orchestration within an exception handler block, but get a compiler error because the message was constructed in the associated scope outside the exception handler block.

For example, consider the following orchestration:

As you can see, I’m trying to send a message that was constructed outside the exception handler block. If an exception is raised before the message is constructed (for example in "Expression_1"), the orchestration will fail sending it.

Luckily, the compiler will warn us about this situation generating the following error:

error X2110: use of unconstructed message ‘myMessage’

In order to deal with this scenario, there is an operator in BizTalk Server 2004 that can be used to determine the outcome of a transactional scope, thus providing us the ability to know if the code within that scope was successfully executed or not.  This operator is called "succeeded()". This operator receives one parameter: the Transaction Identifier of the associated scope.

In our sample, in order to know when to send the message, we should construct the message in a transactional scope, and then ask for the execution result of that scope using the "succeeded()" operator in a Decide Shape, as shown in the following orchestration:

Note: The orchestration samples shown in this article were created in order to illustrate the usage of the "succeeded()" operator. Probably, they won’t have meaning in real scenarios.

Hope this to be useful!

Yesterday I’ve been playing around with the new Windows Powershell. As the name implies, this is the new shell for Microsoft Windows, a real shell compared to Cmd.exe.

One important topic about Windows Powershell is security. The primary security feature in Windows PowerShell is its execution policy. By default, this policy is set to Restricted, which you can verify by running the Get-ExecutionPolicy command-let. In Restricted mode, scripts don't run.

In order to run scripts, you should change the default execution policy mode using the Set-ExecutionPolicy command-let. This is a list of all available modes:

·         Restricted: In this mode scripts don't run.

·         RemoteSigned: This allows local scripts to run without being digitally signed. Remote scripts won’t run unless they've been digitally signed.

·         AllSigned: This mode doesn't allow any scripts to run unless they've been digitally signed.

·         Unrestricted: In this mode every script is allowed to run. 

I recommend setting the mode to RemoteSigned. This mode allows local scripts to run without being digitally signed, providing the easiest way to develop and test scripts: 

PS C:\> Set-ExecutionPolicy RemoteSigned 

For further information about Windows Powershell you could check this great introductory article!