vRealize Orchestrator log message considerations

Both System.log and Server.log are commands in vRealize Orchestrator that are used to log (debug) information from your workflow or action. Apart from System.log, you can also use System.debug | error | warn or Server.debug | error | warn. Log, debug, error or warn determines the log level for the message you’re generating.

The format of a log message is very straightforward:

System.log ("This is a log message");

The big difference between System.log and Server.log is where the message is logged. System.log logs messages to the logs pain of a workflow run (or workflow token) and the system.log log file of vRealize Orchestrator. To see the log messages in the workflow run you must have the vRO client available at the time the workflow is running, the information in the client is lost after you close the vRO client. The system.log file of vRO automatically rotates, which means logs are cleared up and lost.

The Server.log command works exactly the same, but logs messages to the vRO database and the Events pane in the vRO client:

Server.log ("This is another log message");

Log messages logged by the Server.log command are kept for eternity in the database. Server.log messages will always show up in the Events pane of the vRO client, this is not depending on if the vRO client was running at the time of the message was generated.

In most cases System.log is used for debugging workflows. Be careful with logging messages using Server.log because these messages are saved to the vRO database. In case of extensive logging your database will grow quite fast.

Be careful with logging passwords

Another important consideration is what do you want to log. In your workflows you will be talking to external systems; for these systems you will probably need a username and a password. I’ve seen a lot of workflows that also log these passwords. Although this maybe required for some debugging, be careful with this because your password is also logged to the server.log logfile or vRO database….that’s not something I want to see.

Using the securestring type in vRO doesn’t change anything to this, you can still log a securestring in exactly the same way as a normal string. A simple trick is to replace the password in the logging using the replace() function. For example:

var username = "administrator";
var password = "P@ssw0rd";
System.log ("Username: " + username + " and Password: " + password.replace(password, "******");

Or if you want the number of asterix/stars depending on the length of the password string, you can use Array.join(). This will look something like:

var username = "administrator";
var password = "P@ssw0rd";
System.log ("Username: " + username + " and Password: " + Array(password.length+1).join("*"));

Or just don’t log the password at all. If the password is in your system.log and you have to share this file for troubleshooting, you’re maybe sharing some critical passwords…just be careful.

Replacing the password is specifically handy when you’re writing & launching Powershell scripts from vRO. These scripts will probably contain some kind of username/password information, you can mask this information in the logging using the replace() or Array().join() function.

Another question you should ask yourself is if you always want to log everything? You can choose to introduce a true/false value which determines if you want to log messages. Just a simple if statement and your set.

var blLogging = true;
 if (blLogging) System.log ("Only log when blLogging = true");

By adding this true/false to all you workflows and actions you can choose to pass the parameter to the different workflows you’re calling from the main workflow.

The throw command

A last command that also logs information is the throw command:

throw ("An error has occurred!");

Throw generates an error event, your workflow will quit and logs information to the workflow stub and the server.log file of the vRealize Orchestrator. The throw message includes your custom message, but also includes the name of the workflow and the element that generated the error.

Hope this helps, stay tuned for more articles on automation & orchestration. Just follow me on twitter to get updated when new articles on published on this site.