AIOps 2.5 - Post Deployment Process
Click here to see this page in full context

AIOps 2.5 - Post Deployment Process

Contents

  1. Clearing Cache
  2. Import ITOps_PWF_Update Workflow
  3. Device status migration API
  4. ITSM Time Format update in project configuration
  5. Ticket Threshold Policy and Rules

 

Follow the steps mentioned below:

Clearing Cache

This step should be performed once deployment is completed. Please refer swagger: Clear Cache

  1. Clear cache API available at /api/redis/clear_cache

  2. The API should be able to invoke for the below Reference types

    1. reference_data

    2. project_configuration

    3. sorted_ reference_data

Import ITOps_PWF_Update Workflow

  1. Import the skills mentioned in changeLog_03_10_2022.txt

  2. Skill dumps are available at skills

  3. Save, publish and mark the skill as golden

  4. Import the skill into existing projects so that project updates works for those as well.

Device status migration API

  1. Migration API should be used for the existing projects for US 88445 functionality. PFB Swagger details of device status migration API
    Device status migration API

  2. For checking the migration status below API can be used
    Device status migration status check API

    Collection:

    FailureAlerts_<projectId>

    DeviceStatusMigrationHistory

    Note:

    "migrationStatus": "COMPLETED" Indicates migration completed for the alert

    "migrationStatus": "IN PROGRESS" Indicates migration is in progress

    Only after the successful completion of migration US 88445 work as expected for old failure alerts

ITSM Time Format update in project configuration

The “ITSM Time Format” field should be updated in existing projects with the appropriate itsm time format. For Loan Depot %m-%d-%Y %H:%M:%S%p and Investec %Y-%m-%d %H:%M:%S respectively.

Ticket Threshold Policy and Rules

  1. Ticket Threshold Verification for migrated data

    1. For verifying migration, trigger “/api/verification” api.

    2. The verification api should be executed only once migration is completed.

  2. Ticket threshold policy/rule for custom fields in an existing project
    If an existing project contains custom field or newly added, then please do follow the steps below to use them in the ticket threshold policy/rule

    1. Get all the attribute details of “tckt-thPolicyField” and “tckt-thRuleField” using the fetchReferenceData API. For getting all the ‘ticket threshold policy’ attributes, use reference type as “tckt-thPolicyField” in fetchReferenceData API. Similarly use reference type as “tckt-thRuleField” for getting ‘ticket threshold rule’ attributes.
    2. Add the policy attributes and rule attributes to the project, using /api/projectMasterData API. The input should be a list of dictionaries where the key should be the ‘referenceValueCode’ and the value should be the ‘referenceValue’ from the output of fetchReferenceData API. Also add the ‘customFields’ in the project that needs to be added as ticket trigger policy/rule fields. The ‘referenceType’ should be “tckt-thPolicyField” and “tckt-thRuleField”.
      Example


      {
                   "projectId": <projectId>,
                    "referenceType": "tckt-thPolicyField",
                    "referenceValues": [
                              {“source”: "Alert Source”},
      {“alertName”: "Alert Name"},
      {“customField.customName”: "Custom Name"}
      ]
      }
    3. Drop the “TicketingThreshold” collection
      The “TicketingThreshold” MongoDB collection may be dropped after verifying migrated data and sanity test.