on 04-15-2013 9:38 AM
Hi All,
I am currently developing a customized IdM UI using the REST API.
It works fine with every attribute that is configured as a text attribute.
Is it possible to use the REST API to make a request on a Entry reference attribute?
I would like to the following:
/idmrest/v72alpha/entries?EntryType=PERSON&MX_MANAGER={MSKEY=12345}
I am using the following release versions:
REST API: v72alpha
SAP NW IdM: v7.2 SP5
Thank you for the help.
Moritz
Hello Moritz,
I have observed the same problem on SP5. Here's a workaround that solved the problem for me. It is clearly a hack; if anybody has a cleaner solution, I'd definitely be interested.
1. Create a new attribute for reverse lookup of MX_MANAGER
In the MMC, create a new attribute, e.g. Z_PERSON_BY_MANAGER. On the tab "Storage", make sure that the attribute type is "General Attribute" (not "Entry Reference"), and the data type is "Text".
On the tab "Presentation", make sure that presentation is "Single Select". This point is crucial; any other presentation type cannot be used for this workaround solution.
On the tab "Attribute Values", select "SQL Query" and enter the following query (no matter which DB you're using):
SELECT
mcthismskey
FROM idmv_link_ext
WHERE mcattrname='MX_MANAGER'
AND mcothermskey=%USERMSKEY%
2. Create a new UI Task that lists this new attribute
Still in the MMC, create a new UI task, e.g. "search_by_manager" in your provisioning folder.
On the tab "Attributes", set "Entry Type" to "MX_PERSON", and make sure that the new attribute Z_PERSON_BY_MANAGER has the option "List" set. I personally choose not to list any other attributes in this UI task (although it wouldn't hurt for our purposes).
Make sure to add an appropriate access control to the UI task. I choose "Logged in"/"All"/"Everybody".
With that configuration made, I was able to solve the actual REST problem at hand at runtime, again in two steps:
1. Invoke the value help of Z_PERSON_BY_MANAGER to get MSKEYs
Invoke the following URL path to invoke the user-dependent value help of Z_PERSON_BY_MANAGER to get the MSKEYs of all persons that have MSKEY=42 as their manager. The example assumes that 2873 is the ID of your UI task created in step 2 above:
/idmrest/v72alpha/entries/42/tasks/2873/attributes/Z_PERSON_BY_MANAGER
This gives me the following JSON result with two persons (MSKEY=25 and MSKEY=30) who have MSKEY=42 as their manager:
{"MX_REST_SUCCESS":true,"Z_PERSON_BY_MANAGER":{"AllowedValues":[{"VALUE":"","KEY":""},{"VALUE":"25","KEY":"25"},{"VALUE":"30","KEY":"30"}],"DISPLAYVALUE":"","VALUE":""}}
2. Fetch the actual data of each person resulting from step 1
You can now iterate all items in that response in JavaScript and fetch their complete data with the usual approach:
/idmrest/v72alpha/entries/25
/idmrest/v72alpha/entries/30
Alternative 1-step solution
If you are concerned about the performance implications of this approach (it will require n+1 roundtrips, where n is the size of your initial query result set), you could even be more nifty by fetching all your person attributes needed directly in the value help query. In this case, you could specify the following SQL query on the "Attribute Values" tab of the Z_PERSON_BY_MANAGER properties:
/* Fetch more person data in one shot */
SELECT
l.mcthismskey /* mskey */
|| '!!'
|| v1.avalue /* mx_firstname */
|| '!!'
|| v2.avalue /*mx_lastname */
AS person_data
FROM idmv_link_ext l
LEFT OUTER JOIN idmv_value_basic v1
ON l.mcthismskey=v1.mskey
AND v1.attrname='MX_FIRSTNAME'
LEFT OUTER JOIN idmv_value_basic v2
ON l.mcthismskey=v2.mskey
AND v2.attrname='MX_LASTNAME'
WHERE l.mcattrname='MX_MANAGER'
AND l.mcothermskey=%USERMSKEY%
This gives me the values of MSKEY plus two attributes I'm interested in, concatenated by '!!'. The following JSON response is the result:
{"MX_REST_SUCCESS":true,"Z_PERSON_BY_MANAGER":{"AllowedValues":[{"VALUE":"","KEY":""},{"VALUE":"25!!Holger!!Badstuber","KEY":"25!!Holger!!Badstuber"},{"VALUE":"30!!David!!Alaba","KEY":"30!!David!!Alaba"}],"DISPLAYVALUE":"","VALUE":""}}
Again, this will require custom JavaScript parsing code on the client side, but at least you only require one roundtrip to get all the data you want. I haven't tested this with NULL values, i.e. when any of the persons doesn't have MX_FIRSTNAME or MX_LASTNAME
Hope that helps,
Lambert
Last line of the second query was lost in my copy and paste. Added "AND mcothermskey=%USERMSKEY%" to the second value help query, otherwise this wouldn't work as expected. Message was edited by: Lambert Boskamp
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Lambert Boskamp wrote:
I have observed the same problem on SP5. Here's a workaround that solved the problem for me. It is clearly a hack; if anybody has a cleaner solution, I'd definitely be interested.
Like I posted in my reply to be yet moderated, , I did a copy of manager-attribute as simple text-attribute. The drawback with that is duplicating data and the information must be kept up to date when manager changes and exisitng user base has to be migrated with the duplicate attribute.
Hi,
just assign 12345 directly to the MX_MANAGER attribute. You can also use <MSKEYVALUE> if that is easier...
MX_MANAGER=12345
Cheers,
Sietze
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Sietze,
of course I am using valid MSKEYS.
There is no error message, but using the URI with the specified parameters is not working, because
there is no filter.
Using:
idmrest/v72alpha/entries?EntryType=MX_PERSON&MX_MANAGER=12345
is returning every Person and not only those having the argument MX_MANAGER=12345.
Cheers,
Moritz
Are you trying to search with reference attributes? Like what employess have the same manager?
It's not possible (sp7), so made a copy of the manager-attribute to make the search work.
The personnel numbers were considered sensitive information, otherwise would have used the MX_FS_PERSONNEL_NUMBER_OF_MANAGER for the same query.
User | Count |
---|---|
98 | |
11 | |
11 | |
10 | |
10 | |
8 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.