{
"description": "Export all available rules",
"excludeTypes": [],
"includeTypes": [
"RULE"
],
"objectOptions": {}
}
Save the jobId that is returned for use in the next two steps.
Check the status of the export job using https://developer.sailpoint.com/idn/api/beta/get-sp-config-export-status. You will need to provide the jobId from the last step in the URL of this endpoint. Depending on the size of data that needs to be exported, this can take a few seconds to a few minutes. You will need to wait for the status to show COMPLETE before you can download the results.
How would we be able to get a cloud rule name / ID to attach to sources? Would the expectation to be to use SP-Config to initiate an export of rules and the get an name / ID from there? That should work fine - just annoyingly cumbersome compared to having an endpoint for cloud rules.
We are currently going through an IDN implementation. This endpoint is crucial to troubleshooting cloud rules. Otherwise, we cannot view the rules to check the logic as far as I know. It’s rough enough we have to submit a ticket every time they need updated, but being unable to view them is going to be a big roadblock.
Is there another method of viewing the script the cloud rule is running? Can the deprecation simply be pushed until the replacement is available?
I agree, this feels like quite an important endpoint for troubleshooting rules. The description is very clear to me, when you say “There will not be a public replacement available before March 31st” does that mean that there will be a replacement on March 31st or that there’s no planned replacement or ETA for a replacement? As @jalexand says, it’s already a pain that we have to pay extra to get these updated, would be even worse if we had to pay just to see what the rules look like.
Umm, HELP!! - This does NOT return any data, it just starts a background job.
Can you please advise how to update the ruby I/O TOOL (idnio-2.3.4b) to manage this?? (rules.rb) (We’ve been relying on this and have history for 3+ years as our fortnightly backup.)
My ruby knowledge is only as far as I can google - or can AI rewrite it for us??
Sorry about that. You are correct in that this a three step process. I have updated the post to describe each step needed to get the rules, as well as how to do this using Config Hub.
You will need to update your ruby script to follow the three step process mentioned above. I too would need to google the right ruby code but here is some pseudo code to help you update your script. This is not ruby code, just an example of the steps you would need to take in your code to accomplish exporting rules. You’ll need to google the correct ruby code to make this work.
payload = {
"description": "Export all available rules",
"excludeTypes": [],
"includeTypes": [
"RULE"
],
"objectOptions": {}
}
# initiate the export job for all rules
response = IDNAPI.post("/beta/sp-config/export", payload)
jobId = response["jobId"] # Save the jobId
# Check the status of the job every 5 seconds until it is complete
exportStatusUrl = "/beta/sp-config/export/" + jobId
while (JSON.parse(IDNAPI.get(exportStatusUrl).body)["status"] != "COMPLETE")
wait(5) # wait 5 seconds
# Get the results
exportDownloadUrl = "/beta/sp-config/export/" + jobId + "/download"
response = IDNAPI.get(exportDownloadUrl)
rules = JSON.parse(response.body)
The Visual Studio Code Extension for IDN included listing Rules (though just connector rules for whatever reason). We use that tool a large amount for our ongoing enhancements as we flesh out our IDN implementation from last year (2023). To your knowledge is the maintainer of that tool incorporating the new approach for Rules ?
Right, thanks. And I likely answered my own question as it looks like the VS Code rules management uses the Beta Connector Rule Managment APIs, so it should still be ok. And that explains why it just shows the Connector rules and not any Cloud rules.
One key difference I note in the new approach to retrieving Rules is that the beta/sp-config/export API response does not seem to include any of the default rules vs. the /cc/api/rule/list API which included the default/demo rules. i.e. only rules which have been customized in the target tenant are returned by beta/sp-config/export.
Pros and Cons to this difference. Is this on purpose ?
@reklawttocs
Currently, the VSCode plugin can export all rules through the SPConfig.
I have just tested and by selected all rules, cloud rules will also be exported.
Actually, I just learned from Colin’s answer that the SPConfig could be leveraged to get the cloud rules.
Not sure what I can do more.
Cloud rules will not be “editable” as connector rules.
Feel free to create an issue as an enhancement request and to write your expectation, expected behavior and all.
I hope there will be an API available similar to GET /api/rule/list.
Now we are dependent on using the CLI, sp-config or the config-hub, all of which require additional steps, is less user friendly and is not consistent with all other objects that are easily available through GET /v3/any_object_types.
Something like GET /v3/rules that directly gives a JSON array of the rules would be consistent here. We already have GET /beta/connector-rules, which only shows the connector-rules. Instead of /v3/rules it would also be fine for me if an API like GET /v3/cloud-rules would become available. Then we can also use APIs to fetch all rules easily.
1000% agreed. Having to go through sp-config, config hub, or vs code is significantly less user friendly than having a direct API endpoint to get at the data.
Just look at my documentation tool from dev days. Having to engineer in a solution for sp-config instead of having a direct API call is a lot more overhead than what is necessary IMO
Similar to other posts, it would be good to be able to export all rules because, as it is currently working, we are not able to export any SDIM Integration BeforeProvisioning rules.
