10 Replies Latest reply on Apr 23, 2019 11:21 PM by XModem

    XaaS Blueprint Field Label Bugged?

    XModem Enthusiast

      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:

       

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

       

      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:

       

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

        • 1. Re: XaaS Blueprint Field Label Bugged?
          daphnissov Guru
          vExpertCommunity Warriors

          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.

          • 2. Re: XaaS Blueprint Field Label Bugged?
            XModem Enthusiast

            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.

             

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

            • 3. Re: XaaS Blueprint Field Label Bugged?
              daphnissov Guru
              vExpertCommunity Warriors

              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.

              2 people found this helpful
              • 4. Re: XaaS Blueprint Field Label Bugged?
                XModem Enthusiast

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

                • 5. Re: XaaS Blueprint Field Label Bugged?
                  daphnissov Guru
                  Community WarriorsvExpert

                  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.

                  • 6. Re: XaaS Blueprint Field Label Bugged?
                    XModem Enthusiast

                    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.

                    • 7. Re: XaaS Blueprint Field Label Bugged?
                      daphnissov Guru
                      Community WarriorsvExpert

                      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.

                      • 8. Re: XaaS Blueprint Field Label Bugged?
                        XModem Enthusiast

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

                        • 9. Re: XaaS Blueprint Field Label Bugged?
                          craigso Enthusiast

                          Thanks for posting this!

                           

                           

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

                          • 10. Re: XaaS Blueprint Field Label Bugged?
                            XModem Enthusiast

                            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.