This article describes how ServiceNow users can migrate from the Flexera Integration App to the newer Flexera One App.
For users of Flexera One's IT Visibility capabilities who are also ServiceNow customers and have previously installed the Flexera Integration ServiceNow app, this article explains how to install the newer Flexera One ServiceNow app and migrate your existing data. Prerequisites, migration steps, details about the data migration for native tables, and known issues are presented in the sections below:
NOTE: Reach out to your Flexera representative or to Flexera technical support if you require assistance with the prerequisites or the migration process.
Before beginning the migration process, review the following prerequisites:
Follow the steps below to install the Flexera One App in your ServiceNow instance.
Once the Flexera One App is completely installed, follow the instructions in the next section to setup the connection to Flexera One API endpoints. Then proceed to execute the migration script.
Once the Flexera One App is installed in your ServiceNow instance, you must setup the connection to Flexera One servers.
NOTE: Only one active connection is permitted at a time. You cannot create multiple active connections.
Setting | Description |
---|---|
Name | Name of the connection. |
Endpoint | Connection endpoint for Flexera One APIs. This value is auto-populated by the system; however, the correct endpoint is different for different regions. Use the endpoint value that matches your organization’s region: North America—https://api.flexera.com Europe, Middle East, and Africa—https://api.flexera.eu Asia Pacific—https://api.flexera.au |
OAuth Token URL | URL required to fetch the Access Token. This value is auto-populated by the system; however, the correct URL depends on your organization’s region. Use the URL that matches your organization’s region: North America—https://login.flexera.com/oidc/token Europe, Middle East, and Africa—https://login.flexera.eu/oidc/token Asia Pacific—https://login.flexera.au/oidc/token |
Refresh Token | Refresh token value generated by Flexera. |
Resource Path | API path to establish the connection. This value is auto-populated by the system. Replace <org_id> with the Org_ID Flexera assigned to your organization. |
Organization ID | Your organization's Org_ID assigned by Flexera. |
When you complete the Connection Setup settings, continue with the steps for executing the migration script.
The migration script you execute in the steps below is included in the ZIP archive linked to this KB article: Flexera One Migration (from 5.1.2 to 1.1).zip.
If the migration script executes successfully, and you have verified the results, it is safe to uninstall the Flexera Integration App.
When the Flexera One App has been installed and the migration script successfully run, you can safely uninstall the Flexera Integration App from your ServiceNow instance.
NOTE: This step is not required to complete the migration process; however, the removal of the Flexera Integration App will help keep the ServiceNow instance uncluttered.
With the uninstall of Flexera Integration, the migration process is complete. Additional details about the data migration for native tables and known issues are captured at the end of this article.
The following data migration notes provide additional information on how data migration is done for native tables.
When end user selects Retain tables and data while uninstalling the Flexera Integration application, all the data related to Flexera Integration would reside in the instance and below are the fields details:
Column Label | Column Name |
---|---|
Country |
country |
Company ID |
x_fls_flexera_fnms_company_id |
Symbol |
x_fls_flexera_fnms_symbol |
Data token |
x_fls_flexera_fnms_data_token |
Website |
website |
Is deleted |
x_fls_flexera_fnms_is_deleted |
Normalized phone number |
x_fls_flexera_fnms_normalized_phone_number |
Normalized country |
x_fls_flexera_fnms_normalized_country |
Is Software |
x_fls_flexera_fnms_is_software |
Tier |
x_fls_flexera_fnms_tier |
Name |
name |
Normalized city |
x_fls_flexera_fnms_normalized_city |
City |
city |
Normalized website |
x_fls_flexera_fnms_normalized_website |
Data source |
x_fls_flexera_fnms_data_source |
Phone |
phone |
When the Migration script scheduled job runs, it copies the Technopedia ID value from the Flexera Integration App to the Technopedia ID value in the Flexera One App.
Once the migration process is completed the Company table, if you run the snapshot job process, and it pulls records from Flexera IT Visibility while inserting/updating records in the core_company table, ServiceNow Robust transform uses Technopedia ID as a coalesce. Hence we already populated Technopedia ID using the migration script. So when the robust transform searches for an existing Technopedia ID, it will update the record if transform process found the record in core_company or else insert the new record if no record exist.
When end user selects Retain tables and data while uninstalling the Flexera Integration application, all the data related to Flexera Integration would reside in the instance and below are the fields details:
Column Label | Column Name |
---|---|
Technopedia ID |
x_fls_flexera_fnms_flexera_id |
Model number |
model_number |
Full name |
full_name |
Data token |
x_fls_flexera_fnms_data_token |
Data source |
x_fls_flexera_fnms_data_source |
Model categories |
cmdb_model_category |
Short description |
short_description |
Name |
name |
Manufacturer |
manufacturer |
When the Migration script scheduled job runs, it copies the Technopedia ID value from the Flexera Integration App to the Technopedia ID value in the Flexera One App.
Once the migration process is completed the Hardware Model table, if you run the snapshot job process, and it pulls records from Flexera IT Visibility while inserting/updating records in the cmdb_hardware_product_model table, ServiceNow Robust transform uses Technopedia ID as a coalesce. Hence we already populated Technopedia ID using the migration script. So when the robust transform searches for an existing Technopedia ID, it will update the record if transform process found the record in cmdb_hardware_product_model or else insert the new record if no record exist.
When end user selects Retain tables and data while uninstalling the Flexera Integration application, all the data related to Flexera Integration would reside in the instance and below are the fields details:
Column Label | Column Name |
---|---|
Lifecycle Type |
lifecycle_type |
Source |
source |
Lifecycle Phase |
lifecycle_phase |
Technopedia ID |
x_fls_flexera_fnms_technopedia_id |
Model |
model |
Data Token |
x_fls_flexera_fnms_data_token |
When the Migration script scheduled job runs, it copies the Technopedia ID value from the Flexera Integration App to the Technopedia ID value in the Flexera One App.
Once the migration process is completed the Hardware Model Lifecycle table, if you run the snapshot job process, and it pulls records from Flexera IT Visibility while inserting/updating records in the cmdb_hardware_model_lifecycle table, ServiceNow Robust transform uses Technopedia ID as a coalesce. Hence we already populated Technopedia ID using the migration script. So when the robust transform searches for an existing Technopedia ID, it will update the record if transform process found the record in cmdb_hardware_model_lifecycle or else insert the new record if no record exist.
When end user selects Retain tables and data while uninstalling the Flexera Integration application, all the data related to Flexera Integration would reside in the instance and below are the fields details:
Column Label | Column Name |
---|---|
Technopedia ID |
x_fls_flexera_fnms_technopedia_id |
Data Source |
x_fls_flexera_fnms_data_source |
Webpage |
webpage |
Manufacturer |
manufacturer |
Name |
name |
Data Token |
x_fls_flexera_fnms_data_token |
When the Migration script scheduled job runs, it copies the Technopedia ID value from the Flexera Integration App to the Technopedia ID value in the Flexera One App.
Once the migration process is completed the Software Publisher table, if you run the snapshot job process, and it pulls records from Flexera IT Visibility while inserting/updating records in the samp_sw_publisher table, ServiceNow Robust transform uses Technopedia ID as a coalesce. Hence we already populated Technopedia ID using the migration script. So when the robust transform searches for an existing Technopedia ID, it will update the record if transform process found the record in samp_sw_publisher or else insert the new record if no record exist.
When end user selects Retain tables and data while uninstalling the Flexera Integration application, all the data related to Flexera Integration would reside in the instance and below are the fields details:
Column Label | Column Name |
---|---|
Software category |
software_category |
Edition |
edition |
Name |
name |
Version condition |
version_operator |
Technopedia ID |
x_fls_flexera_fnms_flexera_id |
Full name |
full_name |
End of life date |
end_of_life_date |
Publisher |
manufacturer |
Data source |
x_fls_flexera_fnms_data_source |
Product |
product |
Data token |
x_fls_flexera_fnms_data_token |
Version |
version |
Major |
major_version |
GA release date |
ga_release_date |
Edition condition |
edition_operator |
Display name |
display_name |
When the Migration script scheduled job runs, it copies the Technopedia ID value from the Flexera Integration App to the Technopedia ID value in the Flexera One App.
Once the migration process is completed the Product Model table, if you run the snapshot job process, and it pulls records from Flexera IT Visibility while inserting/updating records in the cmdb_software_product_model table, ServiceNow Robust transform uses Technopedia ID as a coalesce. Hence we already populated Technopedia ID using the migration script. So when the robust transform searches for an existing Technopedia ID, it will update the record if transform process found the record in cmdb_software_product_model or else insert the new record if no record exist.
When end user selects Retain tables and data while uninstalling the Flexera Integration application, all the data related to Flexera Integration would reside in the instance and below are the fields details:
Column Label | Column Name |
---|---|
Phase Start Date |
start_date |
Lifecycle Type |
lifecycle_type |
Source |
source |
Lifecycle Phase |
lifecycle_phase |
Product |
norm_product |
Version |
norm_version |
Edition |
norm_edition |
Description |
description |
In case of Software Product Lifecycle, Migration script uses Description field from Flexera Integration and splits Technopedia ID from that field, after split and grab the Technopedia ID and then copy it in Technopedia ID field of Flexera One Integration. Hence, our Migration script copied the Technopedia ID, the next step is to execute Snapshot job process of Software Technopedia Lifecycle Dataset.
Highlighted in yellow is the Technopedia ID that script extracts from description field of Flexera Integration and copied it in Technopedia ID field of Flexera One Integration and the record will look like:
Once the migration process is completed for Software Product Lifecycle table, if you run the snapshot job process, and it pulls records from Flexera IT Visibility while inserting/updating records in sam_sw_product_lifecycle table, ServiceNow Robust transform uses Technopedia ID as a coalesce. Hence we already populated Technopedia ID using the migration script. So when the robust transform searches for an existing Technopedia ID, it will update the record if transform process found the record in sam_sw_product_lifecycle or else insert the new record if no record exist.
When end user selects Retain tables and data while uninstalling the Flexera Integration application, all the data related to Flexera Integration would reside in the instance and below are the fields details:
Column Label | Column Name |
---|---|
Product classification |
function_type |
Product |
prod_name |
Flexera Product Revision |
x_fls_flexera_fnms_flexera_product_revision |
Data Source |
x_fls_flexera_fnms_data_source |
Product Component |
x_fls_flexera_fnms_product_component |
Data Token |
x_fls_flexera_fnms_data_token |
Product type |
product_type |
Publisher |
publisher |
Software Product data in the Flexera Integration App has no Technopedia ID. To successfully run the Migration Script, the system needs Technopedia ID as a coalesce or else duplicate records may be generated in Target tables.
Retrieve Technopedia ID:
Once you start execution of the scheduled job, “Flexera One Migration 1.1”, the migration script executes the Software Technopedia job to bring in Software Product Technopedia ID data.
Once the migration process is completed for Software Product table, if you run the snapshot job process, and it pulls records from Flexera IT Visibility while inserting/updating records in samp_sw_product table, ServiceNow Robust transform uses Technopedia ID as a coalesce. Hence we already populated Technopedia ID using the migration script. So when the robust transform searches for an existing Technopedia ID, it will update the record if transform process found the record in samp_sw_product or else insert the new record if no record exist.
When end user selects Retain tables and data while uninstalling the Flexera Integration application, all the data related to Flexera Integration would reside in the instance and below are the fields details:
Column Label | Column Name |
---|---|
Manufacturer |
manufacturer |
OS Service Pack |
os_service_pack |
Serial number |
serial_number |
Operating System |
os |
CPU count |
cpu_count |
Normalized Model Number |
x_fls_flexera_fnms_normalized_model_number |
RAM (MB) |
ram |
OS Version |
os_version |
Disk Space |
disk_space |
Normalized CPU Speed |
x_fls_flexera_fnms_normalized_cpu_speed |
Normalized OS Version |
x_fls_flexera_fnms_normalized_os_version |
Flexera fnms flexera unique ID |
x_fls_flexera_fnms_flexera_unique_id |
Data token |
x_fls_flexera_fnms_data_token |
Is deleted |
x_fls_flexera_fnms_is_deleted |
Most recent discovery |
last_discovered |
CPU core count |
cpu_core_count |
Normalized CPU Manufacturer |
x_fls_flexera_fnms_normalized_cpu_manufacturer |
Flexera ID |
x_fls_flexera_fnms_flexera_id |
CPU manufacturer |
cpu_manufacturer |
Data source |
x_fls_flexera_fnms_data_source |
Normalized CPU Name |
x_fls_flexera_fnms_normalized_cpu_name |
Name |
name |
OS Domain |
os_domain |
Model ID |
model_id |
Normalized Operating System |
x_fls_flexera_fnms_normalized_operating_system |
CPU name |
cpu_name |
Normalized OS Service Pack |
x_fls_flexera_fnms_normalized_os_service_pack |
Normalized Manufacturer |
x_fls_flexera_fnms_normalized_manufacturer |
Last logged in user |
x_fls_flexera_fnms_last_logged_in_user |
Normalized Hardware Model |
x_fls_flexera_fnms_normalized_flexera_hardware_model |
CPU speed (MHz) |
cpu_speed |
To map data into the Flexera One Computer table, the IRE process is used while transforming data into the target table. For example, the process uses the Identification rule on Hardware table to decide which data needs to be inserted/updated into native tables according to the conditions below:
For example, if customer runs the initial load of Snapshot Job and Hardware Inventory dataset starts processing but there is no record present in Source table, then Hardware ID cannot be not used to identify the existence of records in Computer table. So, IRE uses Serial Number to identify the record and, if record is present with Serial Number, performs an update operation. If no record found with Serial Number, IRE returns NO MATCH and does a look up with the Name field.
Flexera One Job process does not allow insertion of records with same Serial Number. If you check the computer table after running the Job, there is no entry with multiple Serial Number and Name. So, if Flexera Integration contains multiple entries with same Serial Number, then Flexera One updates only one entry. The rest become Stale after some time.
Below are IRE Input and IRE Output payload processing samples:
//IRE Input Payload
{
"items": [
{
"className": "cmdb_ci_computer",
"values": {
"virtual": "false",
"fqdn": "computer-266677.enterprise",
"name": "computer-266677",
"os_domain": "enterprise",
"serial_number": "6NK1311LXM",
"company": "934b1c8787c2e91011a0b259dabb35c0",
"model_number": "8000 SFF",
"model_id": "f15bd0c787c2e91011a0b259dabb35e6",
"cpu_count": "1",
"ram": "3715.239936",
"manufacturer": "934b1c8787c2e91011a0b259dabb35c0"
},
"sys_object_source_info": {
"source_feed": "Hardware Inventory",
"source_name": "FlexeraOne",
"source_native_key": "2147c365-c215-489a-b558-703b89af2f25"
},
"internal_id": "2147c365-c215-489a-b558-703b89af2f25",
"settings": {
"updateWithoutSwitch": "false",
"updateWithoutUpgrade": "false",
"updateWithoutDowngrade": "false"
},
"sys_ire_info": {}
},
{
"className": "cmdb_ci_computer",
"values": {
"fqdn": "computer-18575.enterprise",
"name": "computer-18575",
"os_domain": "enterprise",
"serial_number": "VMware-42 ee bc ea fb 8e 58 52-ce 61 e7 b0 28 e7 93 24",
"company": "",
"model_number": "",
"model_id": "",
"cpu_count": "2",
"ram": "3220.6766079999998",
"manufacturer": ""
},
"sys_object_source_info": {
"source_feed": "Hardware Inventory",
"source_name": "FlexeraOne",
"source_native_key": "f97bce57-25f9-45f4-8c3b-d04e3e0dceda"
},
"internal_id": "f97bce57-25f9-45f4-8c3b-d04e3e0dceda",
"settings": {
"updateWithoutSwitch": "false",
"updateWithoutUpgrade": "false",
"updateWithoutDowngrade": "false"
},
"sys_ire_info": {}
},
//IRE Output Payload
{
"className": "cmdb_ci_computer",
"operation": "INSERT",
"sysId": "3a9d1c8f87c2e91011a0b259dabb3531",
"identifierEntrySysId": "Unknown",
"identificationAttempts": [
{
"info": "sys_object_source NO_MATCH",
"attemptResult": "NO_MATCH",
"identifierName": "",
"attributes": [
"source_name",
"source_native_key"
],
"searchOnTable": "sys_object_source",
"hybridEntryCiAttributes": []
},
{
"attemptResult": "SKIPPED",
"identifierName": "Hardware Rule",
"attributes": [
"serial_number",
"serial_number_type"
],
"searchOnTable": "cmdb_serial_number",
"hybridEntryCiAttributes": []
},
{
"attemptResult": "NO_MATCH",
"identifierName": "Hardware Rule",
"attributes": [
"serial_number"
],
"searchOnTable": "cmdb_ci_hardware",
"hybridEntryCiAttributes": []
},
{
"attemptResult": "NO_MATCH",
"identifierName": "Hardware Rule",
"attributes": [
"name"
],
"searchOnTable": "cmdb_ci_hardware",
"hybridEntryCiAttributes": []
},
{
"attemptResult": "SKIPPED",
"identifierName": "Hardware Rule",
"attributes": [
"mac_address",
"name"
],
"searchOnTable": "cmdb_ci_network_adapter",
"hybridEntryCiAttributes": []
}
],
"info": [],
"errorCount": 0,
"inputIndices": [
0
],
"mergedPayloadIds": [],
"warningCount": 0,
"markers": [
"be9d1c8ffac2e910a688fce8722c8625"
]
},
For Software Installation, the IRE process determines whether to insert or update data based on the following checks:
Below are the IRE Input Payload and IRE Output Payload.
//IRE Input Payload
{
"className": "cmdb_ci_computer",
"values": {},
"related": [
{
"className": "cmdb_sam_sw_install",
"values": {
"normalized_publisher": "Microsoft",
"discovery_source": "FlexeraOne",
"x_fls_flexeraone_flexera_unique_id": "0d765f3c-6e85-6518-0d60-2f5ea41e7db6",
"is_normalized": "true",
"x_fls_flexeraone_is_deleted": "FALSE",
"publisher": "Microsoft",
"normalized_version": "8.0",
"display_name": "Microsoft Live Meeting 8.0",
"version": "8.0"
},
"internal_id": "0d765f3c-6e85-6518-0d60-2f5ea41e7db6",
"sys_object_source_info": {
"source_feed": "Software Inventory",
"source_name": "FlexeraOne",
"source_native_key": "0d765f3c-6e85-6518-0d60-2f5ea41e7db6"
},
"settings": {
"updateWithoutDowngrade": "true"
},
"sys_ire_info": {},
"display_values": {},
"marker": "6fbf18077b06e9105524e247af98b5d8"
}
],
"sys_object_source_info": {
"source_feed": "Software Inventory",
"source_name": "FlexeraOne",
"source_native_key": "f97bce57-25f9-45f4-8c3b-d04e3e0dceda"
},
"internal_id": "f97bce57-25f9-45f4-8c3b-d04e3e0dceda",
"settings": {
"updateWithoutDowngrade": "true"
},
"sys_ire_info": {}
},
//IRE Output Payload
{
"className": "cmdb_ci_computer",
"operation": "NO_CHANGE",
"sysId": "3eafd4078706e91011a0b259dabb358b",
"relatedSysIds": [
"6fbf18078706e91011a0b259dabb35ea",
"2bbf18078706e91011a0b259dabb35eb"
],
"relatedItems": [
{
"errors": [],
"operation": "INSERT",
"info": [],
"errorCount": 0,
"sysId": "6fbf18078706e91011a0b259dabb35ea",
"inputIndices": [
{
"mainIndex": 0,
"subIndex": 0
}
],
"mergedPayloadIds": [],
"warningCount": 0,
"markers": [
"6fbf18077b06e9105524e247af98b5d8"
],
"className": "cmdb_sam_sw_install"
},
{
"errors": [],
"operation": "INSERT",
"info": [],
"errorCount": 0,
"sysId": "2bbf18078706e91011a0b259dabb35eb",
"inputIndices": [
{
"mainIndex": 1,
"subIndex": 0
}
],
"mergedPayloadIds": [],
"warningCount": 0,
"markers": [
"efbf1807ef06e9101c19d68e11dbb6d8"
],
"className": "cmdb_sam_sw_install"
}
],
"identifierEntrySysId": "Unknown",
"identificationAttempts": [
{
"info": "sys_object_source MATCHED",
"attemptResult": "MATCHED",
"sysObjectSourceEntrySysId": "7eafd4078706e91011a0b259dabb3592",
"identifierName": "",
"attributes": [
"source_name",
"source_native_key"
],
"searchOnTable": "sys_object_source",
"hybridEntryCiAttributes": []
}
],
"info": [],
"errorCount": 0,
"inputIndices": [
0,
1
],
"mergedPayloadIds": [],
"warningCount": 0,
"markers": [
"2fbf1807e906e910652048632c247bd8",
"afbf18071e06e9106ac516058955d3d8"
]
},
The following items are known issues related to the migration process:
The following known issues exist with inserting and updating data in the Computer table.
Insertion of New Records
While inserting a record in Computer table if one or both of the following conditions is true
IRE only process picks only one record and update the record as per the attribute’s information. So, if end user inventory contains the computer records that meets above criteria, there is a chance of getting multiple records in ServiceNow Computer table.
According to ServiceNow IRE, end user Computer table should only have one record with unique name and Serial Number. The purpose of IRE is to refine the CMDB by passing it to through some Identification and Reconciliation rule.
Assume we have the following computers to be inserted into target table:
Name | Serial Number | Hardware ID |
---|---|---|
Computer A |
comp123 |
1234@ |
Computer B |
comp123 |
5674# |
Computer C |
comp123 |
8767$ |
While transforming above data into computer target table, ServiceNow picks Computer A record and passes it through IRE Rules and checks the record in Source (sys_object_source) table using Hardware ID and, since it is the insertion operation, so no record found in Source (sys_object_source) table, then it inserts the Computer A record into Target table as well as creates an entity in Source (sys_object_source) table.
After processing Computer A, ServiceNow picks Computer B record and passes it through IRE rules and also checks the record in Source (sys_object_source) table using Hardware ID, since no record is found in Source (sys_object_source) table so ServiceNow generates an entity in Source (sys_object_source) table but IRE rules identifies record based on Serial Number so IRE updates the Computer A record with Computer B record. Similarly, same process repeats when Computer C inserts into target table, an entity is created in Source (sys_object_source) table but IRE identifies the record based on Serial Number and updates Computer B record with Computer C record.
At last, there would be three entities created in Source table for all the computers record and, in the Target SysID, referenced to Computer C record for all the above sample Computers.
Updating of Records
Assume we have the following computers to be updated into target table:
Name | Serial Number | Hardware ID |
---|---|---|
Computer A |
comp123 |
1234@ |
Computer B |
comp123 |
5674# |
Computer C |
comp123 |
8767$ |
While transforming above data into computer target table, IRE will check the record in Source (sys_object_source) table using Hardware ID and, since it is the updating operation, might there be no record found in Source (sys_object_source) table, IRE will be fallback to Serial Number.
Now, there be multiple records in target table with same Serial Number so IRE will throw error for multiple serial number found and ignore the update.
In case of Software Installation records associated with Computer A, Computer B, Computer C:
With the help of IRE rules and Source (sys_object_source) table, only Computer C is present into the Target table as IRE Rules update the records based on Serial Number. So, the software records associated with Computer A, Computer B, Computer C would map to Computer C record, as while making relationships software record with respective computer, ServiceNow first checks the record in Source (sys_object_source) table and successfully found Computer A, Computer B, Computer C record using Hardware ID.
ServiceNow checks the Target SysID field which already referenced to Computer C record for all the Computer (A, B, C) so it creates a relationship with Computer C for all the software records.
Nov 22, 2023 09:21 PM - edited Nov 27, 2023 11:32 PM