We have an application for which the APIs return the response in CSV format. The CSV can be modified to include required attributes.
From documentation SailPoint only supports XML / JSON based responses. I wanted to check if the WebServices Connector will be able to consume this response. If yes, please help with any reference documentation for the same.
The webservices connector does expect the data to be returned in a json or xml format. I haven’t encountered an API that returns a CSV, but I have seen an API that returns plain text. In that case, we had to use an after operation rule to put the text into a json object that we defined in the response mapping.
In the above, the critical factors are the return of the processedData (by that exact name), and that the processedData has a key called “data” that contains the object you are creating. The field in our response mapping was “response”, based on the key in the textResponse Map. The textResponse Map needs to be stored in an ArrayList.
The rawResponseObject is a String that you’ll have to parse and then iterate with a for loop. Hopefully this gets you started. For further examples, use the Web Services After Operation Rule doc:
Thank you @MattUribe for your response, we were able to POC using afterOperationRule. We have three different entitlement Types; can we create three different rules and map them separately to each one of them or a single rule should handle all of the entitlement types.
If you have 3 entitlement types, then you should have 3 different HTTP operations. You could have a separate rule attached to each HTTP operation and it would be fine. However, I’ve come to the point where I like to have as few rules as possible, and if I have multiple entitlements types, I’ll just use a switch within the rule to determine which entitlement type I’m processing. This way the logic that overlaps isn’t duplicated across multiple rules, which makes updates messy.
Do the different types need to be processed differently? If you are just trying to make a CSV out of the response, one fairly simple rule should be able to cover all entitlement types. If you do need to alter your logic based on the entitlement type, then something like this should help:
//Get operation type
String operationType = requestEndPoint.getOperationType();
logMessage = "operationType --> " + operationType;
ruleLogger(logMessage, "debug");
//Determine entitlement type and operation
switch (operationType) {
case "Type 1":
//logic here
break;
case "Type 2":
//logic here
break;
case "Type 3":
//logic here
break;
}
Thank you @MattUribe for quick response. Yes, intention is to have single rule.
Each of the entitlement type has a different URL, But I am not able to differentiate the entitlement types inside rule. Tried with requestEndpoint.getUniqueNameforendpoint but it is not helping.
What does operation type return and how can we differentiate each of these. Please advise.
The operation type for aggregating entitlements is usually “Group Aggregation”. If you have additional entitlement types, then you need additional HTTP operations defined for each, and the operation will be “Group Aggregation-”.
requestEndPoint.getOperationType() should return a String that you can compare for expected values. It is getting the value from the connection parameters property for the HTTP operation called “operationType”.
After you use String operationType = requestEndPoint.getOperationType(); log out the value of operationType to make sure you are getting what you expect. Be careful using the unique name for the endpoint, it is more likely to change than the operation type.