Ivanti ITSM Integration with Generic SDIM (Workaround Fix)

Identity Security Cloud (ISC) ISC Community Knowledge Base
,
1

Hello,

If anyone is using the Generic SDIM Service Desk connector and is having trouble / issues getting it to work. I was able to make it work by modifying the object using the VS Code tenant module. Ticket fetching, status mapping and status updating are all working correctly. You can modify your status map to fit your requirements / itsm instance. In the example we are using an ITSM filtered query for the exact ticket number since we cannot use $ticketID (ticket number) as a “unique key” compatible with ITSM e.g recId. It is very important to send the attachmentToDelete as specified, otherwise you will encounter an error since ITSM expects this value and sailpoint natively strips null values from requests, this is why “attachmentsToDelete”: will not work, but “attachmentsToDelete”: [[“”, “”]] or “attachmentsToDelete”: [ [ null, null ]] will work as the object gets successfully sent. You must include the [0] to catch the first result when returning filtered queries, “responseElement”: “$.value[0].Status”.

When configuring the connector, use basic auth and use whatever you’d like for the username and password.

Additional information found here for finding your parameters here: Create a Service Request

Here is the example configuration:

"generic": {
            "checkStatus": {
                "headers": {
                    "Authorization": "rest_api_key=<your-api-key>",
                    "Accept-Encoding": "gzip, deflate, br"
                },
                "statusMap": {
                    "Submitted": "Queued",
                    "Closed": "Committed",
                    "Fulfilled": "Committed",
                    "Error": "Failed",
                    "Cancelled": "Failed"
                },
                "resource": "/api/odata/businessobject/servicereqs?%24filter=ServiceReqNumber%20eq%20$ticketId",
                "responseElement": "$.value[0].Status",
                "statusMapClosureCode": null
            },
            "provision": {
                "headers": {
                    "Authorization": "rest_api_key=<your-api-key>",
                    "Accept-Encoding": "gzip, deflate, br"
                },
                "request": {
                    "attachmentsToDelete": [
                        [
                            null,
                            null
                        ]
                    ],
                    "strCustomerLocation": [],
                    "localOffset": -330,
                    "attachmentsToUpload": [],
                    "strUserId": "<id>",
                    "subscriptionId": "<id>",
                    "parameters": {
                        "par-<id>-recId": "<id>",
                        "par-<id>": "IT Security Architect",
                        "par-<id>": "Ivan Valadez (ivaladez)",
                        "par-<id>": "8067759858",
                        "par-<id>": "Testing 12345678",
                        "par-<id>": "[email protected]",
                        "par-<id>": "Testing 12345678",
                        "par-<id>": "IT Security"
                    }
                },
                "requestRootElement": null,
                "processResponseElementExpression": null,
                "resource": "/api/rest/ServiceRequest/new",
                "responseElement": "$.ServiceRequests[0].strRequestNum",
                "requestRootElementType": "JSONObject"
            }
        },
        "username": "int"
    },
2

are you using Ivanti Neurons?

4

Yes, that is correct. Ivanti Neurons ITSM.

5

How are you handling tikcet creation in case of role assignement, who is going to be a requster? Also, how are you handling when the identity does not exist in Ivanti, for example a new hire who does not have account in Ivanti yet

6

also, do you think it is possible to populate the parameters dynamically, because in the example you are hardcoding the values, but is it possible to somehow pass those values, such as requester &requestee, ticket type and description

7

Yes, just use the jsonPath values e.g $.xyz , example: “par-id”: “$request.resource”, would send the source name to that parameter.

8

Sending some of the information in the Description parameter is a possible solution. The requester can be an integration account. Then assign tickets based on workflow (ivanti) to the correct groups. Just depends on how you’ve configured your ITSM. Just some thoughts.