Configuring Requests for Multiple Entitlements

Feedback Documentation Feedback Connectivity Documentation Feedback
1

The connector can send a single request for several instances of one entitlement type to the managed system. For example, you can send a single request for several instances of RoleID.

This is the companion discussion topic for the documentation at https://documentation.sailpoint.com/connectors/webservices/help/integrating_webservices/configuring_multiple_entitlement_requests.html
2

I think some clarification needs to be made on this document…

When the document refers to sending “Multiple Entitlements” within the same request, what it is ACTUALLY saying is that you can send multiple entitlements of the same TYPE.

So if you have $plan.RoleId$ as your entitlement and in your Account Schema an Identity can have more than ONE of these (ie. RoleId1, RoleId2, RoleId3) Then when you use the information in this document, the Connector will be able to send ALL of those roles over in a single request.

Meaning, THIS part of the documentation is correct:

{ "addRoleIds": $plan.addRoleIds$  }


1. If `addRemoveEntInSingleReq` is set to `false`, then the placeholder value for the attribute marked as an entitlement is passed in separate API requests.

First request payload:
jsonBody={ "addRoleIds": "9dd23398-b905-4878-b7ad-bc02d22171d9" }

Second request payload:
jsonBody={ "addRoleIds": "8defe39c0-54f6-47b4-8a15-fcc2622923sk" }

2. If `addRemoveEntInSingleReq` is set to `true`, then the placeholder value for the attribute marked as an entitlement is passed as an array and is executed in a single request.

Single request payload, passed as an ARRAY:
jsonBody={ "addRoleIds": ["97ee39c0-54f6-47b4-8a15-fcc262292386","8defe39

Where this falls apart, is defining what happens when you send Multiple Entitlement Requests of the DIFFERENT Types.

For Example:
You have on Entitlement Type called ROLEID and another entitlement type called SERVICEID.

Because these types are not the same, they will be sent as separate requests, EVEN if you have this <entry key="addRemoveEntInSingleReq"> set to TRUE.

This means that if your API requires multiple Entitlement Types be sent at the same time, eg…

<UserSetup>
     <firstname> John </firstname>
     <lastname> Doe </lastname>
     <ROLEID> $plan.roleId$ </ROLEID>
     <SERVICEID>$plan.serviceId$</SERVICEID>
</UserSetup>

your request will fail…
Because ISC will send the Entitlements SEPARATELY, the API will only pick up one set and not the other.

tell me I’m wrong

4

Hi Bakhari, I don’t know if you’re wrong :slight_smile: but we’ll run your question by engineering and get their feedback. We’ve created a Jira issue to track the effort and we’ll update the comment thread when it’s been addressed: CONDOCS-4072

5

Hi all. The work on CONDOCS-4072 has been completed and the document has been updated. Thanks!

6

Hello

In the documentation example you have attribute RoleID but then you have $plan.addRoleIds$

Should that be $plan.RoleID$ ? How does RoleID become addRoleIds ?

(‘add’ is prefixed, ‘d’ becomes lowercase, then ‘s’ is added as suffix)

If I have an entitlement groupGUID - does that become addgroupGuids automagically?

Thanks

7

Hi @jrossicare, thank you for your input. We’re looking into your feedback, and we’ll update this thread when we’ve completed that review.

1 Like
9

Hi @jrossicare,

The work for CONDOCS-8103 has been completed and the document has been updated. The examples should coincide with the RoleID example given at the beginning of the topic.

-Josh

10

Hi @joshb488

Does it take a while to refresh?

I still see

The following is a JSON string example for the payload:

{
  "RoleID": $plan.addRoleIds$
}

Is that correct? plan.addRoleIds ?

11

Hi @jrossicare,

That’s what I was told by Engineering. The placeholders in the example didn’t change, only the attribute that referred to it.

-Josh

12

Thanks Josh.

I appreciate the fast turnaround time for this.