Video: How to Fix ERP Browser Compatibility Issues

Video: How to Fix ERP Browser Compatibility Issues

Solving web browser compatibility issues can be a surprisingly big issue for any IT organization trying to maximize the useful life of its ERP and other enterprise systems that came of age early in the web era. Wasn’t browser-based computing supposed to make everything easier?

If your current ERP system meets your needs, we don’t think browser compatibility ought to be thing that drives you to undertake a costly and disruptive upgrade or migrate to another platform.

Fortunately, Rimini Street engineers have developed a variety of techniques to address issues like this:

  • Web-based screens are unreadable when viewed on a modern browser because the standards for spacing, aligning, and formatting HTML elements have evolved and changed.
  • Menus and drop-downs fail to display properly for the same reasons.
  • ERP functions fail because they require a client side technology like Flash or an obsolete version of Java.
  • The application fails to recognize the Microsoft Edge browser, which didn’t exist when many of these systems were developed.

Some fixes aren’t so tough, once you know about them. For example, to get PeopleSoft to recognize one of the newer browsers as a legitimate client, you edit a file on the server called browscap.ini.

Still, trickier issues can emerge with every update of every browser. For example, by the end of this month, Google says Chrome will flash a security warning whenever a user tries to access a page with the HTTP protocol, as opposed to the encrypted HTTPS version. That’s bound to cause problems with enterprise applications designed to operate inside the firewall where — at least according to the standards of a few years ago — HTTPS connections were considered unnecessary. Pushing HTTPS is part of Google’s campaign to make the public web more secure. Expect to see a flurry of support requests related to this issue.

Give the Browsers What They Expect

In several of these scenarios, we can solve the problem using the Browser Proxy server solution developed by Rimini Street engineers. Based on an Apache reverse proxy, this solution translates the output of the application into the format a modern browser expects. An example is fixing the tagging of HTML tables that displayed just fine on old versions of Internet Explorer into the HTML and CSS code needed to achieve the same cell spacing and alignment on Chrome or Safari.

For example, we worked with one international supply chain logistics company that needed to make selected screens from its SAP ECC 5.0 system available on the public web. Because the company couldn’t dictate choice of browser to customers and partners, Smart Proxy Server made that application possible by translating code intended for Internet Explorer for display on other browsers.

A proxy placed in front of the application server could also be a solution to meeting Chrome’s expectation for HTTPS, while letting the application talk HTTP over a local network secured by other means.

Current browsers have converged on a more or less consistent set of HTML and CSS standards for web page formatting, but one of the things this means is even Internet Explorer can have trouble displaying HTML intended for older versions of IE.  At least in that case, Microsoft introduced a solution in Internet Explorer 11 — an “Enterprise Mode,” which you can toggle on to make pages render like they used to.

Different Flavors of Java

Remember when Java was supposed to be about “Write Once, Run Everywhere” simplicity? For Java in the browser, it really hasn’t worked out that way. Like browsers, Java virtual machines have forced enterprise systems to become dependent on the functionality of a specific Java release. One of our clients wound up with three different enterprise applications requiring three specific versions of Java.

This is one of the scenarios where a virtualization or containerization as a strategy can make sense.

One tactic is to use a virtual desktop interface, where instead of using a browser on their own desktop, users access it via a virtual desktop, which can be configured with the right Java version and browser version for the application.

Alternatively, client-side container software can be used to bundle all the application prerequisites together in a package. This is similar to data center technologies like Docker used to package applications into an environment where they are insulated from changes in the underlying platform. In the client-side equivalent, we give users a desktop icon they can click on to launch a user interface that includes a Java-enabled browser. Inside the container, the Java version can be exactly what the application needs it to be — even if another version of Java is installed on that desktop.

We have three clients in Japan currently using this technique.

Bringing virtualized applications to the native desktop, containerization can be a way of deploying versions of SAP GUI or PeopleTools created for older versions of Windows in a more seamless way.

Big Fixes and Small Ones

One of the oldest traditions in IT is finger-pointing. Is the cause of the problem the client or the server, the operating system, or the application, the vendor, or the integrator? Everyone blames everyone else, even though the truth is often “all of the above.” Rimini Street clients will tell you they value working with us because our engineers find practical solutions for problems with the applications we support, regardless of who or what is at fault.

Is it the fault of the application developers that they designed for Internet Explorer back when it was far and away the dominant browser in the corporate world? Or bought into Java hype at its peak? Is it the fault of the browser makers that they took so long to agree on web standards? Sure, everyone is at fault, and no one is.

Meanwhile, our clients have problems that must be solved, sometimes employing a combination of the techniques outlined here. A few examples:

  • We worked with a health services company to find several different tactics to allow their PeopleSoft system to work with browsers like Chrome and Safari. This meant workers could use their browser of choice, the one they used for every other application.
  • A software company, workers had successfully been using Chrome in combination with an SAP system until one day a Chrome update broke the application. This was a simple HTML rendering issue, but since SAP didn’t offer a fix — and the company didn’t want to tell users to stop using Chrome — Rimini Street’s Browser Proxy server was the best solution.
  • The same firm had a similar issue with a partner portal powered by SAP that had more than 2 million public web users. A Chrome security update broke the application for users of that browser, and again SAP didn’t plan to offer a fix. Excluding Chrome was unacceptable, given that Chrome accounts to about 58% of public web browsers. Rimini Street’s Browser Proxy server provided a solution, making the application accessible to Chrome users again.

The web browser is a wonderful invention, improving all the time. Whether with one technique or several, the Rimini Street engineering team is here to make it work for you, rather than against you.

For more information on what Advanced Technical Services can offer, please contact Heather Young [email protected].