Hi,
I'm currently working with vRealize Automation 7.4.0 and vRealize Orchestrator 7.4.0 and I didn't find any way to get a get a complex Xaas working because of a *simple* issue : when a field is updated by the user, only direct dependencies are correctly updated and not all the indirect dependencies.
Let me showcase the issue in a simple Xaas.
As a mandatory step, I created a very simple vRO workflow just to be able to link with my Xaas : the issue being purely in vRA, it has no significance.
The one I used is this :
Then I could build a quite simple Xaas : the field1 is a checkbox list of strings and has a harcoded set of values :
The field2 is again a checkbox list of strings but uses as possible value list the result of the field1 :
As there is not "field" opion available, it is done using an action call that is dead simple : it sends back what it gets :
Then comes the field3 that is linked to the values selected in the field2 :
Same object, same type, the goal being to have an indirect dependancy of the field1.
Intuitively, any update of field1 should impact field2 (a direct dependency) AND field3 (an indirect dependency).
At the form opening all seems ok :
Selecting all options of field1 gives the expected output :
Then selecting all options of field2 gives the expected output :
But if you unselect now the options of field1, you have field2 updated as expected... but not field3 !
As you may guess, linked fields in a complex Xaas are not rare and you quickly get indirect dependencies that are not currently handled as expected by the product.
Given that, does some have a way to "force" the compute of ALL dependencies, including indirect ones, when a field is updated ?
I'm also open to other technical options that could satisfy such indirect dependencies in a proper way 🙂
Thanks a lot for your help and ideas !
In general, I find it's better and more reliable to handle the presentation form on the vRO side rather than customizing it in vRA. There are just too many little things which make it untenable. That said, have you tried in vRO and letting it surface back through vRA to see if that works?
Hi and thanks for your advice.
I tested your suggestion making the same settings in vRO presentation layer.
First the hardcoded list :
Then the link of field2 to the previous field1 :
And eventually the link of field3 to the field2 :
But at the time of importing the vRO workflow in the vRA Xaas creation wizard, is seems that all the actions have been lost :
The root cause is easy : the field2 and field3 has been matched to "Text field" instead of "Check box list" or "Dual list", despite the fact that the type of all theses fields is "Array of String".
I suppose some control has detected that the output of the action being "Array of string", it was not correct to use it to feed a "Text field".
Well, another bug -_-".
After the mandatory fixes the same process than before gives another set of weirdy results :
At opening, all is ok :
After having selected all the options of field1 :
Yes, the field2 and field3 have been autochecked... No reason for doing so (no default values or such things) :
Lets proceed to the uncheck of all options of field1 :
Field2 is correct, field3 has a remaining option for whatever reason while the two other have been removed as expected.
This impredictable behavior is a nightmare -_-".
Open to any other ideas !
Thanks for your help 🙂
Hi all,
After opening a support ticket, we could get the following answer from VMware :
"Thank you so much for your time on the call today. Engineering has updated that this functionality is a limitation of the product."
Meaning that the internal ticket open by VMware Support team to VMware internal Engineering / R&D team has been closed as "known issue, nothing to be fixed in the future, there is nothing to see out there".
We have to admit that such a limitation is a deal-breaker while talking of any Xaas that is more than an handful of fields. It basically limits any form to a very simple one if you don't want to run into these issues.
We are trying another approach with our VMware contacts hopping that this answer was a misunderstanding / mistake / not the definitive one.
We will see what can be done 🙂
Regards.