Upgrading from WSO2 CEP 4.1.0
This section provides information on how you can upgrade from WSO2 CEP 4.1.0 to WSO2 CEP 4.2.0. For more information on release versions, see the Release Matrix.
You cannot roll back the upgrade process. However, it is possible to restore a backup of the previous database so that you can restart the upgrade progress.
Preparing to upgrade
The following prerequisites should be completed before upgrading.
- Make a backup of the CEP 4.1.0 database and copy the
<CEP_HOME_4.1.0>
directory in order to backup the product configurations. - Download CEP 4.2.0 from http://wso2.com/products/complex-event-processor/.
Migrating configurations
Follow the procedure below to migrate configurations from CEP 4.1.0 to CEP 4.2.0.
Configurations should not be copied directly from CEP 4.1.0 to CEP 4.2.0 because some of th configuration files were updated with new properties between the two releases.
- Make the required changes in the datasource files in the
<CEP_HOME>/repository/conf/datasources
directory to make sure that they are configured as required. For more information, see Datasources. - Check the configurations in the following files in
<CEP_HOME>/repository/conf/data-bridge
directory for CEP 4.1.0, and apply the same changes in CEP 4.2.0.-
data-agent-config.xml
-
data-bridge-config.xml
-
Check the configurations in the following files in CEP 4.1.0, and apply same configurations in CEP 4.2.0.
Configuration File Location axis2.xml
<CEP_HOME>/repository/conf/axis2
axis2_client.xml
<CEP_HOME>/repository/conf/axis2
carbon.xml
<CEP_HOME>/repository/conf
master-datasources.xml
<CEP_HOME>/repository/conf/datasources
identity.xml
<CEP_HOME>/repository/conf
log4j.properties
<CEP_HOME>/repository/conf
registry.xml
<CEP_HOME>/repository/conf
catalina-server.xml
<CEP_HOME>/repository/conf/tomcat
web.xml
<CEP_HOME>/repository/conf/tomcat
If the Cipher tool was configured for CEP 4.1.0, check the configurations in the following files and apply the same changes in CEP 4.2.0.
Configuration File Location cipher-text.properties
<CEP_HOME>/repository/conf/security
cipher-tool.properties
<CEP_HOME>/repository/conf/security
- Check the configurations in the other files located in the
<CEP 4.1.0_HOME>/repository/conf
directory and apply the same changes to CEP 4.2.0. - If there are any third party libraries used with CEP 4.1.0 that you want to migrate, copy the following directories as applicable from CEP 4.1.0 to CEP 4.2.0.
- If you have used JMS libraries, JDBC libraries etc, copy
<CEP_HOME>/repository/components/lib
. - If you have used OSGi bundles such as SVN kit etc, copy
<CEP_HOME>/repository/components/dropins
.
- If you have used JMS libraries, JDBC libraries etc, copy
- Start the CEP 4.2.0 server. For more information, see Running the Product.
Migrating artifacts
All artifacts can be migrated from CEP 4.1.0 to CEP 4.2.0 via Composite Application Archive (CAR) files. For detailed instructions package artifacts as C-App archives, see Packaging Artifacts as C-App Archive.
You should manually deploy Composite Application Archive (CAR) files that you have in CEP 4.1.0 to CEP 4.2.0.
To migrate deployment artifacts:
Updating execution plans
WSO2 CEP 4.2.0 uses Siddhi 3.1.2 whereas CEP 4.1.0 uses Siddhi 3.0.5.
All Siddhi versions older than Siddhi 3.1.2 add a length window of size 1 for the initial stream of join queries. From Siddhi 3.1.2 onwards, a length window of size 0 is added. Therefore, once you migrate execution plans from CEP 4.1.0 to CEP 4.2.0, you need to manually add a length window of size 1 for the join queries as shown below (i.e. if you were relying on a length window of size 1 to be added by Siddhi in CEP 4.1.0).
e.g., The following query is included in an execution plan in CEP 4.1.0.
from TempStream[temp > 30.0]#window.time(1 min) as T join RegulatorStream[isOn == false] as R on T.roomNo == R.roomNo select T.roomNo, R.deviceID, 'start' as action insert into RegulatorActionStream;
When this execution plan is migrated to CEP 4.2.0, #window.length(1)
property should be manually added to it as shown below.
from TempStream[temp > 30.0]#window.time(1 min) as T join RegulatorStream[isOn == false]#window.length(1) as R on T.roomNo == R.roomNo select T.roomNo, R.deviceID, 'start' as action insert into RegulatorActionStream;
Migrating dashboard elements
This section covers the additional steps are required to migrate dashboard elements (i.e. gadgets and dashboards).
The Analytics Dashboard functionality in CEP 4.2.0 is powered by WSO2 Dashboard Server 2.1.0 whereas the same functionality in CEP 4.1.0 and earlier versions is powered by WSO2 Gadget Server 1.4.0. This section explains how to migrate the gadgets and dashboards from CEP 4.1.0 to 4.2.0.
There are two methods that can be used to migrate gadgets and dashboards between the two CEP versions.
- Deploying the gadgets and dashboards in a CAR file
- Migrating the dashboards and gadgets pointing your product home directory.
In both methods, the following two files are used to execute the migration.
File Name | Path | Description |
---|---|---|
ds-migration-1.0.x-2.0.x.bat or ds-migration-1.0.x-2.0.x.sh | <CEP_HOME>/migration/dashboards/migration-1.0.x-2.0.x | This triggers the execution of the migration |
migration.xml | <CEP_HOME>/migration/dashboards/migration-1.0.x-2.0.x | This contains the migration configuration that specifies the mode and user inputs. |
Click on the relevant tab depending on the method you want to follow.
Validating path changes
CEP 4.2.0 has a different directory structure to CEP 4.1.0 that affects the path to the gadget store as shown below.
CEP 4.1.0: <CEP_HOME>/repository/deployment/server/jaggeryapps/portal/store/<Tenant_Name>/gadget
CEP 4.2.0: <CEP_HOME>/repository/deployment/server/jaggeryapps/portal/store/<Tenant_Name>/<StoreType [fs/es]>/gadget
Therefore, if a gadget has relative paths included in its index.xml
file (
i.e. in the <CEP_HOME>/repository/deployment/server/jaggeryapps/portal/store/<Tenant_Name>/<StoreType [fs/es] >/gadget
/<GADGET_NAME>
path), you should check whether they are updated with the change in the directory structure. This check should be carried out after running the migration script.
e.g., A path is given as follows in the index.xml
file in CEP 4.1.0.
<script language="javascript" type="text/javascript" src="../../../../js/igviz.js"></script>
The same link should be given as follows in CEP 4.2.0 due to the change in the directory structure (i.e. an additional ../
should be added for the new directory added to the structure).
<script language="javascript" type="text/javascript" src="../../../../../js/igviz.js"></script>
Updating layout configurations
The dashboard layout configurations are defined in the index.xml
file. This file differs as follows based on the CEP version.
CEP Version | 4.1.0 | 4.2.0 |
---|---|---|
Location | <CEP_HOME>/repository/deployment/server/jaggeryapps/portal/store/<Tenant_Name>/layout/<LAYOUT_NAME> | <CEP_HOME>/repository/deployment/server/jaggeryapps/portal/store/<Tenant_Name>/ |
Indexing | 1 based indexing | 0 based indexing |
Format | { "blocks": [ { "id": "a", "row": 1, "col": 1, "size_x": 4, "size_y": 3 }, { "id": "b", "row": 1, "col": 5, "size_x": 4, "size_y": 3 }, { "id": "c", "row": 1, "col": 9, "size_x": 4, "size_y": 3 }, { "id": "d", "row": 4, "col": 1, "size_x": 4, "size_y": 3 }, { "id": "e", "row": 4, "col": 5, "size_x": 4, "size_y": 3 }, { "id": "f", "row": 4, "col": 9, "size_x": 4, "size_y": 3 } ] } | { "blocks": [ { "id": "a", "x": 0, "y": 0, "width": 4, "height": 3 }, { "id": "b", "x": 4, "y": 0, "width": 4, "height": 3 }, { "id": "c", "x": 8, "y": 0, "width": 4, "height": 3 }, { "id": "d", "x": 0, "y": 3, "width": 4, "height": 3 }, { "id": "e", "x": 4, "y": 3, "width": 4, "height": 3 }, { "id": "f", "x": 8, "y": 3, "width": 4, "height": 3 } ] } |
The layouts migrated from CEP 4.1.0 to CEP 4.2.0 will have the format in which layouts are saved in CEP 4.1.0. To make them compatible with CEP 4.2.0
- Replace
"size_x"
and"size_y"
attributes with"width"
and"height"
respectively. - Replace
"row"
and"col"
attributes with"x"
and"y"
respectively, and reduce their values by 1 to match the 0 based indexing.
e.g., { "id": "a", "row": 1, "col": 1, "size_x": 4, "size_y": 3 }
should be replaced with { "id": "a", "x": 0, "y": 0, "width": 4, "height": 3 }
.
Testing the upgrade
Verify that all the required scenarios are working as expected. This confirms that the upgrade is successful.