Signals Line Listing Review: Importing a Study exported from another Spotfire environment may fail.

Background:

A typical Line Listing Review (LLR) scenario with Spotfire and Medidata Rave is that the customer has a development environment and a production environment, and they have the same study and configuration settings in both. If configuration changes are needed, then typically the customer first applies changes in the Development environment and executes testing there, without impacting end users in Production. When the customer is ready, the Study and configuration are exported from Development and then imported into Production, to migrate the changes. Spotfire and LLR allow the customer to import the Study as a new version of an existing Study, or as a new Study. These steps result in Production having potentially new or removed data tables, domains, and keys, for both configuration and Study content.

Problem:

The export and then import of Studies between environments can be problematic when there are lots of changes, especially when domains (LLR categories such as AE, DM or LB) are added or removed or edited. If a data table has been removed or added in Spotfire, and the corresponding Domain has not been disabled or enabled in LLR, then the import may fail.

The error message below will be seen. It may look like the error is reporting a failed Automation Service job; that is just because the 'import Study' feature uses some of the AS code. It is actually an 'import' failure.

Task 1 'Signals Medical Review' failed with: Revvity.ClinicalAnalytics.Spotfire.Review.Domain.DomainException: Template Validation Error: Cannot find data table with name '<name_of_table >'

The below screenshot captures a relevant section from the LLR User Guide, which illustrates linkage with domains and tables of a Study.

If one or more domains gets disabled in the exported configuration (the source environment), then the import process may result in the target Study expecting one or more of the disabled domains to still be present (in the target environment). Such a problem will manifest as a failing Study Import action that cannot update a Study, based on current configuration settings. 

Solution:

If a Study Import operation fails due to this type of dependency, and the domain has been disabled in the exported Study configuration, then manually disabling the domain within the target to be updated might fix the problem. After disabling the domain in the Study (to match the import configuration), then it is necessary to re-attempt import of the Study.