I need to debug a WebServiceBeforeOperationRule. Is it possible to do this using the Sailpoint CLI?
I don’t really understand this debugging part. I know that when I enable temporary logging, it is recorded in the ccg.log, but the file is huge.
I would like to know if it is possible to get this information in real time using the CLI.
Hi @raibom ,
If you’re using the SailPoint CLI to interact with IdentityNow, I believe you can query logs through the Logging API (though this is not real-time, it’s still useful to pull recent logs). You can run a command that filters logs for specific timestamps, users, or rule executions.
What I need is to monitor the logs generated by the rule, for example log.warn, log.error…
If it is a SaaS based web services connector (i.e. one that doesn’t need a VA), you can use the SailPoint CLI, if not you have to use ccg.log.
What I usually do is add a standard prefix to all my debug statements in the rule, that way it will be easier to grep on them and potentially pipe that into a separate file. Example, add “WS-RULE-XXXX” and then do:
grep "WS-RULE-XXXX" ccg.log > WS-RULE-XXXX.log
1 Like
Hello @sauvee , thanks for the reply. I believe that is the point.
This is starting from a VA and I have to maintain an existing rule.
In the code of the rule called there are several log.warn().
I changed the log-config with the following body:
{
"durationMinutes": 5,
"rootLevel": "TRACE",
"logLevels": {
"sailpoint.connector.webservices": "DEBUG"
}
}
After that I generated the entitlement removal events that are generating errors.
I generated the file as mentioned successfully.
But in the logs of this file the log.warn() of the rule do not appear. Several events appeared but with the same error that is displayed in sailpoint.
Another thing I noticed is that all the logs are as “Operation”: “Modify”
I don’t know if this is correct. Because the action was remove. Although modify also gave an error.
What I have noticed before that it takes some time for the log config to take effect on the VA, so it could be that the 5 minute window you set there is too short. Can you try with a 60 minute window instead, see if that catches any of the errors?
I’ll try the way you suggested. Would it be possible to export the data and only bring the logs generated in the last 60 minutes?
From what I understand, this command will return all the logs regardless of the time they were generated, correct?
That way it would be easier to filter.
Yes exactly, the logging will return all logging. That is why it is always good practice to put in some text in your rule’s log statements that allows you to filter them through a grep command (or search for them in a text editor if you prefer).
Going with logs is fine, but there is another faster way of debugging.
I use
throw new exception("your data::"+ variable);
I will print the values whatever and wherever I need a couple of times to understand where the problem is, this will display data in Identity page and in search page as well.
I know this is ugly but it is quick, not suitable for debugging in Production environment.
Thanks
Krish
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.