cancel
Showing results for 
Search instead for 
Did you mean: 

REST Request with Reference Attribute

moritz_kppen
Explorer
0 Kudos

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

Accepted Solutions (1)

Accepted Solutions (1)

lambert-giese
Active Participant
0 Kudos

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.

Designtime

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".

Runtime

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

terovirta
Active Contributor
0 Kudos

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.

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi,

just assign 12345 directly to the MX_MANAGER attribute. You can also use <MSKEYVALUE> if that is easier...

MX_MANAGER=12345

Cheers,

Sietze

moritz_kppen
Explorer
0 Kudos

Hi Sietze,

seems that you didn't quite get my problem.

Of course I already tried using the direct way:

/idmrest/v72alpha/entries?EntryType=PERSON&MX_MANAGER=12345

This doenst work, because it is not an assigned text attribute, but a reference attribute.

Cheers,

Moritz

Former Member
0 Kudos

Hi Moritz,

it worked for me. I only used SP6 and SP7 and only used MXREF_MX_ROLE and so on, but I don't see the difference here.

You have to make sure that 12345 is a valid MSKEY though.

What is the exact error message?

Cheers,

Sietze

moritz_kppen
Explorer
0 Kudos

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

Former Member
0 Kudos

Hi,

the task you're using has the attribute MX_MANAGER included?

Cheers,

Sietze

moritz_kppen
Explorer
0 Kudos

Hi,

the taks does include the argument.

Maybe this really is a SP5 problem.

Cheers,

Moritz

terovirta
Active Contributor
0 Kudos

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.