Unable to finish task with provisioning job for access request

[fuko]

Hi Saviynt forum,

As part of the access request process, I need to configure AddAccessJSON and configure a Provisioning Job (WSRETRYJOB) with that target application. The job seems to run successfully (checking from log seems no error) but the task still at the pending queue. I don't know where to look further. Could someone help shedding a light on?

For the AddAccessJSON, I already try to replace the dynamic values in param with fixed and valid values but still got nothing happen. In other words, instead of:

      "httpParams": "{\"ApplicationCode\": \"StarField\", \"UserId\": \"${account.accountID}\", \"RoleList\": [\"${entitlementValue.entitlementID}\"]}",

it becomes

      "httpParams": "{\"ApplicationCode\": \"StarField\", \"UserId\": \"phill\", \"RoleList\": [\"Admin\"]}",

To make sure that my pending task is associated with the right job, I check the task's detail and does see the number of triggered job matching with the number of times I triggered the provisioning job.

Attached is the log file from the last provisioning job run. The keyword to search for the AdddAccessJSON is AssignAppRole which is the target application's endpoint for assigning role.

[Vedanth-BK]

Hi @fuko 
Please share your add access Json and what is the Entitlement Type name in your endpoint?

[fuko]

Hi @Vedanth-BK,

The AddAccessJSON looks like as below and the entitlement type (i think) is role:

{
  "call": [
    {
      "name": "Role assignment",
      "connection": "acctAuth",
      "url": "https://XXX/OSUserRoleManagement_Core/rest/UserManagementAPI/AssignAppRole",
      "httpMethod": "POST",
      "httpParams": "{\"ApplicationCode\": \"StarField\", \"UserId\": \"${account.accountID}\", \"RoleList\": [\"${entitlementValue.entitlementID}\"]}",
      "httpHeaders": {
        "appkey": "ZZZ",
        "Accept": "application/json"
      },
      "httpContentType": "application/json",
      "successResponses": {
        "statusCode": [
          200
        ]
      }
    }
  ]
}

[Vedanth-BK]

The entitlement type name  and the name specified in the Json should be the same. 
i.e. if its role in the endpoint then role  in the json as well

{
  "call": [
    {
      "name": "role",

[fuko]

Thanks @Vedanth-BK,

But it still does not work 😞

{
  "call": [
    {
      "name": "Role",
      "connection": "acctAuth",
      "url": "https://xxx/OSUserRoleManagement_Core/rest/UserManagementAPI/AssignAppRole",
      "httpMethod": "POST",
      "httpContentType": "application/json",
      "httpParams": "{\"ApplicationCode\": \"StarField\", \"UserId\": \"devia\", \"RoleList\": [\"Award_Admin\"]}",
      "httpHeaders": {
        "Accept": "application/json",
        "appkey": "zzz"
      },
      "successResponses": {
        "statusCode": [
          200
        ]
      }
    }
  ]
}

Still the same keyword for lookup in the log: "addAccessJSON"

[Raghu]

@fuko  Logs saying 200 resp , look success try below

{
"call": [
{
"name": "Role",
"connection": "acctAuth",
"url": "https://XXX/OSUserRoleManagement_Core/rest/UserManagementAPI/AssignAppRole",
"httpMethod": "POST",
"httpParams": "{\"ApplicationCode\": \"StarField\", \"UserId\": \"${account.accountID}\", \"RoleList\": \"${entitlementValue.entitlementID}\"}",
"httpHeaders": {
"appkey": "ZZZ"
},
"httpContentType": "application/json",
"successResponses": {
"statusCode": [
200
]
},
"unsuccessResponses": {
"statusCode": [400, 403, 401, 404, 409, 501, 500]
}
}
]
}

[rushikeshvartak]

Validate below

• send Authorization 
• check entitlement type name

[fuko · Accepted solution]

Hi all, just to update on this topic.

In summary, I wanted to test the ability to assign an entitlement to an account in an application A but I never see the traffic goes out or the endpoint was invoked at the application A side. Only until playing around with another similar application, we discover that configuring only the AddAccessJSON won't get me anywhere, the other related JSON strings are also required (e.g., CreateAccountJSON, RemoveAccessJSON, RemoveAccountJSON). I didn't do the trial and error method to test whether only one specific additional JSON string or a combination of JSON string are sufficient, instead filling up all CreateAccountJSON, RemoveAccessJSON and  RemoveAccountJSON, and it works like a charm.