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.
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 methodConfig, here);
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…