Logger for better Logs in VCF Operations Orchestrator

VCF Operations Orchestrator cannot dynamically include an action or sub-workflow name in console logs. The expression this.workflow.name returns the top-level workflow name, even inside sub-workflows and actions.

I described my solution on SimplyGeek several years ago. I still consider it the best option and believe it avoids these logging limitations.

My Logger class provides consistent logging across actions and workflows. Import it wherever you need to identify the source of a message.

You can download my Logger module as a package here or as native JS here.

This example uses Logger in addComputerToAD, an action that adds a computer object to Active Directory:

+00:00 INFO [Action: WindowsConfigService] Get activeDirectoryDomainName
+00:00 INFO [Action: WindowsConfigService] Found activeDirectoryDomainName: FREELANCERCOLO
+00:00 INFO [Action: WindowsConfigService] Get activeDirectoryServerOUDN
+00:00 INFO [Action: WindowsConfigService] Found activeDirectoryServerOUDN: OU=Windows,OU=flc-servers,DC=freelancercolo,DC=local
+00:00 INFO [Action: addComputerToAD] activeDirectoryDomainName: FREELANCERCOLO
+00:00 INFO [Action: addComputerToAD] activeDirectoryServerOUDN: OU=Windows,OU=flc-servers,DC=freelancercolo,DC=local
+00:00 INFO [Action: addComputerToAD] activeDirectoryServerOUName: Windows
+00:00 INFO [Action: addComputerToAD] Creating Active Directory computer account 'flcgs10' in OU path 'OU=Windows,OU=flc-servers,DC=freelancercolo,DC=local'
+00:00 DEBUG [Action: ActiveDirectoryService] Get Active Directory Host with name 'FREELANCERCOLO'
+00:00 DEBUG [Action: ActiveDirectoryService] Found Active Directory host 'FREELANCERCOLO'
+00:00 DEBUG [Action: ActiveDirectoryService] Finding Active Directory object with name 'Windows' of type 'OrganizationalUnit'
+00:00 DEBUG [Action: ActiveDirectoryService] Extending search using Distinguished Name 'OU=Windows,OU=flc-servers,DC=freelancercolo,DC=local'
+00:00 DEBUG [Action: ActiveDirectoryService] Finding Active Directory object with name 'flcgs10' of type 'ComputerAD'
+00:00 WARNING [Action: ActiveDirectoryService] No Active Directory object found for 'flcgs10' of type 'ComputerAD'
+00:00 DEBUG [Action: ActiveDirectoryService] Finding Active Directory object with name 'flcgs10' of type 'ComputerAD'
+00:00 DEBUG [Action: ActiveDirectoryService] Found Active Directory object: flcgs10
+00:00 INFO [Action: addComputerToAD] Successfully created Active Directory computer account.

The output identifies messages from addComputerToAD and the actions it calls, with INFO, DEBUG and WARNING log types. This makes each message's source clear and helps with troubleshooting.

To import Logger, add the following code at the top of the action or workflow scriptable task:

var log = new (System.getModule("com.simplygeek.vcf.orchestrator.logging").Logger())(
    "Action",
    "myTestAction"
);

Set these two parameters:

Parameters:

Name	Type	Description
logSource	string	The source of the log. Must be set to ‘Action’ or ‘Workflow’
logName	string	The name of the log message (the name of the Action or Workflow).

The code creates a Logger instance in log. Use that variable to send messages, or rename it if needed.

Set logName manually to the action's name. A Jasmine unit test can check this. If you rename the action, you also need to update logMessage. Across the thousands of actions I have written, this has been a minor issue.

Using arguments.callee to retrieve the action name dynamically causes problems with nested actions.

Use one of the following methods to send a console message:

log.info("my log test");
log.warn("my log test");
log.error("my log test");
log.debug("my log test");

The example above outputs the following:

Screenshot unavailable. This image could not be recovered from the original blog.

Alternative logging methods

The System class also provides setLogMarker . Pass a string to setLogMarker to set the prefix for subsequent log messages.

In more complex deployments, LogMarker can throw errors when an action runs from the UI or calls nested actions. These limitations rule it out for me because most of my code uses that structure.

You can find the details of the setLogMarker method at vroapi.

You can also read more about its implementation at CloudBlogger.

Thanks for reading, and please let me know your thoughts or if you found this post useful.