ERP systems and other enterprise applications sometimes break when the software was written to work with a specific release of Java that is not the one user desktops are configured to use by default.
What are you supposed to do when that happens? Make users revert to a version of Java that may be obsolete or include known security vulnerabilities. Or upgrade to a new version of the application, solely to resolve that issue?
Fortunately, there is a better way. You can configure user desktops to run specific versions of Java for specific, trusted applications. For everything else, you can run the latest version of Java, or a specific version specified by corporate IT. You can also block client side execution of Java entirely for any application not specifically whitelisted.
If you’re experiencing this issue, watch this short video (one of our Tech Talk series) for a closer look at how we can help you resolve the problem.
If you’re a Rimini Street client, our engineers can work with you to implement this solution. It’s in the same general category of workarounds as our solutions for ERP browser compatibility issues, but here we’re talking about “rich internet applications” that includes Java applets. Over the last couple of decades, many enterprise software vendors have taken advantage of client side Java as a way of offering richer user interface functions than they could provide with HTML alone. Even though momentum has shifted away from the use of client side Java, thanks to the maturation of JavaScript frameworks and web standards, many enterprises continue to run continue to run applications that rely on Java.
In fact, several of our clients have multiple applications that only work with certain Java versions on the client, and the same employees may need to access more than one of them. The strategy we recommend in most cases is to employ Java Deployment Rule Sets. Rule Sets have been a standard part of Java since 2013. With multiple versions of Java installed on the desktop, you can specify that applications available from a given URL – such as the web address of your ERP system – follow your rules for which Java version to load. For Java applications installed on the desktop, rather than downloaded as web applets, a hash signature can be used as an alternative to a URL.
Other possible solutions include using virtual desktops configured with the required Java version. For a company that makes extensive use of Citrix or similar platforms, that might be the best solution. But the Rule Sets option has the advantage of being a relatively simple, native Java fix for the problem.
Java Deployment Rule Sets work best in combination with a systems management platform that allows IT to install and update a digitally signed Java archive (JAR) file on each managed desktop. That file, named DeploymentRuleSet.jar, must be installed in a specific location that is hard coded -C:WindowsSunJavaDeployment on Windows – and you need administrative access to each client computer to create that directory and install the file.
Creating these rules is relatively simple, based on an XML format for defining application locations and Java versions. For example, we can assist you in setting up a Rule Set enabling Java for web access to an ERP system and blocking Java execution for anything else.
Sure, getting the configuration right can be a hassle, but we’re here to help. Compared with ripping out an enterprise system that took millions of dollars to license and implement, implementing Java Deployment Rule Sets is a pretty simple solution.
For more information on what Rimini Street Advanced Technical Services can offer, please contact Heather Young [email protected].