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.

Unblu Spark 8 requires a search database such as OpenSearch or Elasticsearch. Refer to the unblu-kubernetes-base migration checklist for information on available templates and documentation.

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.

Running Unblu Spark 8 in standalone mode now requires Java 21.

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. Some of these changes affect how the JavaScript APIs are imported and accessed, that is, the global entry point. Others affect elements of the APIs themselves.

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, dialog bots, external messengers, custom actions, and message interceptors use the outbound request mechanism (ORM) instead of webhooks.

Each request type has its own response type or types, depending on the outcome of the request. For more information, refer to the schema descriptions in the Unblu web API reference.

In the case of dialog bots, only the response type for offer events, BotBoardingOfferResponse, has a well-defined body. You can respond to all other bot dialog events with an empty JSON object {}. For more information, refer to Dialog bots.

For more information on the outbound request mechanism, refer to The outbound request mechanism (ORM).

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: