Recording the transactions details like inputs, outputs, processing details etc. and errors/exceptions information for any transactions flowing through a system is known as logging. For any solution of medium to complex level; logging plays a significant role for operational excellence, transactions tracking, issues fixing and performance analysis.
Like any solution developed in any programming language; integration solutions designed and developed in TIBCO BW also demand a sophisticated level of logging to achieve above mentioned performance and operational goals. In this article, I will talk about best practices and common considerations for Logging in TIBCO BW
What should be logged?
The answer to this question can’t be generalized as requirement for level of logging greatly varies from project to project depending on project criticality, transactional behaviour and complexity level.
However, we can still consider following few items which MUST be logged always:
- Process start and end information
Logging the start and end information along with timestamps helps in tracking the process in terms of the timings as well as duration for its completion.
- Input and Output Payloads
Irrespective of the type of process starter of a TIBCO BW process, payloads logging is quite needful for tracking and investigating data related issues. However; logging the payload should be considered only after keeping in mind the performance and storage factors. For example; if your process starter receives a very huge chunk of data (say over a thousand records in an xml file); you can’t straight away decide to log this payload without thinking on how much memory resources you have and how it can affect overall performance of the solution.
- Internal activities/sub-processes information
Normally TIBCO BW processes involve quite a number of activities for different types of functionalities (e.g. JDBC activities, Mappers, XML activities etc.) and also calls to various sub-processes. A good solution should have such information also duly logged so that an operations resource is able to identify bits and pieces of the solution by looking into the logs. If some stored procedure is called; output of the procedure can be logged. Similarly if any mappers or XSLT transformations are used; logging the results can be quite helpful for operational support.
- Exception data
Exceptions or errors in any solution are inevitable and any solution developed should have adequate exception handling logic implemented. Exceptions whether caught and handled explicitly or not—must get logged along with all relevant information including Stacktrace, error message, error codes and other transactional details.
How information should be logged?
Logs can be either file based on database based. Both variants have own pros and cons associated with them. Having standard file based logs relieves from the extra burden of maintaining a relational database but on the other side; it makes it less convenient for transactional tracking.
Database based logs make it much easier to track, trace, slice and dice through the logged information as well as to do any types of reporting based on the logged results. One example of such logging is TIBCO’s CLE (Common Logging and Exception Handling) which helps organizations to achieve a much sophisticated solution for Logging and exception handling. With tools like CLE; it becomes quite easier to correlate between logs and exceptions, enable retries for exceptions scenarios as well and generating email alerts for any exceptions logged in the database. CLE also further helps organization by providing some dashboards for having a more detailed graphical look into the logs and exceptions information for any number of configured solutions.
What makes TIBCO Logs good?
Any BW solution will be considered to be designed with efficient logging if:
- Transactions can be traced and tracked easily from the logs.
- Logs help in quick resolution of the issues.
- Payload and other associated data can be found in logs when and as required.
- There are no duplicates/redundant information in logs.
- Information logs and exception logs can be easily correlated.
Conclusion
Make it a habit to think by putting yourself in the shoes of a support or operational team resource when developing your TIBCO BW solution. Think critically and decide smartly what pieces of information in the logs can make the life of the teams easier without compromising the code quality.
Hi,
I have to use one shared variable in two different BW components (.ear). In one component I have to set it and later on it will be used by another component.
So, while testing in lower environment ,it is giving error like “Variable not set”. And as per my requirement I don’t want to use any Database,it should be file based.
Please help me in this .
Thanks
Venugopal
Use shared variable with multi engine checked and persistent.
If you don’t want to use db. you can use wait notify activities as well.
your site is so good
And also we want exception handling mechanisms
Pingback: Top Reasons of Poor Performance of A TIBCO BW based Project