Looking for a community answer, as SailPoint documentation seems a bit conflicting. Does the JDBC connector + rule support the delete operation?
Basically, I want to use the “manage accounts” action in a workflow to initiate the delete operation. The connector rule will use the code block under the delete operation to prepare a sql statement to write “delete” to a DB attribute.
When I tried this, the workflow threw an error: (workflow works fine with a disable operation)
“errorMessage”: “request failed (type: Bad Request, retryable: false): 400 - 400 Bad Request”
} else if (AccountRequest.Operation.Delete.equals(account.getOperation())) {
statement = connection.prepareStatement("UPDATE OBFUSCATED.TABLE.NAME SET STATUS = 'delete' WHERE PK_IDENTIFIER = ?");
statement.setString(1, (String) account.getNativeIdentity());
statement.executeUpdate();
result.setStatus(ProvisioningResult.STATUS_COMMITTED);
Hi Jonathan - the “Delete” operation is supported - see here for examples
However, the ‘Delete’ operation right now on Workflows appears to only be supported for Delimited Files (see Manage Accounts on Workflow Actions - SailPoint Identity Services ) - unless the Workflow Actions page is out of date.
What use case are you trying to achieve by running the ‘Delete’ in the workflow? There may be another way to meet your needs that doesn’t involve a workflow
Ahhhh, delete via workflow is the issue, not the operation itself.
Basically, I wanted to use the delete operation as a trigger to write a specific value to the DB. We use a “dummy group” generated during account aggregation, as this table doesn’t have legitimate entitlements, only accounts. Therefore, we can never truly remove the accounts via access revocation.
The thought was, we use a workflow to trigger on the revocation, send a delete operation, use the connector rule to write “delete” to the DB, then the DB admins can use a stored procedure to clean up the account resulting in the account removal from the identity.
Hope that makes sense. These sources need love from the owners anyway, just trying to gain some functionality in the interim.
With this, you can key in certain reactions in your Source to change what you want to do based on certain behaviour. In your case, you can use this to change something like a Remove Entitlement operation to one where you update an attribute in your plan. Similarly, you could set it as a ‘Delete’ operation in your lifecycle state, change that to a ‘Modify’, and set that attribute in your provisioning plan
I have explored the SSBPR, but we’re not ready to move to that yet. @margocbain thank you for the help!
That said, I’ve found a simpler solution. I didn’t realize I could trigger on the dummy group removal (even though it’s not actually removed of course). We do have the dummy group (IDNGROUP) as an entitlement in our account schema. Basic logic in the connector rule should solve our use cases. I’ll share the logic below in case it can help others in a similar situation with dummy groups.
if (account != null) {
AttributeRequest attrReq = account.getAttributeRequest("IDNGROUP");
if (attrReq != null && ProvisioningPlan.Operation.Remove.equals(attrReq.getOperation())) {
statement = connection.prepareStatement("UPDATE OBFUSCATED.TABLE.NAME SET STATUS = 'delete' WHERE PK_IDENTIFIER = ?");
statement.setString(1, (String) account.getNativeIdentity());
statement.executeUpdate();
result.setStatus(ProvisioningResult.STATUS_COMMITTED);
}
}