Design time activities performed using the BusinessEvents resources include building an ontology — a set of concepts, scorecards and events that represent the objects and activities in your business — and building rules that are triggered when instances of ontology objects that fulfill certain criteria arrive in events. The output of the design-time activities is an enterprise archive (EAR) file, ready to deploy (or configure for deployment as needed).
Studio is an Eclipse-based project building environment. It organizes project resources and makes the project organization and the project resources visible in graphical ways.
BusinessEvents Studio Development Provides resources for building BusinessEvents projects.
BusinessEvents Studio Debug Provides resources for debugging rules and rule functions in BusinessEvents projects.
BusinessEvents Studio Diagram Provides interactive graphical views of a project that allows you to see relationships between project resources and open editors for individual resources.
BusinessEvents Studio Decision Table Provides resources for building decision tables. (Available with TIBCO BusinessEvents Decision Manager.)
BusinessEvents Studio State Modeler Provides resources for building state models. It allows you to model states of ontology concept instances and use those states in rules. (Available with TIBCO BusinessEvents Data Modeling.)
TIBCO BusinessEvents communicates with TIBCO ActiveMatrix BusinessWorks through a provided plug-in that contains a palette of ActiveMatrix BusinessWorks Activities. Details are provided in
TIBCO BusinessEvents Developer’s Guide.
Administration of a deployed system involves management of objects generated by the inference engine, deploy-time configuration for tuning and other aspects of the system, deployment, management, and monitoring.
Your choice of an object manager depends on the need to persist objects generated by the rules executing in the inference engine. You can manage objects in memory only, or using a persistence database, or using a cache and backing store.
The recommended way to manage objects for most production needs is to use a cache and a backing store. When Cache Manager is used, agents of different types co-operate to provide efficient object storage and access, with options to use load balancing and fault tolerance of data and engine processes.
Object management is partly a design-time and partly an administration topic, because your choice of object management method can affect how you design rules. For example, you may have to retrieve objects if they are stored only in the cache or only in the backing store, so they can be used in the Rete network. See
Chapter 6, Object Management Options for an introduction to these topics.
The CDD editor enables you to define all the deploy-time properties for the entire cluster, from cluster-wide settings dealing with object management, through processing unit settings (that is, those at the BusinessEvents engine level), to agent class and agent instance settings. At deploy-time, you specify an EAR file, which contains project resources, and also a CDD file and a processing unit (a unit that deploys as an engine). The CDD defines all the deploy settings that apply to the specified unit. Thus, there is no need to maintain separate configuration files for each separate engine (processing unit), and you can change configuration settings without having to rebuild the EAR file. Deploy-time settings include object manager configuration, processing unit and agent class definition, specification of the channels and rules to enable for a a particular agent class, and what startup and shutdown functions to run.
If you will deploy using the BusinessEvents Monitoring and Management component (see next), then you will use the canvas-based site topology editor to configure the deployment topology. In the topology editor you configure deployment units that deploy to host machines, and you bind them to host machines. Each deployment unit contains one or more processing units (generally one), and each processing unit contains one or more agent classes. The processing units and agent class definitions are read from the CDD file, and you add deploy-time configuration settings.
BEMM can use the topology file definitions to manage the deployment — deploying, starting, stopping engines and so on. It also makes various methods available for controlling the deployment at different levels. You can also add more engines that are not predefined in the topology file and monitor and manage them (but you can’t restart them using BEMM).
BEMM can also monitor the health of the deployment, based on health metric and alert thresholds you configure and display the metrics using a web-based graphical UI. It can send out email when certain conditions occur or take other action. BEMM has a profiler and can generate other helpful reports. BEMM monitoring features enable you to easily spot bottlenecks or other troublespots in the system so you can address any issues.