VMware Cloud Community
lurims123
Enthusiast
Enthusiast
Jump to solution

How to log vCO vRO action name programatically?

Anyone knows if we can log action name programatically just like a workflow name can be done, something like Workflow.action.name?  This helps to identify from which action the failure occurred.

1 Solution

Accepted Solutions
rszymczak
Hot Shot
Hot Shot
Jump to solution

As Jörg already said, there is no such build-in function. However, you can use the default Rhino engine javascript capabilities to achieve what you're trying to do. Use this:

//VRO's arguments.callee.name implementation will always return the String "Module + action name".

//We remove the "Module" prefix. Remember: while this works with vRO 6 and 7, it may stop working if the RHINO implementation changes.

var actionName = arguments.callee.name.substr(6);

//Keyword this represents the module this action is part of. The Module scripting object provides access to the name property.

System.log("The currently running action is: " + this.name + "." + actionName);

Regards

Robert

View solution in original post

10 Replies
tschoergez
Leadership
Leadership
Jump to solution

Hi,

I dont think that's possible, unfortunately. You have to add the action name manually in the log lines.

What vRO version do you use? In newer versions the Action name is automatically added to all the log messages from the action AFAIK.

Regards,

Joerg

Reply
0 Kudos
rszymczak
Hot Shot
Hot Shot
Jump to solution

Got nothing to test but if I remember the error handling behaviour correctly then you should be provided with the action name if you use throw rather then System.error.

E.g.

throw("Error: this is your error message within your action element");

should result in a exception that contains the name of the element where the exception was thrown at.

/Edit: yes, the error source will be logged (see screenshot). However: this was vRO 7.0 - so, as Jörg said, you might need to upgrade if you want that feature. Got no vRO 6.x to verify the behaviour there.

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee
Jump to solution

Not sure if it is applicable for your use case, but you can set action name (or other useful info) to so called 'business status' on the action (and other types of) elements in the workflow schema editor. At runtime, you can log the value of this business status field with code like the following:

System.log(workflow.businessState);

which will print the business status property value of the currently executed element.

Reply
0 Kudos
lurims123
Enthusiast
Enthusiast
Jump to solution

No that did not work, it returned null.  I use several vCO/vRO actions in the WF.  When I run the WF and look into the log, it shows the log as if I run a long script.  I would like to have something like the following in every Action I have as a template.  I do not want to write the action name for every action, inside the action.  Something like the following.

System.log('---------------------------------');

System.log(action.name similar to workflow.name);

System.log('---------------------------------');

..............

........

.......

.......


This will let me troubleshoot easily.

Reply
0 Kudos
rszymczak
Hot Shot
Hot Shot
Jump to solution

As Jörg already said, there is no such build-in function. However, you can use the default Rhino engine javascript capabilities to achieve what you're trying to do. Use this:

//VRO's arguments.callee.name implementation will always return the String "Module + action name".

//We remove the "Module" prefix. Remember: while this works with vRO 6 and 7, it may stop working if the RHINO implementation changes.

var actionName = arguments.callee.name.substr(6);

//Keyword this represents the module this action is part of. The Module scripting object provides access to the name property.

System.log("The currently running action is: " + this.name + "." + actionName);

Regards

Robert

lurims123
Enthusiast
Enthusiast
Jump to solution

Thanks rszymczak!  It worked.  Can you explain "it may stop working if the RHINO implementation changes" better? Is it going to be deprecated in vRO in later versions?  Going an extra step, how to log all the inputs names and their values programatically.  Something like, thinking the inputs are in an array, just print their name and value.

Reply
0 Kudos
rszymczak
Hot Shot
Hot Shot
Jump to solution

Well, first off the JavaScript standard defines a arguments.callee object as of JS 5 for what I know - you can read about it here: arguments.callee - JavaScript | MDN

Then we got Rhino, which has it's own JS engine that ->should<- be compliant to the standard. The callee object should return the function that is currently beeing executed. While it's a function we should be able to access all the common properties a function object has: function expression - JavaScript | MDN‌. One of them is the property name, which should return (just) the function name. However: in the current vRO implementation it's returning the String "Module"+FUNCTIONNAME. So when you create a action vRO is internally prefixing the action with the String "Module". This is compleatly hidden to you in the vRO UI. But once we go down to the Rhino layer and use JS functions which - btw is probably not officially supported by VMware - you see the prefix. So: the example I provided will remove that substring for you so you see the function (aka action) name you would see in vRO. There are a couple of things that can go wrong here:

- VMware may decide to disallow access to the base JS functions and restrict them in future releases, this will render access to the method broken.

- The prefix may change or be compleatly removed. The example I provided expects minimum of 6 chars ("Module"). Best case: you action name will be cut. Worst case, In case your action name would be less then 6 chars, you'll probably get an exception thrown.

- Rhino may decide to implement things differently (unlikely)

- VMware my decide to dump Rhino and use something else (unlikely)

- JS standard may decide to dump the callee object (unlikely)

In any case, the example I provided would no longer function. Thus: before upgrading to any newer version of vRO you'll have to test if the call still works. VMware most likely will not inform you of any changes "under the hood" where you're not supposed to be working.

regards

Robert

Reply
0 Kudos
imtrinity94
Enthusiast
Enthusiast
Jump to solution

Doesn't work anymore I guess.

imtrinity94_0-1656329723009.png

 


Mayank Goyal
vRO Engineer
https://www.linkedin.com/in/mayankgoyal1994/
https://cloudblogger.co.in/
Reply
0 Kudos
xian_
Expert
Expert
Jump to solution

It works, within a workflow:

xian__0-1675469345953.png

 

Reply
0 Kudos
Andreas_Diemer
Enthusiast
Enthusiast
Jump to solution

Of course ONLY in a workflow.
Think of "this" and the context it is running in.
It's like trying to use the keyword "workflow" in an action and then run the action --> this must fail
The use of this "solution" is limited and should be implemented with care to get the desired results, always in mind that this could change with next update.

------ for correct and / or useful answers please award points visit http://www.vcoteam.info & http://mighty-virtualization.blogspot.com
Reply
0 Kudos