SteskaljGE
Enthusiast
Enthusiast

Bring back the Java Client for vRealize Orchestrator 8.x

We need VMWare to stop making everything an HTML5 site. They never work as expected and are actually more of a headache as compared to what they call the legacy client. We as a community need to make noise about this and have them bring it back and continue development on it. Who's with me?

Labels (7)
9 Replies
qc4vmware
Virtuoso
Virtuoso

I'm still stuck in the 7.x realm for now... I'm looking to start all my migration to 8 work starting next month.  I've only briefly played with 8.x of vRA/vRO so I don't have any strong opinions yet.  Personally, I have no problem with the client being HTML5 based.  If they've made poor design choices and its difficult to use then we need to lean on them to fix it.  I'm not certain that means a java based solution though or a locally installable client.  I'll check back in a bit with my more informed opinion! 🙂

With the version 8 client what are some of the specific things that are driving you crazy?

0 Kudos
nef_user
Enthusiast
Enthusiast

The html5 client is a lot better than the java client in my opinion. It's faster and better looking. They need to improve some details. The clients are very different, you will struggle in the beginning, but as far as you get used to it you will see that things got better.

KThorlund
Enthusiast
Enthusiast

I agree!

It is such a downgrade of the product in terms of daily use and development. The backend might be good, thou. 

Yes, maybe it is good if you just use a standard workflow, but as soon you actually need a bit development it is a disaster. 

We tested vRO 8 for a while, but it simply doesnt work in the everyday. Our conclusion is that for practical work we need a proper client and tool, and decided to stick with v7. v8 is far far away to offer this. It is not about being conservative, but the everyday just needs to be manageable. When having such a incomplete product  / client linked up to critical infrastructure, it is just a great risk. There is not room for such risk - at least not in the environment I operate..

0 Kudos
qc4vmware
Virtuoso
Virtuoso

Can you provide some specific examples of things you cannot do in version 8?  I may discover these on my own as starting next month I'll be working on my vRA/vRO 7.6 to 8.x migration.  I've only spent a few hours with the 8.x versions of the products.  We have been extending/customizing vRA for years now starting with version 6.  I understand 8 is a massive evolution for the products so I'm expecting a steep learning curve but it would be great to know what just doesn't work going into it.  Might save me some time.  I don't see how we can stay on version 7 forever so it may boil down to keeping vRO 7 in the environment for a while even if its a companion to vRO 8.  I think the way to move forward is to document what is not working and push for changes to the HTML5 client.  We have to be detailed though we can't just throw out broad criticisms.

I know with vRA 8 for quite a while they did not support properties at all.  I believe now they have reintroduced that feature of the product but I'm not sure how its been implemented.  That is a specific example of a non starter for us as we've heavily leveraged this in our customizations.  I didn't want to tackle vRA 8 until that feature was back.  I realize this is not a vRO issue but it might be similar in that it was a missing feature slated for return.  Is what we are dealing with in vRO similar in missing features (which may be on the roadmap to be implemented), is it performance, UI, api, etc... I know initially the HTML5 client was missing the hierarchical object browsing but I believe they brought that back.  That was a very specific UI feature heavily requested be put back.

0 Kudos
SteskaljGE
Enthusiast
Enthusiast

Now that I've been working more and more with the web client. I have to say from a development standpoint, it is horrible. The workflow to design new workflows and actions is not intuitive. You loose your place in your flow if you are jumping between execution and design. It would have been better if VMWare just created a full UI plug-in in to VSCode that would replace this java client, rather than the webclient. The webclient should have been left specifically for execution of workflows.  

Tags (4)
0 Kudos
VitorJorge
Enthusiast
Enthusiast

Hi,

I share the same opinion, the current HTML5 client is not functional, everytime we test a feature on the workflow it changes to another windows, then when we close, it does not returns to the item where it was, now we have to to 5x more clicks to test an return to the previous item where we left of.

It is not practical for medium and big developments. Have to work with multiple windows just to keep track of my changes and progress.

0 Kudos
KThorlund
Enthusiast
Enthusiast

I am so sad... I often cry when i go to bed. I miss the Java client so unbelievable much! My life used to be fun, innovative and productive with vRO 7.6 and its client. Now its different. Its daily head wind, I dont understand why they have made it so difficult to use - they have removed on the unbelievable power it used to offer. 

If anyone can recommend a course/class which shows me how to use it properply and as affective as 7.6 please feel free to sent me a PM.

😞

0 Kudos
htdo
Contributor
Contributor

I'm so dread of the day that I have to switch over to vRA 8 (we are in the process of standing it up). The people who made the decision to cut off the Java client are not the one who use the product regularly. Imagine if one of your workflow comprises of over 100 sub workflows/actions, and you have to work in HTML5. If VMware wants to cut it off, please provide a suitable tool to do: Visual Studio Code, a hack to make old vRO client to work with vRO 8 (I saw some blog's pictures that show Java client shows the EBS execution for vRA8).

0 Kudos
xian_
Expert
Expert

You can connect to older versions of vRO8 with the legacy client, up to 8.4.1 I believe (hence the screenshot you mentioned).

Later versions will not work as the corresponding API the legacy client uses was removed.

0 Kudos