Developing SOA Compliant, well modularized, loosely coupled solutions in TIBCO BW have always been a great experience for me. Developing a solution which actually solves a problem instead of adding to the problems is the key that every developer should keep in mind while digging into the logic. Every programmer can write lines of code but not every programmer write a piece of code which follows the best practices and gets the job done in an efficient, accurate and optimized manner.
When it comes to developing smart and optimized code, TIBCO isn’t an exception. Being a middleware lying in the middle of the entire battleground, need of following the best practices raises many times for those fighting in this war zone.
In this article, I will explain some of the TIBCO best practices that I follow and recommend you to follow as well:
- Never Keep a Loophole: Handle Exceptions Properly
A good piece of code should always cater both positive and negative scenarios. You never know how unforeseen case
s can spoil your day so beware of it. While developing solutions in TIBCO where you write processes to integrate enterprise applications, Exception handling should be carried out all the key points. In your BW Processes, use Generate Error activities and Catch activity for generating errors and handling them.
You should also specify Error Schema for your End activity so that response is sent properly to calling application in error scenarios. You can get help from one of my tutorials on how to handle exceptions in TIBCO if needed.
- Organize the Code for the ease of modifications
A well-organized person writes well-organized code. While developing processes in TIBCO designer, you are the architect and it’s you who have to decide where to place the brick and mortar.
A best practice is to organize the code with proper layering through separate folders. For example, when I develop a TIBCO BW project, I create separate folders for Business Processes, Schema Definitions, Connections (with further hierarchy of JDBC Connections, HTTP Connections, FTP Connections etc.) and WSDLs.
Also, within a folder, create further folders with more organized project structure. I often keep the Inbound and Outbound processes in separate layers.
When you have your code properly arranged and organized, it will be much easier for you in future to understand the overall flow and to make any code level or configurationally changes.
While defining Global Variables in your project, same hierarchical distribution should take place and same best practice should be followed. For example, if TIBCO interacts with a CRM system in your project, you can make a Global variables group CRM and all GVs relevant to CRM should be defined under this.
- Write re-usable components/services
Smart programmers and designers never go for re-inventing the wheel. They go for reusable code components to get their future jobs done with ease and comfort. While developing TIBCO BW solutions, think for the ways you can produce such processes which have common functionality embedded and then use these processes at any place needed.
For example, I often require logging, auditing, error handling and reprocessing in my TIBCO projects. What I do is that I write BW Processes for these functionalities in a Common Layer and then use same processes throughout my project when and where needed.
This reusable code development not only helps me save my time but also reduces overall effort and hence the cost.
- Group the activities properly
Grouping with different types of iteration conditions are often needed in TIBCO projects. Whenever you have a set of activities which are used to achieve a particular type of functionality, think of grouping them so that you a group level error handling and iteration logic.
This helps not only to specify grouped error handling conditions but also organizes the code more decently.
You can go through my blog post about group iterations for more understanding of the subject.
- Use Label Activity to describe a Process
Whenever I design a new process in TIBCO designer, I think about those poor guys who will be asked to make the changes in the code in the future when I won’t be looking into it. And then I think how I can put some sort of comments/labels which can help them understand the logic quickly without digging into each and every activity, every transition and every sub-process calling. And then I opt for using Label activity to provide details in a couple of sentences what a particular process does.
Best practice when developing Designer processes is to use Label in each process where you can mention process purpose and its input, output parameters.
- Be careful when using checkpoint activity
Using checkpoint activity can be very useful for restoring the engines in case of crashes but one should think smartly before deciding use of checkpoint activity in TIBCO Designer processes.
Remember that using Checkpoint activity when it makes no sense is just nonsense. For example, using Checkpoint activity after HTTP receiver makes no sense as HTTP connections get closed after any crash and hence no use of check pointed recovery after this.
Also, if you are using any transaction group in your designer process, never use checkpoint activity inside the transaction group.
- Use Proper naming conventions
Names matter a lot for all of us and same goes for our applications, projects, processes etc. While developing TIBCO BW projects, you should follow a single naming convention throughout your application to make it less confusing.
I often go for process names with first letter capital. E.g. a process which queries accounts is named as Account Query Process by me. Names should be meaningful so that one can get a clue of process logic from its name.
Designer palette activities when used in processes should be renamed properly. For example, when using JDBC Query activity to query records from account table, I name it as QueryAccount.
Naming of Connections, Schema definitions and variables should also follow proper naming convention.
- Don’t be dirty—align the activities properly
TIBCO Designer Processes often become too complex with dozens of activities, large number of transitions and many groups which can make it clumsy and bad looking. Don’t design the processes in such a way that it presents you as a dirty coder. Align the activities neatly to the best possible way and draw the transitions neatly.
Smoothly aligned activities in a designer process will not only look good but will also make it easier for you to debug and modify the code in future.
- Be smart in choosing activities
While developing processes in TIBCO, you have dozens of activities available in different palettes which you can use to achieve your goals. Best practice when developing TIBCO BW solutions is to use an activity only when it is actually needed.
Using JDBC update activity excessively with unnecessary auditing or logging, using checkpoint activity unwantedly, making too much process variables instead of using XML Schema definitions can lead to poor performance of your application.
When you have synchronous applications, try to reduce the overall performance burdens so that calling application doesn’t get hanged.
- When using RV, Consider data criticality and time criticality
For RV based messaging in your application, you have choice of either using Reliable RV or Certified RV. Which RV method to use, depends on your project requirements.
If you are much concerned about your application speed than data safety and can afford data loss to some extent, go for Reliable RV messaging. But if your application is data critical and every chunk of information sent matters a lot, go for Certified RV.
You can read my blog post about difference of Reliable RV and Certified RV for more insight into the topic.
If you are interested to dig deeper, refer to my video on TIBCO BW Design & Development best practices which covers the subject in much details.
