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_
Researched and written by Xmarter TIBCO Consultants
Traditional deployment of business integration project requires a lot of configuration effort. The administrator needs to ensure that the configurations for multiple interactions are supported and configuration files are required for different components on different machines. TIBCO ActiveMatrix BusinessWorks, in contrast, provides an interface for creating deployment configuration and then deploying the project. To deploy TIBCO ActiveMatrix BusinessWorks Projects, TIBCO Administrator is used. It is a central administrator server for creating, deploying, managing, and monitoring TIBCO applications and machines within the administration domain. Upon deployment, TIBCO Administrator will create deployment configuration that will be sent to the machines where the projects will be deployed.
All TIBCO BusinessWorks Projects undergo same project phase: design, deploy, and run. After designing and testing the process in TIBCO Designer and setting up the required resources, projects will be deployed in TIBCO Administrator to run on its designated machines. There are two ways to deploy the project in the TIBCO Administrator Server: using the TIBCO Administrator GUI or using scripting deployment utilities. TIBCO Administrator GUI is a web-based graphical-user interface where administrators can easily manage and deploy TIBCO BusinessWorks Projects using a web browser while scripting utilities allow TIBCO Administrator functions to be executed from the command-line.
In using TIBCO Administrator GUI to deploy projects, an Enterprise Archive (EAR) file needs to be created using TIBCO Designer. The EAR file must contain all the required resources such as adapter configurations and process definitions that need to be deployed. After building the EAR file, it will be uploaded to TIBCO Administrator GUI to create the application and to set deployment configuration. On the other hand, in using command-line utilities for deployment, only the Buildear and AppManage utilities are used. Buildear utility is used to build the EAR file based on an archive defined in a TIBCO Designer project while AppManage utility creates an XML based deployment configuration file then uploads the deployment file and EAR file into TIBCO Administrator.
TIBCO Administrator allows applications to be deployed multiple times. However, only one deployment configuration can run anytime. It has a Configuration Console which provides options for deploying and updating applications and it maintains a deployment configuration history that allows reverting of deployments in the future. Updating of application is very important if new TIBCO software is installed on the machines where the application is deployed.
Once an application is deployed, TIBCO Administrator imports all the values defined for global variables from the EAR file. This allows global variables to be changed during deployment. Global variables may vary depending on the environment and these variables might use environment specific values. Thus, setting correct variables during deployment is critical for the application to run.
TIBCO Administrator enables administrator to manage deployed processes and services included in the application. Processes deployed in TIBCO Administrator can be assigned and run on any machine that belongs to the same administration domain. The target machine where processes and services are deployed is called ‘container’. Services can also be enabled and disabled. Disabled services will not be deployed in the next application deployment unless enabled before deploying. Service’s process instances execution can be controlled by changing process configuration properties like Max Jobs, Activation Limit and Flow Limit. This is helpful if process instances need to run sequentially due to limited CPU resources and memory. Max Jobs property is used to limit the number of concurrent process instances that can be loaded in memory. Meanwhile, Activation Limit property is selected if process instances that are loaded in memory will stay in memory until completion. However, Flow Limit property sets the maximum number of process instance that can be started before suspending the process starter.
Project deployment maybe a simple task but it’s at least as important as the project design. Deployment needed to include required resources and configurations to have a smooth run in production. Thus, TIBCO ActiveMatrix BusinessWorks allows business integration project deployment to be easily configured and run on any machine in the domain.
In another perspective, TIBCO lets you integrate different incompatible applications in a service-oriented architecture (SOA). This can be achieved through ActiveMatrix (AMX) Service Grid and other AMX family of products. In AMX Service Grid, you can create a composite, which contains services, components, and references. You can think of a composite as a circuit board which holds several important electronic modules.
Services simply refers to web services, which are standardized methods of communication between two contracting parties, commonly a service provider and a service consumer/client, in a language only both of them can understand. Communication happens through message exchanges either one-way or two-way. In a two-way communication, the consumer sends a request message and expects a response message back. This message comes in a specific format usually SOAP or JMS.
Components are implementations of web services. You can use TIBCO ActiveMatrix BusinessWorks, Java, .NET, or Ruby to create the implementations of web services provided that these applications conform to the specifications that describe your web services. A common model used to describe the specifications of web services is the Web Services Definition Language (WSDL). However, there are circumstances when the service provider or the implementing applications cannot change the structure of the message format they are using, yet the client must conform to their specification. This is where mediation comes in. One of the things mediation does is translating the message into a format which can be understood by the receiving end.
References are external web services which provide operations you want to reuse as implementations of your own web services. Alternatively, you can refer to another composite within your AMX SOA project.
After creating the composite, you need to be able to run the web service by deploying it to logical and physical servers. Now that you have pieced all the components together in the circuit board, you need to make sure that these components will work harmoniously as a single unit. Deploying web services in AMX Administrator, which supports both graphical and command-line interfaces, is very simple and straightforward and takes less time to achieve.
First, you need to create a service assembly. A service assembly is simply a collection of composite, shared resources, connections, metadata, and other necessary files in your AMX SOA project. Think of it as a CPU composed of a motherboard, which is like a composite, together with other essential stuffs, to make the whole system working. The service assembly is compressed into a portable ZIP file which is uploaded to AMX Administrator GUI during deployment. You can create a service assembly by using a utility provided in TIBCO Business Studio, which is the main development tool for creating AMX SOA projects.
When you upload the ZIP file, AMX Administrator will automatically determine what components are present and are ready to be deployed in nodes. Nodes are instances of the Java Virtual Machine, which run containers, software that executes the code, and the messaging bus. Nodes are installed on a physical server and they can be started, stopped, and uninstalled anytime, while containers can either be activated or deactivated. You can deploy various components, which become service units during runtime, into multiple nodes for fault tolerance and load balancing. You can map several nodes to one service unit.
The environment lets you logically manage the nodes, the messaging bus, which can be one or more instances of the TIBCO Enterprise Message Service, and the connectors, containers, shared resources, and keystores contained in nodes. Shared resources enable services to connect with physical resources such as a JMS or an HTTP server. You can have one or more environments to enable and maintain system scalability and flexibility depending on system requirements. Environments also let you configure logging events for tracing errors easily and manage substitution variables or enterprise level variables which could potentially alter from one environment to another. Examples of these variables are queue destinations, service URLs, among others.
When it meets all the requirements for deployment, the service assembly now becomes deployable. On AMX Administrator, you can just simply click the Deploy button to deploy the service and after it is deployed, you can start the service. When the status changes to Running, your web service is now usable and ready to accept requests from service clients.
AMX Administrator GUI comes with monitoring and management tools such as dashboard, infrastructure, service, deployment, and log views which let you track the status, health, and performance of the AMX infrastructure and the services running on that infrastructure.
AMX Administrator also provides a utility that gives you an option to deploy services through the command-line interface. All you have to do is write build scripts which are in XML format and specify the deployment options with the target resources you want to execute. Scripting makes it easier and faster to deploy services especially if it requires you to deploy a lot of services into multiple nodes and environments. It also makes deployment possible for operating systems that don’t support GUI.
TIBCO ActiveMatrix simplifies the life cycle of web services and empowers you truly create SOA applications easily, rapidly and efficiently. With the accelerating adoption of SOA in enterprise applications, you can be assured that your business will realistically benefit in the long run from using this software. With absolutely shorter integration phases and quicker, zero downtime deployments, the TIBCO ActiveMatrix solution strongly brings business advantage and growth together to a much higher level.
|In this TIBCO video, you will learn about the different software products in the TIBCO BusinessEvents 4.0 suite. Unlike the TIBCO BusinessEvents 3.0 Enterprise Edition, the 4.0 version consists of numerous smaller software products. You pick and choose which product to use for your unique Complex Event Processing requirements.|
If you want an event to inherit the properties of another event, it is critical that neither events have properties with the same name. For example, if both EventA and EventB have a property called “Name”, then these events cannot be made to inherit the other.