Looks like db query exceeds database character limit can you paste your JDBC provisioning rule or prepared statement for add entitlement that you tried btw which db it is ?
Coming back to logs/ test query make sure rule is attached properly and debug log statements are present or you might have missed capturing latest log to deal with that add some unique characters to log.debug(“*********”+var); statements
The connector still requires a valid Add Entitlement SQL statement and executes that directly. If the SQL exceeds the 256-character limit, the recommended workaround is to encapsulate the logic in a stored procedure (or database function) and invoke that from addEntitlementSQl.
Recommendation:
1.First check add entitlement query in your database.
2.then Execure through a configuration or JDBC Provisioning Rule.
Hi @sxxnex it should not be necessary any other configurations, just the rule attached to the source. Take into account that the add/remove entitlement operation is caught as a Modify operation, as follows:
Operation operation = accountRequest.getOperation();
List attributesRequestList = accountRequest.getAttributeRequests();
if (AccountRequest.Operation.Create.equals(operation)) {
// query for create account
} else if (AccountRequest.Operation.Modify.equals(operation)) {
Iterator attributeRequestsIterator = attributesRequestList.iterator();
while (attributeRequestsIterator.hasNext()) {
AttributeRequest attributeRequest = (AttributeRequest) attributeRequestsIterator.next();
String updateOperation = attributeRequest.getOp().toString();
if (updateOperation.equalsIgnoreCase("Add")) {
// add entitlement
}
else if (updateOperation.equalsIgnoreCase("Remove")) {
// remove entitlement
}
}
}
@sxxnex Based on your configuration, the JDBC Provisioning Rule is likely not being invoked for Add Entitlement operations because ISC still expects a valid value in the Add Entitlement SQL field and executes that operation directly. The provisioning rule is typically used to customize provisioning behavior, but it does not automatically replace all entitlement operation SQL statements. The dummy query (select 1) satisfies validation but may prevent the connector from invoking the rule for the entitlement action itself.
A few things to verify:
Ensure the rule is correctly attached to the source and the rule name matches exactly.
Confirm the rule type is JDBCProvision and not another JDBC rule type.
Check whether the entitlement request reaches the Virtual Appliance by reviewing ccg.log.
Verify that the entitlement operation is actually generating an Add Entitlement provisioning plan.
Test whether the same rule is invoked for Create, Modify, or Remove Entitlement operations.
Unfortunately, the JDBC connector does not currently provide a mechanism to leave the Add Entitlement SQL field blank when entitlement provisioning is enabled. If the operation requires logic exceeding the 256-character SQL limit, common approaches are:
Move the complex logic into a stored procedure and call it from the Add Entitlement SQL.
Use a database function/procedure wrapper and pass the required parameters.
Split the logic across multiple SQL statements if supported by your use case.
For example:
EXEC dbo.AddEntitlement ?, ?
or
CALL AddEntitlement(?, ?)
This avoids the 256-character limitation while keeping the entitlement operation supported by the JDBC connector.
My suspicion is that the JDBC Provisioning Rule is not intended to fully replace the Add Entitlement SQL operation, which is why the rule is not firing when only a placeholder query is configured. I would recommend checking the provisioning transaction in ccg.log to confirm whether the connector is executing the SQL directly and bypassing the rule for that operation.
The database we are using is PostgreSQL, and the prepared statement for Add Entitlement is an INSERT statement.
When I created the JDBC Provisioning Rule, I intentionally added an log.error() statement at the very beginning so that I could easily verify whether the rule was being executed. I also enabled debug mode on the Virtual Appliance cluster before testing Add Entitlement provisioning. However, no log entries from the rule appear in the VA logs, which makes me think that the rule is not being invoked at all.
Regarding the rule attachment, my understanding is that the rule is correctly attached if the source configuration contains the following connector attribute:
/connectorAttributes/jdbcProvisionRule
For example:
"jdbcProvisionRule": "test_rule_v0.1"
Is that correct?
The beginning of my rule looks like this:
ProvisioningResult result = new ProvisioningResult();
public Object getAttributeValue(AccountRequest acctReq, String attribute)
{
if (acctReq != null)
{
AttributeRequest attrReq = acctReq.getAttributeRequest(attribute);
if (attrReq != null)
{
return attrReq.getValue();
}
}
return null;
}
log.error("========== JDBC ROLE PROVISION START ==========");
Since even this log.error() message never appears in the VA logs, it seems the rule itself is not being executed. Am I missing any additional configuration required for the JDBC Provisioning Rule to be invoked for Add Entitlement operations?
Unfortunately, using a stored procedure is not an option in our environment, so we are trying to handle the Add Entitlement operation through a JDBC Provisioning Rule instead.
The Add Entitlement SQL itself works correctly when executed, so the SQL is not the issue.
Is there any additional configuration required to make the JDBC Provisioning Rule execute for Add Entitlement operations? Or should the rule be invoked automatically once it is attached to the source?
If the JDBC Provisioning Rule is not intended to replace the Add Entitlement SQL directly, could you please advise what kind of SQL statement should be configured in the Add Entitlement SQL field to allow the Provisioning Rule to be invoked?
Currently, we are trying to handle the Add Entitlement operation through the Provisioning Rule because using a stored procedure is not possible in our environment.
I have already confirmed from the ccg.log that the Add Entitlement operation is being processed by the connector. However, I am not sure how to verify the Provisioning Transaction you mentioned in the log.
Select Add Entitlement to add SQL queries which add entitlements during create operations.
Under Add Entitlement, select Add.
In the Entitlement Type field, add the entitlement key in the following format:
.addEntitlementSQL
For example, if the entitlement attribute in the account schema is Roles, add the following:
Roles.addEntitlementSQL
In the Query field, add an SQL query or a stored procedure to add the Roles entitlement to an account.
SQL Query
If the attribute is included in the Provisioning Plan:
insert into databasename.tablename (attribute1,attribute2) values ($plan.attribute1$, $plan.Roles$)
Or
insert into databasename.tablename (attribute1,attribute2) values ($plan.nativeIdentity$, $plan.Roles$)
If the attribute is not included in the Provisioning Plan, you can fetch it using a SELECT query, then insert the response of the first query into the second query:
SELECT attribute FROM databasename.tablename WHERE fname = $plan.attribute1$;
insert into databasename.tablename (attribute1,attribute2) values ($response.attribute$, $plan.Roles$)
