Migrating custom server operator actions

If you created custom server operator actions on your system in a release earlier than BMC Cloud Lifecycle Management 4.5, you need to migrate those actions after upgrading to 4.5 or later.

Before version 4.5, you could create custom server operator actions through BMC Remedy AR System workflows and BMC Atrium Orchestrator workflows. In subsequent versions, with the introduction of the new My Cloud Services console, BMC Remedy AR System workflows are no longer supported as part of the front end UI flow. This means any Active Links you created to customize the UI will no longer work. This includes any custom server operator action customizations you created. Version 4.5 or later supports only custom actions that call BMC Atrium Orchestrator workflows.

This topic contains the following information:

Migration cases

If you used Active Links only as a way to trigger BMC Atrium Orchestrator workflows, follow the guidelines in this topic to transition out of BMC Remedy AR System workflows completely.

If you did not use BMC Atrium Orchestrator workflows at all, you must first first create BMC Atrium Orchestrator workflows that replace the old BMC Remedy AR System workflow actions. Consider contacting BMC Professional Services to help you with this step. After that step has been completed, follow the guidelines in this topic to migrate BMC Atrium Orchestrator workflow actions imported into the Platform Manager action catalog for use in version 4.5 or later.

Migration summary

1. Identify custom server action BMC Atrium Orchestrator workflows you want to import into the Platform Manager action catalog.
2. Issue the API call http://pmHostname:pmPort/csm/ActionCatalog/refresh to generate staging catalog json files (the delta folder).
3. Modify the json files as needed, and do any special handling as needed.
4. Issue the API call http://pmHostname:pmPort/csm/ReferenceActionCatalog/refreshCatalogs to incorporate the staging catalog files into the Platform Manager action catalog.
5. Customize labels of the new actions’ names, and input parameter labels as needed (see section on i18n label customization).

To migrate custom server operator actions

1. In a REST client, log in to BMC Cloud Lifecycle Management using the following request:
   http://pmHostname:pmPort/csm/login
   See Logging on to the API server for more information.
2. Note the Authentication-Token from the Response header and use it for subsequent requests.

3. Run the following API call to import BMC Atrium Orchestrator workflows as catalog entries:
   http://pmHostname:pmPort/csm/ActionCatalog/refresh
   See ActionCatalog refresh request for more information.

   Request body example

   {
      "operationParams":[
         {
            "name":"criteria",
            "type":"java.lang.String",
            "multiplicity":"1",
            "value": "module1,module2:workflowname"
         },     
         {
            "name": "groupName",
            "multiplicity": "0..1",
            "type": "java.lang.String",
            "value": "CustomServerOperatorAction"
         }
   		],
      "timeout" : 1500
   }

   This API is only implemented by the Custom Action provider. It communicates with the BMC Atrium Orchestrator webservice and gets list of all modules and workflows using the getModuleProcessDescriptions request. It filters the list of modules/workflows and finds entries that contain the criteria specified in the request. The criteria is a simple comma separated list. It can be a module name or a workflow name. Typically in BMC Atrium Orchestrator a workflow name is fully qualified name containing the module name as well, so if you specify the module name in the criteria the call will fetch all of the workflows within that module.

   Additionally, all metadata is captured. BMC Atrium Orchestrator typically has the type of the input parameter as String-XML. If not specified, BMC Cloud Lifecycle Management defaults to String. The parameters also have description fields. The data is transferred as catalog entries and catalog entry input parameters. Other details of the catalog entry input parameters that are not directly mentioned in the metadata are defaulted. For example, the isUserInputRequired is set to true.

   Corresponding to every matching workflow entry, an action catalog entry for both reference action catalog and custom action catalog is created. An option parameter groupName can also be passed in when the workflows being added are for custom server operator actions. The only supported group name is CustomServerOperatorAction as shown in the example above. If this parameter is not specified, then by default all of these entries are put in the Custom group.

   Note

   If you are executing this API multiple times, you must specify all of the module names every time. The delta catalogs generated in any run will override the contents of the Reference catalog.

   This API returns out label-text key-value pairs that are needed for internationalization support in the UI.

4. If needed, customize your parameters in the Configuration\actionCatalogs\delta\Reference_ActionCatalog.json file:
   

   • Set whether the parameter is optional:
     "isOptional" : true

   • Set whether the parameter is encrypted:
     "isEncrypted" : true

   • Set the parameter order:
     "sequence" : "1"

   • Set whether end user input is required (Hidden):
     "isEndUserInput" : true


     Note

     The additionalInfo parameter should set "isEndUserInput" : false, because it is a special parameter that provides context information to the workflow by the system.
5. When you have completed your changes to the delta catalogs, run the following API:
   http://pmHostname:pmPort/csm/ReferenceActionCatalog/refreshCatalogs
   See ReferenceActionCatalog refreshCatalogs request  for more information.
   This API merges the catalogs from the delta folder into the main catalogs in BMC Cloud Lifecycle Management. This includes the handling of the modification of entries and their input parameters. You can modify names, labels, and descriptions, add new parameters, change the types of old parameters, delete old parameters, and old action catalog entries, and so on.) The API then refreshes the Reference Action catalog in the database, and calls ActionCatalog#onboard for each of the provider catalogs to refresh the catalogs in the system.
6. If needed, configure your labels for internationalization:
   
   1. Open the <installationDirectory>\Configuration\actionCatalogs\delta\CLMCustomUILabels.properties file.
      This file contains the key/value pairings for labels.
   2. In a text editor, open the <installationDirectory>/Cloud_UI/custom/i18n/resources-locale_en.js file for editing.

   3. Using the pairings from the CLMCustomUILabels.properties file as a guide, add code to the resources-locale_en.js file that maps the label's key to a label value that is displayed in the UI. See the following examples.

      Pairings in the CLMCustomUILabels.properties file:

      

      Original resources-locale_en.js file:

      

      Mapping for an Application ID field in a revised resources-locale_en.js file

      

   4. Save and close the CLMCustomUILabels.properties and resources-locale_en.js files.

   5. If needed, repeat this series of steps for other language files in the i18n directory.