Top Reasons of Poor Performance of A TIBCO BW based Project

TIBCO BusinessWorks (BW) is a very handy tool which helps medium as well as large enterprises to integrate their heterogeneous systems in an efficient manner and run the business smoothly. TIBCO BW is not only good in terms of its ease of use and development friendliness; but also equipped with all the required features to outperform in highly critical environments with huge flux of data flowing around.

Despite all the great features available in TIBCO BW; some of the common mistakes committed during the project design, development and deployment; may lead to poor performance of the projects developed and deployed using this great tool.

In this post; I am going to talk about a few major blunders or mistakes that are committed by developers or architects in BW based projects.

 

Inefficient Usage of JDBC activities

Data is the key in almost every business and we can’t even think of any projects which don’t involve database related activities. Same is true for any integration projects developed using TIBCO BW. TIBCO BW provides different JDBC activities for updating/inserting/deleting/querying the data and also for invoking the stored procedures.

Writing queries with higher execution cost results in higher processing time of the queries and often causes JDBC timeout errors. Queries should be fine tuned; underlying databases should be properly indexed to reduce the associated costs of all the queries involved in any TIBCO process.

Specification of proper timeout value in JDBC activities configuration is also important. Specifying very low timeout value will result in higher rate of overall JDBC timeouts in the process. Timeout values should be decided only after a thorough analysis of the queries involved.

When using JDBC Query activity to fetch huge number of records from database; Process in Subsets option should be used and in subsequent activities; proper grouping should be used to iterate through the records in an efficient manner.

Since database activities are always time taking; any unnecessary redundant queries to the database should be avoided and data re-usability should be increased in the project. For example; If you are fetching some configuration data from the database in a starter process; same information should be flowing to any subsequent processes which also require same data (instead of querying from the database again).

 Tight Coupling in the Code

The term “tight coupling” refers to a high degree of dependency and linking between the entities/processes involved in a project. When developing TIBCO BW based projects; services should be kept as much loosely coupled as possible so that any future changes can be done with least possible disturbance in the overall picture.

For example; If your TIBCO project is interfacing with n number of upstream systems and you are using same schema structure in a single XSD file for all the interfaces; any changes if required for one interface; will impact all other n-1 interfaces as well as all interfaces are tightly coupled due to same XSD being used.

Hard coding of the data should be minimized as much as possible by utilizing the Global Variable options. Any configuration information if hard coded within TIBCO processes; result in unnecessary rework for any changes required in later stages. For input configurations of any activity; Schema elements should be preferred over specifying Complex Elements directly so that future changes are easy to handle.

Any global variables used for run-time configurations should also be set at service level if multiple services are made part of a single EAR. Keeping such variables at individual service level won’t disturb other service(s) using the same global variable if changed for one service.

However; re usability should not be compromised just to reduce the coupling. Any resource in the project which can be re-used for multiple processes, services or interfaces; should be utilized.

 Lack of Modularity in the Code

Another element counting to the poor performance of a project is redundant un-modularized design of the project. If project resources are not duly separated into re-usable modules; It results into introduction of large chunk of duplicate and redundant code which leads to overall degradation of the performance and code quality.

When designing TIBCO BW based projects; project resources should be proerly modularized based on their usability, interfaces and systems connectivity and other correlation factors. For example; If you are developing a TIBCO BW project which is interfacing with a billing system, a CRM system and a warehousing system; you should divide the processes/services in your project in a way like below:

* CRM Inbound Module

* CRM Data Handling Module

* CRM Outbound Module

* Billing Inbound Module

* Billing Orchestration Module

* Billing Outbound Module

* Warehouse Inbound Module

* Warehouse Outbound Module
* Common Auditing and Logging Module
* Exception and Error Handling Module

 

 Poor Architectural Decisions

Like any other project; TIBCO BW based projects also suffer mainly from the poor design decisions taken at architectural level as all underlying development and deployment level decisions are mainly governed by the high level architectural decisions taken at the project level.

Selection of inappropriate messaging mechanism; inefficient decision regarding flow of information between different systems; flawed decisions regarding deployment topology, wrong infrastructural estimates and wrong choices of associated additional tools and technologies are the key contributors towards architectural failure of any TIBCO BW based project.

Based on the estimated flux of data flow, possible addition of any additional systems to the information system, frequency of future business/architectural changes in the overall enterprise and business needs regarding throughput of the systems; decisions should be made with thorough analysis.

Whether EMS or Rendezvous should be chosen for message communication; whether SOAP services should be considered or REST services; ADB Adapter should be selected or normal JDBC activities are enough; ActiveSpaces based caching is required or not; synchronous communication is needed or asynchronous mode of communication can also work; reprocessing mechanism is required or not; etc. are some of the example key architectural decisions which count greatly towards a TIBCO BW based project’s success or failure.

 

Improper Logging and Auditing

The biggest pain for a support resource is inability to find the root cause of any failure case. For the entire flow of a service request in TIBCO BW Code; if logging and auditing is not implemented properly; It becomes a big challenge to exactly find out the reason of any request failure. In order to enable proper tracking of the requests flowing in and out of a TIBCO service; not only errors and exceptions should be logged properly but also; proper auditing should be done for the requests at different checkpoints.

For example; If your TIBCO Based service is responsible for taking request from a CRM system and then it is responsible for validating the request, handing it over to a charging system,  getting response back from the charging system and updating the CRM system back with the final response; auditing should be done at each and every level starting from reception of the order to the final response handling.

Exceptional scenarios should also be logged properly with meaningful log messages which are understandable for the operational resources.

Refer to another tutorial where I explained TIBCO BW Logging Best Practices in detail.

Inefficient Deployment Settings

No matter how smart you have developed and designed your project; If the services are deployed with improper settings; things won’t go right. Deployment of the services in a domain is a critical decision for which sufficient resources must be made available depending on the data traffic and business needs.

Deploying the applications in fault tolerant and load balanced mode with sufficient memory and CPU resources, with appropriate process configuration parameters (MAX JOBS, FLOW LIMIT, ACTIVATON LIMIT etc.) is a prime contributor towards the smooth and efficient running of the services in the production environment.

 

The list of performance measures doesn’t end here but I conclude here to keep the post to a reasonable length. I hope this post will help you to understand all these performance measures involved in any TIBCO BW project.