Is that somehow avoidable or does anyone know how to work around it?
Don't use the new HTML5 client to create or edit workflows that will be consumed by vRA. This is a known issue and can be found in the release notes for vRO 7.6.
daphnissov Thanks for your reply.
1) I was looking through Release Notes of both vRA and vRO 7.6 now and I could not find that statement anywhere.
2) I just tested it using a legacy workflow and it yields the same issue:
So, I guess there I should open another SR.
Place a form Text in the second column next to the Text Field - it will straighten out the layout (field2 is hidden for another test).
They actually changed the wording on the release notes. Here is what it said previously (as of 12 April):
vRealize Automation XAAS forms support only workflows created in the Orchestrator Legacy Client.
That statement has been removed. This is the next closest one:
The input parameter constraints of workflows created or edited in the vRealize Orchestrator Client do not automatically transfer to the XaaS blueprint request form in vRealize Automation. When using these workflows in XaaS operations, you must manually define the input parameters constraints in the XaaS blueprint request form. This limitation does not impact workflows created and edited exclusively in the Orchestrator Legacy Client.
The moral of the story here is this: If you're going to consume vRO objects of any type by vRA, don't use the HTML5 client to create or edit them.
Yeah, that makes sense, but does not apply to my issue. Thanks anyway.
daphnissov: Now I found that passage in the vRO 7.6 Release Notes. This is wrong too, IMO, since it's technically a vRA XaaS blueprint issue.
The (extended) Moral of the story is, the Custom Forms engine for vRO 7.6 is useless unless you only create the workflow for other admins executing them in the new vRO HTML5 client. If you use those workflows in vRA XaaS, you must (re-)implement all the logic in the XaaS blueprint form, similar to when you use CF on top of a XaaS blueprint (which is both a shame, really).
How does it not? You've used the HTML5 client to create/edit a workflow which you're then presenting to vRA for consumption in an XaaS blueprint. The symptoms you're seeing with the field names not adhering to the workflow is due to this issue.
Did you not read the second part of my first reply? I created another XaaS blueprint using a legacy vRO workflow and had the same issue.
You're right, I went back and re-read. So it seems like it's an issue with the presentation rendering in vRA and not necessarily vRO. Let's hope this gets addressed in a hotfix. Things like this are why I never recommend jumping to the latest GA release unless to experiment with in a lab environment.
Indeed, that's why I did exactly that in my lab environment and shared it here for comments.
Thanks for posting this!
Could this be resolved with a bit of CSS applied to the form?
vRA was not created with active customization of web components in mind. While it might be possible, you'd have to quite the CSS expert not to make it worse. Eventually, any update will overwrite your changes, since you'll only be able to edit files expanded from the .war file to the cache.
I think rather that a hotfix will have to remedy this and go with the workaround I provided.