JDBC Backing Store
A backing store enables persistent backup of the objects generated and modified at runtime. Use of a backing store enables recovery in the event of a system-wide failure.
For instructions on migrating from the legacy Oracle Types (Oracle only) backing store to the JDBC backing store, see the migration chapters in TIBCO BusinessEvents Installation
The backing store feature requires use of Cache object management. Before you add a backing store, develop your caching solution and test it. Also ensure that your project ontology is completely configured.
- Use a separate schema and schema owner for each project, even if different projects use the same ontology (otherwise ontology conflicts can occur).
- If your project ontology changes after the backing store is in place, you must update the backing store schema. See Updating Existing Backing Store Schema .
The upper (blue) area in the diagrams shows TIBCO BusinessEvents Studio configuration tasks. The lower (yellow) area shows database setup utility tasks. The tasks shown map to task sections in this chapter.
For the simplest case where no additional project configuration is required (see Ontology Identifiers that Exceed the DBMS Maximum Column Length).
For more information see Ontology Identifiers that Exceed the DBMS Maximum Column Length.
- Backing Store Setup and Configuration
Setup refers to using the provided scripts to create the backing store schema for your project. - Ontology Identifiers that Exceed the DBMS Maximum Column Length
Entity names and entity property names are used by backing store scripts to generate database table and column identifiers. - Ontology Identifiers that Use Database Key Words
As well as database names that are too long, ontology terms that are key (reserved) words in your DBMS product must also be mapped to an alias. If errors occur when you run the SQL scripts due to key word clashes, examine the errors and add the appropriate words to the key word mapping file. - String Properties that Exceed the DBMS Maximum Column Length
The default column size for String type attributes is 255 characters. If you expect the data length of an entity property to exceed that value, then in the CDD file set the Max Length field for each entity’s properties The utility changes the data type of String attributes with long lengths to CLOB, as appropriate. - Install Prerequisites for DBMS Software
You must install prerequisites for the DBMS software before you begin to configure the backing store. - Configuring Your Machine for Windows Authentication
This authentication is only supported on Microsoft Windows operating systems. In order for TIBCO BusinessEvents to support Windows authentication when accessing SQL Server database, follow these steps: - Configuring Your Machine for Oracle Database
For configuring your machine for Oracle databse, you need to install OCI drivers. - Configuring CDD for Special Cases (As Needed)
This section summarizes CDD configuration that may be required to handle special cases. - Adding a JDBC Connection Resource (Now or Later)
Add a JDBC Connection resource to your project and configure it to connect to the backing store. You can do this before or after you configure the database itself. These settings are ignored by the setup utility during the database setup process. - Configuring Backing Store Settings in the CDD (Now or Later)
You can do the backing store configuration before or after you configure the database itself. These settings are ignored by the setup utility. - Building the EAR File
The EAR file is required when you run the database setup utility. Ontology information in the EAR is used to build tables in the database. - Initializing the Database and Generate Non-Project Tables
Ensure that you have done all earlier tasks that may pertain to your case. - Project-Schema-Specific SQL Scripts
You can do this task using a TIBCO BusinessEvents Studio wizard, or you can do it manually. - Aliases File and Project Schema Script
For every entity, property, or state machine whose database identifier name exceeds the database maximum length, a table name entry is created in the generated yourname.aliases file (for example, acme.aliases). - Configuring Aliases File and Project Schema Script
To configure aliases files and project schema scripts: - Updating Existing Backing Store Schema
If you change the project ontology, that is, if you create, alter or delete a concept or an event, you must update the backing store schema so it matches the updated ontology. In the case of changes in project ontology, you must update the backing store schema before you deploy the updated project. - What the Schema Update Utility Can Handle Automatically
You must examine the alter script before you run it. Decide what changes to make manually and what changes to make using the script, taking into account the kind of data in the tables. Entries that could result in data loss are commented. Remove or comment entries for changes you will make manually. - Backing Store Table Reference
The backing store uses relational tables and SQL data types for ease of maintenance. The SQL (DDL) scripts use ANSI SQL type definitions (where supported by the target DBMS product).