Thursday, September 6, 2007

How to step into web service in debug mode from the BizTalk

Recently, I was working with BizTalk solution where send port communicate with web service. So, to successfully complete it, I had to debug web service.Here are two methods how to do it:

Method 1)
My web service project is file system based(not IIS based), so if you start debug session, Visual Studio will engage Cassiny server (ASP.NET development server). However, the deployed web service is hosted in the IIS .
Ones I started the project in the debug mode, I copied the URL from the browser (it was http://localhost:60149/.....). Next step is to change SOAP property of my web port to this URL. Ones orchestration activated, it sends a message to the web port, then to the web service and finally hit the break point. The only disadvantage is that you have to change SOAP property in your port.

Method 2)
Open the web project in Visual Studio.
Attach to the process: w3wp.exe (tip: if you do not see this process listed, you have to lunch the working process by executing the web service in the browser first)
Engage your orchestration
Break point got hit

Saturday, July 14, 2007

My experience with BizTalk 2006 Enterprise Service Bus (ESB) Guidance

Marty Wasznicky and Don Smith have released the CTP2 version of the Enterprise Service Bus (ESB) Guidance. You can get it here: http://www.codeplex.com/esb. This is out of the box message repair and error handling solution prepared by Microsoft’s Patterns & Practices team.
It is happened that my current client is requesting such as functionality, so I downloaded and installed it on my VPC already with an idea to use it as a good start-point.
The installation of ESB is not easy. I chose to install core system with the source files. It is a solution with 23 projects, including BizTalk, C# and C++ project types, so if you got an error “Unable to load project” when you first time try to open your solution – that means that you are missing some of the Visual Studio 2005 components. In my case, I forgot to install C++, so “ESB.JMS.PipelineComponents” refused to load. I installed C++, but it takes 800Mb of my limited VPC's HD space, so I just removed C++ project from my solution instead (it is for MQSerios adapter anyway and I do not plan to use it in the near future). Talking about prerequisites: please read documentation first and try to follow it – you will save a lot of time later on.
Do not forget to change a target SQL Server name for each BizTalk project.Just goto project's Properties-->Deployment-->Server and replace original server name by your local name, or just type“.” Also, do not worry about missing strong key – they are presented and each project has inline notation with relative pass to the .snk file (you still have to unzip whole solution to the “C:/Projects” directory).
Finally, you opened your solution successfully. If you still fail to build then you probably missing some referenced components, so go to “C:\Projects\Microsoft.Practices.ESB\Source\Core\Install\Scripts” directory and prepare “PreProcessingCORE.vbs” for the run. I would recommend to check all paths and replaced “%programfiles%/BizTalk……” with the correct one, becouse if VBS script failes, it does it silently without creating important objects, like web-site or user. Also, I would recommend to enhanced it with comments, like this: Msgbox “User created” … - it was really helpful for me.
Next script to run is CORE_CreateBizTalkApplication.cmd . It failed to deploy solution, but I was able to deploy it manually from the solution level with no problem at all. Last step is to import binding file. Hint: do not forget to change some send ports and receive locations FILE adapter URI path to the correct one, because most of the ports are pointed to the “E” directory and my VPC for example has only one “C” drive. Now you are ready to go, just do not forget to restart a host instance.
Finally, the most interesting part - working scenario test.
My first application to run was “Repair and Resubmit Custom Exception Handler Sample”. The prerequisites does not look to complicated, so after running setup script I was ready to go and test how it works. However, when I tried to submit InfoPath form after repair, I got HTTP error 405 “Method Not allowed”:

That is because your virtual directory does not have execute permissions (by default):


After changing it to “Script and executables” I submitted my InfoPath form again hoping that all my problems are far behind. Not yet J . I got new HTTP error 404 “Not Found”:



Checking permissions of the “HwsMessages” virtual directory did not show any problems. Path was correct and pointed to the right DLL.
I spent some time before I realized what is missing. BizTalk HTTP Adapter is implemented as an ISAPI application. Make sure BtsHttpReceive.dll is an allowed Web Services Extensions in IIS.
To enable, launch IIS Manager and click on the "Web Service Extension" folder located below the "Web sites" folder in the navigation tree. If not found, add an entry by right click on the Web Service Extension folder. Select "Add a new Web service extension...”, give it an identifiable name such as "BizTalk HTTP Adapter" and add the path of BtsHttpReceive.dll (usually found on C:\Program Files\Microsoft BizTalk Server 2006\HTTPReceive\BTSHTTPReceive.dll)




Friday, July 13, 2007

BizTalk 2006 installation guide simplified

If you want to install BizTalk Server 2006 and look into the documentation http://www.microsoft.com/downloads/details.aspx?FamilyId=B273269C-97E0-411D-8849-5A8070698E4A&displaylang=en, it is a lot of reading. I would not say that it is useless(which is defenatly, not and I personally founf this white paper pretty impressive and detailed), but sometimes would be nice just have a short overview of the whole process.
Here are my notes about it in short:
  • Make sure you have Windows 2003 Server with all service packs and updates
  • Install IIS(Installation CD is required)
  • If you plan to use SharePoint services - install WSS 2.0 and extend default web-site (.NET Framework 2.0 must be installed prior to install this feature. This prerequisite is not enforced by BizTalk Server 2006 setup program.)
  • Install MMC 3.0 (download from Microsoft site )
  • Install SQL Server 2005 with next futures selected as Yes:
  • Notification services
  • Reporting services
  • And next futures selected as No:
  • Mobile edition
  • MSDE
  • Start SQL Agent on Startup
  • Install Service Pack 1 for SQL Server 2005
  • Install VS.net 2005
  • ---Custom install,
  • Uncheck the SQL Server Express component
  • Add the following "groups" from the administrative tools computer management “users and groups” utility...
  • Administrators
  • BAS Enabled Hosts
  • BizTalk Application Users
  • BizTalk BAS Administrators
  • BizTalk BAS Managers
  • BizTalk BAS Users
  • BizTalk BAS Web Services Group
  • BizTalk Isolated Host Users
  • BizTalk Server Administrators
  • BizTalk Server Operators
  • Debugger Users
  • EDI Subsystem Users
  • SSO Administrators
  • SSO Affiliate Administrators
  • Add the current account (current logged in user account) to each of those groups.
  • Note: the “SQLServer2005NotificationServicesUser$[your machine name here]” account was automatically created when we installed SQL Server and checked the notification services box.
  • Install BizTalk 2006
  • Configuration steps: Open BizTalk configuration wizard
  • Select “Custom” installation and enter the “Server name” and domain user account with run as service permissions (you will save some typing time later). Here are my thoughts about user accounts. Microsoft, in his installation guide - listed 14 different service accounts. I think that this is too much and does not necessary. If you planning to have a several security zones where your processing host and DBs would be behind firewall and your isolated host – outside or your internal domain – then you should considering to create a separate users for each of those hosts. Otherwise, one domain user account is good enough to run all services.
  • At the point of configuring SSO, please remember the location and password for the Master Secret backup. It is really important because if for some reason you change service account “user/password” combination, the BizTalk server will be disabled until you restore master secret. It is recommended to keep it in the safe place on the CD separately from the Server.
  • Do not install next BizTalk futures, which are completely useless:
  • HWS runtime
  • HWS web services

Enjoy!