Assigning AD group to Business Role via API

Just for completeness, which version are you using?

I assume that UID_Org=82a38937-7ed6-4aea-9e77-59dbf432f8b1 and UID_ADSGroup=08fd7d42-4b93-4040-9271-fe04d52d26db then your call need to look like this.

POST request to:

AppServer/api/assignments/OrgHasADSGroup/UID_Org/82a38937-7ed6-4aea-9e77-59dbf432f8b1

BODY contains:

{"members": ["31d99791-d658-40d7-b5e5-58eecf998797"]}

Note that the members property is lowercase.

Thank you Markus, I lowercased the members without luck.

We are on version 8.0

I grabbed the "Business Role" from "/api/entities/BaseTree": UID_Org=82a38937-7ed6-4aea-9e77-59dbf432f8b1

I grabbed the "AD Group" from "api/entities/ADSGroup": UID_ADSGroup=08fd7d42-4b93-4040-9271-fe04d52d26db

POST: AppServer/api/assignments/OrgHasADSGroup/UID_Org/82a38937-7ed6-4aea-9e77-59dbf432f8b1
BODY: {"members": ["31d99791-d658-40d7-b5e5-58eecf998797"]}

Just gives back: 

assigned removed
-------- -------
0 0

I can confirm the Role does not contain the AD group.

Does this method work on your side?

First of all, I would check the log of the Application Server for any errors that might have happened.

Secondly, are you sure that the UID_ORG = 82a38937-7ed6-4aea-9e77-59dbf432f8b1 is part of the Org view? I am asking because you are fetching this via the BaseTree table.

And third, can you assign this AD Group to the same Org via the Object Browser using the same login credentials?

1. No errors that I can see, are there API specific logs somewhere?

2. I think this is the issue... what table should an Employee Type Business Role be pulled from in this case?

3. Yes it can

Rest API logs are in the AppServer log as well. You can turn the log level to debug or trace, in either case, you will see more messages.

And yes, it tried it with the API Documentation page which is doing pure REST API calls. I do not know which tool or language you are using to set the value but the body has to be defined as content-type application/json, just as a reminder.

Wow that was it, not explicitly adding the content type was the issue! Of course it is good practice but many APIs these days will simply default, interestingly I would have expected an error to be thrown rather than showing 0/0 assigned/removed. I feel kind of silly, sorry for the waste of time here, hopefully this helps someone else though :-/. On another note it seems that once a group is added and you try to add again an error is thrown... rather than simply showing that it was not action'ed... it seems the behaviors for missing content type and adding existing groups are opposite what would be expected.. IMHO ;-).

Thanks for your suggestions. We are looking into these.

Just as an explanation for the error thrown. Think about adding not just one but 10 memberships, in the case that one item would silently fail, the caller might want to know which one is failing to act accordingly.

We are currently thinking about adding the option to let the API ignore these types of errors for adds and deletes and returning the list of tolerated members in an additional return property.

Thanks for your suggestions. We are looking into these.

Just as an explanation for the error thrown. Think about adding not just one but 10 memberships, in the case that one item would silently fail, the caller might want to know which one is failing to act accordingly.

We are currently thinking about adding the option to let the API ignore these types of errors for adds and deletes and returning the list of tolerated members in an additional return property.

Great to hear!

In terms of multiple memberships the issue is still relatively the same, if the first member fails due to it already existing, the rest of the set fails. I agree if it failed to be added due to incompatibility (cross domain - non-universal group, or wrong guid, etc) 100% it should error. However, if it failed due to the member already existing it could fail silent and the assigned tally could be skipped for that group, and/or a third tally column (no_action) could be used.

Of course this is not a pressing issue as one could simply check the mappings in (OrgHasADSGroup) and remove any in the set that exist.... as I am now doing :-).

We have created backlog entry VPR#32930 for this enhancement. Thank you.