400 Bad Request : WebService Connector

[Gopi2000 (Gopi S)]

Hi There,

In our scenario, there are multiple entitlement types, each with its own endpoint (e.g., teams, entities, roles_products). The roles_products entitlement type has a unique format that consists of multiple entitlement values combined into a single entitlement. For instance, 18:A represents a single entitlement, where 18 is the role, and A is the product.

To handle this, we have implemented an After Operation Rule to process these values in a concatenated format. During provisioning, this rule splits the concatenated value to match the required payload format.

Problem Statement 1:

When we provision multiple roles_products entitlements as part of an access profile, the system returns a message indicating that roles_products are already assigned. This triggers multiple requests based on the number of entitlements, causing redundancy.

Problem Statement 2:

To address the above issue, we set the addRemoveEntInSingleReq parameter to true in the connection settings. This resolves the problem by sending a single request instead of multiple requests. However, this approach introduces a new challenge: we cannot add different types of entitlements (e.g., teams, entities, roles_products) into an access profile because each entitlement type corresponds to a different endpoint. As a result, we receive a 400 Bad Request error, which is expected.

Request for Assistance:

Could you suggest an approach to address these issues? Specifically:

1. How can we prevent redundant requests for roles_products entitlements while provisioning them within an access profile?
2. How can we support adding multiple entitlement types (with their respective endpoints) into a single access profile without encountering errors?

[sushantkulkarni]

It doesn’t look like the addRemoveEntInSingleReq flag will be the best fit for your use case since you have separate endpoints for entitlement types.

You mentioned that roles_products consists of multiple entitlement values combined into a single entitlement: How is it combined, is it delimited? If I am understanding correctly, 18:Afrom your example is one entitlement. Is it like a comma delimited, or pipe delimited string you’re seeing in after operation that you break into individual entitlements? Example:18:A|19:B|20:C —> 18:A and 19:B and 20:C?

If you are doing this, I don’t see why you should face redundancy issue during provisioning. Does your roles_productsendpoint not handle internal list update of the entitlements?

[Gopi2000 (Gopi S)]

Hi @sushantkulkarni

Yeah, the ‘addRemoveEntInSingleReq’ flag doesn’t work for our scenario.

Here’s the rule we’ve used for your reference. The issue seems to be that when it comes to access profiles, the system triggers multiple requests based on the entitlement count. However, in our code, a static payload is generated each time, which leads to the error.

Provisioning error: webservices before operation rule

Hi There, I’m trying to provision an entitlement called ‘roles-products.’ I can provision it individually or in bulk by submitting multiple entitlement requests at once. However, when it comes to an access profile, I am unable to provision an access profile that contains more than one entitlement of this type. I am receiving an error stating that the entitlement has already been assigned. Despite the error, when I check the target system, the entitlement appears to have been provisioned, but i…

In this rule, we’ve processed all attribute requests in a single payload. However, the same payload is being passed for multiple requests. Is there a way to pass individual values into the payload for each request rather than processing and sending them all at once?

Example Scenario:
Let’s consider an access profile that consists of two entitlements: 18:A and 18:B.
In our current rule, the payload is generated in the following format:

[
  {"roleId": 18, "ProductId": "A"},
  {"roleId": 18, "ProductId": "B"}
]

The issue is that this same payload is passed twice since there are two entitlements in the access profile, and this is where the error occurs.

Requirement:
Instead of sending the entire payload twice, we need to process the entitlements individually. For example:

• During the first processing, the payload should be:

[{"roleId": 18, "ProductId": "A"}]

• During the second processing, the payload should be:

[{"roleId": 18, "ProductId": "B"}]

Request:
Is it possible to process the entitlements inside the access profile individually and generate separate payloads for each request? If so, could you suggest an approach for this?

[vguleria (Vikas Guleria)]

Hi @Gopi2000

Thank you for the question.

I think you need to update the after operation rule while provisioning the AP where you need to first check if the role is already assigned to the user or not and same for product and then adjust the payload accordingly.

So you extract the role value from requested entitlement and then make a get API using restClient and then check if the role is already assigned to the user if so then there is no need to include this role into the payload (assuming there is no PATCH API). And same thing for product if the product is already assigned then send only the information about the role in the payload if both are not assigned then include both of them in the payload.

I am not sure if you are already using the same process on account aggregation where you read the product and role assignment and then store the entitlement attribute in the same format as 18:A otherwise when the scheduled aggregation rule and if these assignments are provisioning via ISC roles then ISC will keep trying to provision these roles again and again.

I hope this helps.

Regards
Vikas.

[Gopi2000 (Gopi S)]

Thankyou Everyone for Helping

Problem Statement:
I was unable to provision an access profile that contained multiple entitlements of the type roles-products, especially when including other types such as entities or teams.

Solution:
Findings: While fetching the provisioning plan and retrieving the attribute requests, the input is processed as a list. Since the access profile includes multiple entitlements, it was triggering the provisioning process multiple times, resulting in the same payload being sent repeatedly and causing the issue.

Resolution:
Instead of working with the provisioning plan directly, I utilized the WebServices Before Operation Rule to extract and work with the request body. By fetching the JSON body from the rule, I was able to split the entitlements into separate requests and process them individually. This approach resolved the issue effectively and avoided the duplication problem that occurred with the earlier method.

[bhavithra (bhavithra palanisamy)]

Thanku Gopi. It is very useful for everyone.