Creating and deleting custom server operator actions

BMC Cloud Lifecycle Management displays the available server operator actions in the Actions menu in the My Cloud Services Console. You can add custom actions to this menu by creating a BMC Atrium Orchestrator workflow that implements the action, configuring the Callout Provider, and then using API calls to import the BMC Atrium Orchestrator workflow to BMC Cloud Lifecycle Management.

To create a custom server operator action

1. Create the BMC Atrium Orchestrator workflow that performs the action.
   For information about creating BMC Atrium Orchestrator workflows, see the Workflow basics and the Workflow coding recommendations topics in the BMC Atrium Orchestrator online technical documentation.

   Note

   If the AO workflow needs context information like Server or Service to execute actions, then include the additionalInfo parameter. This parameter passes context information about ComputeContainer, VirtualGuest, User, Service Offering Instance,  and Server group when the operator action is invoked.  
2. Configure the Callout Provider:
   

   1. On the BMC Cloud Lifecycle Management Platform Manager computer, open the providers.json file for editing.

   2. Ensure that the Callout Provider can communicate with the BMC Atrium Orchestrator computer by setting the following attributes in the providers.json file:

      • AO hostname

      • Port

      • Grid name

      • Username

      • Password

   3. Save and close the providers.json file.

3. Import the workflow and update your labels:
   

   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.

   
   
   

4. Customize the fields. The "type": mentioned in the request body example decides the UI component on the panel. The following data types are supported for the input fields:

• String for text field

• NEW IN 4.6.06List for drop-down

• NEW IN 4.6.06Boolean for check box

NEW IN 4.6.06 To customize the fields, you can associate custom java script files with the panel. For more information about how to use java script files, see Using JavaScript to customize the My Cloud Services console. The following examples describe specific scenarios for customizing the fields:

• • Adding default data to the text field
  • Populating the list options
  • Making the fields inter-dependent
  • Selecting the check box by default
    
    For more information, see Adding dynamic lists to fields.

To delete a custom server operator action

1. In the <PlatformManagerInstallationFolder>\configuration\actionCatalog\Reference_ActionCatalog.json file, delete the non-required CustomServerOperatorAction block. After deleting the block, ensure that the JSON is valid. The following is an example of a non-required CustomServerOperatorAction block that needs to be removed.
   
   

   {  
      "name":"CustomServerOperatorAction",
      "catalogEntries":[  
         {  
            "name":"Day2:Stop Baremetal Server",
            "catalogEntryInputParams":[  
               {  
                  "name":"input",
                  "sequence":"1",
                  "isOptional":true,
                  "label":"@action.catalogEntry.CustomServerOperatorAction.Day2Stop.Baremetal.Server.input.label@",
                  "valueDataType":"String",
                  "isEndUserInput":true
               }
            ],
            "label":"@action.catalogEntry.CustomServerOperatorAction.Day2Stop.Baremetal.Server.label@",
            "actionType":"Custom"
         }
      ],
      "label":"@action.catalogEntry.CustomServerOperatorAction.label@",
      "applicableClass":"ComputeContainer",
      "description":"@action.catalogEntry.CustomServerOperatorAction.description@"
   }

2. Run the http://PlatformManagerServer:8080/csm/ReferenceActionCatalog/refreshCatalogs rest call to finish the integration.

An alternate way to delete (replace) the action is as follows.

1. Exclude the module from the criteria parameter in the refresh API of the ActionCatalog class.
   For example, in the following code, you would delete module 2:
{
   "operationParams":[
      {
         "name":"criteria",
         "type":"java.lang.String",
         "multiplicity":"1",
        "value": "module1,module2"
      },  
      {
         "name": "groupName","multiplicity": "0..1",
         "type": "java.lang.String",
         "value": "CustomServerOperatorAction"
      }
        ],
   "timeout" : 1500
}
2. Execute the refreshCatalogs API from the ReferenceActionCatalog class.