SCIM 2.0 Disable Operation

[k_diksha (Diksha Keshri)]

Which IIQ version are you inquiring about?

8.2]

Please share any images or screenshots, if relevant.

Please share any other relevant files that may be required (for example, logs).

Share all details about your problem, including any error messages you may have received.

I am connected to SCIM2.0 connector and found that during every scim call api path is part of payload but when it is for enable/disable for “active” path is not mentioned as part of payload created by sailpoint what is the reason

In case of add entitlement, the payload has path.

{
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"
    ],
    "Operations": [
        {
            "op": "add",
            "path": "entitlements",
            "value": [
                {
                    "value": "31"
                }
            ]
        }
    ]
}

But in case of active path is missing any specific reason?

{
   "schemas": [
       "urn:ietf:params:scim:api:messages:2.0:PatchOp"
   ],
   "Operations": [
       {
           "op": "replace",
           "value": {
               "active": "false"
           }
       }
   ]
 }

[Arpitha1 (Arpitha Halaguru Kunne Gowda)]

@k_diksha Both way is correct as ‘path’ is optional parameter.

Please refer this link for more details.

[k_diksha (Diksha Keshri)]

Thanks @Arpitha1 for sharing the link

[bhanuprakashkuruva]

Hi @k_diksha ,

It all depends on how the application behaves and how the application expects the request along with the payload from the external sources. That is how the application team could have developed the APIs to perform actions in the application using APIs from external apps. So, in your case, the error showing 400 bad request, the reason for a 400 response is typically due to malformed request syntax, invalid request message framing, or deceptive request routing.

So for this, what you can try is. for whatever the application you are trying, there will be documentation for all these APIs related (for create, delete, update, disable, enable etc). So check with the application team where you can find the documentation for the APIs. Once you get that APIs list, then find out the disabled API. And compare with whatever you are getting in the logs.

Besides this, you get the request endpoint in the logs along with the payload and use the same thing in the Postman application and see if it will work or not. If it does not work, then check the disable API in the documentation as mentioned above and prepare like that and try. Once you get success in the Postman application, you can check in SailPoint logs to see if SailPoint is sending the request the same way or not (btw, you can’t play much with the endpoint request in the SCIM connector because we don’t have the control or in the scope on that, but you can confirm if the APIs are sending properly or not).