Skip to main content
  1. Posts/

Browser strategy for Siebel Open UI Applications

·4 mins

Siebel High Interactivity client, “HI” as it is lovingly known, is a simple world for admins.

You select the Internet Explorer used in the organization. You copy the predeploy.htm for your own use and deploy the ActiveX controls through Windows admin tools, or just ask the user to click on Siebel URL and expect delays the first time.

And then came Open UI.

The typical Siebel admin tasks just got a wee bit interesting. As an admin you will -

  1. Keep track of browsers that the various people are going to use (and what your organization recommends)
  2. Keep track of devices that people may use to access Siebel. Keep track of resolutions in addition to screen layout sizes
  3. Try to accommodate all nuances in your own development
  4. Try to fidget with what browser is supported

Oracle provides a standard statement - “Siebel is supported on any browser that is compliant to HTML5 standards”. While this umbrella statement provides comfort to the senior management, browser upgrades (even when they are HTML 5 compliant) will break the application.

Siebel open UI browser strategy

Since the various browser vendors have their own upgrade schedules that match their fancy, and upgrades happen every other month (or week), you are kept on your toes. Siebel or your developers can spoil the party by having some functionality that refuses to behave with a few browsers, browser versions, devices, or screen layouts.

Organisations need to define their browser strategy to prepare themselves and shield against any potential application issues.

Browser strategy for Open UI #

The browsers that you have to support and the devices you support may not cover each and every browser/device supported by Oracle. You define the strategy at two levels.

Development/testing #

Identify the target device for the Siebel application in close collaboration with the business teams. Make the targeted devices as part of the non-functional  requirements so that all stakeholders or on the same page.

Next, lay down the framework for browser support. Target specific versions of one or two browsers that can be used for all development and testing activities.

When the browser versions change during the course of the development siphon off a few team members test application on the new browser version. Depending on the intensity of problems with the new browser (if any), and the phase of development, drive a decision on whether you can accept the new browser version.

Since organisations have really strong desire to be as secure as possible, and security is directly proportional to the browser versions, expected pushback about freezing the browser versions.

If the versions of the browsers cannot be fixed, set clear expectations that any browser upgrades during the development phase will have a small impact on the Siebel application. While the development team works alongside Oracle to identify the issues resolve them, there is a small probability of risk of this impacts the project timelines.

Ongoing support #

You really have two options here -

1. Support browser upgrades as they happen

Become part of the beta program for browsers (Chrome beta, or Firefox beta). Assign one or two team members in the support team to test your application on beta versions of the browsers.

If there are any issues found in beta testing, you have a couple of options:

  1. Works with your development team and Oracle to find a fix for the issue
  2. Depending on the severity of the issue, evaluate whether you need to stop browser upgrades for the Siebel users or continue

Even though the risk is a minimised following this approach, you still have the remote chance’s that the final version of the browser has few more changes that can break your application.

2. Control browser upgrades

This is the approach that I like. Simply stopped the browser upgrades happening automatically on client computers. Instead channelled the upgrades through an enterprisewide deployment mechanism. Internet Explorer provides really good support in the space, and Firefox/chrome have tools that can enable such deployments.

Spend effort to test your application whenever the new browser is released, signed deploying the browser to use computers if there are no significant issues found.

Note that application issues due to browser upgrades are not specific to Siebel. Any application that is accessible through the web browser may be subject to the same problems.

Isn’t Open UI fun?