VMware Cloud Community
bsti
Enthusiast
Enthusiast
Jump to solution

Getting an error when I try to use worfklow.changeCredential() function

I have a WF that uses the following code block:

//  Change the running credential:

System.log("Workflow started running as: " + Server.getCredential().username);

System.log("Changing to: " + newCredential.username);

workflow.changeCredential(newCredential);

System.log("Credential is changed.");

System.log("Workflow is now running as: " + Server.getCredential().username);

Line 5 errors out with a NULL error.  I get nothing descriptive at all:

2017-09-20 12:56:11.301] [E] Workflow execution stack:

***

item: 'Credential Test/item1', state: 'failed', business state: 'null', exception: 'null'

workflow: 'Credential Test' (670d0b4c-b6d8-46c8-8471-6853dbf08413)

|  'attribute': name=errorCode type=string value=

|  'input': name=newCredential type=Credential value=newUser:newPassword123

|  'no outputs'

*** End of execution stack.

I would just use the "Change Credential" built-in action, but as you see above the credential you pass into it gets exposed in plain text to any user running the workflow.  My workaround was to create a new credential in the script and use workflow.changeCredential() to change to it.

For some reason, I can't call workflow.changeCredential though.  The "CHange Credential" action DOES work, and as far as I can see, it uses the same javascript code.

Does anyone know how to change the running credential with code?

I'm running VRO 7.3.0.

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
bsti
Enthusiast
Enthusiast
Jump to solution

OK, I think I'm finally to the bottom of this.  There is a bug somewhere in the system that occurs when you have the following conditions:

- You are nesting workflows

AND

- You change security context within a nested workflow

If you change security context within a workflow that is not at the top level, you have issues calling the following two functions:

- Server.getConfigurationElementCategoryWithPath()

- Server.getAllConfigurationElementCategories()

The error is:  InternalError:  Server Error:  null

The behavior is not 100% consistent.  It appears to work sometimes if I hard-code the credentials vs pulling them from a Configuration Element Attribute.

If you move the Change Credential action to the top level workflow, then the issues all appear to go away.

View solution in original post

0 Kudos
3 Replies
iiliev
VMware Employee
VMware Employee
Jump to solution

Hi,

Changing credentials of the currently running workflow causes some internal stuff to be re-initialized, possibly affecting the code after it.

Could you try to restructure your code in a way that the workflow.changeCredential() call is the last thing in its scriptable task item, and the 2 System.log() lines are in another scriptable task item that is next in the execution chain?

BTW, in the scripting code in built-in "Change credential" element workflow.changeCredential() is also the last executable piece of code, so perhaps it would also not work if there were a followup code in it like System.log() calls.

bsti
Enthusiast
Enthusiast
Jump to solution

Thanks for the response.  I still get failures when I call it at the end.  However, I was able to dig in a bit deeper and I found the issue is specifically with this function:

Server.getConfigurationElementCategoryWithPath()

What I'm doing is recalling a ConfigurationElement Attribute that stores my credential, then changing to it.  Here is my more complete code:

This is encapsulated in an action called GetConfigurationValue:

//  INPUTS:

//  categoryName

//  elementName

//  attributeName

if (!categoryName)

{

  categoryName = "my";

}

//  Server error : null  is thrown by this statement:

var category = Server.getConfigurationElementCategoryWithPath("Library/" + categoryName);

if (category == null)

{

  throw "Cannot find a ConfigurationElement category named " + categoryName;

}

else

{

  var elements = category.configurationElements;

  if (elements)

  {

    var elementIndex = elements.map(function (elem) { return elem.name.toLowerCase() }).indexOf(elementName.toLowerCase());

    if (elementIndex >= 0)

    {

      var element = elements[elementIndex];

      var attr = element.getAttributeWithKey(attributeName);

      if (attr)

      {

        return attr.value;

      }

      else

      {

        throw "Unable to find an attribute named " + attributeName + " at path Library/" + categoryName + "/" + elementName;

      }

    }

    else

    {

      throw "Unable to find a element named " + elementName + " in category " + categoryName;

    }

  }

}

That function is called here, where I change running context:

//  Get the VM Cluster:

targetVmCluster = host.parent;

if ( !targetVmCluster )

{

  throw ("You must specify a clustered host as the destination!");

}

var cred = System.getModule("com.my.common").getConfigurationValue(null, "Credentials", "provisionWorkflowRunAs");

System.debug("Changing to context: " + cred.username);

workflow.changeCredential(cred);

If I use the Change Credential action, tie the credential to an attribute, and link the attribute to this same configuration element, everything works. 

I've confirmed my function is returning the configuration element.  I also make several calls to GetConfigurationValue in other places in the same workflow.  The ones that occur BEFORE the change credential work fine, the first one after throws the error.

I'm digging more to see if I find anything else but any input is appreciated.

0 Kudos
bsti
Enthusiast
Enthusiast
Jump to solution

OK, I think I'm finally to the bottom of this.  There is a bug somewhere in the system that occurs when you have the following conditions:

- You are nesting workflows

AND

- You change security context within a nested workflow

If you change security context within a workflow that is not at the top level, you have issues calling the following two functions:

- Server.getConfigurationElementCategoryWithPath()

- Server.getAllConfigurationElementCategories()

The error is:  InternalError:  Server Error:  null

The behavior is not 100% consistent.  It appears to work sometimes if I hard-code the credentials vs pulling them from a Configuration Element Attribute.

If you move the Change Credential action to the top level workflow, then the issues all appear to go away.

0 Kudos