Maintaining High Interactivity and Open UI in parallel (1)

Hi, folks!

When Siebel upgrade process involves the activation of Open UI, there are usually someone that requires High Interactivity to be maintained for a while. They say that it minimizes risks until they confirm that all features are still working, and until their team receive adequate training.

Scenario

On changing from High Interactivity to Open UI, sometimes it’s required to have a different behavior between both UIs, and:

  • It should work in both UIs;
  • It should be still working when High Interactivity is turned off (without legacy Browser Scripts);
  • It should follow Open UI development patterns;

Problem

The main problem of this approach are:

  • Open UI is based on newer technologies, that provides different ways to solve some problems. Maintaining old approaches is usually a bad idea;
  • New requirements are eventually requested based on what is new, which can be messy for High Interactivity implementation;
  • Even if Oracle say that you can have both UI working together (having two different Object Managers), there are some bug solutions that affects one when fixing the other one;
  • Open UI uses explicit Javascript (Manifests) instead of Browser Script. But for backward compatibility, Open UI still download and execute Browser Scripts (using require.js). So, what’s the problem? Upgrading process involves removing Browser Scripts (translating to Manifest Javascript files, since you cannot run genbscript against an Open UI Configuration file), and then… Bye bye, High Interactivity.
  • And so on…

Solution

Manifest files (Javascript files) are executed only in Open UI, and, after that, Siebel invokes legacy Browser Scripts (that you cannot see easily in the browser’s Developer tools because they’re loaded by require.js at runtime), that runs on both UI. After that, Siebel follows the Event Handling sequence.

Siebel Open UI Event Handling Sequence

Keeping it in mind, I thought: If Open UI Javascript runs first, I can use it to execute some specific Open UI code here. And if there is any way to stop the event propagation, so I can have a complete and specific behavior for Open UI, keeping High Interactivity as-is. So… here it is (an example):

OverrideButtonFunctionViewPR.js (Manifest: Physical Renderer, on the View where the Applet is, and that contains the button is placed on):

// Prevents redefinition of class
if (typeof(SiebelAppFacade.OverrideButtonFunctionViewPR) === "undefined") {
 // Class placement
 SiebelJS.Namespace('SiebelAppFacade.OverrideButtonFunctionViewPR');

 // Class package definition, Imports, Implementation
 define("siebel/custom/OverrideButtonFunctionViewPR", ["siebel/viewpr"], function () {
 // Class definition
 SiebelAppFacade.OverrideButtonFunctionViewPR = ( function() {
 // ? extends Class
 SiebelJS.Extend(OverrideButtonFunctionViewPR, SiebelAppFacade.ViewPR);

 // Constructor
 function OverrideButtonFunctionViewPR(pm) {
 SiebelAppFacade.OverrideButtonFunctionViewPR.superclass.constructor.call(this, pm);
 }

 // Init
 OverrideButtonFunctionViewPR.prototype.Init = function () {
 SiebelAppFacade.OverrideButtonFunctionViewPR.superclass.Init.call(this);
 }

 // Setup
 OverrideButtonFunctionViewPR.prototype.Setup = function () {
 // do nothing
 };

 // SetRenderer
 OverrideButtonFunctionViewPR.prototype.SetRenderer = function () {
 var pm = this.GetPM();
 var oAppletMap = pm.GetAppletMap();

 var oApplet, sAppletName, oAppletPM;
 var sAppletId;

 for (var applet in oAppletMap) {
 oApplet = oAppletMap[applet];
 oAppletPM = oApplet.GetPModel();

 oAppletPM.AddMethod("InvokeMethod", InvokeMethodWrapper, {sequence:true, scope:this});
 }

 };

 // EndLife
 OverrideButtonFunctionViewPR.prototype.EndLife = function () {
 // do nothing
 }

 // Methods
 function InvokeMethodWrapper (methodName, psInputArgs, lp, returnStructure) {
 if (methodName === "MethodToOverride") {
 SiebelApp.S_App.GotoView("Web Application Embedded View", null, null, null);
 returnStructure ["CancelOperation"] = true;
 }
 }

 return OverrideButtonFunctionViewPR;
 }() );

 return "SiebelAppFacade.OverrideButtonFunctionViewPR";
 });
}

What I’m doing, in details, is:

  • When Siebel renders this view (only this view, because you had inserted this Manifest File only for this view, do you remember?), I told Siebel to call my custom method (InvokeMethodWrapper) whenever an InvokeMethod is called. My custom method will be called before vanilla InvokeMethod is called, because of the “sequence:true” parameter. (read about the third paremeter of AddMethod, called methodConfighere);
    oAppletPM.AddMethod("InvokeMethod", InvokeMethodWrapper, {sequence:true, scope:this});
  • And then, in my wrapper method, I can do anything… In this case, when “MethodToOverride” is called, I told Siebel to go to a specific view (without any context loaded), and to cancel the execution of the vanilla method implementation (returning returnStructure[“CancelOperation”] = true);
     function InvokeMethodWrapper (methodName, psInputArgs, lp, returnStructure) {
     if (methodName === "MethodToOverride") {
     SiebelApp.S_App.GotoView("Web Application Embedded View", null, null, null);
     returnStructure ["CancelOperation"] = true;
     }
     }
    

This approach was used to have a button that, in High Interactivity, opens a modal popup (by using the deprecated javascript method showModalDialog, that still works on Internet Explorer 8, but not in Google Chrome), and in Open UI, it takes Siebel to another View, that contains a embedded web application seamless within. In my next post I’ll bring some details about this View. :)

PS.: I agree that it’s weird to do this kind of thing at View Physical Renderer level instead of at Applet Physical Renderer, but when it was done, there was the same button on all Applets of View. The main problem here, is that even when you add a manifest file for a specific applet, at runtime this file will be loaded globally (not only in the context of the Applet). I’ll not discuss it here, just wanted to explain my silliness. :)

My humble opinion

I’ve no doubt that the best scenario is when you can turn on Open UI and turn off High Interactivity in the same project (occurring at the same time in the Production environment). But in fact there are good arguments from customers to maintain them both for a while. So… even it’s weird to eventually do some nasty things, I think it’s better than doing it twice (in Browser Script while High Interactivity still works, and then translating it to Manifest files after “killing” it).

Thats all, folks! :) See you later…

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>