Preparing the server for import

This topic provides instructions for preparing the BMC Service Request Management destination server for import. 

The following information is provided:

Overview

You prepare the destination server for import as part of the process for migrating BMC Service Request Management objects and data. The following objects must be present on the destination server before importing service request definitions (SRDs) and process definition templates (PDTs). Otherwise, imported objects might not function as expected.

Foundation data

All foundation data must be identical in the source and destination servers, including the GUIDs for each record. If you manually re-create foundation data (such as companies and sites) on the destination server, the system might not recognize the data, even if the names are the same. This occurs because the records in the foundation data on each server might have different GUIDs.

In 8.1.02 and later versions, foundation data is automatically checked for consistency. For more information, see Foundation data validation: 8.1.02 and later.

Customizations

Customizations include workflow and form changes. Any customizations must be migrated manually, including:

• Standard forms that have been modified
• New forms and workflow
• Custom advanced interface forms (AIFs) and workflow

Configuration data

Configuration data populates fulfillment configuration forms that are used in the Application Administration Console, and is referenced in BMC Service Request Management. This data must be migrated manually, including data in the following forms:

• Approval mappings—APR:Approver Lookup
• On Behalf Of management—OBO:OnBehalfOfDefinition
• Service Level Management data (for example, service targets, work information, and attachments)
  • Service target defaults—INT:SLMSRS:ConfigServiceTarget:Defaults
• Work order rules—WOI:CFG Rules
• AIF configuration—SRS:CFGAdvancedInterface
• Atrium Service Catalog data (requestable offerings and service offerings)
• Define application field—SYS:Form Field Selection (any records added or changed)
• Define application target data—SRM:AppTargetData (any records added or changed)
• Tasks templates—TMS:TaskTemplate
• Task group templates—TMS:TaskGroupTemplate

In pre-8.1.01 versions, you must also migrate data from the following forms:

• SRD packages—SRD:SRDPackages
• SRD levels—SRD:SRDLevelCompanyModuleAssoc and SRD:SRDLevel 
• Fulfillment application templates—WOI:Template, CHG:Template, and HPD:Template 
  
  If the template referenced by an AOT does not exist on the destination server when the AOT is imported, the AOT is set to inactive. To activate the AOT in this situation, you must manually register a template with it. See Parameters for registering application templates with AOTs.

To prepare the server for import

1. (8.1.01 and earlier) Verify that Foundation data is identical on the source and destination servers.

2. Use BMC Remedy Developer Studio to migrate custom form and workflow definitions from your source server to your destination server. For more information, see Exporting and importing definitions (BMC Remedy Action Request System documentation).

   Note

   For custom AIFs, use the Directly Related option to migrate the forms and custom workflow. You should also attach the standard workflow on the destination server after the custom AIF is imported. See Creating AIFs from templates.

3. Migrate BMC Service Request Management configuration data:
   1. Use the reporting function to export the configuration data in .arx format from the source server, as explained in Running reports.

   2. Import the data by using Data Import, as explained in Importing data into BMC Remedy AR System forms.

      Notes

      If you are migrating SRDs that were linked to a requestable offering (RO) from the Atrium Service Catalog, transfer the related Atrium data by using Atrium Integrator before you import the SRDs. This ensures that the RO relationship data is preserved. If you do not transfer the Atrium data first, the data is not preserved. A new RO is created as a Transactional offering, and the Service and Service Offering fields on the SRD are empty.

      Manually creating the related Atrium data does not ensure that the RO relationship data will remain after you import the data. In this case, the keys used to maintain the relationship will not match, and the RO information is lost. You can associate the imported SRD to the new Business Service and Service Offering.

      When you delete an SRD, the related requestable offering in the Atrium Service Catalog is not deleted until the data is purged (this is usually a scheduled process). If you export, delete, and then import that SRD on the same computer, make sure that the requestable offering related to the deleted SRD is purged, or the new SRD will not be imported properly.

Where to go from here

Importing data from the Import Export Console