SteskaljGE
Contributor
Contributor

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