I have been avoiding this for sometime now. That is, adding new activity items to the current BAM deployment in production. Production has been running for months now and in this high volume system we partition the BAM activities every week and archive each month (giving the client a rolling month worth of activity data). I was concerned that during the update of the BAM definition this data was going to be blown away (an experience that has caused much embarrassment in the past).

So the procedure I used this time did the trick…well almost

• Took a “backup” of the current BAM definition using BM.exe
  
  

  bm.exe get-config -FileName:MyConfig.xml

  
  
• Added the new activity items using Excel and edited the views
• Exported the new BAM definition to xml
• Removed the existing views using BM.exe
  
  

  bm.exe remove-view -Name:MyView

  
  
• Deployed the new definition using BM.exe and the update-all command – FAILED
  
  

  bm.exe update-all -DefinitionFile:MyNewDef.xml

   
  The error message in the command window was:

              All queries
combined using a UNION, INTERSECTorEXCEPT operator
must have an 


equal number of expressions in their
target lists.

 
Upon investigation, I found that the partition tables did not get updated with the new activity items. As the view spans both the current activity tables and all the partition tables the view creation failed. Interestingly, the BAM Archive tables did get updated.


• “Upgraded” the partition tables using the script from this blog post
  
  I did need to make a slight change to avoid some errors that cropped up with partition tables already archived and as such no longer present in the BAMPrimaryImport database (although the original script works).
  
  I changed the CURSOR definition to filter out those tables already archived:
  
  

  DECLARE partition_cursor CURSORLOCALFOR
  SELECT InstancesTable
  FROM [dbo].[bam_Metadata_Partitions]
  WHERE ActivityName = @activityName 
  
  AND ArchivedTime IsNull--
  Added additional filter
  ORDERBY CreationTime ASC
  

• Deployed the new definition again using BM.exe and the update-all command – SUCCEEDED
• Re-applied security to the Views using BM.exe
  
  

  bm.exe add-account -AccountName:TheStig -View:MyView

  
  

Unfortunately all my BAM Alerts got blown away . Makes sense as the alerts reference the view that was removed. Luckily taking the backup in step one allowed me to pull out the original alert definition and paste them into my new definition file. I re-deployed that using the update-all command and alerts are back to normal.

I did come across this KB 969558 article for BTS 2006 R2 that appeared to address the partition tables issue. It looks as though this did not make it into BTS 2009.

I am getting a few reports that after a recent windows update (or installing .NET Framework 4.0) the ESSO service fails to restart. Microsoft have released a hotfix to address this (http://support.microsoft.com/kb/2252691)

Microsoft Reports:

This issue occurs after installing .NET Framework 4.0. The registration of the assembly used by ENTSSO to access SQL Server does not specify the correct version of the .NET Framework. When .NET Framework 4.0 is installed, the assembly will try to use the newer framework and then fail to load

To resolve this manually:

32-bit Server

1.       Open a command window
2.       Go to C:\Windows\Microsoft.NET\Framework\v2.0.50727
3.       Type: regasm “C:\Program Files\Common Files\Enterprise Single Sign-On\ssosql.dll”

64-bit Server

1.       Open a command window
2.       Go to C:\Windows\Microsoft.NET\Framework64\v2.0.50727
3.       Type each of the following and hit ENTER:

32bit:  regasm “C:\Program Files\Common Files\Enterprise Single Sign-On\win32\ssosql.dll”
64bit:  regasm “C:\Program Files\Common Files\Enterprise Single Sign-On\ssosql.dll”

Note On a 64-bit server, regasm will need to be run for both the 32-bit and 64-bit versions of ssosql.dll.

Hope this helps

In a (not so recent) post, I walked through the steps to get your BizTalk Server 2006 R2+ Orchestrations exposed to the Cloud. See Exposing BizTalk Orchestrations to the Cloud. With the release of the Microsoft .NET Services SDK (March 2009 CTP) this week, you will find your existing .NET Services endpoints no longer valid.

Here's how to resolve the issue.

At the moment your existing .NET Services endpoints are in the form:

sb://servicebus.windows.net/services/[solution name]/[service name]/

This has now been changed to:

sb://[solution name].servicebus.windows.net/[service name]/

Note: you can still register your service hierarchy as before (e.g. sb://.../[service group]/[service name]) but for simplicity I have just used [service name] in the URI's above.

So, even if you followed Microsoft's advise and coded your service endpoints URI's this way:

Uri address = new Uri(String.Format("sb://{0}/services/{1}/{2}", ServiceBusEnvironment.DefaultRelayHostName, solutionName, serviceName));

that didn't get you out of trouble when the URI change was released. We are now encouraged to use the following when generating endpoint addresses in code:

Uri address = ServiceBusEnvironment.CreateServiceUri("sb", solutionName, serviceName);

This will give us an address in the new structure and protect us from any future changes (but we heard that somewhere before didn't we). Also, be aware that (as of time of posting) the published services feed is not listing your services correctly (but they are still accessible). Your new published services feed will also be:

http://[solution name].servicebus.windows.net/

In the coming days, the team at Breeze will be walking through the new goodies the March CTP brings so look out for future posts (of particular interest is the queuing and routing features we have now!).

This week I gave a presentation to the Sydney BizTalk User Group on (Biz)Talking to the Cloud. I showed how we can quickly and easily configure a BizTalk Receive Port to consume services hosted in the cloud. In the demo, we configured BizTalk to participate in a multicast events scenario.

I have been playing further with BizTalk and Cloud services and in this post I will demonstrate how to expose BizTalk Orchestrations to the Cloud. To make it easy for you to build this on your own environment, I have used the now famous (or infamous) EchoService as the basis of this demo. This allows you to use the existing Microsoft .NET Services SDK sample to call the BizTalk Orchestration through the cloud.

Before You Begin

1. Sign-up to Microsoft .NET Services and create your Solution.
2. Download the Microsoft .NET Services SDK and install on your BizTalk Server 2006 R2 development environment.
   Note: Nothing more is needed as far as BTS is concerned. I am pleased Microsoft is making good on ensuring developers can use existing skills and technologies to get started with cloud services. Furthermore, we can be fairly comfortable that playing around with this stuff is not going to break or render our existing dev environment useless. Credit where credit is due.

BizTalk Development

In this step we will create a simple orchestration that receives a generic message, pulls the "echo" text out, creates the response message, and sends it back out the two-way port. I have used System.Xml.XmlDocument types avoiding the need to create schemas and simplifying the demo.

1. In Visual Studio 2005, create a new Empty BizTalk project.
2. Go ahead and set your Assembly Key File and BizTalk Application project settings. (I called my BizTalk App BizTalk Services as we will see later on)
3. Add a new Orchestration to the project.
4. Create the following messages:
   

Add the following shapes to the design surface

            // Retrieve the text sent in
the request strText = xpath(msgRequest, "string(//*[local-name()='text'])"); //
Construct the response strResponse = System.String.Format("<EchoResponse
xmlns=\"http://samples.microsoft.com/ServiceModel/Relay/\">

<EchoResult>{0}</EchoResult></EchoResponse>", "BizTalk:
" + strText); // Create the response document xmlDoc.LoadXml(strResponse); //
Assign the response message variable msgResponse = xmlDoc;

Wire up the port operations and don't forget to set the Activate property of the Receive shape

BizTalk Application Configuration

In this step we will configure a WCF-Custom receive port to expose our newly created orchestration to the cloud.

1. In BizTalk Server Administration Console, navigate to the BizTalk Application you just deployed to (mine was called BizTalk Services).
2. Create a new Request-Response receive port.
3. Add a new receive location and set the Transport type to WCF-Custom.
   
   
   
4. Configure the WCF-Custom adapter.
5. Set the EndPoint Address to:
   
           sb://servicebus.windows.net/services/[your solution name]/EchoService/
   
6. Set the Binding Type to NetTcpRelayBinding
   Note: This is one of the new bindings added when you installed the Microsoft .NET Services SDK
   
   
   
7. On the Behaviors tab, add a new behavior extension called transportClientEndpointBehavior to the EndPointBehavior node.
8. Set the credentialType to UserNamePassword and enter your solution credentials on the UserNamePassword element of the ClientCredentials node.
   Note: If you are using Windows CardSpace instead, set the transportClientEndpointBehavior to use it here instead.
   
   
   
9. Click Apply and verify no errors occurred with your WCF-Custom adapter configuration.
10. Click OK to close the Adapter configuration dialog.
11. Set the Receive Handler to your BizTalk Server Application host.
12. Leave the Receive and Send piplines as PassThru (as we are not requiring xml parsing of the messages we are sending and receiving).
13. Click OK to save the new receive location.
14. Do likewise for the receive port.
15. Now, configure your orchestration bindings and start the BizTalk application.

Verify the Service is Exposed to the Cloud

In this step we will browse to your Microsoft .NET Services service registry feed and verify your service is exposed to the cloud.

1. Launch Internet Explorer and browse to the following URL:
   
        http://servicebus.windows.net/services/[your solution name]/
   
2. You should now see your service endpoint listed in the Atom feed.

Test Your Solution

1. In Windows Explorer, navigate to the samples folder under the install folder for Microsoft .NET Services SDK
   Note: If you installed to the default folder it should be C:\Program Files\Microsoft .NET Services (Nov 2008 CTP) SDK\Samples
2. Locate the ServiceBus\GettingStarted\Echo sample and open your flavour of choice (C#/VB)
3. Build the Solution using VS 2008
4. Run the Client.exe
5. Enter your Solution name and password.
6. Enter some text to send to your service.
7. Verify the service response includes BizTalk: <your echo text>
   
   

What did we just do?

Using only the new WCF features that were installed in the Microsoft .NET Services SDK we were able to configure a request-response receive port in BizTalk that exposed our orchestration to the cloud. This is very cool .

At the very least, we could do away with the orchestration binding and just configure the receive port to drop messages into the BizTalk MsgBox. We then use content based routing to route the messages off to our existing orchestrations.

Think of the times you wanted to expose your BizTalk services to customers and clients outside your organisation, but had to jump all those hurdles the IT infrastructure team seams to magically come up with.

This is just the beginning...

Putting together BizTalk integration solutions can be complex and tricky at times. Debugging them is an art in itself. While onsite recently, I found myself (on more than one occasion) having *words* with BizTalk.

One example that tested our relationship (BizTalk and I) was an orchestration decision shape that appeared to be misbehaving. I had three branches in the decision shape, each branch testing the existence of a node in the message being processed using the xpath() function. For Example:

xpath(msgRequest, "string(count(/*[local-name()='root']/*[local-name()='parent']/*[local-name()='child' and code='some value']))") == "0"

Tip: use Dan Sharp's Xml Viewer to retrieve the correct xpath to use in these statements. BizTalk schemas will give you them to, but Dan's tool has some nice features thrown into the bargain

One branch rule tested for a zero node count, another for exactly one, and the Else rule branch to handle multiple occurrences of the node. During testing and debugging we found the else branch was always being used despite the messages satisfying one of the other rule conditions (over different tests). Repeated checks, breakpoints, and logging soaked up 20 minutes or more and had me demanding satisfaction by challenging BizTalk to a duel with pistols at dawn.

It was then, a bright beam of light breached the false ceiling above me and shone down in all is splendour. No, this was not a helping hand from god, but rather from a colleague working with me. Picking up on my frustrations, he calmly stood, moved over to me, and placing a soothing hand on my shoulder, utters two words that have changed my life...Kane Theory. I eagerly implemented a quick change (as guided by Kane Theory teachings) and my problem was solved! More cases arose during the project and each of them resolved with ease using this mystic and elegant theory.

Ok. That's a bit dramatic, but I am considering a professional self-help book exploring the practical uses of Kane Theory and wanted to get some practice in.

So what is Kane Theory?

Although only a novice in its teachings, I am fortunate to receive guidance from the enlighten one himself. Kane Adams (his real name used here to protect reveal his identity)  explains it in terms of Yin & Yang, Karma, and the Force. Reflecting on this I can best describe it as a derivative of keep it simple stupid (KISS).

In the example above, we declared an orchestration variable (System.String) to store the result of the xpath function in an Expression shape before entering the Decision shape. We then used the variable in the rule expression for the comparison. Eg:

strNodeCount == "0"

By powers understood only to the enlighten one, this worked a treat and we could all break for a quick cup of the worst coffee ever brewed. (Sceptics might argue that it has to do with the way the XLANG engine performs explicit type conversions during the comparison operation...but they would say that wouldn't they!)

As for the enlighten one himself:

Some say he is a direct descent of John Adams, author of the mystical theory of political architecture and founding father of the new Empire (there's the link to the Force we needed).
Some say, he meditates to the haunting chants of mid-level public servants.
We know him as The Stig!

Had a strange error appear last week when using the WCF LOB Adapter for Oracle and spent an hour of my life I will never get back. When attempting to connect to an Oracle DB we kept getting the following error:

ORA-12154: TNS:could not resolve the connect identifier specified

This occurred when we:

1. Tried to generate metadata in our BizTalk project using the Add Generated Items wizard.
2. Tried to generate metadata in a Class Library project using the Add Adapter Service Reference wizard.
3. Connect to an Oracle DB using the Oracle Explorer.

We had all the latest versions/patches of the Oracle client and WCF LOB Adapter (Oh, yeah. Thanks Oracle for packaging patches in easy to consume 1GB downloads...love your work!!)

We could however, connect to Oracle using the Oracle SQL Developer Tool. So we knew something was happening (or not happening inside of VS).

It turns out the issue relates to the install directory of VS2005. In our case it was

C:\Program Files (x86)\...

This triggers an *undocumented feature* in the Oracle Data Provider for .Net (ODP.NET) so that applications with a parenthesis in their (exe) path fail to connect to the server.

The solution was to uninstall VS2005 and reinstall using a different install directory *one that did not have (x86) in it*.

... I know, I did not want to believe it either, but if you want to save yourself time and hair try this solution first.

Recently I implemented a BizTalk web services interface that required the need to support SoapFault messages. I quickly fell into a common trap and received a compiler error:

error X2162: must receive before sending a fault message on an implemented port

(see Scott Colestock's post that nicely outlines his experience with the same issue)

As Scott describes, the solution involved using the succeeded() function to first test if a transaction scope had succeeded or not in order to send out my soap-fault correctly. I vaguely recalled this function but never used it in anger before. After having spent a hour or so I will never get back, I made a note-to-self to seek out and reacquaint myself with the other operators and functions available to use in expression shapes within an orchestration.

Here is the full list taken from the online documentation:

Since then, this little exercise has helped in a few occasions, particularly the need for the exists function when working with optional property schema fields.

I knew I should of read the manufacturers instructions

Today I was working on a BizTalk solution to intercept, transform, and relay emails sent from a LOB system. BizTalk polled a POP3 mailbox and my orchestration replaced the original plain/text email body with some fancy, template driven HTML content and sent it out a dynamic SMTP send port. Only the email body was to be modified, the rest of the email message was to replicate the original email message, including any attachments (that may or may not be present).

To aid in testing I wrote a simple .Net email client. (I got tired of composing a new email in Outlook every time I wanted to test the solution)

The solution worked well (and perhaps I may post about the details sometime later) accept for the fact the outbound message had lost the attachment filenames.

Note: The attachment on the outbound message has a filename of ATT00241.DAT

A helper class in my orchestration inspected the inbound message for attachments and added them to the new outbound message. Each message part (attachment) was assigned the MIME message part context properties of the same inbound message part. What I found was the MIME.FileName property was not being populated by the MIME decoder.

The MIME decoder in the POP3 adapter (when configured to apply MIME decoding) populates the following message part context properties when a MIME encoded message is received:

I checked the message source of the email I was sending (via my DIY email client) to check the MIME headers were present.

Appears OK right?...

content-type: application/octet-stream; name=SampleAttachment.zip
content-transfer-encoding: base64

Wrong

It turns out the MIME decoder is looking for the content-disposition header values

content-type: application/octet-stream; name=SampleAttachment.zip
content-transfer-encoding: base64
content-disposition: attachment; filename=SampleAttachment.zip

So some quick changes to the Breeze Simple Email Client ...

attach.ContentDisposition.DispositionType = System.Net.Mime.DispositionTypeNames.Attachment
attach.ContentDisposition.FileName = Path.GetFileName(attachmentFileName)

...and we were back to cooking with gas.

and now attachments on our outbound message retain their original filename...noysh!

And BTW, not all commercial email clients populate these MIME headers correctly either (or so a friend of a friend who's aunt once knew someone that was talking to a girlfriend at the supermarket said). Check out the message source of items in your inbox. You might be surprised.

Happy spamming er...umm...BizTalking