Testing variables in embedded workflows...

[crago]

I've included a simple package with 2 workflows...

the 'test' workflow is just a custom decision block returning true or false on 'testString' length...  this works fine if you run it directly.

the 'parentTest' workflow is just a workflow that runs the 'test' workflow and always fails with: 'TypeError: Cannot read property "length" from null'

Obviously this is an oversimplified example, but what would be the proper way to do this?

Thanks,
Deric

[Andreas_Diemer]

Hi Deric,

strange behavior. But the error is correct. I've expanded your flow by a task:

If you run direct, the attribute is initialized as an empty string (length = 0).

If you run embedded the attribute is NOT initialized as an empty string (testString is NULL) and so the method .length must fail on NULL.

If there is an entry for testString like "aaa" the flow runs - values are initialized in both cases.

The question is why is the attribute testString not initialized in embedded run? Very strange. Maybe there is a problem to identify if a string attribute is NULL or empty. I've tried this with type number and everything works fine. It's easier to decide if a number is set or NULL.

@Developers, is this a feature or a bug?

Regards, Andreas

[tschoergez]

Hi Guys,

I can reproduce the behaviour.

More: Even if you  initialize the string in the inner workflows's attributes and set it to empty in scripting task

(a add a line

testString = "";

to Andreas' example)

the inner workflow works as expected with an empty string with length 0.

When using it in another workflow again it is "converted" to null.

So in general, it seems that empty strings are converted to null at the limit of a workflow.

For me, it's a bug, or at least it should be documented.

Cheers,

Joerg

[cdecanini_ · Accepted solution]

Definitly a bug.

What happens is that when you put a workflow in a workflow there is a complex stack of variables handled in the same wf  (if that makes sense to you) and here you have a particular case where the type of the attribute cannot be determined since it was not initalized in the first place (the empty string box has not initialized the variable).

If you try add in you decision box System.log(System.getObjectClassName(testString)) you will see that when running the wf it knows it is a string and when running from the parent it does not know (the same way it would not know what an non initialized variable is.

To simulate this you can do in a scriptable box:

var testString;

System.log(System.getObjectClassName(testString));

To fix this you have 2 solutions.

First one is to initialize your variable with adding a scriptable box before the decision one with:

testString = "";

Another solution withou touching the sub workflows is to add it in the parent workflow as a nested workflow instead as a suborkflow.

The nested workflow is run in a separate workflow context. You workflow will run exactely as if you would be running it separately.

I had opened a similar bug but I would need to check with engineering if this is similar enough and if this will be fixed by next update.

You will have to bug me with this again in a few days since I am in vacation tonight !

Christophe.

[cdecanini_]

You won the speed contest

[Andreas_Diemer]

@all

it's cool to see that this communtiy react so fast - with positive results!

Thx 4 support from VMware

[cdecanini_]

If only I was not so busy I could react more often. PM me when the case is desperate. I do not promise anything but I may help.

[crago]

The nested workflow has been working for me as a workaround until now. Using a variable type of "properties" and ultimately trying to run the workflow asynchronously I have not been able to get this to work.

The original workflow creates a properties variable ( var origProps = {'color': 'red'} ) and I have tried using both asynchronous and nested workflows, but both result in "TypeError: Cannot read property "color" from null"

Has this "bug" (hopefully) been fixed in a more recent version? I'm running 4.1.1 build 733.

See attached example...  Re-route the workflow for either asynchronous or nested.

Thanks,
Deric

[cdecanini_]

I am not sure if this has been fixed. The best way to make sure it has is to contact VMware Global Support Services so they can track this and make sure it gets fixed.

You can poin them to this thread and provide your example.

Christophe.

[tschoergez]

As a small follow-up on this one: I didn't do an explicit test yet, but the if I understand the release notes of the current version 4.2.1 right, this bug should have been fixed now...:

http://www.vmware.com/support/orchestrator/doc/vcenter-orchestrator-421-release-notes.html

The 7th point in "Resolved Issues".

cheers,

Joerg