Use of a standard logging framework would make most of this less brittle through extension. A working debugger would help make much of this moot. Ability to debug running business rule logic would put OS lightyears ahead of the CPM field from a development perspective.
Ultimately, logging should be the responsibility of the developer. If that developer is OneStream, then start there. Use a standard logging framework and establish logging practices.
Redaction where logging is our only form of debugging, may potentially cripple the development process.
I also think that OS will find that redaction is a brittle, reactive design approach - on they will be in constant maintenance of. Extend a standard framework with redaction services and make that configurable.
An alternative to redaction is to extend a logging framework with something specifies something written to the log as "Administrative" such that it doesn't get listed in the log viewer unless the user is in the Administrator group.
Logging doesn't sell the product. Use off the shelf standard frameworks, and focus on features that sell.
Couldn't agree more, Robb! Alas, no word yet that the 'feature' of redacting is going to be removed, made optional, or made at least somewhat controllable.
Besides the fact that it limits our ability to test, it also just seems arbitrary. I mentioned it before, but someone really needs to explain to me what purpose redacting of the decimal positions serves. And one, albeit repeated example, the redacting of the value of a constant called CLASSNAME, but not redacting it when I change the name to RULENAME.
All of this is secondary to your much more important point that Onestream needs a debugging/logging framework.
And while i am on it, may I add a feature to check out and check in rules, and actually every object, so that we don't overwrite each other's work. I can check out and check in a report in narrative reporting but not a rule.
(edit) - As I thought this through a little further.
While I would love to have access to a runtime debugger for business rules, a runtime debugger does not replace the sort of degugging info I need to write to a log. A runtime code debugger and a logger serve two different needs.
For logging, I personally think a far simpler and better solution would be to provide a pair of new api/BRApi.UserLog() functions The idea of a user log would be to provide us a place to write whatever debugging type info we need without any redacting. The user log would only be viewable by the user who invoked the logic, and auto-delete when the user logs out the last session they may have open. As such, the user log might persist for a day at most. If you need to be debugging logic that someone else needs to run, then use the existing ErrorLog that can have some reasonable redacting (by "reasonable", I mean far less redacted than is currently being done with 9.0). A UserLog needs to collect log info for the one or more sessions a user may have running at any given time, so it is possible to view the UserLog from another session the user has open. It might even be handy to have a button to access the user log placed next to the Task Activity button, so non-admins can easily access their user log without having access to System.
The vast of majority of debugging stuff I personally write to the ErrorLog is of no value much more than 5 minutes later and simply makes it harder to find the log entries that do belong in the ErrorLog. Some of my log entries will still need to go to the ErrorLog, but the vast majority would more rightfully belong in a UserLog. An added benefit of a UserLog is that the entries will already be filtered to that user and with no other fluff. The only downside of this possible UserLog solution would be if one forgot to turnoff debugging when done (not that we ever forget), it might take longer for us to notice, during which system performance would remain less than optimal.
Please don't let OS off with this approach. If you've ever used a debugger to troubleshoot code, you know the amount of time it saves vs having to physically type out BRApi.ErrorLog.LogMessage(si, $"Some Value is: {value}") to write every last variable to the log, then stop execution and read the log.
The very idea that code you had to write to "debug", you have to delete 5 min later is the very reason for the debugger. With that tool you never have to write the code that writes to the log in the first place. Huge productivity increase immediately. Run the code, follow execution flow, and observe the variable values in realtime, in the actual code. You'll almost never use the log for this again.
At a minimum, we should be using a live console and not the log for writing things that pertain to troubleshooting runtime execution.
I revised my suggestion slightly. Much of what I log to the ErrorLog would be a bit out of scope of a traditional runtime code debugger. I will capture multiple specific pieces of info/loop and output all of that into a single ErrorLog entry. A traditional runtime code debugger would allow me to step through the code one line at a time and look at any of the variables at that point in time to more readily see where and why a block of code is coming off the rails, or to assist in finding coding inefficiencies. As such, we need both a runtime code debugger and also have a means of logging whatever messages we see fit to a UserLog. The two serve different but complementary purposes.
