Wednesday, October 28, 2009

Complete installation of ESB Toolkit 2.0

Here is my guide for installing the ESB Toolkit 2.0 in BizTalk 2009. It's for 32bit and everything is located on the same server.
  1. Import ESB.Core into BizTalk
  2. Import ESB.Exceptions into BizTalk (overwrite resources)
  3. Import ESB.JSM into BizTalk (overwrite resources)
  4. Install each msi onto the server as well (checkbox at the end of the import wizard)
  5. Give SQL Service Account permission to BAM databases by running this query in SQL Management Studio
    USE BAMStarSchema
    GO
    CREATE USER SQLService FOR LOGIN [W1BTS3\SQLServiceAccount]
    GO
    EXEC sp_addrolemember db_datareader, SQLService
    GO
  6. Deploy BAM activities
    "c:\program files\microsoft biztalk server 2009\tracking\bm.exe" deploy-all -definitionfile:"c:\program files\microsoft biztalk esb toolkit 2.0\bam\microsoft.biztalk.esb.bam.exceptions.xml"
    "c:\program files\microsoft biztalk server 2009\tracking\bm.exe" deploy-all -definitionfile:"c:\program files\microsoft biztalk esb toolkit 2.0\bam\microsoft.biztalk.esb.bam.itinerary.xml"
  7. Run ESBConfigurationTool.exe and apply the configuration before hitting the next page.
  8. Install UDDI from the BizTalk media. Make sure to uncheck the SSL requirement.
  9. Run the UDDI Publisher tool \Bin\Microsoft.Practices.ESB.UDDIPublisher.exe).
  10. Run "C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" -r -y
  11. Extract ESBSource.zip to C:\Projects\Microsoft.Practices.ESB
  12. Remove the read-only attribute on all files and folders.
  13. Open PowerShell and run Set-ExecutionPolicy unrestricted
  14. Open ESB.AlertService sln, set setup project platform to x86
  15. Build ESB.AlertService
  16. Open ESB.Portal, verify web.config
  17. Verify ExceptionService web.config
  18. Build ESB.UDDI.PublisherService
  19. Run portal install script
  20. Enable TCP/IP connections in SQL Server
With this done, everything should be up and running properly.

Tuesday, October 27, 2009

BizTalk 2009, ESB Toolkit 2.0 and UDDI

I have spent numerous hours trying to publish the UDDI services in the ESB Toolkit using UDDIPublisher.exe. I have received pretty much every error possible, from 404 to 503 to the entire IIS falling apart. I just found the solution: don't install UDDI as a normal Windows 2008 role, but install UDDI3 as a part of the BizTalk Server install.

At one point I managed to get UDDIPublisher.exe to install the services properly, but I cannot remember the route I went. Most likely it included changing permissions in IIS, UDDIPublisher.config as well as ApplicationHost.config and also fiddling with the account used to run the whole shebang. By installing UDDI from the BizTalk DVD and then running the publishing exe, it works without a hitch.

Wednesday, October 21, 2009

The woe of installing ESB Toolkit 2.0

Installing the ESB Toolkit 2.0 by following the official documentation is pretty much a task doomed to fail. There is however quite a number of guides available on the net. One of the better ones I've found is from Quicklearn: Getting up and running with BizTalk ESB Toolkit 2.0.

This one helped me with a basic issue that caused some grief.

After importing and installing the Core and Itinerary msi packages, I tried to run the Management Portal installation script Management_Install.cmd which worked half way before spewing out a ton of error messages.



I started looking at this issue and noticed that a number of exceptions came from IIS related components, for example: "Property 'AppPoolIdentityType' cannot be found on this object; make sure it exists and is settable.".

It seemed I had missed to enable IIS 6.0 extensions properly. The ESB Toolkit uses IIS 6.0 calls and these components are not installed by default when adding IIS 7 in Windows 2008 Server.

Later on I found myself with a minor issue when deploying the BAM activities.
Deploying View... ERROR: The BAM deployment failed.
OLE DB error: OLE DB or ODBC error: Cannot open database "BAMStarSchema" requested by the login. The login failed.; 42000.

Clearly a better error message than before, so I added the appropriate account to the databases.

USE BAMStarSchema
GO
CREATE USER SQLService FOR LOGIN [W1BTS3\SQLServiceAccount]
GO
EXEC sp_addrolemember db_datareader, SQLService
GO


With this change, the deploy was successful.

I'm still stumped on why the installation of the toolkit is so badly documented and lack a proper guide since the amount of settings, scripts and packages to handle is quite vast and it's so easy to miss a required setting/permission/whatever that will make at least parts of the installation process to fail.

Monday, October 19, 2009

BizTalk SQL adapter deadlocking issues

A few months ago I had an assignment at a company that was having issues with their BizTalk installation. When examining their integration platform I noticed that the event log was filled with deadlock exceptions from the SQL adapter. It was the standard error message stating that a message sent to adapter "SQL" is suspended. The transaction was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

The vast amount of deadlocks that occured directly pointed me to the procedures that was being called by the receive locations.



In this particular flow, a number of receive locations where scheduled to poll a database for data every minute. Nothing unusual about this so far. When looking at the procedures, I saw that each one logged the time of execution to a log table used for debugging purposes. This is a valid practise, if it weren't for the fact that the logging was set up wrong. Instead of letting each procedure write it's own row with execution data, the table had one single row with a number of columns, one for each procedure.



So, only one row in the table, which all the procedures tried to write to. The chance of all procedures running at the same time and therefore trying to do an update on this table row at the same time is actually pretty slim if the procedures run fast enough. However, the procedures in this case did take a few seconds to run.

Adding to this is the fact that BizTalk will wrap the call in a serializable transaction meaning that the row will be locked throughout the entire execution of the procedure. The risk of another procedure trying to gain access to the table while its locked increases then quite a bit, resulting in the high volume of deadlocks I saw in the event log.

Since this was in production and a valid test environment was missing (shudder), I made certain that the log table wasn't used for anything (you never know) and then commented out the UPDATE statements in the procedures. Since the entire flow were to be rewritten from scratch, I saw no need to more or less do a transposition of the table to get the procedure timestamps on their own rows since the data were of no more use.

The result: The number of deadlocks were reduced with 97% and according to the server operators, the BizTalk/SQL Server installations now runs a lot better while we build the replacement to this flow.

What to remember from this is that it is both vital to know how BizTalk handles transactions in the SQL adapter and to also know the different table and locking hints available in SQL Server.

Monday, October 12, 2009

BizTalk orchestration expression shape unable to write entries to Windows eventlog

I were just in the process of debugging an orchestration in BizTalk 2006r2 the old fashioned way: writing eventlog entries from an expression shape when I noticed that I got an exception in the eventlog instead. The exception was of type "Security Exception" with an inner exception detailing "Requested registry access is not allowed.". Easy enough, a quick google turned me to this blogpost and the solution which is to add the appropriate BizTalk service account to the eventlog node in the registry. After setting the permission, writing entries work.

Sunday, October 4, 2009

The beginning

The professional life is starting to fill up with interesting bits and pieces that I encounter both during my own time as well as when I'm working with a customer. This blog will be a place to keep all those pieces together, so that I can remember them and also so others can (hopefully) learn a thing or two.