Case Study: Service Now RM Orchestration through HWA

This Blog aims to showcase how we can use HCL Workload Automation to Implement a Request Management Workflow for a repeated task for a Service Line and how the complete request can be managed End to End through HWA.

The request we are covering here is for a “DB Backup” request being requested by an Application Team of their Application DB. So in a typical scenario, an Application Team would raise a Request on Service Now through a Ticket.

The Ticket would be received and acknowledged by the DBA Team and they would go ahead and process this ticket by logging into the specific DB Server in question and would run a manual command to take this adhoc Backup of the Application DB requested in the Ticket to specific location requested and would then go ahead and update the ticket once the Backup is taken in the appropriate location and would further close the Ticket/Request post the Successful Backup creation.

The same flow can be realized through HWA & would comprise of the Following Jobs as part of a Jobstream called SNOW_ORCHESTRATE :

Service RESTFUL Get Job which would extract the last Ticket received in a Queue and extract all information pertaining to the ticket from Service Now and get a JSON response of the request in an Output File.

• Extract sys_id unique to a Ticket from the JSON Response in the Output File into a HWA Variable.
• Extract Job which would extract the DB Name from the JSON response stored in the output file.
• Extract Job which would extract the DB Server Name from the JSON response stored in the output file.
• Extract Job which would extract the target location from the JSON response stored in the output file.
• Variable Creation Jobs which would extract the DBName, DBServerName and target location into separate HWA Variables.
• A Variable table Job type which would collate all these variables for DBName, DBServerName and target location,sys_id into a Variable table.
• An Event Rule which would run on Successful run and Updation of the Variable table Job which would trigger a Backup job to pass all these parameters to the job to take a Backup of the specific DB in question to the specific location from the specific DB Server.
• RESTFUL Put job which would update the ticket stating that a Successful Backup was taken.
• RESTFUL Delete job which would close the Ticket post the Update Step.

For the above Usecase, we are making use of a Service Now Instance on SaaS with Administrator Role and having the below experience and View built in the table for Request Management :

Fig 1

Fig 2

SERVICENOW_GET_TICKETS Job :

This is a RESTFUL GET job which is setup to call the Service now URL instance https://dev114719.service-now.com/api/now/table/x_650167_dbapps_0_db_apps and query by descending order and pick the latest Ticket. This job also stores the output in an output file /tmp/snowoutput.

Fig 3

EXTRACT_TICKETNO_WA_VAR Job :

This is a Unix Job which parses the JSON output within /tmp/snowoutput and extracts the sys_id(Unique Identifier) from the same through cut command and exposes it as a HWA variable using jobprop utility, the HWA variable is called “TICKETNO”.

Fig 4

SNOW_EXTRACT_DBNAME Job :

The job SNOW_EXTRACT_DBNAME would extract the DB Name from the JSON output within /tmp/snowoutput.

Fig 5

SNOW_EXTRACT_DBSERVERNAME Job :

The job SNOW_EXTRACT_DBSERVERNAME parses the JSON output within /tmp/snowoutput and extracts the DB Server Name.

Fig 6

SNOW_EXTRACT_TARGETLOCATION Job :

The job SNOW_EXTRACT_TARGETLOCATION parses the JSON output within /tmp/snowoutput and extracts the Target Location.

Fig 7

STORE_DBNAME_WAVAR Job :

The job STORE_DBNAME_WAVAR fetches the joblog output of SNOW_EXTRACT_DBNAME and stores it in a Variable called DBNAME through jobprop utility of HWA:

Fig 8

STORE_DBSERVERNAME_WAVAR Job :

The job STORE_DBSERVERNAME_WAVAR fetches the joblog output of SNOW_EXTRACT_DBSERVERNAME and stores it in a Variable called DBSERVERNAME through jobprop utility of HWA:

Fig 9

STORE_TARGETLOCATION_WAVAR Job :

The job STORE_TARGETLOCATION_WAVAR fetches the Joblog of SNOW_EXTRACT_TARGETLOCATION job and stores it in a variable called TARGETLOCATION using jobprop utility:

Fig 10

VT_UPDATE_SNOW_DB_USECASE Job :

The job VT_UPDATE_SNOW_DB_USECASE is a Variable Table jobtype which updates a variable table called SNOW_DB_USECASE and stores all variables in it such as DBNAME, DBSERVERNAME, TARGETLOCATION and TICKETNUMBER etc. exposed earlier into the variable Table :

Fig 11

DBBACKUP Job :

The DBBACKUP Job is a Unix Job that takes DBNAME, DBSERVERNAME and TARGETLOCATION as command line arguments and takes a Backup of the DB in question on the given DB Server to the given target location.

Fig 12

SNOW_UPDATE_TICKET_DBUSECASE job :

The SNOW_UPDATE_TICKET_DBUSECASE job is a RESTFUL Put job that updates the specific Ticket in Service Now to indicate that the Backup was Successful. The job picks the variable from variable table SNOW_DB_USECASE:

Fig 13

Fig 14

SNOW_DBUSECASE_TICKET_CLOSE Job :

The Job SNOW_DBUSECASE_TICKET_CLOSE takes the TICKETNUMBER as input and performs a RESTFUL Delete Operation on the Ticket in question for closing the Ticket:

Fig 15

Negative Use Case :

SNOW_UPDATE_TICKET_NEGCOND__DBUSECASE Job :

The job SNOW_UPDATE_TICKET_NEGCOND__DBUSECASE is setup to Update the Ticket incases when Backup Fails, this is a RESTFUL Put job which would pick the Ticket Number in question and update the Ticket to indicate that the Backup Failed. This job would act as a Conditional Successor of the DBBACKUP job and would only run when it Abends:

Fig 16

Fig 17

Some Important Considerations:

• The Variable Table SNOW_ORCHESTRATE is associated at Jobstream Level on the Jobstream.
• All Variable passing jobs involved have the “Variable Resolution at Runtime” option checked.

The Complete Flow of the Jobstream SNOW_ORCHESTRATE once created :

Fig 18

Fig 19

Fig 20

Jobstream in Action:

When executed the Jobstream would get the Service Now Ticket details from the last Ticket and extract it into an Output File in json format . From the Files, the extract Jobs would extract details of the Ticket such as DB Server Name, DB Name, Target Location in question . The Store jobs would expose HWA variables pertaining to all Parameters from the extract jobs for further processing within the Jobstream. The Variable Table Update Job would update the variables passed from each of the Store Jobs into a Variable Table associated at the Jobstream level .

The DB Backup Job would run on the variable table update and perform the actual Backup on the DB Server in question for the specific DB . If the DB Backup Job was successful, the Ticket is updated by the RESTFUL Put Job through a “Backup Successful” Post Message.

Fig 21

Fig 22

</jsdl:jobDefinition>

= TWSRCMAP  :

= AGENT     : DAUNIX

= Job Number: 950632797

= Fri 06/18/2021 09:08:54 CEST

===============================================================

AWKVTJ019I Changing variable table: "SNOW_DB_USECASE".

AWKVTJ004I Variable "TARGETLOCATION" with value "/tmp" was added or updated.

AWKVTJ004I Variable "DBNAME" with value "USECASE" was added or updated.

AWKVTJ004I Variable "DBSERVERNAME" with value "10.14.37.83" was added or updated.

AWKVTJ004I Variable "TICKETNUMBER" with value "d74d2ab11b3474103f696288b04bcbd8" was added or updated.

AWKVTJ013I The Variable table job execution is successful.
===============================================================
= Exit Status :0
= Elapsed Time (hh:mm:ss) : 00:00:01

= Fri 06/18/2021 09:08:54 CEST

===============================================================

===============================================================
= JOB       : MASTER_DA#SNOW_ORCHESTRATE[(0908 06/18/21),(0AAAAAAAAAAABCA3)].DBBACKUP
= USER      : db2inst4
= JCLFILE   : /home/db2inst4/dbbackup.sh USECASE 10.14.37.83 /tmp
= TWSRCMAP  : = AGENT     : MASTER_DA
= Job Number: 950632798
= Fri 06/18/2021 09:09:01 CEST

=============================================================== 
Backup successful. The timestamp for this backup image is : 20210618090904  
================================================================ 
Exit Status           : 0
= Elapsed Time (hh:mm:ss) : 00:00:09
= Job CPU usage (ms) : 54= Job Memory usage (kb) : 26144
= Fri 06/18/2021 09:09:10 CEST
===============================================================

</jsdlrestful:RestfulParameters>

               </jsdlrestful:restful>

  </jsdl:application>

  <jsdl:resources>

    <jsdl:orderedCandidatedWorkstations>

      <jsdl:workstation>D59D04CADB9611EA847C29F79A38B2EB</jsdl:workstation>

    </jsdl:orderedCandidatedWorkstations>

  </jsdl:resources>

</jsdl:jobDefinition>

= TWSRCMAP  :

= AGENT     : MASTER_DA

= Job Number: 950632800

= Fri 06/18/2021 09:10:14 CEST

===============================================================

{“result”:{“notes”:”Backup Successful”,”sys_mod_count”:”1″,”sys_updated_on”:”2021-06-18 07:10:32″,”sys_tags”:””,”sys_class_name”:”x_650167_dbapps_0_db_apps”,”number”:”DBAPPS0001008″,”sys_id”:”d74d2ab11b3474103f696288b04bcbd8″,”sys_updated_by”:”dbadmin”,”db_name”:”USECASE”,”sys_created_on”:”2021-06-18 05:25:52″,”db_host”:”10.14.37.83″,”target_location”:”/tmp”,”sys_created_by”:”admin”}}

===============================================================

= Exit Status           : 0

= Elapsed Time (hh:mm:ss) : 00:00:01

= Fri 06/18/2021 09:10:14 CEST

===============================================================

Fig 23

As you can see in the screenshot above the Ticket’s Notes section gets updated through the Post.

Fig 24

The last part of the flow is the conditional dependency part where if the Backup was not Successful a Job named SNOW_UPDATE_TICKET_NEGCOND__DBUSECASE would update the Ticket Stating that the Backup was not Successful and would stop processing.

The Final Job closes the ticket in question DBAPPS0001008:

Fig 25

Conclusions from the Use Case:

Typically in any Customer Environment,each Support Team/Service Line would have some repeated tasks for which Tickets would be raised from time to time. All such repeated tasks of the Support Teams can be automated by leveraging the Orchestration capabilities of HWA so as to free the Support Teams(Service Lines) for other Tasks which require deep investigation and analysis.

2-3 Three Tasks in each Service Line can be identified and similar Jobstream Flows can be created which could Orchestrate repeated tasks.

Learn more about HCL Workload Automation here or drop us a line at HWAinfo@hcl.com

Authors Bio

Sriram V, Senior Technical Specialist, HCL Technologies

Sriram is working with Workload Automation for the last 12+ years. Started out as a Scheduler, later as an Administrator, SME and India SME of the Product. He has been part of the Product Team in the last few years supporting Workload Automation on SaaS before moving to the Lab Services and Tech Sales of WA.​

Linkedin: https://www.linkedin.com/in/sriram-v-4163b820/

Ajay Mohandhas, Technical Specialist, HCL Technologies

Ajay has 10+ years of Workload Automation experience. He has been Workload automation SME for various clients across business verticals before Joining HCL Lab Services and Tech Sales Team of WA.

Linkedin: https://www.linkedin.com/in/ajay-mohandhas-84053767/