I have a comment around the following language in the documentation:
If the target source is a direct connection, then the request body must be empty. If the target source is a delimited file source, then the CSV file needs to be included in the request body.
However, disableOptimization attribute is a body attribute. I just tested this in our sandbox with Postman. Can someone please correct the documentation?
Good point. I included this in ticket DEVREL-1521.
The documentation has been updated.
The documentation has mentioned to enable the idn:account:create as a scope, but that doesnāt seem to be an actual scope value in the system.
What is the minimum scope actually needed for this API?
Welcome to the Developer Community, @beam_ntth! Thanks for catching that!
The correct scope is idn:account:manage
The docs have been updated.
The UI is still using the cc API for loading accounts in Sandbox. Do you know when the UI is going to be updated to use the new API ?
Thank you Colin!
Is the new beta API being expedited for a /v3 release? We now have around six weeks before the /cc endpoint is deprecated and need to migrate to using the new endpoint, but since it is /beta it is subject to design changes without notification, correct? Iām not overly comfortable migrating my production environment to use an endpoint that can change without notice.
Dear all,
Iād like to relate to the questions above, and add some of my own
Iāve been trying to use the beta api from a workflow to do an unoptimised aggregation - it works fine from postman, but all Iām getting via the workflow is optimised aggregations - is this a known bug?
Workflow json below
{
"name": "unoptimised aggregation",
"description": "",
},
"definition": {
"start": "HTTP Request",
"steps": {
"End Step - Success": {
"displayName": "",
"type": "success"
},
"HTTP Request": {
"actionId": "sp:http",
"attributes": {
"authenticationType": "OAuth",
"formRequestBody": {
"disableOptimization": "true"
},
"method": "post",
"oAuthClientId": "redacted",
"oAuthClientSecret": "redacted",
"oAuthScope": null,
"oAuthTokenUrl": "https://redacted.api.identitynow.com/oauth/token",
"requestContentType": "form",
"url": "https://redacted.api.identitynow.com/beta/sources/xxxxxxxx3f60a43efb7xxxxxxxx/load-accounts",
"urlParams": null
},
"displayName": "",
"nextStep": "End Step - Success",
"type": "action",
"versionNumber": 2
}
}
},
"trigger": {
"type": "SCHEDULED",
"attributes": {
"cronString": "30 04 * * *",
"frequency": "cronSchedule",
"timeZone": "Europe/London"
}
}
}
I also tried with the formRequestBody formatted like this (which is the way it is done in the Co-Lab example that uses the cc version), but this also resulted in an optimised aggregation.
"formRequestBody": "disableOptimization:true",
Iām having the same issue. I tested with a webhook site and it looks like using the āformā Content-Type results in āapplication/x-www-form-urlencodedā on the http request. From the beta endpoint documentation it looks like it is expecting a āmultipart/form-dataā content-type, which I think is what is causing the problem.
Hi Fabio. Welcome to the Developer Community.
Beta can change with short notice, but itās rare that we do so in practice. We usually stick to non breaking changes, like adding new features. We donāt have a firm timeline on when it will move to v3, but you should prefer to use the beta version for now because the CC version will be shutoff this year. If you are experiencing any issues using the beta version, you can ask for help in this forum or open a support ticket if it is time sensitive.
@caryharper Welcome to the Developer Community.
I think @liamkokeeffe is correct. Workflows doesnāt support multipart/form-data, which is needed by this new API. I am talking with the engineering team to see how we can best solve this.
Hi @colin_mckibben,
My suggestion on how this can be best solved (which I believe is also the quickest) is to update the API and also allow Content-Type = application/json for this POST API, where we can give this in the body:
{
"disableOptimization": true
}
Besides application/json+patch for the PATCH APIs, almost all ISC APIs are using type application/json, so I would encourage keeping that, where I do understand we canāt use it for CSV imports.
In general APIs are able to accept multiple content types and handle them accordingly. I hope that the SailPoint API infrastructure has been designed in such a way that it is also easily possible to add handlers for multiple content types.
Allowing workflows to support multipart/form-data can be nice, but I can image it takes much more time for SailPoint to include it, time that might be spend better in other parts of the ISC product, including workflows.
Kind regards,
Angelo
Thatās an interesting thought. I can propose that as well to the team. I have also suggested to them to make disableOptimization a query param instead of a body param. The discussion is still ongoing though.
Ahh that would work as well, I think I might like your suggestion even more as it is a simple key value pair and it will not break max URL length. Unless you foresee additional parameters where those values are better represented as JSON object. As long as the API will not complain when we try performing a unoptimised aggregation without added CSV file whilst giving the standard Content-Type it should be good and then the workflow can deal with is as well without having to specify a different Content-Type.
Note that the workflows HTTP request is slightly broken when doing a GET operation, as the API will still give a body with content and Content-Length=4, which will result in errors on some endpoints that donāt expect any body on GET calls (even if the given body is the four letter code NULL) and will complain because of this.
Kind regards,
Angelo
Looking back, I see this issue was previously reported and acknowledged. Do we have an ETA on these actions logging as āsystemā?
I can see in the API response to the cc version the ālauncherā is the username, but the same ālauncherā response for beta comes back as āsystemā, and this is also still what is recorded in the UI.
Thanks Neil!
Following up, I have heard from our Engineering that this was fixed, and on the release train to sandbox and production. It currently is in āpre-releaseā status, so I would estimate this would probably be released in the next week or so. Iāve asked for clarification on timing, and will let you know if I hear anything.
Is anyone having an issue where they kick off an unoptimized aggregation where the API call is successful but when looking in the UI is says 0 accounts scanned successful. Not sure if I am doing something incorrectly or not.
{
"success": true,
"task": {
"type": "QUARTZ",
"id": "f968c9b2051243248194d3df8b6624ae",
"name": "Cloud Account Aggregation",
"description": "Aggregates from the specified application.",
"parentName": null,
"launcher": "System",
"created": 1715702112838,
"launched": 1715702112849,
"completed": null,
"completionStatus": null,
"messages": [],
"returns": [
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_APPLICATIONS",
"attributeName": "applications"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_TOTAL",
"attributeName": "total"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_OPTIMIZED",
"attributeName": "optimizedAggregation"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_IGNORED",
"attributeName": "ignored"
},
{
"displayLabel": "TASK_OUT_UNCHANGED_ACCOUNTS",
"attributeName": "optimized"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_CREATED",
"attributeName": "created"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_UPDATED",
"attributeName": "updated"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_DELETED",
"attributeName": "deleted"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_MANAGER_CHANGES",
"attributeName": "managerChanges"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_BUSINESS_ROLE_CHANGES",
"attributeName": "detectedRoleChanges"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_EXCEPTION_CHANGES",
"attributeName": "exceptionChanges"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_POLICIES",
"attributeName": "policies"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_POLICY_VIOLATIONS",
"attributeName": "policyViolations"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_POLICY_NOTIFICATIONS",
"attributeName": "policyNotifications"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_SCORES_CHANGED",
"attributeName": "scoresChanged"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_SNAPSHOTS_CREATED",
"attributeName": "snapshotsCreated"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_SCOPES_CREATED",
"attributeName": "scopesCreated"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_SCOPES_CORRELATED",
"attributeName": "scopesCorrelated"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_SCOPES_SELECTED",
"attributeName": "scopesSelected"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_SCOPES_DORMANT",
"attributeName": "scopesDormant"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_UNSCOPED_IDENTITIES",
"attributeName": "unscopedIdentities"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_CERTIFICATIONS_CREATED",
"attributeName": "certificationsCreated"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_CERTIFICATIONS_DELETED",
"attributeName": "certificationsDeleted"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_APPLICATIONS_GENERATED",
"attributeName": "applicationsGenerated"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_MANAGED_ATTRIBUTES_PROMOTED",
"attributeName": "managedAttributesCreated"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_MANAGED_ATTRIBUTES_PROMOTED_BY_APP",
"attributeName": "managedAttributesCreatedByApplication"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_IDENTITYENTITLEMENTS_CREATED",
"attributeName": "identityEntitlementsCreated"
},
{
"displayLabel": "TASK_OUT_ACCOUNT_AGGREGATION_GROUPS_CREATED",
"attributeName": "groupsCreated"
}
],
"attributes": {
"eventId": 1074697,
"clusterCcgBuild": "742",
"appId": "2c91808983e6f7250183f66daa0237a9",
"optimizedAggregation": "disabled"
},
"progress": null
}
}
Afternoon everyone! Has there been any development of being able to run unoptimized source aggregations via workflows with this new beta API?
Weāve tried various forms of SailPoint workflows and even Power Automate flows without success on /beta/sources/{id}/load-accounts
Hi SailPoint team,
What is the timeline for deprecating this cc apiā for load accounts? Is that still mid june? We are also facing some issues in automating this rest api call for non-optimized aggregation.