nexus/knowledgebase/csd-wiki/ICSD/Set-up-Native-SACM-for-SaaS_688996404.md

Set-up-Native-SACM-for-SaaS_688996404

Introduction

This topic guides you through the steps to prepare Native SACM in a SaaS environment.

Prerequisites

Manually add an unknown value to the OsFamily attribute in UCMDB. If you have a custom OS type in SMAX, you must also create a corresponding OsFamily value in UCMDB. For more information about how to do it, see Federation between SMA OS type and UCMDB OsFamily.

Push data from UCMDB on-premises to ESM SaaS

To migrate data from UCMDB on-premises to ESM SaaS, contact SaaS Operations.

Data pre-check before data migration

This section summarizes the preparation steps to handle the potential CI data issues (e.g., data configuration and format) that might exist in both SMAX and CMS before Native SACM can be activated.
We recommend that you manually fix these potential data issues before starting the Native SACM migration for the first time in Suite Administration.

Manual Pre-check on CI data

Step 1. Pre-check SMAX data domain and CMS tenant definition

There are 3 scenarios:

Scenario 1. SMAX has the "Public" domain only and CMS Multi-Tenant has not been enabled

No action is needed if the SMAX version is 2021.05 or greater.

For earlier versions of SMAX, please contact support for a hotfix.

Scenario 2. SMAX has additional domains (e.g., IT, HR, Finance) and CMS Multi-Tenant has not been enabled

If multiple data domains exist in SMAX, you must enable CMS Multi-Tenancy first. To do this, go to the UCMDB JMX Console, disable the CI owner tenant, and then call the enableTenant method with the tenantName parameter set to All Tenants.

Scenario 3. SMAX has additional domains (e.g., IT, HR, Finance) and CMS Multi-Tenancy has been enabled

When SMAX has multiple data domains and CMS has multiple tenants configured, you must align the default UCMDB tenant setting with the SMAX Public domain. To do this, follow these steps:

1. In the UCMDB JMX Console, call the setGlobalDefaultTenant method to change the system default tenant to All Tenants. Note that this name is fixed and unchangeable.
   This action sets All Tenants as the default tenant at the system level and the change will take effect for newly created customers. You can view the global default tenant by invoking the getGlobalDefaultTenant JMX method.
2. If one or more customers already exist, perform the following steps for each of them:
   1. Call the setTenantAsDefault JMX method to change the default tenant to All Tenants. 2. You can view the default tenant of a consumer customer by invoking the getDefaultTenant JMX method. 3. Use an enrichment rule to move CIs from the original default tenant to All Tenants as needed. 4. If the System Default Tenant exists, move CIs owned by this tenant to other tenants, and then delete it.

Note: For UCMDB customers, be aware that CIs assigned to All Tenants are accessible to all users.

Step 2. Pre-check CI data information in SMAX and CMS

All following steps are strongly recommended before the data migration.

Step 2.1. Global ID check for CMS CIs

The CMS Global ID serves as the key linkage field between SMAX and CMS which means that all CMS CIs without global IDs will be ignored during the migration. Therefore, make sure all federated CMS CIs have global IDs so that they can be properly synchronized to SMAX. Federated CMS CIs include the following CI types (including all sub-CI types).

• Service
• Business Application
• Application Resource
• Application System
• Running Software
• Cloud Service
• Node

Note:
For data push integrations of multiple CMS servers, for example, during SaaS onboarding process, you need to ensure that the CIs' global IDs will not be overwritten after the CIs are pushed from the source CMS server to the target CMS server. To do this, you can:

1. Access to the JMX console.
2. Use the getGlobalID command in the UCMDB JMX Quick Search page.
3. Make sure that the getGlobalID command returns "All" in the response.
4. If the result is not "All", you need to do these steps:
   1. Go to JMX console > setAsGlobalIdGenerator 2. Fill in customerID; Leave dbTimeout as empty; Set overWriteE xistingGlobalIDs as False. 3. Click Invoke.

Step 2.2. ENUM consistency check

You need to make sure all ENUM values are aligned between SMAX and CMS. A typical out-of-the-box example is SMAX OsType and CMS OsFamily. By default, there is "Unknown" defined in SMAX OsType, which is not defined on the CMS side. You must manually add this value to the CMS OsFamily ENUM to make them consistent.

This also applies to any other customized ENUM values in SMAX OsType and CMS OsFamily.

For the migration process, only the SMAX OSType and CMS OsFamily are required to be aligned.

Step 2.3. Complex type data format check

In SMAX, there are 6 complex-type fields for the SMAX Device record type, which are CPUs, DiskDevices, FileSystems, IpAddresses, NetworkCards, and RunningSoftwares. All sub-attributes of these fields are of the string type, which is not accepted by the corresponding CMS attribute definition. You must detect unaligned data values and correct them in SMAX prior to the migration.

The following table covers the sub-attributes of complex type fields which need special attention.

SN	Complex Type Attributes	Data Format Required by CMS
1	IP address type	IpV4 or IpV6 only, as they are ENUM values in CMS.
2	IP address value	Keep 4 segments (e.g. 192.168.56.33) for IpV4, and 8 segments for IpV6 (e.g., 2001:3CA1:010F:001A:121B:0000:0000:0010), otherwise they will not be accepted by CMS.
3	CPU ID	String type Note: This field is mandatory.
4	CPU clock speed	Integer only
5	Disk device size	Integer only
6	File system size	Double only
7	Network speed	Integer only
8	Running software ports	Integer only, single port only Note: Multiple ports are not supported by the migration.

Step 2.4. Empty display label check for SMAX CIs

SMAX allows for creating CIs via REST call or importing via.csv, so some SMAX local CIs may have empty display labels even though this field will always be set via UI. However, in many cases, an empty CI name is not supported by CMS, which is mapped by SMAX CI display label during migration. Therefore, you need to find every SMAX local CI with an empty display label and set a proper value, especially for Actual Service, Service Component, and System Element.

For Device, CMS has reconciliation rules to uniquely identify one CI with different attributes, for example, BIOS UUID, BIOS Serial Number, or BIOS Asset Tag.

In order for a successful migration, you need to make sure at least one of these key attributes in SMAX Device is not empty. For example:

• Hostname
• Serial number
• BIOS UUID
• BIOS serial number
• BIOS asset tag
• Net BIOS name

Specifically, for the display label, you can use one SMAX business rule that figures out the display label. As shown in the example below, you can set the hostname or other attributes which will be copied as the display label.

Step 2.5. Duplicate display labels check for SMAX CIs

SMAX locally allows duplicated display labels for all SACM records, the current logic during migration maps the SMAX CI display label to the UCMDB CI name for Device, Service Component, Actual Service, and the CMS CI discovered product name (for SMAX system element). However, UCMDB by default doesn't accept identical names among different CIs, therefore the duplicated CIs existing on the SMAX side will be rejected by UCMDB.

In a real-world environment, duplicated CIs existing on the SMAX side are mostly caused by the old OPB-based integration and have been moved to End of Life or Final metaphase already. Hence, if these SMAX CIs are rejected by UCMDB, the migration mechanism will automatically re-push them to UCMDB with the discovery_state attribute set to Purgeable, thiswill bypass the UCMDB reconciliation and will be accepted by UCMDB. This solution reduces the orphan CIs left in SMAX, thus improving the CI consistency between SMAX and UCMDB.

Note that for any existing CI in UCMDB before the migration, no Purgeable flag will be set during the migration. Instead, the flag will be set by UCMDB when these CIs have aged with the enhanced CI lifecycle after Native SACM is enabled.

If the duplicated CIs exist on the SMAX side aren't at End of Life or Final metaphases, additional steps are still needed according to different record types.

• For Actual Services and Business Applications, you need to update their display labels to different ones, or remove the duplicate CIs, or move them to the Final metaphase, or perform the following steps to remove UCMDB identification rule before the migration:
  1. Go to the CMS CI Type Manager. 2. Select the BusinessService CI Type. 3. In the Identification pane, set the identification method to No identification. 4. Save the change. 5. Repeat step 2 to step 4 for the InfrastructureService and BusinessApplication CI Type.
• For System Elements, currently, only SMAX Running Software will be migrated to UCMDB, and duplicated discovered product names aren't allowed among multiple Running Software associated with one single node in UCMDB. Therefore, we recommend that you update their display labels to different ones, or remove the duplicated CIs, or move them to End of Life metaphase before the migration.
• For Devices, similarly, we recommend that you update their display labels to different ones, or remove the duplicated CIs, or move them to End of Life metaphase before the migration.

Step 2.6. Review SMAX Business Rules

Some custom business rules may conflict with the CI notification of Native SACM, please review the following types of business rules and make adjustments as needed.

• The business rule Define field as mandatory. For example, if a customer defines any field as mandatory for Device through this rule, all UCMDB nodes can't be synchronized to SMAX (either creating or updating) when UCMDB can't populate the mandatory field values (e.g., any SMAX local fields such as "Owner"). To avoid this, please make sure all mandatory fields will be set by default for newly created devices in SMAX and all existing SMAX devices have all mandatory fields populated before enabling Native SACM.
• The business rule Define field as read-only. For example, if a customer defines any federation fields (e.g., "Serial number" or "Subtype") as read-only for Device through this rule, UCMDB nodes can be synchronized to SMAX. However, after Native SACM is enabled, any CI notifications including "Serial number" or "Subtype" will fail and cause CI inconsistency. To avoid this, please remove/disable relative read-only rules or exclude all federation fields from the rules.
• The business rule Restrict editing of fields. For example, if a customer restricts editing of any federation fields (e.g., "Serial number" or "Subtype") for Device through this rule, all UCMDB nodes can't be synchronized to SMAX (either creating or updating). To avoid this, please remove/disable relative restrict editing rules or exclude all federation fields from the rules.

Step 3. Configure Native SACM settings and trigger Migration in Suite Administration

By now you have fixed the known data issues and you can start to configure the Native SACM settings in Suite Administration.

It is expected that there is a data mismatch of CIs between SMAX and CMS. You will get the following popup window.

The popup window indicates that SMAX detects CIs that are different between SMAX and CMS, so a data migration is needed. Since you have already fixed the known data issues in SMAX and CMS, you can go ahead to click MIGRATE to start the migration. If all issues are resolved the migration will succeed and Native SACM will be automatically enabled and set to active.

In case the migration identifies errors, the errors will be tracked in the migration report. You can download and review the report and fix the issues according to your actual business needs. You are recommended but not forced to fix all the issues. For example, if some SMAX local CI relationships fail to be migrated, and if you believe UD can discover those CI relationships in a more accurate manner and this error can be accepted anyway, it is okay for you to leave it as is.

Do not click the Enable button until all issues are resolved or you can accept all remaining issues, as you CANNOT start the migration again and the data will not be in a synchronized state.

Migration limitations

There are some migration limitations because CMS has different CI and CI relationship characters with SMAX.

Limitation 1. Standalone system element is not supported for the migration

CMS does not allow standalone "Running Software" to which SMAX System Element is mapped, so all standalone SMAX system element CIs will not be migrated.

Limitation 2. System elements of limited OOB subtypes are supported by the migration

SMAX system elements have 13 OOB subtypes as shown in the following screenshot, and only system elements of 4 of them (Running Software, Web Server, Database, and Application Server) are allowed to be migrated to CMS CIs of the same CI Type names if each system element is already linked to one existing device.

System elements of all other 9 out-of-the-box subtypes are not supported by the migration, due to the following reasons.

• Mapped peer CMS CI Type is abstract (e.g., Application System, Application Resource, AWS Resource, and WebService Resource), which cannot be instantiated in CMS.
• Not supported by the current mapping file between SMAX Subtype and CMS CI type (e.g., Virtualization, CI collection, and Other), and the mapping file cannot be customized in SaaS.
• Not business applicable (e.g., Database Resource and Cloud Service).

System elements with customized or empty subtypes will not be migrated either, due to the following reasons.

• The CMS CI type mapped with SMAX subtype does not follow a certain pattern, it is hard to guarantee the migration of system elements of customized subtypes will succeed. Currently, it is not supported.
• The base CI Type mapped to System Element is "Infrastructure Element," which is abstract and cannot be instantiated in CMS.

Limitation 3: Devices of the "Cluster resource group" subtype are not supported by the migration

CMS does not support a standalone "ClusterResourceGroup," which has to be linked with at least one cluster CI. Hence, devices of the "Cluster resource group" subtype in SMAX will not be migrated as SMAX does not support the migration of any cluster CIs in System Elements. To work around it, you may change the "ClusterResourceGroup" subtype of the device to "Other" in order to migrate it to CMS.

Enable enrichment rules in UCMDB

When a CI of a federated CI type is created or discovered in UCMDB, enrichment rules are implemented for mapping Subtypes of SMA. The SMAX folder contains preset enrichment rules for the federated CI types. By default, these enrichment rules are inactive, we recommend that you activate them all and don't make any changes unless you have customized Subtypes. To do this, open Enrichment Manager in UCMDB and activate all enrichment rules in the SMAX folder.

UCMDB Browser

To build an end-to-end topology, it's required to connect the logic with the physical elements. To do so, you can use the Assisted Service Modelling feature from the UCMDB browser. The UCMDB browser is directly accessible from the SMA UI by using the “Explore” functionality.

Note: You need to have the Enable 'Explore' in CI details permission enabled in the user role. For details about how to enable this permission, see Roles.

Related pages

• Page: ESM Cloud Farm Version Tracking
• Page: How to get an Opentext Confluence account
• Page: ITOM APM AppPluse Cloud Farm Information
• Page: ITOM Cloud Service Ops Doc Management Process
• Page: ITOM ESM Cloud Service Catalog
• Page: ITOM OpsB NOM Cloud Service Catalog
• Page: OpsB and NOM Cloud Deployments Version Tracking