Suvidhaa Infoserve assists retail service providers like malls and multiplexes to bridge the gap of time, accessibility and convenience by providing them with well-customised services and developing the required web interfaces for them. This empowers retail service providers to function better as they can have various services at their disposal at the click of a button to address their consumer needs more efficiently.

The company works hand-in-hand with various service providers like IRCTC, airlines and multiplexes (they already have a tie-up with Adlabs and have also started work with PVR Cinemas). Suvidhaa was looking for a middleware that would seamlessly work with the technology platforms of all these service providers. So the company went on to deploy Microsoft Biztalk Blade Server 2007 as a middleware. There are other seven servers used for Web, Application, Database and DNS services.

Prior to this, the company’s application framework was on ASP .NET, which needed to be worked upon, to make it compatible with other application frameworks like Linux etc. used by other service providers. The Biztalk server proved to be a common intermediate middleware. "Basically we wanted to go in for a middleware that is compatible with other technology platforms as well as easy to develop and faster to deploy" says Naresh Sharma, vice president – IT, Suvidhaa Infoserve.

"This is a key link in our process," he adds and goes on to affirm that as Suvidhaa is an ITES company, it is solely reliant on technology. If any of the servers in the chain of hardware and applications malfunction or any link is broken, the company comes to a standstill. Even if the application server goes down, the company comes to a halt, irrespective of the fact that the DB, middleware and service provider servers might still be running. So a glitch in any component of the chain of services affects the overall services. Biztalk is a part of that link.

The company uses web services for connecting to its clients’ services.

Major challenges: server downtime and piling up of log files

Stabilising the server environment was the principal challenge for Suvidhaa during deployment. It was done with the help of an external agency recommended by Microsoft. However, the executives from the organisation were not aware of the strengths and weaknesses of the product itself. Initially, the challenge was that the Biztalk server used to go down after regular intervals, maybe, once in a week and often it went down on Sundays, so employees had to work on a rotation basis. Gradually, the problem was detected. The configuration of the product was incorrect. The hardware configuration was also incorrect. While there ought to have been separate hardware for Biztalk application and Biztalk DB, the agency had advised to run them on the same server, "As a result, we were running Application and DB on the same server and consequently the CPU utilisation crossed 80 to 90 percent," says Sharma. After the identification of the problem, the application and DB were hooked on to separate servers, resulting in a reduced CPU load consumption.

Before moving on to understanding the second reason for the downtime, let us look at how a typical information request is processed and exchanged between the Suvidhaa Infoserve server and the service provider’s server. Suppose there is an enquiry directed to the railways’ server about the trains available between two points. The Database captures this information in a packet format and the railways’ server replies back with the required information, which is also stored in the DB. The tracking can now identify whether the request is for an enquiry or a booking packet.

The second reason for the downtime that Suvidhaa faced was the clearing time required for accumulated log files. Due to improper maintenance, the information requests from Biztalk to the service provider were forwarded but there was no response from the service vendor. The performance went down and Suvidhaa started getting time-out arrests on its front-end side. The company had put a time out of 90 seconds i.e. if Biztalk did not respond to its front-end application, the same would time out after 90 seconds and subsequently the front-end would just hang.

There was also no provision to delete the requests after a certain time. All these repeated requests got accumulated and every time a fresh request was made, the Biztalk server used to go through all the pending requests that slowed down the entire process, resulting in mounting up of query load and thus, an increased CPU load.

Tracking the Information Exchange Timeline came to the rescue

The internal IT team and the implementation partner collaborated to overcome these challenges. "We broke down the exercise into different steps, like how much time does it take a typical request to reach from the front-end to the application server, then to the web server and further on to the Biztalk server and finally to the application at the service provider’s end" explains Sharma. After evaluating the processing timings of the request in between these various servers and applications, the company finally arrived at a solution.

The vendor’s consultant went through the log files and found out that the pending requests were about two to three months old. These requests got into a loop, resulting in slow response time. There was a constant improvement in the performance after the logs were deleted.

At the end of it all, we can say that the hassles were a blessing in disguise for the company as it helped the Suvidhaa executives to better understand the Biztalk server. "We have brought about a basic change in the whole system. Earlier we started off with an application making a request to Biztalk and later waited for Biztalk to respond back. Now the path that a typical request follows has been changed," reveals Sharma. However, he was not willing to release any information on the changed path. The company uses Windows 2003 as Operating system and Oracle 10.2g as Database.

Pluses: Independent DB and Speed

The main advantage of a Biztalk server lies in the fact that it works on an independent database keeping a track of all transactions. The server also has an independent log in the DB that facilitates information retrieval in case of a dispute. Secondly the speed – not only the development speed but the performance speed too – works as an advantage. "If it were not for the Biztalk server we would have to write our own interface (codes) and that can become a bottleneck in case there is a spurt in volume," says Sharma. The Biztalk is scalable, which also helps in load balancing, merely by adding a node to the cluster of Biztalk servers.

Apart from Biztalk Server 2007, the company evaluated Web Sphere from IBM, however, Biztalk turned out to be friendlier because the amount of coding involved in development and deployment is minimal in Biztalk. This user-friendliness is facilitated by the drag and drop kind of development. Web Sphere is an older product too; it’s been around for 10 years now.