Migrating from Earlier Versions : Overview of Migration of 3.x Projects

Overview of Migration of 3.x Projects
Direct migration from 3.0.0 and after to the current release is supported. After importing the 3.x project into BusinessEvents Studio, some manual steps will be required due to the changes in architecture.
Direct migration from versions earlier than 3.0.0 is not supported. First migrate to the latest 3.x version, then migrate from 3.x to 4.x.
This section explains some key points to help you understand the migration steps.
Runtime Properties are Configured in the CDD File
3.x Configuration
In 3.x (and earlier), runtime properties were set using individual properties set in one or more TRA files. In some cases, runtime properties were set in TIBCO Designer, specifically in the BAR resource, and some were set in the TIBCO Designer TRA file.
4.x Configuration
Now only JVM-level properties (those that need to be used before the engine starts up) are set in the be-engine.tra file. Properties that were set in the TIBCO Designer TRA file (designer.tra) are now generally set in the studio.tra file:
BE_HOME/studio/eclipse/configuration/studio.tra
In 4.x, runtime properties and other deploy-time settings are configured using a structured XML file called the Cluster Deployment Descriptor (CDD). A multi-tab editor in BusinessEvents Studio enables easy maintenance of this file.
In the 4.x architecture, you can’t select what resources to include in the EAR file. This means that the EAR now includes all project resources and can be very large. During runtime however, the resources are enabled (filtered) through the CDD Agent Classes and Collections tabs.
Also in the CDD, you configure processing units that reference the agents you want to include in one engine at runtime. At deploy time you specify which processing units to deploy.
CDD file
The CDD file provides fields for all commonly used settings, and it has property sheets where you can add other properties as needed. The property sheets are available at various levels, cluster, engine, and agent) so that you can scope the effect of the property appropriately.
When you import a 3.x project into BusinessEvents Studio, a CDD file is created using all known properties that can be automatically migrated. You must also check to ensure all properties are migrated. You may have to add some properties manually. Some properties are not relevant in the 4.x product, and additional properties not used in 3.x have been added to the product.
See Property Migration Reference for a list of 3.x runtime properties and their equivalent in 4.x.
Preloading of Entities is Configured in the CDD and has been Simplified
If you use the preloading feature to load objects from the backing store into cache, you may have to reconfigure your settings. Configuration is done only in the CDD file now, and the logic of inclusion and exclusion has been simplified.
Metadata Properties (Extended Properties) Not Used for Preloading
The following settings have been removed from entity metadata properties (also known as extended properties):
All Engine Types and Agent Classes are Now Configured in the CDD File
In 3.x agents were configured using individual properties in the TRA files. Each TRA file provided the configuration for one engine.
In 4.x you configure all the engines you need to deploy in a single CDD file. When you deploy an engine, you specify the PU to use.
Some agents and processing units are created for you based on information available. After you import the project into BusinessEvents Studio, edit the CDD file to fully configure the agents and engines (processing units) as needed.
Use of the JDBC Backing Store is Recommended
It is recommended that you use the current backing store implementation, the JDBC backing store. The JDBC backing store works with more DBMS products than the legacy Oracle-only backing store. It also has a more human-readable schema.
The legacy Oracle-only backing store is deprecated.
See Migrate the Backing Store Implementation and Backing Store Data for more details.
Migrating TIBCO BusinessEvents Decision Manager Projects
If you use the TIBCO BusinessEvents Decision Manager add-on, you must follow a procedure to import the 3.x decision project (containing the decision tables) after you import the related 3.x TIBCO Designer project. See the TIBCO BusinessEvents Decision Manager User’s Guide for details.
Check Deprecated Features in Release Notes
As a part of upgrading it is important to check the deprecated features list in the Release Notes document and take action accordingly.
Various engine properties that were used in earlier versions are no longer used. See no longer used is provided in properties
Migration Summary Procedure
Use this chapter and referenced documentation as needed to complete your migration. In summary, the steps are as follows:
1.
2.
3.
Import the TIBCO Designer (3.x) project into BusinessEvents Studio. Note that if your project contains ActiveMatrix BusinessWorks or TIBCO Adapter resources, plan to use two projects, one for the TIBCO Designer resources and one for BusinessEvents.
4.
In BusinessEvents Studio select Project > Validate to validate the project and then review the issues in the Problems tab and in the Error Log tab.
5.
6.
For above actions, see Other Post Import Actions for more details.
7.
Finally, rebuild the EAR files and deploy. See TIBCO BusinessEvents Administration for documentation on deployment options in 4.x.