VMware Cloud Community
XModem
Enthusiast
Enthusiast
Jump to solution

XaaS Blueprint Field Label Bugged?

Hi everyone

It looks like in 7.6, if you use Workflows from the new HTML5 vRO Client as a XaaS backing, the new form elements are not properly used or translated in the XaaS blueprint.

Simple example:

pastedImage_0.png

Now let's look at it in the XaaS Blueprint Designer:

pastedImage_1.png

But if you publish it as a catalog item, it will crush the field label space and it looks like that, no matter the label size you selected in the blueprint designer:

pastedImage_2.png

Any other experience with that? Is that somehow avoidable or does anyone know how to work around it?

1 Solution

Accepted Solutions
XModem
Enthusiast
Enthusiast
Jump to solution

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:

pastedImage_2.png

So, I guess there I should open another SR.

Workaround:

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).

pastedImage_1.png

pastedImage_0.png

View solution in original post

Reply
0 Kudos
10 Replies
daphnissov
Immortal
Immortal
Jump to solution

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.

Reply
0 Kudos
XModem
Enthusiast
Enthusiast
Jump to solution

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:

pastedImage_2.png

So, I guess there I should open another SR.

Workaround:

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).

pastedImage_1.png

pastedImage_0.png

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

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.

XModem
Enthusiast
Enthusiast
Jump to solution

Yeah, that makes sense, but does not apply to my issue. Thanks anyway.

EDIT:

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).

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

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.

Reply
0 Kudos
XModem
Enthusiast
Enthusiast
Jump to solution

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.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

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.

XModem
Enthusiast
Enthusiast
Jump to solution

Indeed, that's why I did exactly that in my lab environment and shared it here for comments.

Reply
0 Kudos
craigso
Enthusiast
Enthusiast
Jump to solution

Thanks for posting this!

Could this be resolved with a bit of CSS applied to the form?

Reply
0 Kudos
XModem
Enthusiast
Enthusiast
Jump to solution

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.

Reply
0 Kudos