SDIM tracking_id if tracking ritm

SailPoint Human Fabric (SHF) SHF Discussion and Questions
,
1

Hi all,

We have a custom catalog item for SDIM. When we have the SDIM track RITMs, the provisioning is creating duplicate tickets on identity refresh for an existing provisioning operation but i switch it to request we are not seeing any issue.

Looking for pointers on what might be missing.

This is working :

"attributes": {
        "password": "<passwd>",
        "provisioningTimeout": "180",
        "serviceRequest": {
            "checkStatus": {
                "statusMap": {
                    "closed_complete": "Committed",
                    "closed_rejected": "Failed",
                    "requested": "Queued",
                    "in_process": "Queued",
                    "closed_cancelled": "Failed",
                    "closed_incomplete": "Failed",
                    "closed_skipped": "Failed"
                },
                "closeNotes": "$.result[0].close_notes",
                "resource": "/api/now/table/sc_request?number=$ticketId&sysparm_fields=request_state,close_notes",
                "responseElement": "$.result[0].request_state",
                "statusMapClosureCode": null
            },
            "provision": {
                "request": {
                    
                    "short_description": " <short desc>",
                    "opened_by": "$!{plan.arguments.opened_by|'Default_ServiceNow_Account_Sys_ID'}",
                    "req_description": "Service Request created by Service Desk Integration Module (SIM)", "correlation_id": "$!plan.arguments.identityRequestId",
                    "description": "<descr>",
                    "requested_for": "$!plan.arguments.requested_for"
                },
                "requestRootElement": "items",
                "resource": "/api/x_sap_sdim/sailpoint_cart_js_api/create_ticket",
                "responseElement": "$.result.request_number",
                "catalogItem": {
                    "<isc_src_id1>": "<catalog>",
                    "<isc_src_id2>": "<catalog>",
				    "<isc_src_id2>": "<catalog>"
                }
            }
        },
        "ticketType": "serviceRequest",
        "authenticationType": "Basic",
        "connectorClass": "openconnector.connector.servicedesk.ServiceDeskConnector",
        "requesterSource": "<sourceID>",
        "url": "snowUrl",
        "spConnDebugLoggingEnabled": false,
        "username": "userID"
    },

This is creating duplicates :

"attributes": {
        "password": "<passwd>",
        "provisioningTimeout": "180",
        "serviceRequest": {
            "checkStatus": {
                "statusMap": {
                    "1": "Queued",
                    "2": "Queued",
                    "3": "Committed",
                    "4": "Failed",
                    "5": "Failed",
                    "7": "Failed",
                    "8": "Queued",
                    "9": "Failed",
                    "closed_rejected": "Failed",
                    "-5": "Queued",
                    "closed_cancelled": "Failed",
                    "closed_incomplete": "Failed",
                    "closed_skipped": "Failed",
                    "closed_complete": "Committed",
                    "requested": "Queued",
                    "in_process": "Queued"
                },
                "closeNotes": null,
                "resource": "/api/now/table/sc_req_item?number=$ticketId&sysparm_fields=state",
                "responseElement": "$.result[0].state",
                "statusMapClosureCode": null
            },
            "provision": {
                "request": {
                    
                    "short_description": " #if($!plan.arguments.source == 'Certification' || $!plan.arguments.accessRequestType == 'REVOKE_ACCESS') This request is submitted by SailPoint Automation to revoke users access. #elseif($request.operation == 'Create'|| $!plan.arguments.accessRequestType == 'GRANT_ACCESS') This request is submitted by SailPoint Automation to add users access. #elseif($!plan.arguments.source == 'WebService')This request is submitted by SailPoint Automation to terminate users access. #else This request is submitted by SailPoint Automation to modify users access. #end",
                    "opened_by": "$!{plan.arguments.opened_by|'Default_ServiceNow_Account_Sys_ID'}",
                    "req_description": "Service Request created by Service Desk Integration Module (SIM)",
                    "track_ritm": "true", 
                    "correlation_id": "$!plan.arguments.identityRequestId",
                    "description": "<desc>",
                    "requested_for": "$!plan.arguments.requested_for"
                },
                "requestRootElement": "items",
                "resource": "/api/x_sap_sdim/sailpoint_cart_js_api/create_ticket",
                "responseElement": "$.result.items",
                "catalogItem": {
                    "<isc_src_id4>": "<catalog>",
                    "<isc_src_id5>": "<catalog>",
                }
            }
        },
        "ticketType": "serviceRequest",
        "authenticationType": "Basic",
        "connectorClass": "openconnector.connector.servicedesk.ServiceDeskConnector",
        "requesterSource": "sourceid",
        "url": "SNOW URL",
        "spConnDebugLoggingEnabled": false,
        "username": "<userName>"
    },

What i observed when using to track ritm is the tracking_id sent to SNOW is different for each RITM in the same req and also the tracking id i see in snow is not the tracking number for the provisioning activity. also can you help understand what should be correlation_id on SNOW ticket should match to in ISC.

I think we can live with using SC_request but i want to understand why is it different when tracking ritm.

@mcheek : Appreciate any thoughts on this.

2

Are you seeing a “ticket number” in the account activities?

I’m gonna have to see if I can track down the code for the rest endpoint on the servicenow side because I don’t have that plugin installed in my demo instance currently

My suspicion is your $.result.items mapping isn’t correct but I’ll see what I can find

NVM that’s correct

3

Thanks for quick response. Yes. I see ticket number in account activities. its just that it keeps creating same tickets while there is already a pending request.

4

Are you able to hit the servicenow table API to look at the response for the status checks?

I’m thinking maybe it’s returning a state value that isn’t in your status mapping

Also state for RITM is always a numeric string unless you specifically put sysparm_display_value=true in the URL

5

I can get the status of RITM and I verified again that the status is mapped :

I don’t know but should i check what the tracking_id value should be ?

I thought tracking_id on ServiceNow should be trackingNumber in Sailpoint and if the account acctivity has 3 sources, then i think the 3 RITMs created through that particular prov’ing process should have same tracking_id and that should eb trackingNumebr in the Sailpoint. but imy case those 3 have different tracking_id value and none of those are matching with Sailpoint. Am I wrong about the tracking_id part?

image
image1009×488 24.3 KB

6

The rest endpoint on the ServiceNow side basically takes the payload directly sent to it from SailPoint and creates an RITM. Now, the request body sent to ServiceNow has an items array, which gets iterated through. So if ISC is sending more than one item in the payload, more than one RITM will be created.

Tracking ID is the field label on the RITM but I’m fairly certain the field name is tracking_number which should be the trackingNumber from ISC - are you seeing 3 different values for those on your RITMs?

7

yes. it is different for each RITM in same REQ.

I also want to mention again that the catalog item is not the ootb. I wan to pull our SNOW folks on to a call and verify if there are any differences which came ootb to to this custom but i am not sure if I know what to check.

I will try to capture the payload they are getting when these are made.

8

It’s possible that the catalog items you’re using might not have a Tracking Id variable on them, so that’s not getting sent back to ISC. IDK why that would be needed but it’s possible that could be an issue.

You can see in the code that if you choose to use RITM tracking, it includes trackingId in the response payload along with the RITM number - so maybe ISC needs that to map back and track.

    // Prepare response
    response = {
        "request_number": rc.request_number
    };
    // Return REQ number
    if (returnRitm === false) {
        response = {
            "request_number": rc.request_number
        };
        return response;
    }

    var responseJson = "";
    var item1 = [];

    var ritmRecord = new GlideRecord('sc_req_item');
    ritmRecord.addQuery('request', rc.request_id);
    ritmRecord.query();

    while (ritmRecord.next()) {
        var variables = ritmRecord.variables.getElements();
        for (var j = 0; j < variables.length; j++) {
            if (variables[j] != '' && variables[j] != undefined) {
                var question = variables[j].getQuestion();
                var label = question.getLabel();
                var value = question.getDisplayValue();
                if (label.equals('Tracking ID')) {
                    item1.push({
                        trackingId: value,
                        ticketNumber: ritmRecord.number.toString()
                    });
                    break;
                }
            }
        }
    }

    response = {
        items: item1
    };

    return response;

Side note, I feel the pain of the developer who had to write this ES5 compatible looping structure through the variables instead of more modern JS methods :smile:

9

Thanks @mcheek . I will let you know here once i talk to my friends on SNOW side and review this code but this is very helpful. I have something to work with them now. :folded_hands:

10

Cheers, best of luck with MCI on Sunday

11

about that. I am keeping my expectations in check. :wink:

12

I met with our ServiceNow folks and had them look into what you have pointed and everything is as is. but your input was very helpful to have some conversation with them.

It turns out, the culprit was setting below to true. There is no document reference as to what this is or does. in fact, customer support asked us to keep this true. we have now set this to false and its been about a week and results are good so far.

“noProvisioningRequests”: true

Thanks for the swift response. This helped me the momentum going.