vRO LogMarker: Better than Logger Action? [CB10111]

Introduction This one came by surprise to me. We do use some super huge vRO Workflows in our environment and troubleshooting or even pointing out where that log is coming can be a task in itself sometimes. We started using some techniques, like using identifier at the start and end of Scriptable tasks and actions…


min read


This one came by surprise to me. We do use some super huge vRO Workflows in our environment and troubleshooting or even pointing out where that log is coming can be a task in itself sometimes.

We started using some techniques, like using identifier at the start and end of Scriptable tasks and actions but as we also use 4 to 5 layers of nested Workflows, that doesn’t seem to be really good solution as it kind of loose track.

I was looking for some options online and I found a good solution “Standardized Logger Action” by Gavin Stephens (simplygeek.co.uk). It was so good that we almost implemented it in our environment. However, then I discovered this logMarker which is almost doing the same thing. I wonder why I haven’t ever heard or read about it. I just loved it. And this post is all about it. But first see, what exactly logger is doing.

What’s Logger?

There is an action which returns a function Logger. What this function does is it adds the callee type and its name before each and every log operation you do.


function Logger(logType, logName) {
    this.type = logType;
    this.name = logName;
    this.log = function (logMsg) {
        System.log("[" + this.type + ": " + this.name + "] " + logMsg);


var logType = "Action"; 
var logName = "actionName"; 
var Logger = System.getModule("com.simplygeek.library.util").logger(logType, logName);
var log = new Logger(logType, logName);
log.log("The inventory data collection process started.");
while (i < counter){
    log.log("Task running...");


So, it kinds of uplift the logs and it becomes super easy to identify where is this log coming from.

[Action: startDataCollectionOnComputeResource]: The inventory data collection process started.
[Action: getDataCollectionRunningStatus]: Task running...
[Action: getDataCollectionRunningStatus]: Task running...

What’s LogMarker?

It’s an inbuilt method System.setLogMarker() in vRO which adds a additional payload to all the logs/warnings/errors/debugs following it. So it can be easily used in your Workflows’ Scriptable tasks, actions and even at other places. Let’s see a quick demo.

Implementation for Scriptable tasks

Just add this line of code in at the top of your scriptable task:

System.setLogMarker("SCRIPT: "+System.currentWorkflowItem().getDisplayName());
System.log("Performing tasks...");
System.log("Task 1 completed");
System.debug("Subtask 1a completed");
System.warn("Task 1 completed with some errors");

Implementation for Direct Actions (drag & drop) in Workflow

Just add this line of code at the top of your action:

try{ System.setLogMarker("ACTION: " +arguments.callee.name.substr(6)); } catch(e){};
System.log("Performing tasks in action...");
System.log("Task 2 completed");
System.debug("Subtask 2a completed");
System.warn("Task 3 completed with some errors");
System.error("Task 4 failed");

Implementation for inline Actions (called inside a scriptable task)

The scope of logMarker seems to be at function level (direct actions and scriptable tasks are converted into functions by vRO Executor). Hence, if an action which is called inline is using setLogMarker() then, marker will remain set to what was set by action even after it start executing the rest of the code in scriptable task.

So to fix that, you can just set the logMarker again for the scriptable task as you can see here in line 5.

With these 3 simple rules, I think you can quite improve your workflow logs with minimal efforts and just using built-in method.

Which one would you prefer? Please let me know in the comments, Is it Garry’s Custom Logger or the vRO’s LogMarker?

Personal thoughts

I think, with all due respect, logMarker wins because

  • There is no need to import custom code every time.
  • You can still use System.log() instead of using the custom log.log();
  • Probably faster.


6 responses to “vRO LogMarker: Better than Logger Action? [CB10111]”

  1. Leave a Reply

    Jean-Philippe Martin Avatar
    Jean-Philippe Martin

    Here’s one I use in my wf to trace the different steps. it log the wf/sub wf name and steps item names :

    * @param {string} message message to log
    * @param {any} WFitem workflow item force for bug in Orchestrator :
    * System.currentWorkflowItem() does not return the correct step item
    * @param {string} fonction function to call : log/warn/debug
    * ex:
    * var msg = “some msg ! “;
    * System.getModule(“path.utils”).logthis(msg, System.currentWorkflowItem(), “warn”);
    try {
    var fonction2 = fonction;
    if (workflow) {
    try {
    // current workflow name (in case of sub wf)
    var wfName = workflow.currentWorkflow.name;

            // step name (item.description)
            var itemName = System.currentWorkflowItem().getDisplayName();
            var itemName2 = System.currentWorkflowItem().getName();
            // needed for sub wf (2nd param)
            if (WFitem) {
                itemName = WFitem.getDisplayName();
                itemName2 = WFitem.getName();
            } //if
            var msgLog = wfName + " (" + itemName + "/" + itemName2 + ") " + message;
        } catch (e) {
            msgLog = "Err :" + e.message;
            fonction2 = "error";
        } // catch
    } else {
        // if called from an action ... not sure about this part
        var actionName = "[" + this.name + "\\" + arguments.callee.name + "]";
        msgLog = actionName + message;
    } // else
    switch (fonction2) {
        case "error":
        case "debug":
        case "warn":
            System[fonction2](msgLog + "\n");
            // log
            System.log(msgLog + "\n");
    } // switch

    } catch (e) {
    System.error(“logthis ” + e);
    } // catch

    1. Leave a Reply

      Mayank Goyal Avatar

      Even thats a good one.

      1. Leave a Reply

        Mayank Goyal Avatar

        In reality, there are many different ways to do it. However, I am very happy that logMarker exists by default.

  2. Leave a Reply

    Allan Kjaer Avatar

    I like to reset the “System.setLogMarke” in the ending of the script at the end of the scripts in both Actions and Workflow Scriptable tasks so it do not get used in the next workflow element, as most public and build-in workflows do not use this, by setting the “System.setLogMarke”:

    In the action I also prefer to set the module name, so I get al the information I need in big workflows.

    if(arguments.callee.name.substr(6)) System.setLogMarker(“ACTION: ” + this.name + “/” + arguments.callee.name.substr(6));

    1. Leave a Reply

      Mayank Goyal Avatar

      If Actions is used directly or if there is a scriptable task with no inline action called, then this would be enough because logMarker won’t really jump across Workflow elements. The only issue is with scriptable tasks using inline action and for that, I think as you said, we can either reset logMarker at the end of every action or in the next line of scriptable task using System.setLogMarker(“”);

      1. Leave a Reply

        Mayank Goyal Avatar

        However, even if we reset it at the end of the action, we still have to set it again in Scriptable task when the interpreter presumes from next line of scriptable task otherwise it would print nothing for the following logs later in that scriptable task.

Related Posts

Leave a Reply

%d bloggers like this: