Ordered Delivery: So, continuing on the issue of ordered delivery and queuing, one important point which Tomas pointed out in the newsgroup is that it is not enough to just send to the queue whether it be MSMQ or MSMQT in sequence, but the orchestration that subscribes to it must also be a singleton if we want to ensure the sequencing. This makes sense because if we put a ton of messages into MSMQT or MSMQ then automatically a lot of subscribing instances are going to kick in to consume the messages and if in a set of messages, one instance is slightly slower to execute than another (say, a particular branch of the orchestration has been picked which the other instances didnt get), then it might happen that a message intended for later appears at the destination first. So if you wanted to keep inserts and updates in sequence and the update reached first because of the processing situation, then the destination system could throw an exception. The singleton would stop this, but we would sacrifice some processing speed. Without the singleton we would have to put in custom logic in an orchestration to handle the exception. For example, if we are sending an update or delete message and we recieve an exception, we could invoke a branch which set a delay interval and tried again for a few times and if the final attempt didnt work, it could put the message in a business exception queue which should be monitored and picked up. It all depends on how many messages are being pumped in at the source. If that is controlled then singletons and sophisticated exception handling is not needed. If a small number of messages are flowing the singleton could be good enough (assuming you do face situations where the messages have overlapped). If there are hundreds of messages coming in at source, then throughput becomes extremely important and the exception handling would be the better approach [if you are aware of something even better, then do let me know]. I’ll prototype this and let you all know what I find. In order to avoid changing the design of the orchestration later, i am leaning toward the exception handling approach now (just to be safe).
SSO in distributed environments. Heres a tip in case you encounter this annoying SSO error message. We finally got round to deploying the code into DEV and immediately hit a snag. We had been using MSDE on our workstations and giving the ASPNET user the needed access to the Biztalk databases. Once we got to a distributed environment, of course the ASPNET user on the app server couldnt be given any access to the database server. This access is very important to us because we have orchestrations published as webservices. We hit the familiar error message saying ; SSO AUDIT GetConfigInfo failed. Access Denied. etc. We used impersonation and gave the domain user access to the database and made them members of the Biztalk groups and all that and eventually when we set the user to be a member of SSO Administrators and SSO Affiliate Administrators on the application server, the problem got solved.
Workgroups: Its amazing how no matter how many times you install Biztalk 2004, theres always a problem in configuration. 2.5 years ago when i first started with it, i spent nearly a week installing and uninstalling and deleting databases for the config to work. About a month ago i managed to get it to work with only 1 rollback. That was my best experience so far. Yesterday, I was not so lucky. My previous laptop had been stolen from my desk at the office and so i was given a replacement (just 512MB RAM mind you, in contrast to the 2GB on the old one.. sniff!! sob!!) . I managed to install VS.NET and SQL and then when it came to Biztalk i dredged up the old articles from memory and set the registry permissions for EnableAuthEpResolution, enabled RPC Endpoint authentication etc so that SSO wouldnt give me the stupid “The Enterprise Single Sign On service failed to start” error that plagues folk when they install BTS. I also made the BiztalkUser account that runs all services a member of the Admins on the box. Drastic measure, i know, but sometimes when you just want to get the dratted thing installed on a laptop, priveleges dont really matter. Besides, i dont think there is any accurate doc on MS that says exactly which accounts need to be setup for development and what priveleges they need (for BTS). Anyway, i thought i had been smart. Boy, was i wrong!!! I didnt get the expected error message but got another one “Failed to generate the master secret”. This plagued me for the rest of the evening. Finally i didn what this article says and since i got the return code =2, i removed the laptop from the domain and then the configuration worked!!!
I think its quite sad that MS doesnt have another SP or hotfix with a set of scripts that can do all these settings before you start configuring Biztalk 2004. MS has moved onto Biztalk 2006 and Biztalk2006 R2 and planning for vNext, but a lot of people are still on Biztalk 2004 for various reasons and we would appreciate the install and configuration experience being made just a little bit better till the day we can move to 2006 or whatever comes next. I installed 2006 on a spare workstation the other day and there were no errors whatsoever. (I did use a account with admin priveleges again) and it even connected to the net to download missing prequisites and automatically installed them. Is it so difficult to patch the 2004 configuration engine to do something similar? Or even if it cant do this, why not give us the ability to simply SAVE the configuration settings which we so laboriously set up (user accounts, database connections etc), before proceeding to execute the configuration so that if it rolls back , we can fix whatever is needed, reload the configuration and go on instead of having to start from scratch? I hope someone from MS is listening but i fear its too late. They didnt care to do it these past 3 years and i doubt they are going to start now.
If you havent started Biztalk yet, i’d advise you to avoid v2004 and go straight to 2006. The install experience alone is worth the switch.