Administration Overview

The TIBCO BusinessEvents Administration guide explains how to prepare for deployment. It also explains how to deploy, monitor, and manage the runtime application.

Before you begin to use TIBCO BusinessEvents Administration, gain a basic familiarity with the product by completing the tutorials in TIBCO BusinessEvents Getting Started, and read TIBCO BusinessEvents Architect’s Guide.

Building EAR Files for Deployment

Deployment requires project Enterprise Archive (EAR) files, which are considered as an input for administrative tasks. For more information on EAR files, see Enterprise Archive (EAR) Files.

You can build EAR files as follows:

Deploy-Time Configuration

System level configuration is generally needed. Edit the engine TRA file to add and set values for settings that are read before the engine starts.

Custom Functions and Third-Party Jars at Deploy-time

With all methods of deployment, ensure that certain files are available at run time. If your project has JAR files for custom functions or third-party software, manually copy them to the runtime location. Copy them to a location on the classpath of the deployed application. The recommended location is the BE_HOME/lib/ext/tpcl directory. If you choose a location that is not in the classpath, then update the classpath in the TRA file to include the location.

At run time the software uses the classpath set in the be-engine.tra file to locate the libraries (third-party libraries and custom function libraries) needed to execute the code. Ensure that you have added all the classpaths needed before you deploy. For example, you must update the classpath to specify the locations of libraries for TIBCO Enterprise Message Service, TIBCO Rendezvous, third-party software, and custom functions.

Business Rules Deployment Directory Property

Before deploying a business rule and starting the engine, set the property be.cluster.ruletemplateinstances.deploy.dir in the Cluster Deployment Descriptor (CDD), be-engine.tra, or in a .properties file. The property specifies the directory from which the engine loads business rules for the specific project. During startup, the engine reads the business rules from the specified directory and loads them into all the rule sessions. Ensure that the directory is local to the machine on which the engine is running. To avoid conflicts, the deployment directory specified should not contain business rules for other projects.

Deployment

The output of a design-time project is one or more EAR files and one or more CDD files.

For details on configuring and building these files, see Enterprise Archive (EAR) Files.

An EAR file deploys as one TIBCO BusinessEvents processing unit (engine). A processing unit can either contain one cache agent, or it can contain one or more agents of other types. Processing units and agents are defined in the CDD file.

When you deploy an EAR, you specify the CDD file to use, and you specify which processing unit class to deploy.

You can deploy in these ways:

Overriding Global Variables at Deploy Time

All methods of deployment enable you to override global variables at deploy time. For design-time procedures relating to global variables see "Working with Global Variables" in TIBCO BusinessEvents Developer’s Guide.

Hot Deployment

You can configure your TIBCO BusinessEvents engine to allow you to replace the EAR file without shutting down the engine. This is known as Hot Deployment.

Management and Monitoring

Depending on your method of deployment, you can use either TIBCO BusinessEvents Enterprise Administrator Agent or TIBCO Administrator (with TIBCO Hawk) for monitoring and management:

Authentication and Authorization

Certain components use authentication (TIBCO BusinessEvents Decision Manager). Currently, only TIBCO BusinessEvents Decision Manager uses authorization (access control).

Cluster Startup and Shutdown

There are only two main points to keep in mind for orderly system startup and shutdown:

Start storage-enabled agents (cache agents) first
 When Cache OM is used, you must start a node that has storage enabled first. In production systems that would be a dedicated cache agent engine. In test deployments, this could be another type of agent node with cache storage enabled.
Stop other engines before storage-enabled agents (cache agents)
 In unusual situations where all cache agents are stopped but engines running other types of agents are running, restart all engines.