EM Migration Guide PDF

Engagement Management
EM Migration Guide
Release Version: 15.3-FP7
Document Revision: 1.0
Unauthorised use, duplication, or modification of this document in whole or in part without the written consent of Verint Systems
Inc. is strictly prohibited. By providing this document, Verint Systems Inc. is not making any representations regarding the
correctness or completeness of its contents and reserves the right to alter this document at any time without notice. Features
listed in this document are subject to change. Contact your Verint representative for current product features and specifications.
All marks referenced herein with the ® or TM symbol are registered trademarks or trademarks of Verint Systems Inc. or its
subsidiaries. All rights reserved. All other marks are trademarks of their respective owners.
© 2018 Verint Systems Inc. All rights reserved worldwide.

EM Migration Guide
© 1992–2018 Verint Systems Inc. All Rights Reserved Worldwide.

Confidential and Proprietary Information of Verint Systems Inc.
All materials (regardless of form and including, without limitation, software applications,
documentation, and any other information relating to Verint Systems, its products or
services) are the exclusive property of Verint Systems Inc. Only expressly authorized
individuals under obligations of confidentiality are permitted to review materials in this
document. By reviewing these materials, you agree to not disclose these materials to any
third party unless expressly authorized by Verint Systems, and to protect the materials as
confidential and trade secret information. Any unauthorized review, retransmission,
dissemination or other use of these materials is strictly prohibited. If you are not authorized
to review these materials, please return these materials (and any copies) from where they
were obtained. All materials found herein are provided “AS IS” and without warranty of any
kind.
Verint Systems Inc. does not warrant, guarantee or make any representation regarding the
use or the results of the use of the information, links, tools, and materials in terms of the
accuracy, reliability, quality, validity, stability, completeness, currentness, or otherwise of its
content or products. The entire risk as to the use, results and performance of information,
links, tools and materials provided or referenced herein is assumed by the user. Verint
Systems Inc. shall not be liable for damages resulting from the use, misuse or unlawful use
of the information, links, tools, and materials contained or referenced herein.
Any third party technology that may be appropriate or necessary for use with the Verint
Product is licensed to you only for use with the Verint Product under the terms of the third
party license agreement specified in the Documentation, the Software or as provided online
at http://verint.com/thirdpartylicense. You may not take any action that would separate the
third party technology from the Verint Product. Unless otherwise permitted under the terms of
the third party license agreement, you agree to only use the third party technology in
conjunction with the Verint Product.
The Verint Systems Inc. products are protected by one or more U.S., European or
International Patents and other U.S. and International Patents and Patents Pending.
All marks referenced herein with the ® or ™ symbol are registered trademarks or trademarks
of Verint Systems Inc. or its subsidiaries. All rights reserved. All other marks are trademarks
of their respective owners.
Visit our website at www.verint.com/intellectualpropertynotice for updated information on
Verint Intellectual Property.
Document Revision 1.0
Published 03 December 2019
Customer Engagement Solutions™
Verint Engagement Management 1

EM Migration Guide
Contents
What is Migration? 4
Migratable Entities and Domains 5
Entity Dependencies 8
Case Type Dependencies 8
Dynamic Entity Definition Dependencies 9
Script Dependencies 9
Cross-Domain Dependency Examples 10
Administrator Migration Tasks 16
Making an Entity Migratable 16
Migrating Entities 17
Export Data 17
Import Data 21
Migration File Name 21
Migrating Case Types and Case Templates 22
Exporting Case Types or Case Templates 23
Importing Case Types or Case Templates 24
Migrating Updated Dynamic Content Entity Definitions 25
Migrating Dynamic Content 25
Migrating Rules Containing Queued Work Types 27
Developer Migration Tasks 30
Making Entities Migratable 30
Local Entities 30
Remote Entities 31
Replace and Revive 31
Entity Replacer/Revivers 32
Writing Field Replacer/Revivers for the Migration Framework 32
Changing the Behaviour of Field Replacers/Revivers 36
Adding an Entity Type to a Migration Domain 36
Child Entities 37
Migration Listeners 38
Importing Data from 3rd Party Systems 38
Migration Templates 39
Code Required to Generate Migration File 41
Importing and Exporting Using the Command Line 42
Migration Timeouts 44

EM Migration Guide
GTJson Summary 44

EM Migration Guide What is Migration?
What is Migration?
Migration is the transfer of data from one environment to another. For example, this can be
from a development environment to a testing environment or from testing to production.
Migratable data is the most commonly configured Entities, such as Case Types, Scripts,
Dynamic Entity Definitions and Knowledge Items.
These Entities are grouped into domains and data is migrated based on domain. Entities are
not migrated individually. You cannot choose to export a single Script, for example, instead
you would migrate its domain, in this case the Content domain. The exception to this is
Case types, which can be exported individually, although part of the Business Configuration
domain, you can choose to export all or a single Case Type.
The content of a domain does not always have to be exported in its entirety, it is possible to
export only recently changed data. This is useful for performing updates on an existing
system.
A major consideration when migrating data is dependencies between Entities. A Case Type
may have an action that runs a Script, which creates a dependency between these two
Entities. If you import the Case Type into a system that does not have the Script, then the
import fails at the validation stage.
Some Entity dependency relationships trigger the export of the dependency when the owner
is exported. The rules that control which dependencies are automatically exported are
covered in "Entity Dependencies" on page 8

EM Migration Guide Migratable Entities and Domains
Migratable Entities and Domains

The following Entities are migratable by a Business Administrator. All migratable Entities
are grouped into domains. To migrate an Entity, you must export its parent domain and
import the generated migration files into the target environment. All Entities in that domain
get migrated, although you can restrict the Entities exported to those that have changed
since a specified date.
The exception to the preceding migration rule is Case Types.

Although part of the Business Configuration domain, the
Manage Case Type screens allow you to export all Case Types
or a single Case Type.
Rules and Rule Sets can only be migrated from one

environment into another successfully if the Queue and Queued
Work Type non-migratable Entities are exactly the same on both
environments. For more information, see Migrating Rules
Containing QWT.
To make the migration of Rules effective in runtime, after the

migration of Rules the user must save all relevant Rule Sets
(Inbound, Outbound, Integration and Queues) that were defined
with the Rules, and resolve any validation errors.
The list of migratable Entities within each Domain is shown in the following table:

Domain List of Entities
Content l Assets
l Discovery Group
l Dynamic Content
l Email Form
l Embedded Site
l Exit Code
l Exit Code Case Action
l Exit Code Persistence Action
l Exit Code Wrapup Action
l Page Set
l Page Set Components Template
l Page Set Contact
l Page Set Page
l Popup Text
l Reference Info
l Reusable Page Fragments
l Tag
l Tagset
l Template
l Web Link
Business l Case Type

Configuration l Case Template
l Dynamic Entity Definition
l Dynamic Entity View
l Working Hours Calendar

Domain List of Entities
Knowledge l Content Format

Configuration l Content Source
l Index fields
l Pipeline
l Search Schedule
l Spidered Content type
l Stop Words
l Synonym Sets
When a migration is
performed on any of the
above Knowledge Entities,
the search web application
configuration data is
moved from the source
environment to the target
environment. Services are
used to retrieve the
configuration on export
and insert it into the target
environment on import. For
a File System Content
Source to be valid, the file
location must exist on the
target system.
Rules l Rule
l Rule Set

EM Migration Guide Entity Dependencies
Entity Dependencies
Due to their nature, complex Entities such as Case Types, Scripts and Dynamic Entity
Definitions have dependencies on other Entities. This means when these Entities are
exported, the Entities they depend on must also be exported along with it, or already be
present on the target environment, otherwise they cannot be imported correctly into another
environment.
In most cases, dependencies occur between Entities in the same domain. This relationship
means when you export an Entity, its dependencies are also brought along as part of the
export. However, Entities in different domains are generally not exported together, so where
dependencies occur across domains, you must migrate the Entities to another environment
separately.
The exception to this rule is a Dynamic Entity Definition (Business Configuration domain). It
has a dependency on a Script (content domain), so these are exported together.
The following sections show the dependencies for Case Types, Dynamic Entity Definitions,
and Scripts. For each, the section shows the Entities that get exported with the Entity and
those that do not, and so must be exported separately.
Case Type Dependencies

The following diagram shows the dependencies a Case Type can have and which Entities
are included when the Case Type is exported. Entities shown in red are not included as part
of the export but references to them are. This means it is expected that these Entities exist
on the target environment.

Dynamic Entity Definition Dependencies

The following diagram shows the dependencies a Dynamic Entity Definition can have and
which Entities are included when the Dynamic Entity Definition is exported. Entities shown
in red are not included as part of the export but references to them are.
Script Dependencies
The following diagram shows the dependencies a Script can have and which Entities are
included when the Script is exported. Entities shown in red are not included as part of the
export but references to them are.

Cross-Domain Dependency Examples

This section contains several examples of typical relationships between Entities across the
Business Configuration and Content domains. Each example provides a method of
migrating this data so that any dependencies between Entities are satisfied upon import into
the target environment.
Example 1 - Case Type and Page Set
In this example, a Case Type has an action that runs a Page Set, creating a dependency
between the Business Configuration and the Content domains. Due to the migration
dependency rules, if you export the Case Type, the Page Set does not get exported
along with it, instead, a pointer to the Page Set is created. If the Page Set exists on the
target environment, then the dependency is satisfied and the Case Type can be
successfully imported into the target environment. However, if the Page Set does not
exist on the target environment, it must be migrated across by exporting and then
importing the Content domain.

To migrate the Case type in this example:

1. Export the Content domain.
2. Export the Case Type.
3. Import the Content migration files into target environment.
4. Import the Case Type migration file into the target environment.
Example 2 - Case Type with dependencies on Dynamic Entity Definition and Page Set
In this example, a Case Type has an action that runs a Page Set and has a Dynamic
Entity Definition as an associated type, creating a dependency between the Business
Configuration and the Content domains.
If you export the Case Type, according to the migration dependency rules, the Dynamic
Entity Definition is exported along with the Case Type, as it is in the same domain, but
the Page Set is not. If the Page Set exists on the target environment, then the
dependency is satisfied and the Case Type can be successfully imported into the target
environment. However, if the Page Set does not exist on the target environment, it must
be migrated across by exporting and then importing the Content domain.
To migrate the Case Type in this example:

The generated migration file includes the Dynamic Entity Definition.
3. Import the Content migration files into target environment.
Example 3 - Case Type with a dependency on a Dynamic Entity Definition
In this example, a Case Type has an a Dynamic Entity Definition as an associated type.
As both Entities are in the Business Configuration domain, if you export the Case Type
the Dynamic Entity Definition is exported along with it.


The migration file also contains the Dynamic Entity Definition.
Example 4 - Case Type with dependency on a Dynamic Entity Definition which has a
dependency on a Page Set
In this example, a Case Type has an a Dynamic Entity Definition as an associated type,
which in turn has a view implemented by a Page Set. This creates dependencies
between the Business Configuration and Content domains. Normally, entities in different
domains are not exported together, however, an exception is made where a Dynamic
Entity Definition has a dependency on a Page Set. For more information, see Dynamic
Entity Definition Dependencies.
If you export the Case Type, the Dynamic Entity Definition and the Page Set is exported
along with it.

Example 5 - Case Type with dependencies on Dynamic Entity Definition and Page Set
In this example, a Case Type has two direct dependencies:

l With a Dynamic Entity Definition as an associated type.
l With a Page Set due to a Case Type Action running a script.

The Dynamic Entity Definition has a view implemented by a Page Set creating another
dependency.
When you export the Case type, only one of the Page Sets (PageSetB) are exported with
it. Due to the dependency rules, the Dynamic Entity Definition gets exported because it is
in the same domain. It brings along PageSetB, as this is one of the exceptions where
cross-domain entities do get exported together.
The other must be exported separately if it is not on the target environment.
If you migrate the Content domain, you migrate all the Page
Sets in that domain. When you import the Case Type
migration file, you reimport PageSetB, and simply overwrite
the first imported version of PageSetB that was imported as
part of the Content domain.

3. Import the Content migration file.
Example 6 - Page Set creates a case
In this example, a Page Set creates a case during execution as a result of an exit code
action, creating a dependency between the Content and Business Configuration
domains. Due to the Page Set export dependency rules, if you export the Page Set, the
Case Type does not get exported along with it, instead, a reference to the Case Type is
created. If the Case Type exists on the target environment, then the dependency is
satisfied and the Page Set can be successfully imported into the target environment.
However, if the Case Type does not exist on the target environment, it must be migrated
across by exporting and then importing the Case Type.

To migrate this data in this example:

1. Export Case Type.
2. Export Content domain.
3. Import Case Type migratable file into target environment.
4. Import Content domain migratable file.
Example 7 - Multiple Cross Domain Dependencies
In this example, a Case Type has a case action which sends an email using a template
and also runs a script (PageSetA), creating dependencies between the Business
Configuration and the Content domain. This Page Set embeds a view of a Dynamic
Entity. This Dynamic Entity has a view implemented by another Page Set (PageSetB).
If you try to migrate the Business Configuration domain, the Template and PageSetA
must exist on the target system, or you must migrate the Content domain to the target
system. However, if you try to migrate the Content domain, it fails due to the dependency
on the Dynamic Entity Definition in the Business Configuration domain. Therefore, for
this data to be migrated, you must export the Content domain and the Business
Configuration domains together to satisfy all dependencies.

1. Export the Business Configuration and Content domains together.
2. Import the migratable files into target environment.
Example 8 - Case Type has Dependency on Page Set with Multiple Content
Dependencies

In this example, a Case Type has a dependency on the Dynamic Entity Definition of an
associated type and a case action, which runs a script (PageSetB), creating a
dependency between the Business Configuration and the Content domain. The Dynamic
Entity Definition has a view implemented by another Page Set (PageSetD). According to
the dependency export rules, PageSetB is not exported but the Dynamic Entity Definition
and PageSetD are included in the migration file when you export the Case Type.
All other dependencies PageSetB has are within the Content domain and get included in
the migration file when this domain is exported.

3. Import the Content domain migration file into the target environment.
4. Import the Case Type migratable file into target environment.

EM Migration Guide Administrator Migration Tasks
Administrator Migration Tasks

A Business Administrator has the following capabilities:
l Make a new or existing Entity migratable on its Add or View/Edit screen.
l Export Data based on domain on the Manage Migration screen.
l Import migration archive files into an environment on the Manage Migration screen.
l Export Case Types, export all or a single Case Type from the Manage Case Type
screen.
Making an Entity Migratable

When a Business Administrator creates any of the following types of Entity, they have the
option to make them migratable. This means that it is possible to create Entities that are not
be exported when their parent domain is exported. For example, you can create Entities
used for testing that you do not want to migrate into a Production environment.
You are not able to export a domain if there are any

dependencies on Entities that are not migratable. For example, if
a migratable Case Type has a non-migratable Subcase, then an
error is displayed when you try to migrate the parent Case Type.
The migratable Entities are the following:

l Case Types
l TagSets
l Assets
l Templates
l Dynamic Content (Knowledge Content)
l Articles
l FAQs
l Alerts
l Uploads

l Dynamic Entity Definitions

l Scripts
l Exit Codes
l Emails Forms
l Pop-ups
l Scripts Contacts
l Reference Infos
l Script Web Links
l Script Templates
l Exit Code Actions
Migrating Entities
Some of the most commonly used Entities are migratable by a Business Administrator using
the Activities > Manage Migration screen. This screen allows an administrator to export
data based on domain, which is a grouping of similar types of entities. It also allows an
administrator to import data from a migration archive file, which can be a single JSON file, or
multiple JSON files packaged up in either a ZIP file or a JAR file.
When an entity is migrated from one environment to another, it is either of the following:
l Converted into a JAR or ZIP file containing an archive of JSON files for migration.
l It is migrated as a set of un-archived JSON files.
In either case, the JSON files that are used for the migration contain information relating to
the following:
l The entities that are being migrated.
l The fields that are associated with each entity.
l All child-entities that are subject of the migration, including their fields.
The JSON files that are generated during a migration contain JSON representations of each
exported entity. If a migrated entity is available throughout all locales, then the migration
JSON file contains one serialised entity of each locale.
Exporting Localised Entities
By default, an Entity is exported in all installed locales that it can be loaded in and all
Entities are written to the same JSON file. This behaviour can be changed by implementing
the getExportLocale() method of an Entity to just return the locale it is to be exported
in.
Export Data
The Export tab of the Manage Migration screen allows you to export data based on
domain. You can choose any combination of the available domains to export. You can also

specify a Migrate From date so that only Entities and dependencies that have changed
since that date are exported.
By default, when the export is complete, a JAR file is available to be downloaded.
Before performing the Migrate All action, Administration screens

must be closed to ensure that no data is edited during the export.
To export data:
1. Select one or more Domains to export the data from.
l Business Configuration - Includes Case Types, Dynamic Entity Definitions.
l Content - Includes Scripts, Tagsets, and Authored content.
l Knowledge Configuration - Includes Index Fields, Content Sources.
l Rules - Includes Rule and Rule Sets.

For a full list of Entities in each domain, see Migratable Entities and Domains.

2. Choose what to export from the selected domain.

l Migrate All - Exports everything in that domain. Close all Administration screens
before exporting with this option, so that no data is edited during the export.
l Migrate From - Exports only Entities that have changed since the specified date. This
behaviour applies to dependencies as well. Only dependencies that have changed
since the specified date are included, unless the dependency is an Asset.
For further information on using this feature, see "Exporting Data Using the Migrate
From Option" below.
If Knowledge Configuration is included in the selected

domains, the Migrate From option is not available.
3. Insert a Description, if necessary. This description is used in the manifest file if a JAR
file is generated.
4. Click Export to begin.
If the specified output type is a JAR file, a link to download the JAR file becomes
available on completion of the export, as shown in the previous screenshot.
Exporting Data Using the Migrate From Option

To make migration faster, you can limit the amount of data that is migrated depending on the
date it was last modified.
Setting the Migrate From date in the Manage Migration > Export screen allows you to limit
the amount of data that is migrated from migratable domains. The data is limited to a subset
of Entities and Entity dependencies from the chosen domains which have been edited since
midnight on the specified date.
For example, if you are exporting from the Business Configuration domain and you set a
Migrate From date of 2 November 2019, the JAR that is generated will only include Entities
and Entity dependencies from the Business Configuration domain that have a Last Modified
date after 2 November 2019.
If you are using the Migrate From option, we recommend that:
l It is best practice to set Entities as Migratable only when they are ready to be migrated.
l We recommend that the value entered as the Migrate From date is the date that the last
export was conducted. This is to ensure that the export includes all Entities that have
been modified since the last migration export.
l In the target environment, ensure that all previously exported JARs have been imported
before importing the latest migration JAR.

Using Migrate From with Entities that have Assets
If you use the Migrate From feature to migrate Entities which have Assets, such as images,
as immediate dependencies, then these Assets are migrated alongside the parent object.
Directly linked Assets are migrated regardless of the value of their Last Modified date or
Migratable flag. For example, if a migratable Knowledge Article contains an image which is
not marked as Migratable, that image is migrated alongside the Article.
Examples
Assuming that the following Entities and Assets exist in the Content Domain:
Entity A - An object that is Migratable, with a Last Modified date of yesterday.
Entity B - An object that is Migratable, with a Last Modified date of last year.
Asset A: An Asset that is not Migratable, with a Last Modified date of last year.
Asset B: An Asset that is Migratable, with a Last Modified date of last week.
Scenario 1
You migrate the Content Domain with a Migrate From date of yesterday.
Where:
Entity A directly references Asset A.
Result:
Both Entity A and Asset A are exported.
l Entity A is marked as Migratable and has a Last Modified date within the Migrate From
time frame, so it is exported.
l Asset A is not marked as Migratable, but it is directly referenced by Entity A, so it is
exported.
Scenario 2
You migrate the Content Domain with a Migrate From date of yesterday.
Where:
Entity A references Entity B which references Asset A.
Result:
Only Migratable A is exported.
l Asset A is not a direct dependant of Entity A, and is not marked as Migratable, so it is not
exported.

l Entity B does not meet the Last Modified date criteria and is not an Asset, so it is not
exported.
Scenario 3
You migrate the Content Domain with a Migrate From date of a month ago.
Where:
Asset A and Asset B are not referenced by any Entities.
Result:
Only Asset B is exported.
l Asset B is marked as Migratable and has a Last Modified date within the Migrate From
time frame, so it is exported.
l Asset A is not marked as Migratable and is not depended on by any Migratable Entities,
so it is not exported.
Import Data
The Manage Migration > Import tab is used to import entities into Engagement
Management. Each entity is imported into Engagement Management in JSON format and
may be imported as a single JSON file or multiple JSON files packaged up in either a ZIP
file or a JAR file.
Migration File Name

To import a migration JSON file the following naming convention must be used:
<entityDefinitionName>_<migratableReference>_<entityVersion>_
<locale>.JSON
where migratableReference is a unique identifier for an Entity and locale identifies
which locales the Entity is for.
For all Entities except Dynamic Content, the value for locale is ALL. If there is data for
multiple locales, it is contained in the same JSON file.
For Dynamic Content such as Articles and FAQs, the migration files are targeted at a
specific locale and contain data for that locale. The value of locale in the file name must
have the targeted locale specified.
Examples
l For Dynamic Content an example name is: DynamicContentED_
pGpBcMn1Ml0fp4MDRza526_0_en-GB.json
For a Case Type, an example name is: CaseTypeED_HelpDeskCaseED_0_ALL.json

Before performing an Import all action, Administration screens

must be closed to ensure that no data is edited during the import.
To import data:
1. On Manage Migration > Import, click Upload.
2. Use the file browser to select a JSON , a ZIP or a JAR file and click Confirm.
Each of the files to be imported are verified to ensure that any external references listed
as dependencies exist on the target system, or are being imported in one of the other
migration files.
l Any problems found with the file are reported.
l If verification is successful, a summary of the file contents is displayed, including the
number of entities found.
3. Upon successful verification, click Import to complete the process.
If an import is being performed against an entity that has

been modified in the target system, then the import only
replaces entities that have the same migratable reference. If
an import is performed multiple times, then the import
continues to overwrite entities that are being migrated.
The CCADMIN_IDMAP table is not updated with unique

entries when performing an import against a system. The
import works as if the imported entities had been created via
the user interface screens, using the ID generator rather than
the ID map.
Migrating Case Types and Case Templates

Engagement Management makes it easy for a Business Administrator to migrate Case
Types and Case Templates from one environment to another. The Manage Case Type
functionality provides an export mechanism which allows an individual Case Type or all
Case Types to be exported. As well as the Case Types themselves, any Entities they
depend on also get exported, with a few exceptions. For more information, see
Dependencies.
The Manage Migration screen provides the import mechanism for bringing Case Types and
their dependencies into the target environment.

A Business Administrator needs the Case Type Migration

entitlement to use the Manage Case Types screen to export
Case Types.
Exporting Case Types or Case Templates

Whether you choose to export all Case Types or an individual Case Type, use the Export
Case Type screen.
By default, when the export is complete, a JAR file is available for download.
The files generated as a result of the export depend on the

kernel.migration.saveasdirectory property. If true,
each Case Type is saved as a JSON file to the specified output
directory. If false, the JSON files are packaged in a JAR file.

Before performing the Export all action, other Administration

screens must be closed to ensure that no data is edited during
the export.
To export Case Types:

1. On the Manage Case Types screen either:
a. Export all of the Case Types by clicking Export All .
OR,
b. Export a single Case Type by selecting it and clicking Export .
The Export button is only enabled when a Case Type is selected.

Both actions display the Export Case Types screen.
2. Optionally, add a description which are added to the JAR manifest.

3. Click Export to perform the export operation.
To export Case Templates:

1. On the Manage Case Templates screen either:
a. Export all of the Case Templates by clicking Export All
OR,
b. Export a single Case Template by selecting it and clicking Export
The Export button is only enabled when a Case Type is selected.

Both actions display the Export Case Templates screen.
2. You can add a description which are added to the JAR manifest.
3. Click Export to perform the export operation.
As the export is performed, an indication of the progress is shown. When complete, if a
JAR file is the selected output format, a link is displayed to download the JAR file.
Otherwise, the exported files are available from the specified location.
Importing Case Types or Case Templates

Use the Manage Migration > Import tab to import Case Types and Case Templates.

To import a Case Type or Case Template:

1. Select the Manage Migration >Import tab.
2. Click File Upload and browse to the location of the migration file containing your Case
Type data.
Migrating Updated Dynamic Content Entity

Definitions
If you edit any of the following Dynamic Entity Definitions to add fields to your Dynamic
Content, then special precautions apply when migrating the updates:
l KnowledgeAlertED
l KnowledgeArticleED
l KnowledgeFAQED
l KnowledgeUploadED
You cannot migrate the Dynamic Entity Definitions from the Business Configuration domain
and the dynamic content from the Content domain together in this scenario. The updated
Dynamic Entity Definitions must exist on the target environment before any updated content
can be imported. Therefore, the Business Configuration domain must be migrated before the
Content domain can be migrated.
Migrating Dynamic Content

Knowledge Content, or Dynamic Content, which is marked as Migratable can be migrated to
and from Engagement Management using the Content Domain in the Manage Migration
screens. Only Knowledge Content that is in the Published or Pre-Published Workflow states
can be exported.
When migrating Knowledge Content, be aware of the following:
Prerequisites
The following Content Domain items require certain prerequisites for migration to be
successful:
l Stop Words and Synonyms: The appropriate language must be enabled on the target
server. For example, if you are migrating French Stopwords and Synonyms, the French
language must be unretired and enabled in the knlocale Tagset on the target server.
l Content Sources: Before migrating Content Sources, such as File System, WebCS or
Sharepoint, the target Engagement Management system must have access to the sites
and file system locations that need to be crawled. If the target system does not have
access to these resources, the import fails and rolls back.

Validation of the Knowledge Configuration JAR will not fail,

since at this step the application only checks to see if the files
are in the proper format and does not validate the accessibility
of the external resources.
Migrating Content Assets

When migrating Knowledge Content, any assets, such as images, files, or attachments that
are associated with the content are also migrated. Bear the following in mind when
migrating assets:
l Images that are inserted into Content must be marked as Migratable by the relevant
knowledge user when uploading the image to the repository.
If Content is migrated as a result of using the Migrate From

option on the Export screen, then Images which are inserted
in that Content are also migrated even if they are not marked
as Migratable. See "Using Migrate From with Entities that
have Assets" on page 20
l Attachments do not need to be manually marked as Migratable; they are automatically

migrated along with the Content Item they are associated with.
l Uploaded files are migrated if the Uploaded Content Item is marked as Migratable.
Migrating Content Assets with Individual Content JSON Files
Individual Content Item JSON files can also be imported into Engagement Management
using the Import tab on the Manage Migration screen. To import content which contains an
embedded image/upload/attachment file, the assets must be imported alongside the content.
1. The corresponding JSON for embedded image files must be present in the same
location as the content JSON and listed in the MANIFEST.MF file.
2. Asset files must be placed in a folder named RepositoryFiles alongside the JSON
files before importing the content. The RepositoryFiles directory must have the
following structure:
l For images: RepositoryFiles\asset\images
l For attachments: RepositoryFiles\email\outbound\attachments
l For uploads: RepositoryFiles\KM\files\uploaded
Migrating Content when the Author does not Exist

If the author of a Content Item does not exist in the target system, you can specify a user to
be the new owner as follows:

1. On the target system, create a user that is assigned the Knowledge Content Manager
Entitlement
2. In cre.properties, set the property
km.migration.dynamiccontent.import.username to the user name of the
new user.
3. When the content is imported, the contentOwner, publishedBy, and lastModifiedBy fields
on the Content Item are updated with the new user name.
Migrating Content with an Access Control List
If the Content Item has an Access Control list of Agents, Teams, Team Roles, Queues, or
Entitlements, these objects must exist on the target system before the import, otherwise the
import fails.
Migrating Rules Containing Queued Work Types

When migrating Rules that contain Queued Work Types (QWT), the migration is only
successful if the following are fulfilled:
l The migratable rule needs to exist on both environments.
l The QWT must use a migratable reference ID of Entities, which is a unique identifier.
If a QWT uses a non-unique identifier of Entities in their Rule

Editor, it becomes invalid after its migration.
To migrate rules without Non-Migratable Entities

On the Source machine:
1. Log in as an Administrator.
2. Select Activities > Manage Migration > Export Tab.
3. Select the Rules domain to migrate.

4. Click Export and download the rules migration JAR file.
On the destination machine:

2. Select Activities > Manage Migration > Import Tab.
3. Upload the rules migration JAR.
4. Select Activities > Rules Editor.
5. Verify and re-save the newly imported Rule.
To migrate rules with Non-Migratable Entities

If the Rules have Non-Migratable Entities, then use Rules Migration with SQL Initial Export.
2. Select Activities > Manage Migration > Export Tab.
3. Select the Rules domain to migrate.
4. Click Export and download the Rules migration JAR file.

5. Log in as a developer user.

6. Select Activities > Manage SQL Export > Export Initial Release.
1. Rebuild the database with test data for tables and samples.
2. Import the initial release that was exported in the preceding steps.
3. Restart the application server.
1. Create test data which can be migratable via Subsequent Export/Import.
2. Log in as Log in as an Administrator.
3. Select Activities > Manage Migration > Export.
4. Select the Rules Domain to migrate.
5. Click Export and download the Rules migration JAR file.
6. Log in as a developer user.
7. Select Activities > Manage SQL Export > Export Subsequent Release.
1. Click Import Subsequent Release using the release ID 2.
2. Restart the application server with the release ID 2.
Each time you export/import a subsequent release, update the

release ID.

EM Migration Guide Developer Migration Tasks
Developer Migration Tasks

Developers are able to perform the import and export migration tasks using the import-
data and export-dataccadmin commands. These commands allow the same
functionality as you can access through the graphical user interface.
Developers can also export data from a third party system and import it as Engagement
Management Entities using some built-in templates. For more information on this, see
Importing Data from 3rd Party Systems.
Making Entities Migratable

All migratable entities must have the IMigratable entity interface in their hierarchy.
The persistable fields required for migration are stored in the EVA_MIGRATABLE table.
The MigrationJSONReplacerReviver is generic and is used to replace and revive
non-migratable objects.
Local Entities
Making an Entity JSON Migratable:
1. Implement procedure listAllForExport.
2. Implement procedure listAllShallow.
3. Implement procedure loadDeep.
4. Ensure that EIMigrationUtil.populateMigrationFields() is called in the
loading process. For example, in loadShallow.
5. Add IInterchangeable to the list of interfaces which are extended by the migratable
Entity.
6. In the addPersistable procedure of the migratable Entity, set up the migratableReference
and typeName fields and call them EIMigrationUtil.convertToDBO.
For example,
this.migratableReference=GTSystem.createUuid();
this.typeName=this.ENTITY_DEFINITION_NAME;
PersistableList.add(EIMigrationUtil.convertTODBO(this));
7. Update the SecureDownloadConfig section in the

SecureHttpAcceptorConfig.xml to enable the downloading of the
migration.jar file.

Remote Entities
Remote Entities refers to Entities that are returned via Rest API. The process to make these
objects migratable is slightly different from objects which are stored in the Engagement
Managementdatabase.
Making a Remote Entity JSON Migratable
1. Add IInterchangeable and IMigratable to the list of interfaces which are being
extended by the remote migratable entity.
2. Implement the procedure listAllForExport.
3. Inside listAllForExport, call the static procedure
EIMigrationUtil.deleteByType and pass in the entity definition of the remote
entity as a parameter.
4. Inside listAllForExport, call the procedure which queries the Rest API for all of
the objects of this type, then add new entries for them to the EVA_MIGRATABLE table
using EIMigrationUtil.convertToDBO.
5. Implement the typeName and migratableReference fields on your object.
6. When the JSON is returned by the Rest API, you must set the
migratableReference field using a unique ID.
7. Implement procedure loadDeep unless there are no other objects attached to the
migratable object then simply call loadShallow.
8. Implement procedure saveDeep.
The import function relies on the saveDeep method being implemented. For remote
entities, there may be another method which is used to sent the created/edited object to
the Rest API. For example, contentSourceUtil.saveContentSource(). In this
case, saveDeep should call the method used to send the object to the Rest API.
Replace and Revive

To convert an object to and from JSON, replacer/reviver objects are used to specify the
serialisation/de-serialisation behaviour. There are two levels of replacer/reviver:
l Entity Replacer/Reviver: extends the BaseEntityReplacerReviver object and
defines methods for each field on an object where custom serialisation behaviour is
required.
l Field Replacer/Reviver: implements the IReplacerReviver interface and is
responsible for the serialisation and de-serialisation of a particular field of an object.

The replacer/revivers for Entities and Fields are registered in the EVA_MIGRATABLE_
REVIVERS table, which is used to look up the correct implementation object in the
repository.
Entity Replacer/Revivers
An Entity replacer/reviver overrides the default serialisation and de-serialisation behaviour
for each field of a particular Entity type. A replacer/reviver defines toJson and fromJson
methods for each field where custom serialisation behaviour is required. One of the most
common reasons for using custom serialisation methods is to include Entity reference and
dependency metadata.
To create an Entity replacer/reviver:
1. Create an object that extends
FrameworkEVA.API.Objects.BaseEntityReplacerReviver.
The naming convention is <EntityName>EntityReplacerReviver.
2. Insert an entry into the EVA_MIGRATABLE_REVIVERS table with the REVIVER_

PATH as the object's path and ENTITY_DEFINITION as the name of the Entity that the
replacer/reviver operates on. For Entity replacer/revivers, the REVIVER_NAME is null.
3. For each field that requires custom serialisation logic, create a pair of methods on your
Entity replacer/reviver:
toJson_[fieldName], this method is invoked when the named field is serialised to
JSON. The value of the field is passed in as an argument and the return value is written
out to JSON.
fromJson_[fieldName], this method is invoked when the named field is de-
serialised from JSON. The String value from the JSON is passed in as an argument and
the fields value is returned.
Writing Field Replacer/Revivers for the Migration

Framework
What is a Field replacer/reviver
A Field Replacer/Reviver is an object responsible for the serialisation and de-serialisation of
a particular field of an object. All Field Replacer/Reviver objects implement the
IReplacerReviver interface, which specifies a replace() method and a revive()
method.

The replace method is invoked during serialisation and is responsible for generating a
String to be included in the JSON. The replace method is also responsible for indicating
the nature of the relationship between the parent object and the field.
During de-serialisation, the revive method is invoked and passed the String from the
JSON file. The revive method is responsible for recreating the fields value, based on the
String from the JSON file.
Field Replacer/reviver Usage
Field Replacer/Revivers are typically invoked from the toJson_* and fromJson_*
methods of Entity Replacer/Revivers. The Replacer/Reviver is looked up using a key, and
the Reviver associated with this key is configured in the database.
Example Replace invocation (toJson_superEntityDefinitionId() on
CaseTypeReplacerReviver):
if (toReplace) {
return this.replace("superEntityDefinitionId",
toReplace);
} else {
return void 0;
}
Example Revive implementation (fromJson_superEntityDefinitionId() on

CaseTypeReplacerReviver):
return this.revive("superEntityDefinitionId", toRevive,

parent);
In this example the Replacer/Reviver lookup key is superEntityDefinitionId. The

implementation of the Replacer/Reviver can be found by looking for that key in the
REVIVER_NAME column of the EVA_MIGRATABLE_REVIVERS database table. The
REVIVER_PATH provides the fully qualified path of the Replacer/Reviver object.
List fields can be dealt with by calling this.replaceList() and this.reviveList
() instead. See toJson_recipientList() and fromJson_recipientList() on
CaseTypeReplacerReviver for an example.
The replace method is also invoked by the framework during the validation stage of the
import process, to ensure that Entity references can be resolved in the target system.
Creating a Field Replacer/Reviver
To create a new Field Replacer/Reviver, create an object that implements the
IReplacerReviver interface and add a row to the EVA_MIGRATABLE_REVIVERS
table that associates a lookup name with the repository path of the object.

The lookup name must indicate the type of field being replaced and also what it references,
for example, EntityDefinitionIDfor an EvaId field referencing an Entity definition,
EntityDefinitionNamefor a String that references an Entity Definition name, or
EntityDefinitionfor a field of type EntityDefinition.
Object Relationship Types
As well as dealing with serialisation and de-serialisation, Field Replacer/Revivers are
responsible for defining the type of relationship between a parent object and the field. This
relationship metadata is written to the JSON files during export and is used at import time by
the migration framework.
Each relationship consists of two pieces of information, a type and a value. The type is the
lookup name of the Replacer/Reviver associated with the relationship. The value is the
String returned by the replace() method during export.
There are two types of relationship which can be modelled:
l A Reference is a relationship to any other Entity. During import validation the migration
framework checks all the references in the migration metadata, by invoking the revive
method on the Replacer/Reviver associated with the reference. This verifies that all
referenced Entities exist on the target system before an import is invoked.
l A Migratable Dependency indicates a reference to another top level migratable Entity.
This is a specialised type of reference relationship, so all Field Replacer/Revivers that
add a Migratable Dependency also add a Reference. The dependency information is
used to control the import order of migratable Entities.
The following two sections cover how to write Field Replacer/Revivers for these relationship
types.
Reference Field Replacer/reviver
All Field Replacer/Revivers implement the IReplacerReviver interface. This interface
specifies the boolean field named addReferenceToMigrationManifest. If this value
is set to true, then the migration framework adds a reference to the migration metadata. In
most cases, the field must be given an initial value of true. This causes a reference to be
added whenever the value returned from the replace method is not null or undefined.
The value returned by the replace method is the same value which is passed into the
revive method during import. The value must contain enough information to load the
reference Entity on the target system.
For references to non-migratable Entities a system name for the Entity must be used as the
reference value. The system name used must be guaranteed to be the same on both the
source and target systems for the same Entity.
For references to migratable Entities, use the migratable reference as the value. References
that use the migratable reference for the value can be validated by the migration framework
doing a simple check against the EVA_MIGRATABLE table, rather than invoking the revive

method during validation. This makes it more efficient to validate references that use a
migratable reference.
The implementation of the revive method must return null to indicate that the reference
could not be loaded.
Migratable Dependency Field Replacer/reviver
Migratable Dependency Field Replacer/Revivers all implement the
IDependencyReplacerReviver interface. This interface extends
IReplacerReviver. Since a Migratable Dependency Replacer/Reviver is a specialised
type of Reference Replacer/Reviver, everything from the above section also applies to a
Migratable Dependency Replacer/Reviver.
The interface specifies three additional fields that are populated after the replace method
is called:
l migratableDependencyReference: This holds the migratable reference to the top-
level migratable Entity that is depended on. Here the “top level” term means that the Entity
is not an “owned” Entity and it gets its own JSON file in an export. The dependency value
is not necessarily the same as the reference value returned from the replace method. For
example, if an Entity references a Tag, the reference value points to the Tag, but the
dependency points to the TagSet to which the tag belongs.
l migratableDependencyReferenceType: This holds the type of Entity that is
depended on. This must be the Entity Definition name of the Entity depended on.
l exportDependency: This is used to control whether the Entity depended on is
exported or not. When this field is set to true,the migration framework triggers the
migration of the Entity referenced by the dependency. Some dependency relationships do
not force the dependency to the exported (for example, a Page Set that references a Case
Type) but the dependency is still required in the metadata, so that if multiple domains are
exported together, then the dependency metadata can still be used to ensure import
occurs in the correct order.
Extending MigratableDependencyReplacerReviver is the simplest way to
implement a Migratable Dependency Field Replacer/Reviver. The
generateMigratableReference method must to be overridden and must return the
migratable reference of the Entity depended on.
MigratableDependencyReplacerReviver can only be used when the reference
value is the same as the dependency value.
The revive method needs to be overridden when the replaced Field is not an Entity, for
example, for ID fields. In such cases, the implementation can call super.revive() and
then use the ID or System Name of the Entity returned.
The postRevivalOperations method must not be overridden and will likely be
removed from MigratableDependencyReplacerReviver at some point. If you need

to populate something else on the parent object after revive has been executed, then do
this in the persistence layer.
Recommendations for implementing Field Replacer/Revivers
Where possible, Field Replacer/Revivers must be associated with Fields holding the ID or
SystemName of an object, rather than an actual object instance Field. An exception to this is
where a list of objects must be replaced, because typically, the objects do not hold a
corresponding list of IDs or system names.
Changing the Behaviour of Field Replacers/Revivers

One of the functions of a Field Replacer/Reviver on an Entity is to determine whether its
data gets exported along with its parent Entity. This is determined by the
exportDependency boolean field. If this field is set to true, the data gets exported. If set
to false, the data is not exported and a reference to the Entity is created in the parent
migration file instead.
The value of this field has been set for each of the built-in migratable Entities according to
the rules defined in the Dependencies section. This section describes how to change this
behaviour.
All Entity and Field Replacers and Revivers are registered in the EVA_MIGRATION_
REVIVER table. This maps an implementation object in the repository with either a Field or
an Entity Replacer/Reviver. This allows you to change the behaviour of an Entity's Field
Replacer/Reviver by remapping it to another implementation.
You can create a new Field Replacer/Reviver object by defining the desired behaviour and
remapping the Field Replacer/Reviver entry in the database table.
To change the behaviour of the Field Replacer or Reviver
1. Copy the existing Replacer/Reviver to your custom module.
2. Change the value of exportDependency.
3. Update the entry for the Field Replacer/Reviver in the EVA_MIGRATION_REVIVER
table to point to your new implementation object.
Adding an Entity Type to a Migration Domain

To migrate an Entity as part of a domain, the Entity Type must be registered with the
migration framework by adding a row for the Entity Type in the EVA_
INTERCHANGEABLE_TYPE table. You can add your Entity Type to an existing domain, or
create a new domain containing just your Entity Type. Adding a row to this table for your
Entity Type results in your Entity Type being listed in the Manage Migration administration
screen under the domain that you have assigned it to.
The columns of the EVA_INTERCHANGEABLE_TYPE table are described below:

Column Description
ID A unique ID for the interchange type Entry.
IS_ENTITY_ Set this column to Y for all migratable Entities.

DEFINITION
SYSTEM_NAME The name of the Entity Definition.
NAME The name that appears for that Entity Type in the Manage
Migration screen.
DESCRIPTION The description that appears for that Entity Type in the Manage
Migration screen.
RELEASABLE Not used by the migration framework. This is only applicable if the
type can be exporting to SQL.
RELEASE_ID The current release ID.
SAVE_ORDER Must be set to NULL, unless you also need your type to be
exported to SQL using the SQL import/export mechanism.
JSON_ The name of the domain that the Entity belongs to. A domain does
MIGRATION_ not need to be created separately. Assigning an Entity type to a
DOMAIN new domain results in the Manage Migration screen showing the
domain.
JSON_ The order that this Entity Type is migrated in. The system migrates
MIGRATION_ them according to ascending numerical order by comparing the
ORDER values in this column.
IS_REMOTE If the Entity is remote, then migrate it using the REST API.
TENANT_ID The tenant ID for this data.
Child Entities
Child Entities, for example, Tag Entities in a TagSet Entity, differ from top-level migratable
Entities in that they are not added to a domain, but they are migrated depending on their
relationship with their parent Entity.
Adding an Entity type to a migration domain registers it as a top-level migratable Entity.
Child Entities can be exported as owned migratables or child Entities. If a child Entity can be
referenced by other Entities, for example, a Tag can be referenced by a Page Set, then it
must be exported as an owned migratable. Otherwise, it must be exported as a child Entity.

Owned migratables must implement the IMigratable interface and you always have the
migrationFlag field set to false, so that they are not exported as top-level Entities as
well. The parent Entity identifies its owned migratables to the framework by returning them
from the getOwnedMigratables() method.
Child Entities do not need to implement IMigratable. Registering an Entity
Replacer/Reviver for the child Entity type results in that Replacer/Reviver being used when
child Entities of that type are encountered during serialisation/de-serialisation. For example,
if a custom case action is created, which has a config Entity, custom serialisation/de-
serialisation behaviour can be specified for the config Entity by registering an Entity
Replacer/Reviver for the config Entity type.
How child Entities are exported, for example, Tag Entities in a TagSet Entity, depends on
the relationship with their parent. If a child Entity can be referenced by other Entities, for
example, a Tag can be referenced by a Page Set, then it must be exported as an owned
migratable. Otherwise, it must be exported as a child Entity.
Migration Listeners
The migration framework provides a mechanism to add custom behaviour, triggered by
migration import events. This is done by writing migration listener objects and registering
these with the migration framework. Migration listeners are notified of migration events
relating to the domain they are registered to.
Migration observers must implement the
FrameworkEVA.API.Interfaces.IMigrationObserver interface. This interface
specifies the callback methods that the migration framework invokes on the migration
listener.
To register an observer with the migration framework, an entry must be added to the EVA_
MIGRATION_LISTENERS table. This table has the following columns:
l REPOSITORY_PATH: The fully qualified repository path for the migration listener object.
l DOMAIN_NAME: The domain the listener received events for.
l INVOKE_ORDER: Controls the order that the listeners for a domain are invoked in. The
listeners are invoked from lowest to highest invoke order.
Importing Data from 3rd Party Systems

You may have data in other systems that correspond to Entities in Engagement
Management. For example, you may have sets of tags that you want to bring across.
Templates are available, used to map your data into JSON format, which can then be
imported in Engagement Management.
This section describes our recommended approach to importing data, which is to create a
Java class to build your data model and then pass it, along with the correct template, to a file

writer to generate the JSON file. For more information, see the example in Code Required to
Generate Migration File.
Migration Templates
Templates are used to import data from 3rd party systems. They define the structure of the
JSON for an Entity that the imported data must conform to if it is to be imported successfully.
Some templates are supplied which define the JSON structure for TagSets and Assets.
Other templates can be generated using the create-migration-template ccadmin
command, which can create templates for:
l Alerts
l Articles
l FAQs
l Uploads
For more information, see Generating Templates for Dynamic Content.
Templates are defined using FreeMarker, which is used to generate a text output based on
templates. The text output in this case is a JSON file. Each template is basically a JSON file
describing an Entity, with embedded FreeMarker syntax used to add placeholders for data
fields.

Template Location
The supplied migration templates and those generated are located at the following location:
<product.home>\resources\migration-templates
This location can be changed using the kernel.migration.templatelocation
system property.
Generating Templates for Dynamic Content

The ccadmin create-migration-template command is required to generate
templates for the following Entities:
l Alerts - KnowledgeAlertED
l Articles - KnowledgeArticleED
l FAQs - KnowledgeFAQED
l Uploads - KnowledgeUploadED
For example, ccadmin create-migration-template -
DentityName=KnowledgeArticleED
You must generate templates for these Entities because they represent dynamic content.
This restriction is because their structure is customisable - dynamic fields may have been
added to the basic Entity.
Running the ccadmin create-migration-template command determines if extra
fields have been added to the Entity. These fields are added to the migration template for
that Entity.

Migration File Name

To import a migration JSON file the following naming convention must be used:
<entityDefinitionName>_<migratableReference>_<entityVersion>_
<locale>.JSON
where migratableReference is a unique identifier for an Entity and locale identifies
which locales the Entity is for.
For all Entities except Dynamic Content, the value for locale is ALL. If there is data for
multiple locales, it is contained in the same JSON file.
For Dynamic Content such as Articles and FAQs, the migration files are targeted at a
specific locale and contain data for that locale. The value of locale in the file name must
have the targeted locale specified.
Examples
l For Dynamic Content an example name is: DynamicContentED_
pGpBcMn1Ml0fp4MDRza526_0_en-GB.json
l For a Case Type, an example name is: CaseTypeED_HelpDeskCaseED_0_
ALL.json
Code Required to Generate Migration File

Our recommended approach to importing data from third-party systems is to:
l Create a Java class to retrieve the data from the data store
l Write that data to a JSON file using the appropriate template.
See the following example, which pulls in two data objects TagSet and FrenchTagSet,
and writes it out to a JSON file whose name adheres to the required format.
The example below does the following:
Select the template.
Create an object and populate it with the Entity data from your data
store.

The data object must also contain values for the mandatory fields
localisedObjects and productVersion. The value of
localisedObject must be the name of the object containing the
data. LocalisedObject is used in the migration template to
reference the object data for Entity data to be localised. Currently,
this only applies to Tagsets.
For the other Entity types that templates are available for (Assets,
Articles, FAQs, Alerts and Uploads ) object must be used instead
of localisedObjects.
Pass the object along with the template to a file writer to create the
JSON file.
Example Code
Importing and Exporting Using the Command Line

Engagement Management offers command line applications that you can use to import and
export data to and from your application. These commands export files in JSON format. The
files can be packaged in a JAR file, or simply written to a specified location.
You must use the command line if you need to obtain JSON files, rather than a JAR file, to
commit to the version control system for your project.
import-data
Imports data from the specified location.

ccadmin import-data
Required argument:
l importLocation - the path to a JAR file, a ZIP file, or a directory containing JSON
files.
l If you specify a directory, only JSON files are imported. Any other file types are ignored.
export-data
Exports all the data from all or a specified domain.
ccadmin export-data
Optional arguments:
l domain - specifies the domain or domains to export.
Valid options for this argument are:
l single domain - "Content", "Business Configuration", or "Knowledge Configuration"
l multiple domains - "Content, Business Configuration, Knowledge Configuration"
l all domains - all
l if the domain not specified, the default is "all".
l fromDate - specifies the date to export changes from. The date should be in ISO 8601
format. If no date is specified, then all data from the selected domains are exported.
For example, fromDate=2013-03-12T10:00:00+0000
l exportLocation - specifies the export location. If specified, it overrides the location set
by the kernel.migration.storageLocation CRE property.
l exportType - specifies whether the the exported JSON files are packaged in a JAR
with manifest or simply saved in the specified directory. Valid values for this argument are
jar or file, where the default is file.
l description - supply a description that will be used in the JAR manifest.
l clearExportLocation - clears the export location if set to true prior to exporting
data. The default is false.
Example
The following example exports the Content and Business Configuration domains to a JAR
file.

ccadmin export-data -Ddomain="Content, Business Configuration"

-DexportType="jar"
Migration Timeouts
Migrating large amounts of data can take a while and as such, your normal time-out periods
may need to be increased to accommodate this.
Web Server Connection Timeout
If you encounter connection issues when importing large amounts of data, increase the
timeout for your web server.
Transaction Timeout
The commit of an import takes place within a transaction, which is managed by the
application server. If a large number of items are imported, increase the transaction timeout
configured on the application server to allow for the amount of time it takes to commit the
import. If the transaction timeout is breached, the import fails.
GTJson Summary
This object can convert an object into a json file and convert a json file into an object.
Extends: -
Fields
This object has no fields.
Procedure Signatures
- fromFile(fileName,excludedFields,replacer)
Creates and returns a GTObject representation of a json file
object parse(jsonString,excludedFields,replacer)
Converts json to an object.
object stringify(Obj,prettyPrint,excludedFields,replacer)
Converts an object to json format.
- toFile(fileName,Obj,prettyPrint,excludedFields,replacer)
Returns serialised json to the specified file.
fromFile()

This procedure creates and returns a GTObject representation of a JSON file, read from
a locale file.
Objects:
You can use this procedure with the following objects:
l GTJson
Syntax:
GTJson.fromFile(fileName,excludedFields,replacer)
Parameters:
This procedure takes the following parameters:
fileName string The JSON file which will be used to create the
GTObject.
excludedFields array An array of strings. If any of the strings in excludeFields

match fields in the jsonString, the returned GTObject
will not contain that field.
replacer object If replacer is an array of strings, then only the fields

specified will be displayed in the JSON result. If the
replacer is an object, it will look for all procedures on
the object which are of the form "toJson_"<fieldName>.
When Obj is converted to JSON, and a toJson method
in the replacer matches a field in the Obj, the outputted
JSON for that field will be the result of the toJson
procedure.
For example toJson_myDate(Date d) { return "a date
string" } - When a myDate field is encountered, the
toJson procedure is invoked which will result in the
JSON value for myDate being the string "a date string".
Return Values:
Returns a GTObject.
Exceptions:
This procedure does not throw any exceptions.
Example 1:

object = GTJson.fromFile("/home/user/json/example.json")
Parse the JSON which is stored in the specified file. The type of object created will be
what is specified in the ____TYPE metadata field within the JSON file.
Example 2:
object = GTJson.fromFile("/home/user/json/example.json",
excludesList)
Parse the JSON which is stored in the specified file. Any fields whose fieldnames match
an entry within the excludesList array will be ignored during the parsing process.
Example 3:
object = GTJson.fromFile("/home/user/json/example.json",
null, reviver)
Parse the JSON which is stored in the specified file. If during the parsing process, a
<field> is parsed and the reviver object has a fromJson_<field> procedure defined, then
the parsed value for the field will be the output of the execution of the fromJson_<field>
procedure.
parse()
This procedure returns a GTObject representation of a json string.

Objects:
You can use this procedure with the following object:
l GTJson
Syntax:
GTJson.parse(jsonString, excludedFields,replacer)
Parameters:
jsonString string The json string which will be used to create the
GTObject.

excludedFields array An array of strings. If any of the strings in

excludeFields match fields in the jsonString, the
returned GTObject will not contain that field.
replacer Object If replacer is an array of strings, then only the fields

specified will be displayed in the json result.
if replacer is an object, it will look for all procedures on
the object which are of the form "toJson_
"<fieldName>. When Obj is converted to JSON, and a
toJson method in the replacer matches a field in the
Obj, the outputted JSON for that field will be the result
of the toJson procedure.
e.g. toJson_myDate(Date d) { return "a date string" } -
When a myDate field is encountered, the toJson
procedure is invoked which will result in the JSON
value for myDate being the string "a date string".
Return Values:
Returns a GTObject.
Exceptions:
Example 1:
object = GTJson.parse(toRevive)
Parse the JSON in the toRevive parameter. The type of object created is what is
specified in the ____TYPE metadata field within the JSON file.
Example 2:
object = GTJson.parse(toRevive, excludesList)
Parse the JSON in the toRevive parameter. Any fields with fieldnames that match an
entry within the excludesList array will be ignored during the parsing process.
Example 3:
object = GTJson.parse(toRevive, null, reviver)

Parse the JSON in the toRevive parameter. If during the parsing process, a <field> is
parsed and the reviver object has a fromJson_<field> procedure defined, then the parsed
value for the field will be the output of the execution of the fromJson_<field> procedure.
stringify()
This procedure returns an object as serialised json.

Objects:
l GTJson
Syntax:
GTJson.stringify(Obj, prettyPrint, excludedFields,

replacer)
Parameters:
Obj object The object which is to be returned with searialised

json.
prettyPrint boolean If true, formatted json will be returned. If false,

unformated json will be returned.
excludedFields array An array of strings. If any of the strings match the

field in Obj or any child object, they will be removed
from the json result.


specified will be displayed in the json result
if replacer is an object, it will look for all procedures
on the object which are of the form "toJson_
"<fieldName>. When Obj is converted to JSON, and
a toJson method in the replacer matches a field in
the Obj, the outputted JSON for that field will be the
result of the toJson procedure.
Return Values:
Returns a GTObject.
Exceptions:
Example 1:
GTJson.stringify(object)
Returns a JSON string representation of the parameter object.

Example 2:
GTJson.stringify(object, true)
Returns a JSON string representation of the parameter object with a line break following
each coma and closing curly bracket.
Example 3:
GTJson.stringify(object, false)
Returns a JSON string representation of the parameter object in a single line.

Example 4:
GTJson.stringify(object, false, excludesArray)

Returns a JSON string representation of the parameter object in a single line. Any
fieldnames which are present in the excludedArray will not appear within the JSON
output.
Example 5:
GTJson.stringify(object, false, null, replacer)
Returns a JSON string representation of the parameter object in a single line. If there is a
<field> on the object parameter and the replacer object has a toJson_<field> procedure
defined, the output for the field will be output of the execution of the toJson_<field>
procedure.
toFile()
This procedure returns serialised json to the specified file.

Objects:
l GTJson
Syntax:
GTJson.toFile
(fileName,object,prettyPrint,excludedFields,replacer)
Parameters:
fileName string The name of the file where the serialised json is to
be sent.
object object The object which is to be saved as serialised json.
prettyPrint boolean If true, formatted json will be returned. If false,

unformated json will be returned.
excludedFields array An array of strings. If any of the strings match the

field in Obj or any child object, they will be removed
from the json result.


specified will appear in the json result
if replacer is an object, it will look for all procedures
on the object which are of the form "toJson_
"<fieldName>. When Obj is converted to JSON, and
a toJson method in the replacer matches a field in
the Obj, the outputted JSON for that field will be the
result of the toJson procedure.
Return Values:
Returns null.
Exceptions:
Example 1:
GTJson.toFile("/home/user/json/object.json", object)
Saves a JSON string representation of the parameter object to the specified file.
Example 2:
GTJson.toFile("/home/user/json/object.json", object,
true)
Saves a JSON string representation of the parameter object to the specified file with a
line break following each coma and closing curly bracket.
Example 3:
false)
Saves a JSON string representation of the parameter object to the specified file in a
single line.
Example 4:

false, excludesArray)
single line. Any fieldnames which are present in the excludedArray will not appear within
the JSON output.
Example 5:
false, null, replacer)
single line. If there is a <field> on the object parameter and the replacer object has a
toJson_<field> procedure defined, the output for the field will be the output of the
execution of the toJson_<field> procedure.

EM Migration Guide PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EM Migration Guide PDF

Uploaded by

Copyright:

Available Formats

Engagement Management

© 2018 Verint Systems Inc. All rights reserved worldwide.

© 1992–2018 Verint Systems Inc. All Rights Reserved Worldwide.

Verint Engagement Management 1

Confidential and Proprietary Information of Verint Systems Inc.

Verint Engagement Management 2

Confidential and Proprietary Information of Verint Systems Inc.

Verint Engagement Management 3

Confidential and Proprietary Information of Verint Systems Inc.

Verint Engagement Management 4

Confidential and Proprietary Information of Verint Systems Inc.

Migratable Entities and Domains

The exception to the preceding migration rule is Case Types.

Rules and Rule Sets can only be migrated from one

To make the migration of Rules effective in runtime, after the

Verint Engagement Management 5

Confidential and Proprietary Information of Verint Systems Inc.

Domain List of Entities

Business l Case Type

Verint Engagement Management 6

Confidential and Proprietary Information of Verint Systems Inc.

Domain List of Entities

Knowledge l Content Format

Verint Engagement Management 7

Confidential and Proprietary Information of Verint Systems Inc.

Case Type Dependencies

Verint Engagement Management 8

Confidential and Proprietary Information of Verint Systems Inc.

Dynamic Entity Definition Dependencies

Verint Engagement Management 9

Confidential and Proprietary Information of Verint Systems Inc.

Cross-Domain Dependency Examples

Verint Engagement Management 10

Confidential and Proprietary Information of Verint Systems Inc.

To migrate the Case type in this example:

To migrate the Case Type in this example:

Example 3 - Case Type with a dependency on a Dynamic Entity Definition

Verint Engagement Management 11

Confidential and Proprietary Information of Verint Systems Inc.

To migrate the Case Type in this example:

To migrate the Case Type in this example:

In this example, a Case Type has two direct dependencies:

Verint Engagement Management 12

Confidential and Proprietary Information of Verint Systems Inc.

To migrate the Case type in this example:

Example 6 - Page Set creates a case

Verint Engagement Management 13

Confidential and Proprietary Information of Verint Systems Inc.

To migrate this data in this example:

Example 7 - Multiple Cross Domain Dependencies

To migrate the Case Type in this example:

Verint Engagement Management 14

Confidential and Proprietary Information of Verint Systems Inc.

To migrate the Case type in this example:

Verint Engagement Management 15

Confidential and Proprietary Information of Verint Systems Inc.

Administrator Migration Tasks

Making an Entity Migratable

You are not able to export a domain if there are any

The migratable Entities are the following:

Verint Engagement Management 16

Confidential and Proprietary Information of Verint Systems Inc.

l Dynamic Entity Definitions