Programming and application errors can be anticipated, detected and resolved. Error handlers are the ones which are tasked to identify the errors. It can either recover from the errors without the need to terminate the application or keep the error report to a file. Then it will terminate the affected application.
If these application errors are detected on an early stage, it lessens the effort of reworking. Time, cost and resources can also be saved upon the detection.
When an unhandled exception occurs, an activity receives control of execution. This activity is called the Catch activity. Exceptions are handled one by one, or you can specify to handle ALL exceptions. You can have more than one exception, but you must be sure that each Catch activity handles a unique exception type.
If you wish to perform to handle the exception, the Catch activity allows you to transition to activities. You cannot transition back to the main execution track from the Catch track. Transitions are permitted between Catch tracks within an exception scope.
But if you want to throw the exception caught again, you may use the Rethrow activity. This activity is used to propagate the exception to the higher level.
Building A Try/Catch Block
A try/catch block allows you to try to perform an action, or in the case of TIBCO, an activity. If an exception occurs, it will catch the exception and lastly, deal with the exception gracefully rather than crashing the application.
You can create a Try/Catch block in TIBCO with the use of Groups. The Catch and Generate Error activity must be put inside a Group, and set the action into “none”. This is used for grouping without the loop. With only one condition for the group, this will allow you to catch any error that occurs inside of the group. You don’t need to catch errors in each activity individually.
Error data will be available to activities that has executed after the error transition. The error data can be found on two types of process variables, the $_error process variable and the activity error variables ($_error_
The $_error process variable will show the ErrorReport complex element that contains the schema depending on the activity that throws an error. This is the error’s general information like StackTrace, Msg, FullClass, etc. The $_error process variable is also useful in an error-handling procedure because you can map data from this process variable into input items for activities in your error-handling procedure.
On the other hand, the $_error_
|This TIBCO video tutorial shows you how to create a custom function using the TIBCO Java Custom Function shared resource. The custom function will be added in the function list of the TIBCO Designer XPath Formula Builder. This is the recommended practice if the function is needed in numerous processes in the project.|
|In this TIBCO video tutorial, you will learn how to perform checkpointing in your process. This capability is very important in the design of your processes to give them the ability to recover seamlessly from an engine failure. TIBCO allows you to very easily checkpoint the state of your process instances.|
|This TIBCO video tutorial shows you how to create a Destination Bridge in the Enterprise Message Service (EMS) server. In the video, you will see a JMS topic being bridged to a JMS queue. This is a very widely used pattern in enterprise systems integration.|
|This TIBCO video tutorial shows you how to send and receive JMS messages. Here you will learn how to use the JMS Queue Sender and JMS Queue Receiver activities. You will be impressed at how easy it is to do JMS messaging in TIBCO. It’s great!|
|This TIBCO video tutorial shows you how to iterate through a result set. You will learn how to use the Iterate Group in TIBCO Designer. The iteration element here is a database result set. You can have other types of iteration elements as well. Kindly leave a comment after watching. Thanks so much.|
|In this TIBCO Designer video tutorial I show you how to align process activities in TIBCO Designer so that your process flow is more readable. This is a very important aspect of TIBCO development. Many TIBCO developers neglect this aspect when creating their process flows. If you find this TIBCO training resource helpful, will you kindly return us the favor by posting a comment on YouTube? If you can post your comment to both YouTube and in to this blog post, it would be greatly appreciated!|
One of our clients had asked us about the difference in performance between a TIBCO ActiveMatrix BusinessWorks process that uses a subprocess call and one that does not. In other words, one TIBCO process called a subprocess to perform a certain functionality, whereas the other process had the functionality embedded in itself. The functionality in question was a simple JMS Queue Sender activity that sends a JMS queue message to the JMS server. The client was concerned that there may be a large enough performance difference between these two processes to discourage the use of subprocess calls on any process where performance is critical.
The TIBCO Certified Professionals in our company set out to find out the difference in performance between these two processes. We endeavored to answer the following question: how much of a performance cost does a subprocess call incur in TIBCO ActiveMatrix BusinessWorks?
We set up one process that had the functionality embedded in it:
We setup another process with the same exact functionality being called as a subprocess:
We then called these processes individually 10,000 times each using the following loop from a caller process:
The time it took to for each process to execute 10,000 times was noted. The test was repeated 10 times for each process.
Here are the results:
|Test||No Subprocess Call||With Subprocess Call|
To execute 10,000 times, the process that had the functionality embedded in it took 1473.5 milliseconds. On the other hand, to execute 10,000 times, the process that called the functionality as a subprocess took 1780.0 milliseconds. The difference is 306.5 milliseconds. This may seem like a large difference at first, but remember that this is for 10,000 executions. For just one execution, the difference is only 0.03065 milliseconds (306.5 / 10000).
So, surely, executing an embedded functionality is always going to be faster because there is no need to call another process to perform the functionality. Notice, however, that the difference is extremely small. The question a TIBCO architect must ask is, “Is the difference of less than 1 millisecond per execution large enough to warrant giving up the advantages of subprocesses?” One must look at the performance requirements and Service-Level Agreements (SLA) in order to properly answer this question.
The processes were deployed into a desktop computer with an Intel dual core 3 GHz CPU and 2 GB of RAM.
To learn more about this performance test, or to inquire how we can help with your TIBCO projects, feel free to contact us anytime. Please kindly leave a comment, and tell us about your own experiences in performance tuning with TIBCO Software products.