Nikola Kasev @ Blogging

I am happy to announce the second release of the ant deployment framework for TIBCO BusinessWorks. This release includes the following bug-fixes:

• The environment settings EnvironmentSettings.xls did not support XML special symbols, which were breaking the output xml files;
• Complete rewrite of the EditConfigTask class; unexpected (for me) behavior of the SAX parser API;

A brand new task is included: UndeployEar. It allows applications to be undeployed from TIBCO Administrator. During the use of the framework I have noticed, that when changing the contents of the EAR file and deploying an application multiple times some components were not deployed. I have then decided to include this task to make sure, that every time an application is redeployed, the old one is removed from TIBCO Administrator first.

You can download the new (0.2) version from here.

For an example BW project, that includes the deployment scripts perform the following:

• Create a new directory C:\Develop\TibcoDeploymentFramework;
• Unzip the archive file and copy the "samples" directory to the newly created directory;
• Open the C:\Develop\TibcoDeploymentFramework\samples\EchoService\build.xml file and make sure that the name of the TIBCO Administrator server (it is case sensitive!), the name of the TIBCO domain, the admin username and password are set accordingly;
• Save the modifications of the build.xml file;
• Open a new command prompt and navigate to C:\Develop\TibcoDeploymentFramework;
• Run ant;

If the deployment fails, check the C:\tibco\tra\domain\<your domain>\logs\ApplicationManagement.log for more information.

Labels: Aha

During the last several TIBCO BusinessWorks (BW) projects that I worked on, I continuously kept hitting the same type of deployment problems. Imagine a common integration project where a team of BW developers are building services, interfaces and adapters. You also have at least three environments: DEV (local development machines), TEST (QA) and PRODUCTION. Every time when you migrate the solution from DEV to TEST, then from TEST to PRODUCTION most of the environment settings are different. How do you make sure that the deployment is successful and that all settings are correct? Can you follow continuous integration best practices during the development of a BW solution? Can you deliver a set of scripts, so even a less experienced administrator can deploy your application?

In order to answer these questions and make my life easier I have decided to write a set of custom ant tasks and a configuration utility based on Excel. Usually all the BW development is done on a Windows environment, and that is why I stick to it as a prerequisite. What else do I run?

• Microsoft Windows XP, SP2
• Microsoft Excel 2003
• TIBCO Runtime Agent 5.5
• TIBCO BusinessWorks 5.4
• TIBCO Administrator 5.4
• Apache Ant 1.7

I assume that the reader is familiar with Ant, build scripts and automated deployment in general. Make sure that the tool is successfully installed by running "ant" in a command prompt and verify the tool output.

For a quick start with the deployment framework:

1. Download the framework from here;
2. Unzip the archive file to a new local directory;
3. Modify the EchoService\build.xml file and make sure that all properties are valid. For example the path to the TRA, the path to the BW source files, etc.
4. Go to the EchoService\settings directory and modify the environment settings accordingly. By default, the script will use the settings for the TST environment;
5. Return back to the EchoService directory and run "ant".

That's it! What you have just done is:

1. Built an EAR file from a BW project automatically;
2. Reconfigured the environment specific global variables;
3. Deployed the EAR file in TIBCO Administrator.

Start using the framework in your own BusinessWorks projects by copying the build.xml file, and both lib and settings directories into your source folder structure. A best practice is to keep all BW source files in the same parent directory ("src" in the sample project). You can extend the framework by modifying the build scripts or by developing custom ant tasks.

Sources: ant-tibco-0.1.zip. 

I have just completed my two presentations at Microsoft DevDays 2006 in Sofia, Bulgaria. I presented SQL Server 2005 Security for Developers and a case study about Windows Workflow Foundation (WF) implementation for one of our major clients. I got quite positive feedback from the audience and some very interesting questions. I am looking forward to see the results from the feedback and the ranks of the lectors. I am definitely in the top 5 of all 30+ lectors, that’s for sure.

As promised, I am publishing all the source code for the case study that I have demoed. The prerequisites are the following:

1. Windows Server 2003 SP1 or Windows XP SP2;
   
2. Windows SharePoint Services with Service Pack 2 from here;
   
3. .NET Framework 2.0 and Visual Studio 2005;
   
4. Windows Workflow Foundation Runtime Components Beta 2.2 and Visual Studio 2005 Extensions for Windows Workflow Foundation Beta 2.2 from here;
   
5. Microsoft SQL Server 2005 Developer or Express edition;
   
6. DebugView utility from here.
   

The solution contains the following projects:

1. Demo.Common.Sts is a SharePoint document library event handler that handles the inserts and updates of the holiday request documents in STS;
   
2. Demo.Web.Services contains a single web service that is called by the SharePoint event handler when an insert or an update of a document occurs. It also manages the WF runtime and creates holiday request workflow instances;
   
3. Demo.Workflow contains the holiday request WF workflow as well as the ITalkToWorkflow interface definition and implementation. The interface demonstrates the communication between the host and the WF runtime engine.
   

The steps to make the demo running are the following:

1. Install SharePoint Services and upgrade the default STS site to ASP.NET 2.0 following the steps described in the Microsoft Support article;
   
2. Open the solution and build it. Deploy the Demo.Common.Sts.dll assembly in the GAC;
   
3. Open the SharePoint Central Administration tool by selecting Start->Administrative Tools->SharePoint Central Administration;
   
1. Navigate to Virtual Server Configuration->Configure virtual server settings;
   
2. Click on the web site that runs STS (Default Web Site if the default web site is extended by STS);
   
3. Navigate to Virtual Server Management->Virtual server general settings;
   
4. Make sure that the Event Handlers radio button is On;
   
4. Open the STS team site, then go to Documents
   
1. Create a new document library by selecting “Create Document Library”, then choosing “Document Library”;
   
2. Specify the document library name and description;
   
3. Press the Create button to create the library.
   
5. Navigate to the new document library in STS and configure the Demo.Common.Site assembly as the event handler for it;
   
1. When in the document library, choose Modify settings and columns;
   
2. Go to General Settings->Change advanced settings;
   
3. Specify the assembly name “Demo.Common.Sts, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=a9e51c9431eb593f”. Make sure that the full name of the assembly is correct;
   
4. Specify the class name of the document event handler, which is Demo.Common.Sts. GenericDocEventSync;
   
5. Update the settings by pressing OK.
   
6. Modify the default document library template and update it with the InfoPath template from the solution directory;
   
7. Configure the web.config of the Demo.Web.Services project and make sure that the connection string points to an existing SQL Server instance;
   
8. Create a new database and name it WF_Persistence;
   
9. Run the two scripts SqlPersistenceService_Schema.sql and SqlPersistenceService_Logic.sql from the WF installation directory, which by default is “C:\WINDOWS\WinFX\v3.0\Windows Workflow Foundation\SQL\EN”. This will enable the SqlWorkflowPersistenceService tracking service provider to dehydrate (persist) and hydrate WF instances in the WF_Persistence database;
   

To run the demo:

1. Navigate to the document library in STS and press Fill Out This Form;
   
2. InfoPath will be opened and the HolidayRequest form will be loaded;
   
3. Fill out the form, leaving the Status field as New;
   
4. Save the form, giving it an informational name;
   
5. Refresh the document library in the browser and you will be able to see the new document;
   
6. Monitor the execution of the event handler and the web service by using DebugView utility;
   
7. Once the document is received by the WF runtime engine, it will be persisted, waiting for the manager’s answer;
   
8. Check-out the document and edit it in InfoPath;
   
9. Change the status from New to Rejected (or Approved);
   
10. Save the document and then Check-in;
    
11. Monitor the execution of the workflow, as it will go alive for a moment, it will receive the answer of the manager and will complete its execution.
    

Feel free to comment or ask questions with respect to the workflow demo and good luck.

I am posting my first blog post from Microsoft Office Word 2007. It nicely integrates with my blogging provider and works without hassle.

I am quite happy what Microsoft did with the new version of the Office family of products and I am waiting for the RTM ;)

During my recent BizTalk 2004 projects I have been continuously using Scott Colestock’s excellent Deployment Framework for BizTalk 2004. On my first BizTalk 2006 project I thought that the migration of the tools and scripts will be quite smooth. This is when things start to go wrong :)

When executing the “debugDeploy” target you might get the following error:

BUILD FAILED

INTERNAL ERROR

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileNotFoundException: File or assembly name Microsoft.BizTalk.ExplorerOM, or one of its dependencies, was not found.
File name: "Microsoft.BizTalk.ExplorerOM"
   at BizTalk.NAnt.Tasks.ControlOrchestrations..ctor()

=== Pre-bind state information ===
LOG: DisplayName = Microsoft.BizTalk.ExplorerOM, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
(Fully-specified)
LOG: Appbase = C:\Develop\Projects\My.BizTalk.Project\DeployTools\NAntSubset\
LOG: Initial PrivatePath = NULL
Calling assembly : BizTalk.NAnt.Tasks, Version=1.0.0.5, Culture=neutral, PublicKeyToken=null.


The reason for that is the Microsoft.BizTalk.ExplorerOM.dll which is extensively used by the deployment framework to manage orchestrations. Disassembling the BizTalk.Nant.Tasks.dll assembly you will find out that it references version 3.0.1.0 of the Microsoft.BizTalk.ExplorerOM.dll which makes sense with the BizTalk 2004 release. When checking what is the version of the same assembly in BizTalk 2006 you will be stuck with the same version. Though the file size and the contents (apparently) have changed and breaking changes have been introduced. Heard of dll hell?!

What I did in order to make the deployment framework work with the BizTalk Server 2006 release and the .NET framework 2.0 was the following:

1. Get the latest nightly release of NAnt. As of writing the post there is no a stable release that supports the .NET Framework 2.0. I have used nant-0.85-nightly-2006-04-08. Rebuild the NAnt solution;


2. Copy the newly built NAnt files to the %BizTakl2006_solution_directory%\DeployTools\NantSubset directory;


3. Get the latest release of the Deployment Framework for BizTalk 2004 from here. As of writing the post there is no release that supports BizTalk Server 2006;


4. Rebuild the BizTalk.Nant.Tasks project, changing the referenced Microsoft.BizTalk.Explorer.OM.dll to the assembly in the “%BizTalk_2006_Install_dir%\Developer tools”. By default, it is C:\Program Files\Microsoft BizTalk Server 2006\Developer Tools;


5. Copy the newly built BizTalk.Nant.Tasks.dll in the %BizTakl2006_solution_directory%\DeployTools\NantSubset directory;


6. Retry the “debugDeploy” or any other task that might be used during development. Everything works!

As a conclusion I recommend the Deployment Framework for BizTalk 2004 for the automation of the deployment process in BizTalk solutions. Everyone knows the hassle when deploying a BizTalk solution. The tools in the framework save an enormous part of the development time.

Wow, I just passed my first Microsoft SQL Server 2005 official exam. I am now a Microsoft Certified Technology Specialist (MCTS)!

I went for the 70-431 TS: Microsoft SQL Server 2005: Implementation and Maintenance. Quite a challenging one, I have to say.

During the preparation I came across several interesting articles that helped a lot:

1. Database Mirroring in SQL Server 2005, http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirror.mspx; Make sure you setup to SQL Server nodes and play with the queries given;


2. COPY_ONLY Backups in SQL Server 2005, http://www.databasejournal.com/features/mssql/article.php/3591131; As an example scenario you can use the AdventureWorks database and play with the four different backup choices;


3. Monitoring Resource Usage, http://msdn2.microsoft.com/en-us/library/ms191246.aspx; Quite a useful set of performance counters to know when analyzing the performance of a SQL Server 2005 solution;

Unfortunately, there are not many articles and resources on SQL Server 2005 yet. Most of the information I got from the SQL Server Books Online which is the most useful resource ever on Microsoft SQL Server.

I wish you happy preparation and good luck on the exam. I am going for the next one too ;)

It has always been an interesting discussion how to decrease the time consuming tasks of moving data from a business middle-tier to the database backend. Last year, after looking at different samples, snippets and tools I stumbled upon http://www.nhibernate.org.

Most of the NHibernate samples I went through on the internet were not complete and were vaguely describing part of the NHibernate framework, many of them providing little to no pieces of code which was not very helpful. My goal is to give a practical example of a business case and the implementation of the business logic and the data access layer using an ORM tool.

The article first describes the business case that will be implemented and how using NHibernate the development effort can be significantly reduced.

Many resources might be found about what ORM is and how it can be applied in commercial applications. The main purpose of ORM tools and technologies is to reduce the development time in moving the information from the business entity classes to the database back and forth. An over simplistic view of ORM is the following diagram:



Let’s imagine an e-commerce solution that has several well known business entities.



A Customer can have many Orders that can be submitted to the e-commerce site. Every Order can have at least one OrderItem. The OrderItems represent the information in the order with respect to the Products that the Customer has ordered.

No matter which technology we will use for the implementation of the entities, the simple CRUD (create, retrieve, update and delete) operation will take significant part of our development effort. In order to minimize the time needed, we will use the .NET framework, C# and NHibernate. Nunit and Microsoft Enterprise Library will be used for the unit tests.

There are also many discussions lately about TDD (Test Driven Development) and unit tests. While validating the implementation of the CRUD operations in the classes and checking what happens on the database end, we will also reveal the use of the Nunit (www.nunit.org) unit-testing framework.

Let us first start with the basics of ORM. Every such technology needs to make a translation between the database that stores information and the business entities that exists on another tier. For example a table that represents the Customers information will need to be closely designed to the properties which every customer entity has. NHibernate simplifies the mapping of the properties (public members) of a C# class to the columns in a table in the database. Every mapping is described as an XML file with a specific schema. To make things simple we will keep the Customer class with as little properties as possible. Let’s have a customer ID and a Name. The database will also need to contain a table called Customers that will have two columns as a start, ID and Name.



The following NHibernate mapping file contains all information that is needed by the framework to provide all CRUD operations on the entity.



The mapping starts with the relation between the class that has to be persisted (DemoNHibernate.Entities.Customer from the DemoNHibernate assembly) and the Customers table in the database. It then continues with the mapping between the class properties and the table columns. For example the ID property from the class maps to the ID column in the table. Note the bag tag that describes the one-to-many relationship between the Customer and the Order entities.

One common task will be to add or update class properties. What we will need to do is add/update the column in the table, the XML file and the corresponding property in the C# class. It is a great time redeemer.

Once we have all the classes, the tables in the database and the mappings between the classes and the tables, we will also need to implement the data access layer using NHibernate functionality. Only mapping the property will not do that much. It will not transfer the business information to the database. For that purpose we will use a very common design approach. For every business class that we have we will introduce a corresponding DAO (data access object) class. The implementation of the DAO classes will include NHibernate specific parts that will utilize the ORM framework and will make things really working from end to end.



The set of DAO classes have a common part, which is the handling of the connections to the database using the ISession interface from NHibernate. The BaseDao class manages the connection to the database. All DAO classes are direct inheritors of BaseDao and have the connection to the database already available. Their only purpose is to implement the standard CRUD operations.

Some caveats exist, for example that every XML mapping file has to be compiled into the assembly as an embedded resource. NHibernate uses reflection to extract the resources from the assembly once loaded.

The solution has the following structure:

DemoNHibernate – contains the main console application
Dao – contains the implementation of the DAO classes
Entities – contains the implementation of the business entities
Mappings – contains the NHibernate mapping XML files
scripts – contains the db script that describes all db objects
Tests – contains the unit tests for the critical components
App.config – describes the mandatory NHibernate settings
dataconfiguration.config – used only by the nunit tests
In order to build the solution you will need to follow the steps:

1. Download and intall NHibernate 1.0;


2. Download and install Microsoft Enterprise Library June 2005;


3. Download and install NUnit 2.2.4;


4. Create a new database <database name>;


5. Run the db_script.sql to create all database tables;


6. Open the solution and rebuild, referencing to the appropriate assemblies;


7. Reconfigure the App.config file, changing the NHibernate settings for the connection to the database;


8. Reconfigure the dataconfiguration.config file, changing the settings for the connection to the database from the unit tests;


9. Rebuild and run the unit tests.


10. Explore the implementations of the entity classes and the DAO classes, review the XML files with the NHibernate mappings.

As a conclusion, the article uses a pretty nice set of tools and technologies. It demonstrates a complete set of business entities and data access layer using ORM, as well as unit testing. It also uses Enterprise Library in the unit tests to connect to the database and check what are the results of the ORM operations and how the changes in the business layer are reflected to the database.

Although reducing the time to implement stored procedures and calling them using standard ADO.NET or Enterprise Library, we are still required to implement the DAO classes which adds a little bit of overhead. Here the experience of the developer will take place in deciding if an ORM tool will be applicable to the current situation and if it will save time or not. For small and less complex projects the approach that I have described is pretty much everything that is needed. For heavier business logic, lots of relations and a complex database, an ORM tool might not be the best choice. I still haven’t evaluated the performance impact of using NHibernate, but that will follow in an additional article.

You can get the complete solution from here. The article in PDF format you can get from here.

I would like to thank Peter Skelin, for the review of the article prior to its publishing.