Unknown macro: {next_previous_links}
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

This section provides information on how you can upgrade from WSO2 BAM 2.5.0 to WSO2 DAS 3.0.0. For more information on release versions, see the Release Matrix.

WSO2 DAS is not backward compatible with WSO2 BAM

The artifacts of WSO2 DAS are not backward compatible with the artifacts in WSO2 BAM due to the major differences in the architecture between the two products.

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.

Upgrading the database

The instructions in this section describe how you can perform a data migration to upgrade the BAM 2.5.0 database for use in DAS 3.0.0.

  1. Before you upgrade to DAS 3.0.0, create a new database and restore the backup of the BAM 2.5.0 database in this new database.

    Note

    You should NOT connect WSO2 DAS to an older database that has not been upgraded.

  2. Select the relevant script for the upgrade from here and run it on the new database. Running this script will ensure that the new database is upgraded to have the additional tables and schemas that are required for WSO2 DAS 3.0.0.

    Note

    There are three migration scripts available:  migration-service-provider.sql , migration-identity.sql and  migration.sql. However, only the  migration.sql script is required to be executed for the DAS database upgrade.

Migrating the configurations

Handling event flow related configurations

Configurable objects used for realtime processing in WSO2 DAS are different to those in WSO2 BAM as explained in the table below. Therefore, they need to be manually reconfigured instead of migrated.

Artifact Type in BAM  

Replaced in DAS ByNoteRecommended Action
  • Input Event Adapter
  • Event Builder
Event Receiver

The Event Receiver artifact in DAS 3.0.0 embeds both the Input Event Adapter and Event Builder artifacts in BAM 2.5.0.

Identify the input event adapters and event builders used in combination in BAM 2.5.0, and redefine them as event receivers. For detailed instructions, see Configuring Event Receivers.

  • Event Stream
N/AThe Event Stream artifact in DAS is different to that in BAM since a DAS event stream can be a real time event stream or a persistent event stream, whereas BAM event streams are always defined for persistent data.

Redefine the event streams in DAS 3.0.0 using the following procedure.

  1. Log into the WSO2 BAM Management Console, and go to the Main tab.
  2. Under Registry, click Browse to open the Browse page.
  3. Navigate to <Top_Folder>/system/governance/StreamDefinitions/<relevant_event_stream>/<relevant_stream_version> as shown in the example below.
  4. Click on the stream version. This will open the Detail View tab for the event stream version you selected.
  5. Click Display as Text to view the event stream configuration as a JSON array.
     
  6. Copy the JSON array to the clipboard.
  7. Log into the DAS Management Console and go to the Main tab.
  8. Click Streams to open the Available Event Streams page.
  9. Click Add Event Streams to open the Define New Event Stream page.
  10. Click switch to source view.
  11. Clear the existing text in the source view and paste the JSON array you copied to the clipboard.
  12. Click Add Event Stream.
  13. If you want the event stream to persist events, follow the instructions in Persisting Data for Batch Analytics.

Alternatively, you can redefine the complete event stream configuration as described in Understanding Event Streams and Event Tables.

  • Output Event Adapter
  • Event Formatter
Event PublisherThe Event Publisher artifact in DAS 3.0.0 embeds both the Output Event Adapter and Event Formatter artifacts in BAM 2.5.0.

Identify the output event adapters and event formatters used in combination in BAM 2.5.0, and redefine them as event publishers. For detailed instructions, see Creating Alerts.

  • Execution Plan
N/A

The Siddhi Query Language in DAS 3.0.0 is different to that in BAM 2.5.0.
Therefore, the Siddhi queries of an execution plan directly migrated from BAM cannot function in DAS 3.0.0.

Redefine the execution plans in DAS 3.0.0.

For detailed instructions on defining execution plans, see Creating a Standalone Execution Plan and Creating a STORM Based Distributed Execution Plan.

For the modified Siddhi Query Language, see Siddhi Query Language.

Migrating events

Run the <DAS_HOME>/bin/analytics-migrate.sh script to migrate events from WSO2 BAM to WSO2 DAS. For detailed information, see Analytics Migration Tool.

Handling scripts

Scripts that analyze data in WSO2 BAM are written in the Apache Hive query language whereas the scripts in WSO2 DAS are written in the Apache Spark query language. Therefore, the syntax of the scripts differ in WSO2 BAM and WSO2 DAS. Due to this, scripts cannot be directly migrated from WSO2 BAM to WSO2 DAS.

Recommended action

Redefine the required scripts in WSO2 DAS in the Spark query  language. For detailed information on writing queries in the Spark query language, see Spark Query Language.

Handling dashboards and gadgets

The BAM Dashboard in WSO2 BAM is replaced with the Analytics Dashboard in WSO2 DAS. Since the two dashboards and their gadgets are configured differently, dashboards and gadgets cannot be directly migrated from WSO2 BAM to WSO2 DAS.

Recommended action

Redefine the required dashboards and gadgets in the Analytics Dashboard.

Migrating artifacts

BAM toolbox functionality is not available in DAS. Therefore, it is not possible to migrate a toolbox from BAM to DAS. If you need the artifacts in a BAM toolbox for a particular user case, you need to create a corresponding C-App and deploy it in DAS. For more information on creating and deploying C-Apps, see Packaging Artifacts as a C-App Archive.

Testing the upgrade

  1. When the database upgrade scripts are executed, the following are some of the new tables that will be created in the database:
    • UM_DOMAIN
    • UM_SYSTEM_USER
    • UM_SYSTEM_ROLE
    • UM_SYSTEM_USER_ROLE
  2. Verify that all the required scenarios are working as expected. This confirms that the upgrade is successful.
  • No labels
Unknown macro: {next_previous_links2}