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…

Mayank Goyal

By

Mayank Goyal

•

min read

, , , , , ,
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 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

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

Implementation

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...");
.
.
.

Outcome

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.

References

, , , , , ,

Leave a Reply

Related Posts

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

  1. 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");
        break;
    default:
        // log
        System.log(msgLog + "\n");
} // switch

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

    Reply
    1. Mayank Goyal Avatar
      Mayank Goyal

      •

      Even thats a good one.

      Reply
      1. Mayank Goyal Avatar
        Mayank Goyal

        •

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

  2. Allan Kjaer Avatar
    Allan Kjaer

    •

    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”:
    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));

    Reply
    1. Mayank Goyal Avatar
      Mayank Goyal

      •

      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(“”);

      Reply
      1. Mayank Goyal Avatar
        Mayank Goyal

        •

        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.

%d bloggers like this: