Upgrading Spaces to Support Multiple Instances of Connectors

Starting with version 5.17, Birst can connect to multiple instances of the same application. Instead of one connection per Application Connector, there can be multiple connections.

For example, you may need one connection to Salesforce for one set of data, and another connection for another set of data. Each instance uses one Birst application connection.

As a result of this improvement the Application Connectors user interface and underlying infrastructure has changed.

The new functionality and new UI automatically applies to:

All new spaces

All existing spaces that do not have any application connectors

Existing connections retain the previous UI and functionality until you decide to upgrade the space. Upgrading involves:

Automatically migrating the underlying infrastructure to the new version.

Automatically migrating the existing connection (or connections, if you have multiple connectors in the space) to the new version, including:

Connection details (name, type, API version, username, password, environment, site name, source file prefix)

Data source objects

Extraction groups

Extraction schedules (only schedules that use the current release version)

Displaying the information in the new user interface.

Depending on your implementation, migration may take a few minutes.

Prior to migrating

Do the following prior to production migration:

First migrate on a non-production system, then test to confirm the results before migrating your production system. In particular, test your extraction schedules.

For schedules:

Migrate your older release schedules (5.16, 5.15, etc.) to the current release. See To migrate Application Connector data processing schedules to the current release version.

Delete any remaining schedules that have older release versions than the current release.

Since the underlying tables will change, it is best that you delete any unused schedules.

Starting with 5.17.3, Birst checks to ensure that schedule names and times are unique within a space. Update any duplicate names or times.

To ensure that there is no processing during migration, temporarily disable your 5.17 or newer schedules.

It is best that there are no processing tasks in progress during the migration.

Avoid any space operations such as uploading data during the migration.

Important: Ensure that there are no extraction tasks in progress during the migration.

To migrate a space to support multiple connections

For each space:

Navigate to the Define Sources -> Application Connectors tab.

Click Migrate.

After migration

Restart any temporarily disabled schedules or processing tasks.

Note: Using the copyspace command to copy individual connector configurations is not supported after migration. However you can use the copyspace command to copy ALL of the connector configurations. See the copyspace command.

UPDATESFDC ETL Script Update

The UPDATESFDC ETL function now includes a statement to specify the connection name. For backward compatibility the default connection name set to "Salesforce".

If you upgrade and do not change the name of the connection ("Salesforce"), you do not need to make any additional changes. If you change the connection name, you must update the ETL script. See Writing Back to Salesforce Using ETL.