Apama Upgrade Path
|
Current Configuration |
Upgrade Path |
Changes |
|
This is a summary of key changes made in Apama 4.2, but it is not a complete reference. Please refer to the What’s New guide and the Migration Guide (available via ESD) for a comprehensive statement of all migration steps recommended to upgrade to Apama 4.2. |
||
|
Apama 4.1 |
Apama 4.2 |
With Apama 4.1, you had to limit the number of running contexts because of the way contexts were implemented. Apama 4.2 removes this constraint. The com.apama.scenario.SetThrottlingPeriod event is deprecated. Use the com.apama.scenario.ConfigureUpdates event type instead to control the output of Update (and other) events. You must re-compile all pre-4.2 correlator plug-ins before you can use them in 4.2 applications. However, in most cases there is no need for changes to the source code of a plug-in. Rarely, the occasional const may need to be added or removed. The Apama ODBC and JDBC adapters have been deprecated in Release 4.2. You should use the Apama Database Connector adapter (ADBC) instead. Note: If you are migrating from Apama 4.0 to Apama 4.2 See the 4.0 to 4.1 for additional requirements. |
|
MonitorScript 4.1 |
MonitorScript 4.2 |
New reserve keywords have been added to the list of Reserved Keywords. |
|
Custom adapters 4.1 |
Custom adapters 4.2 |
See Apama 4.2 comments |
|
Apama API 4.1 |
Apama API 4.2 |
See Apama 4.2 comments |
|
EventStore 4.1 |
EventStore 4.2 |
EventStore and Research Studio are Deprecated with this release. Use the ADBC Adapter with Apama Studio’s Data Player instead. See Migration guide for details on moving EventStore Data. |
|
Event Modeler 4.1 |
Event Modeler 4.2 |
While all pre 4.2 custom blocks will continue to work, they will need to be migrated to the new format to take advantage of the performance improvements provided with 4.2. This is a manual process. See Migration guide for details. The Database Retrieval and Database Storage blocks are deprecated in this release. Use the new ADBC Retrieval and ADBC Storage blocks. New, parallel enabled, versions of most blocks have been added in 4.2. The existing, non parallel enabled, versions of these blocks have been deprecated. |
|
StateStore 4.1 |
MemoryStore 4.2 |
The StateStore Correlator plug-in has been replaced with the MemoryStore. See Writing Monitorscript Applications, Using the MemoryStore for details. |
|
Dashboards 4.1 |
Dashboards 4.2 |
The Dashboard Studio deployment wizard has been moved into Apama Studio. Dashboard deployment options will need to be reset when running the new deployment wizard. The objects available in the Dashboard Studio palette have changed. Deprecated object in existing .rtv files will continue to function but will not be available in the palette for new dashboards. New objects have been added to the palette and should be used in new dashboards. |
|
Please see the Apama 4.1 Migration Guide (available via ESD) for complete details regarding upgrading to Apama 4.1. |
||
|
Apama 4.0 |
Apama 4.1 |
On Windows 32 the compiler is being changed from Visual Studio/C++ 2003 to Visual Studio/C++ 2008 SP1. Since these are not binary compatible, all 3rd party clients (including remote clients, Correlator Plugins, IAF Transport and Codec plugins), whether created by customers, by Progress Software Professional Services, or by Engineering, will need to be recompiled. No code changes are necessary. Apama 4.0.x tools and clients (including remote clients, Correlator Plugins, IAF Transport and Codec plugins), whether created by customers, by Progress Software Professional Services, or by Engineering, will be able to communicate with Apama 4.1 components, but only if they are run against the respective 4.0.x client runtimes. It is not possible for any 4.0.x client to be run against 4.1 runtimes. This applies to all platforms, not just on Windows 32. It is recommended that all clients be recompiled against Apama 4.1 client libraries. No code changes are necessary. Due to a change to the Correlator Plugin API, all Correlator Plugins will need to be recompiled against Apama 4.1. No code changes are necessary as this change is backwards compatible. This applies to all platforms. |
|
MonitorScript 4.0 |
MonitorScript 4.1 |
In MonitorScript, the 'action' namespace and the 'variable' namespace in monitors and events have been joined up. This means that you can no longer have actions and variables or event members with the same name. Any existing MonitorScript that has code which does not comply with the above restriction will fail to inject into the Correlator. An error message will make this clear. |
|
Custom adapters 4.0 |
Custom adapters 4.1 |
See Apama 4.1 comments |
|
Apama API 4.0 |
Apama API 4.1 |
The management API can now provide additional information with respect to the 'parallel contexts' inside a Correlator. Existing client code which receives this management information should continue working without modification, but will have to be modified to view and process the additional information. See Apama 4.1 comments |
|
EventStore 4.0 |
EventStore 4.1 |
Because of MonitorScript requirement, a minor change has had to be made to the EventStore event API. A field that was called "isExternal" has been renamed to "external". Any code which uses this API will need to be changed accordingly. |
|
Event Modeler 4.0 |
Event Modeler 4.1 |
All Scenario Manager scenarios which have been exported as blocks will need to be reloaded and re-generated with the Apama 4.1 Scenario Manager. Previously generated blocks from scenarios will not work because in some instances the automatically generated code violates the MonitorScript requirement. |
|
Please see the Apama 4.0 Migration Guide (available via ESD) for complete details regarding upgrading to Apama 4.0. |
||
|
Apama 3.0 |
Apama 4.0 |
The following 3.0 files are compatible with 4.0:
Because of the Apama 4.0 transport changes, Apama3.0 and Apama 4.0 components cannot communicate with each other. Because of the new Apama 4.0 directory structure, and the relocation of various files, you might have problems caused by no-longer-correct pathnames in scripts. If you add a bundle that represents a service or adapter that your 3.0 application used previously, the new bundle will contain files that conflict with files that you previously included in your build explicitly. You can eliminate this duplication by examining the build errors that Apama Studio generates. If you have a duplicate file in your project, right-click the project name in the Project View panel and select Apama Build Path > Exclude. This lets you exclude the duplicate from the build without removing it from the project. When you are sure that a file is available in a bundle that you added to the project, you can remove its duplicate from the project. In Apama 4.0 MonitorScript has a new keyword. If you use the context keyword as an identifier, it will result in a compilation error. In old applications, you might have some code for a feature that has become part of the product. Leave this code as is for now. Get your application running in 4.0, and then consider how best to remove the code that duplicates a product feature. Globally replace any occurrences of new MonitorScript reserved keywords. |
|
Developer Studio 3.0 |
Apama Studio 4.0 |
Before migrating application files to Apama Studio, create a backup of your files. To migrate to Apama Studio, you need to add your Apama 3.0 files to Apama Studio projects. You can do this in any of the following ways:
In Apama Studio, click the refresh button to see the changes. While the recommended directory structure is not required, you must be sure to leave the Bundles directory, if there is one, as is. If you brought an old Developer Studio project into Apama Studio, then you have launch configuration information that you need to upgrade. The recommendation is to redo the project’s launch configuration. To do this, in Apama Studio, select Run >Open Run Dialog and click the Components tab. You can now have multiple correlators so configuration is done separately for each correlator. Double-click the default correlator to reset your configuration parameters to what you had them as in 3.0. For existing scenarios, you need to register catalogs from old projects in Apama Studio since catalog management is done from within Apama Studio. The exception to this is when your application resides completely outside of Apama Studio. In this case, the old way of managing them directly in Event Modeler will be the same as before. In order to use 3.0 dashboard projects in Apama 4.0 use the Apama Studio Open Project> Import feature to import existing projects. Note that this does not copy any files to the Apama work directory. Optionally, you can copy your dashboard project into the dashboards directory of the Apama work directory. Then import the project into Apama Studio. After you import 3.0 files into a 4.0 project, you can no longer use that file in 3.0. |
|
Custom adapters 3.0 |
Custom adapters 4.0 |
Custom adapters must undergo minor code changes and be re-compiled due to the latency measurement framework feature. For example, there is a simple addition of a new parameter to some API calls. The static adapter configuration data has been moved into separate files. It is not a requirement for you to split your 3.0 custom adapter configuration files into static and dynamic files. However, the static/dynamic split does make adapter configuration much cleaner and makes updates to new versions of the adapter much simpler. The deprecated <batch> and <monitorscript> elements in IAF config files will now cause fatal errors, and that the default sense of the "inject" attribute on <event> elements has changed. |
|
Apama API 3.0 |
Apama API 4.0 |
You will need to update your application code to reflect changes to the Apama APIs. The What’s New in Apama 4.0 document provides a complete list of the API changes. Be sure to carefully read that section to learn about API changes. Then consult the documentation set to get complete information about each new or changed API. |
|
Apama Dashboards 3.0 |
Apama Dashboards 4.0 |
Apama 3.0 custom functions, commands, login modules, and authorities are compatible with Apama 4.0. To use them, copy Also copy You can use the new –O option to specify an options file on command line. For existing dashboards, if your old 3.0 .dashboard and OPTIONS.ini files have been copied into the dashboards directory in your 4.0 application, you can specify in the project launch configuration that you want to start the default dashboard, which will be determined automatically |
|
Research Studio 3.0 |
Research Studio 4.0 |
To use a 3.0 Research Studio project in Apama 4.0, copy After you save a file in an Apama 4.0 project, you can no longer use that file in Apama 3.0. |
|
EMM 3.0 |
EMM 4.0 |
You can use Apama 3.0 EMM configuration files in Apama 4.0. To do this, copy 3.0_SME_install_dir\etc\emm_state.dat to apama_work_dir\etc\emm_state.dat After you save this file in Apama 4.0, you cannot use it in Apama 3.0. |
|
EventStore 3.0 |
EventStore 4.0 |
Apama 3.0 .sim files and databases are compatible with Apama 4.0. |
|
Event Modeler 3.0 |
Event Modeler 4.0 |
The old Apama 3.0 web dashboards that were built from Event Modeler 3.0 are no longer available. Use Scenario Browser in Apama Studio to quickly test scenarios. With a little editing, you can use Event Modeler 3.0 configuration files with the 4.0 Event Modeler. This allows catalog settings and preferences to be carried forward. To upgrade your Event Modeler 3.0 configuration file: 1. Copy the etc\config.xml file from your 3.0 Event Modeler installation directory to the following location: 2. In the event_modeler_config.xml file, modify the entries for standard blocks and functions. The 3.0 entries look like this: For existing scenarios, you need to register catalogs from old projects in Apama Studio since catalog management is done from within Apama Studio. The exception to this is when your application resides completely outside of Apama Studio. In this case, the old way of managing them directly in Event Modeler will be the same as before. |
|
Dashboard Studio 2.4 |
Dashboard Studio 3.0 |
Run dashboard_management utility in order to update 2.4 Dashboard Studio (.rtv) files to 3.0: <install-dir>\bin\dashboard_management --update <rtv file | directory> If a specific file is specified, it alone will be converted. If a directory is specified, all the .rtv files in it and any sub-dirs will be converted. |
|
EventStore 2.4 |
EventStore 3.0 |
EventStore series need to be migrated by running esutil with the -u option: <install-dir>\bin\esutil -u <series name> This needs to be done for each series. |
