UCOP || Jira+ ServiceNow || Requirement
- Sharmendra Vishwakarma
1. Problem Statement
In Service Now (SN) Incidents are reviewed by ITSS to determine if they are defects and need to be worked on by application development team, if determined that a fix is needed the defect gets created into Tnt Jira and tracked in both places until the fix is moved into production. In addition, when the fix has to be moved into production, a Service Now Change Request is created to get the fix moved in production. Updates are also tracked in both places until this ticket is closed out.
2. User Cases
PHASE 1 - SN Incident to TnT Jira "Defect" Issue Type
As an end user once an incident is triggered from SN, I should be able to see it in the UCPath project as a production defect with the following required fields:
Initiator, Summary, Description, Detected in Environment, Affects Version's, Fix Version's, Business Unit, Component, "Pay, Benefit, or General Ledger Impacts?", Required?, # of Employees Impacted?, Impact on Manual Work/Costs? and Sys ID
Note: the Sys ID should only be in the Create and Edit screen as read only, NOT the view screen.
The defect ID should also be available in the SN incident under the "Related Records" tab, Defect ID field.
As an end user when triggering an incident from SN and the TnT Jira Component field is blank in SN, an alert message should display stating "Please select a valid TnT Jira Component in the Related Records tan to generate the ticket in TnT Jira."
End user should be able to go back to the incident, update the TnT Jira Component field with a value and trigger request again which generates the TnT Jira defect.
As an end user when triggering an incident from SN and the Description field is blank in SN, an alert message should display stating "Description field is required in TnT Jira, please update description field"
End user should be able to go back to the incident, update the TnT Jira Component field with a value and trigger request again which generates the TnT Jira defect.
As an end user if the SN incident have a blank "Location" and the "Requested By" has a "UCPath Salesforce" value, I should be able to create a TnT Jira defect and see the defects display the Salesforce ID and the Business Unit from the incident.
As an end user I should be able to update the comments and add attachments in the TnT Jira existing UCPath defect and have those updates applied to the SN incident until the defect is closed.
Note: Only defects with a valid Sys ID can communicate between SN and TnT Jira.
Attachments can be added before the comments are applied or after comments are applied and still be integrated to SN.
Same with comments, comments can added before adding an attachment or after adding an attachment and still be integrated to SN.
As an end user I should be able to update the comments and add attachments in the Service Now existing incident and have those updates applied to the TnT Jira UCPath defect until the incident is closed.
Note: Only incidents with a valid Sys ID can communicate between SN and TnT Jira.
Attachments can be added before the work notes are applied and posted or after work notes are applied and posted and still be integrated to TnT Jira.
Same with work notes, work notes can added and posted before adding an attachment or after adding an attachment and still be integrated to TnT Jira.
As an end user I should be able to see the defect id in Service Now under the "Related Records" tab, Defect ID field.
As an end user I should be able to update the comments and add attachments in TnT Jira new and existing UCPath defect. However; if the defect doesn't have a valid sys id those updates are not applied to the SN incident. Defect has to be created by the trigger from SN.
Note: Only defects with a valid Sys ID can communicate between SN and TnT Jira.
As an end user I should be able to update the comments and add attachments in the Service Now existing incident. However; if the TnT Jira defect doesn't have a valid sys id those updates won't be carried over to TnT Jira. Defect has to be created by the trigger from SN.
Note: Only incidents with a valid Sys ID can communicate between SN and TnT Jira.
2. Jira to ServiceNow[Comments + Attachments]
3. Jira to ServiceNow[ CR ]
Scope: Create
Summary : UCPath Migration - Migrate CSR {Migration ID}/ UCP-{Parent Key number} to PROD / {Subtask Key number}
Description:
UCPath Migration - Migrate CSR {Migration ID}/ UCP-{Parent Key number} to PROD / { Subtask Key number }
Reporter: { Name of the reporter}
Note: Any attachments in the sub-task should be brought over into the SN Change Request.
PHASE 2 - TnT Jira "Migration" Subtask to SN Change Request
As an end user I should be able to trigger a SN Change Request from the "Migration" sub-task in TnT Jira including the following fields:
Reporter, Summary, Description, Migration ID, Parent Key number and Subtask Key number
Note: the Sys ID should only be in the Create and Edit screen of the Migration sub-task as read only, NOT the view screen.
As an end user I should be able to see attachments and comments from the UCPath defect carried over to the SN change request.
As an end user I should be able to see the Reporter show as the service account name "SNServiceAccount" in SN.
As an end user I should be able to see the actual person that created the migration sub-task (reporter) in TnT Jira in the Description field in SN.
As an end user I should be able to see the Summary from TnT Jira is the Short Description in SN.
As an end user I should be able to see the Migration ID, Parent Key number and Subtask Key number data in the Short Description field in SN.
As an end user I should be able to update the comments and add attachments in the TnT Jira existing migration sub-task and have those updates applied to the SN change request until the migration sub-task is closed.
Note: Only migration sub-tasks with a valid Sys ID can communicate between SN and TnT Jira.
Attachments can be added before the comments are applied or after comments are applied and still be integrated to SN.
Same with comments, comments can added before adding an attachment or after adding an attachment and still be integrated to SN.
As an end user I should be able to update the work notes and add attachments in the Service Now existing change requests and have those updates applied to the TnT Jira the migration sub-task until the change request is closed.
Note: Only change requests with a valid Sys ID can communicate between SN and TnT Jira.
Attachments can be added before the work notes are applied and posted or after work notes are applied and posted and still be integrated to TnT Jira.
Same with work notes, work notes can added and posted before adding an attachment or after adding an attachment and still be integrated to TnT Jira.
In addition to above
When any data push is failed from ServiceNow to Jira send e-mail to specific user group. This is application from both Defects and migration-sub task
Make the sys-id as non-editable field in Jira
As an end user, I should be able to pull all the comments and attachments when CR is created for the first time.
As an ed user, I should be able to push description updates of migration sub-task to servicenow
3.1 Field Mapping for CR
Sl No | ServiceNow Field | Jira | Value | Remarks |
|---|---|---|---|---|
1 | Number | (will be in callback) | (system assigned) |
|
2 | Parent | No | N/A |
|
3 | Requested by | Yes | (varies) | Need to pss the Ids |
4 | Configuration item | Yes | UCPHRPRD (in Jira as "Promote to" field value in migration subtask) |
|
5 | Owner group | N/A | PeopleSoft Support Services | SysId: 329e8e485154950078c1717bfc16b68f |
6 | Impact | No | derived from Risk Assessment but since RA is boilerplate this will always have a value of "4 - Low" |
|
7 | Risk | No | derived from Risk Assessment but since RA is boilerplate this will always have a value of "3 - Medium" |
|
8 | Type | No | Out of scope, depends on lead time between generation of CR and deployment | Pass as”Normal” |
9 | Category | No | "Application" |
|
10 | Change Request State | No | As per spec, a change request record will be created and left in Draft status |
|
11 | Complexity | No | "Minor" | Set as” Minor” |
12 | Monitoring Changes | No | "No Changes Needed" | Pass as “No Changes Needed” |
13 | Other Reference Number | Yes | Component | needs dev work |
14 | Environments impacted | Yes but not used | "Production" (other environments are out of scope) | Pass as “Producation” |
15 | Approval Exception/Follow-up | No | NULL |
|
16 | Title/ Short Description | Yes (requires parsing) | UCPath Migration - Migrate CSR #### / UCP-##### to PROD |
|
17 | Description | Yes (requires parsing) | UCPath Migration - Migrate CSR #### / UCP-##### to PROD | UCPath Migration - Migrate CSR #### / UCP-##### to PROD |
Schedule |
|
|
|
|
18 | Planned start date | Migration Request Date | Jira's "migration request date" plus 7:30 PM Pacific | For Now put random date less than end date |
19 | Planned end date | Migration Request Date | Jira's "migration request date" plus 10:30 PM Pacific | For Now put random date greater than start date |
20 | Impact During Change | No | "No Downtime Expected" |
|
Planning |
|
|
|
|
22 | Implementation Plan | No | "1. Verify CSR in STAT Tool and its dependencies
|
|
23 | Justification | Yes (requires parsing) | "Copy the description from the JIRA UCP-YYYYY" |
|
24 | Pre Test Plan | No | "The Fix via STAT CSR has been validated in PTST/PUAT environment and has been documented in JIRA tool |
|
25 | Post - Test Plan | No | "Release Team will run a compare report to ensure successful migration. If the job fails they will troubleshoot, correct or contact developer for guidance. |
|
26 | Backout Plan | No | "Before migration:
File Objects:
DMS Scripts:
Back out after Migration:
File Objects:
DMS Scripts:
|
|
27 | Impact | No | "UCPath Application is Impacted by this Change. |
|
References
Link to get the ServiceNow API details : https://developer.servicenow.com/dev.do#!/reference/api/rome/rest/c_TableAPI