Webservices Connector: retry operation using DIFFERENT API endpoint

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

:bangbang: Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic

Dear colleagues,

I have a question about WebServices connectors in IdentitySecurityCloud, and I can’t find the answer in the forum.

If the connector receives a specific, recognizable error message during an operation (say: the API call associated to a CREATE ACCOUNT operation), is it possible to have it retry the operation, but using a different endpoint?

For example: imagine the account creation is associated to
POST https: //yaddayadda/create/{user}, and this operation returns a specific error. As a result, still as part of the account creation, we want to fire
POST https: //yaddayadda/fix/{user}.

My heart tells me that this should be possible with some After Operation Rule magic. Can it be done?

Thank you in advance

Best regards
Fabio Carraro

2

Yes, This can be accomplished using Web Services After Operation Rule.
Here’s the general pattern:

import connector.common.JsonUtil;
import sailpoint.connector.webservices.WebServicesClient;
import java.util.HashMap;
import java.util.ArrayList;

Map response = JsonUtil.toMap(rawResponseObject);

// Check for specific error condition
if (response.get("error") != null && response.get("error").equals("SpecificErrorCode")) {
    
    // Create new client or use existing restClient
    WebServicesClient client = new WebServicesClient();
    String fixUrl = "https://yaddayadda/fix/{user}";
    
    Map args = new HashMap();
    args.put(WebServicesClient.ARG_URL, fixUrl);
    client.configure(args);
    
    Map header = requestEndPoint.getHeader();
    List<String> allowedStatuses = new ArrayList();
    allowedStatuses.add("2**");
    
    Map payload = new HashMap();
    // Build your fix payload here
    
    String fixResponse = client.executePost(fixUrl, payload, header, allowedStatuses);
    
    // Process the fix response and return updated data
}

Hope this helps.

3

Awesome, thanks for the info.

Just for my complete understanding: there is no other way of achieving this, than a custom Rule, right? Or, at least, this is the recommended solution.

Duplicating the operations in the configuration (like in the screenshot below) would achieve nothing, am I correct?

image
image878×312 5.95 KB

4

You cannot execute 2 endpoints on the create account operation unless these have Parent and child relationship in the configuration. AfterOperationRule is the best and recommended solution.

5

Yes, that’s correct. Duplicating only creates a copy, allowing you to add more details or adjust the configuration for a new operation. However, you cannot use two separate “Create account” operations with different URLs.

6

Nice, thanks for the info.
One last question: how do I “log“ the behavior of my rule (I need to debug it, if doesn’t work). Can I have output printed? I imagine I should connect to the VA and monitor the CCG.

7

The rule includes a default logger that can be used for logging — simply call log.info() or log.error() as needed.

8

Thanks everyone.

Unfortunately, since I introduced the logging, it seems that the Rule, that I attached to the correct operation, is not taken in charge at all. It seems that it is completely ignored.

Just for context.

  • I have validated the Rule with the dedicated API
  • I have attached the rule (type: WebServiceAfterOperationRule) to the correct operation (CREATE)
    -The rule is attached as an “afterRule“, I have checked.

Still, when the connector fires a CREATE and fails (correctly, with the expected error), it seems that the Rule never kicks in.
Do I need to set up something, for retry in case of failure? Does the call need to be SUCCESSFUL, if I want the Rule to be executed?

9

Dear colleagues,
I am still struggling with this.

In the snippet above, Sita Ram has written:
// Create new client or use existing restClient
WebServicesClient client = new WebServicesClient();

Now, how do I re-use the existing client that the operation should already have used? In other words, how do I re-cycle the configuration of the source, when it comes to connecting to the WebService? I don’t want to re-write the parameters in the Rule code.

THanks

10

Some of the info above is incorrect. Your screenshot of where you had two create operation calls would achieve something. When you have two calls of the same operation defined, the connector will chain those two calls together. They would always be called even if the first one was successful, so you may receive an error on the second attempt that the account already exists.

Using the after rule on the create operation is probably the better approach anyways. You do not have to define a completely new WebServicesClient in the rule. The connector passes an instance into the rule already by name restClient, however you do have to re-define the parameters, but you can get them from the already configured operation which is calling the after rule. Here’s an example:

//Grab original headers and URL
Map originalHeaders = requestEndPoint.getHeader();
String fullUrl = requestEndPoint.getFullUrl() + "/" + employeeId + "/domains";

//Build JSONObject for this individual request
JSONObject reqJson = new JSONObject();
reqJson.put("domain_id", "8");

//Execute PATCH request for individual attribute
String response = restClient.executePost(fullUrl, reqJson.toString(), requestEndPoint.getHeader(), Arrays.asList("200"));

See the javadoc (sailpoint.connector.webservices) for more info: Java docs | SailPoint Developer Community

11

Awesome, thanks Patrick. I was able to adapt your example to our scenario and make it work!

Thanks everyone

1 Like