GRC WebServices - Invalid priority type

[former_member201064]

Hello forum,

I have a problem regarding the priority types in the IdM -> GRC webservices (posted here and in IdM forum as well).

This problem occurs for the webservices GRAC_LOOKUP_WS and GRAC_USER_ACCES_WS.

Using the webservice GRAC_LOOKUP_WS I cannot retrieve any data for the priorities. I tried re-adding the configuration as I read in another thread here. But that didn't helped a bit (or maybe I did it wrong?!).

Using the IdM VDS and SoapUI I get the same errors for GRAC_USER_ACCES_WS:

<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
   <soap-env:Header/>
   <soap-env:Body>
      <n0:GracIdmUsrAccsReqServicesResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">
         <MsgReturn>
            <MsgNo>4</MsgNo>
            <MsgType>ERROR</MsgType>
            <MsgStatement>Invalid priority type</MsgStatement>
         </MsgReturn>
         <RequestId/>
         <RequestNo/>
      </n0:GracIdmUsrAccsReqServicesResponse>
   </soap-env:Body>
</soap-env:Envelope>

Here the XML from SoapUI (shortened a bit by the items, but they are correctly configured)

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:sap-com:document:sap:soap:functions:mc-style">
   <soapenv:Header/>
   <soapenv:Body>
      <urn:GracIdmUsrAccsReqServices>

         <RequestHeaderData>
            <Reqtype>001</Reqtype>
            <Priority></Priority>
            <ReqDueDate></ReqDueDate>
            <ReqInitSystem>GRC_TO_IDM</ReqInitSystem>
            <Requestorid>Trui</Requestorid>
            <Email>trui.dominik@knauf.de</Email>
            <RequestReason>Hello world</RequestReason>
            <Funcarea>func</Funcarea>
            <Bproc>bproc</Bproc>
         </RequestHeaderData>
         <RequestedLineItem>
            <!--Zero or more repetitions:-->
            <item>
               <ItemName>V_DEGI_00140</ItemName>
               <Connector>GRC_TO_IDM</Connector>
               <ProvItemType>ROL</ProvItemType>
               <ProvType></ProvType>
               <AssignmentType></AssignmentType>
               <ProvStatus></ProvStatus>
               <ValidFrom>20150922</ValidFrom>
               <ValidTo>20151231</ValidTo>
               <FfOwner></FfOwner>
               <Comments></Comments>
               <ProvAction>006</ProvAction>
               <RoleType>BUS</RoleType>
            </item>
         </RequestedLineItem>
         <!--Optional:-->
         <UserGroup>
            <!--Zero or more repetitions:-->
            <item>
               <UserGroup></UserGroup>
               <UserGroupDesc></UserGroupDesc>
            </item>
         </UserGroup>
         <UserInfo>
            <!--Zero or more repetitions:-->
            <item>
... all items
            </item>
         </UserInfo>
      </urn:GracIdmUsrAccsReqServices>
   </soapenv:Body>
</soapenv:Envelope>

When I look in the table GRACPRIORITYT there are five priorities stored, from 1 to 5.

I cannot figure out where the problem could be. I tried various values like: High, Medium, 1, 3, 5, 001, 003, 010, ...

Any ideas on this?

Best regards

Dominik Trui

[alessandr0 · Accepted solution]

Dear Dominik,

I assume that the priority types are not maintained for the process ID you are requesting. Make sure that the priorities are maintained accordingly (SPRO > GRC > Access Control > User Provisioning > Maintain Priority Configuration).

For access requests use MSMP Process ID SAP_GRAC_ACCESS_REQUEST, etc.

Priorities are then stored in table GRACPRIORITY and are three characters long (e.g. 001). GRACPRIORITYT contains the texts to the maintained priorities.

Hope this helps.

Regards,

Alessandro

[former_member201064 · Accepted solution]

Hello Alessandro,

indeed, they were missing. The five already configured had other process ID's.

After adding two priorities with that type, they can be loaded from GRC into IdM and the error vanished.

I now have some other problems because I misconfigured the GRAC_USER_ACCES_WS but I should be able to solve that.

Thank you

Dominik