Migrating to Unblu Spark 8

Because of the changes made to the configuration system, it isn’t possible to migrate directly from Unblu 6 to Unblu Spark 8. You must migrate to Unblu 7 first.

Earlier versions of Unblu provided an entry point to deliver JavaScript code, referred to as the "enterprise snippet", that initialized Unblu. This entry point was primarily intended for customers with on-premises application server deployments that used the SecureFlow Manager (SFM).

The enterprise snippet and the corresponding entry point have been removed in Unblu Spark 8. Customers that still use the entry point must adapt the configuration of the SecureFlow Manager to point to the URL of the Unblu visitor.js or visitor.min.js file instead.

Unblu Spark 8 drops support for version 3 of the Android and iOS mobile SDKs.

Earlier versions of the Unblu Collaboration Server could be deployed on-premises in two different ways:

Unblu Spark 8 no longer supports deployment on a Java application server. If you want to run Unblu on-premises, you must deploy it in a cluster.

The database versions Unblu Spark 8 runs on are different from those supported by Unblu 7. Review the list of supported database versions in Compatible databases before you start migrating.

MariaDB is no longer supported.

There have been a number of changes to the Floating and Embedded JS APIs:

You should review your use of the Unblu JavaScript APIs and make sure it’s compatible with version available in Unblu Spark 8.

Refer to the references of the Floating JS API and Embedded JS API for more detailed information.

Validating the URLs users are redirected to is an important feature that provides a minimum level of security when using Unblu. You can specify patterns to filter permissible redirect URLs with the configuration properties com.unblu.redirectFilter.black and com.unblu.redirectFilter.white. The order in which the lists are evaluated is specified in com.unblu.redirectFilter.order.

In Unblu Spark 8, the default order in which URLs are evaluated against the patterns has been reversed. The default value of com.unblu.redirectFilter.order is now WHITE_BLACK: the URL is first compared to the whitelist, then to the blacklist. URLs that pass the whitelist filter can thus still be blocked by the blacklist.

If you relied on the default value of com.unblu.redirectFilter.order for redirect validation, you must now explicitly set the property to BLACK_WHITE.

For more information, refer to Managing redirects in Unblu.

In version 7 of Unblu, onboarding, reboarding, and offboarding processes weren’t migrated if the conversation they were related to had to be migrated to a different cluster node. If a participant was in the middle of a process when their conversation was migrated to a different node, they had to restart the process. This was particularly annoying for lengthy boarding processes, possibly involving multiple bots.

In Unblu Spark 8, boarding process are migrated along with the conversation they’re related to. As a result, the following text and configuration properties are no longer needed and have been removed from the product:

With the introduction of version 4 of the Unblu web API, all dialog bots use outbound web API events instead of webhooks. Each event has its own response schema. Only the response schema for offer events, BotBoardingOfferResponse, has a well-defined body. For all other bot dialog events, you can respond with an empty JSON response.

For more information, refer to Dialog bots.

In earlier versions of Unblu, conversations received a copy of the configuration and text properties of the conversation template they were created from.

In Unblu Spark 8, you can specify whether conversations should inherit changes made to the configuration and text properties of the template they’re based on after the conversation was created.

During migration, this feature is enabled for all conversation templates. However, the feature is only applied to conversations created after migration. Conversations created before the migration aren’t affected. They retain the configuration and text properties that were copied from the template when they were created.

For more information, refer to Conversation configuration inheritance.

Unblu Spark 8 introduces new configuration entities for configuration and text properties. These configuration entities are then referenced by the entities that use the configuration. If two entities have the same configuration, they can reference the same configuration entity.

When you migrate from Unblu 7 to Unblu Spark 8, the new configuration entities are migrated and created dynamically in the background. There’s no additional step in the migration.

For more information, refer to New configuration entities.

Unblu 7 uploaded files with the content type multiform/data. Unblu 8 uses the content type application/octetstream instead.

If you have a web application firewall (WAF) rule in place to divert file uploads to another application, such as an antivirus scanner, that rule will no longer work with Unblu 8. Instead, you must implement and configure a file interceptor to process the uploaded file and return the result to Unblu Spark.

For more information on file interceptors, refer to File interceptors.

To log how the configuration properties are migrated, set com.unblu.logging.level.com.unblu.core.server.core.storage.configuration.ConfigurationObjectServiceHelper to TRACE.

The following enum values have changed:

Unblu Spark 8 includes version 4 of the web API. Compared to version 3, a number of endpoints have changed.

The following endpoints have been removed:

The following endpoints have been replaced:

For more detailed information, including about the differences between old and new endpoints, refer to the Unblu web API reference.