Standard Interactivity or High Interactivity

With winters approaching hibernation starts and efficiency dips (even though its below par through out the year). But still issues never stop. Recently while working on standard interactivity portal we have written script on BC which was used in both HI as well as SI application. However typical business requirement forced us that this piece should be executed only on SI mode of the application and not on the HI mode.

The real trick here is to identify in which mode of application you are working on. With some support from Google we were able to find its-another-mystery-service-type business service which is used extensively but less talked about. "Web Engine State Properties" is the magic service here. Below piece of code can help you find the mode.

var sInputs = TheApplication().NewPropertySet();
var sOutputs = TheApplication().NewPropertySet();
TheApplication().GetService("Web Engine State Properties").InvokeMethod("IsHighInteractive",sInputs,sOutputs);
var sTest = sOutputs.GetProperty("IsHighInteractive");

The key here is the name of the method and name of output argument is same. There are more methods of this BS. All will return either 1 or 0. This BS is primarily used in SWT tags to determine modes, main example being CCStylesChoice.swt where it directs which CSS file to be used for which mode. Any other method to identify application mode is more than welcome in comments section.

Happy Crunching!!

Confirm in Standard Interactivity

"Confirm" function in javascript is as powerful as batmobile which work as check for users prior setting or clicking mission critical values. It allows developer to seek user blessings if they want to perform particular operation or not.In ongoing series on Standard Interactivity, here we will discuss usage of "Confirm" and use the result to set/reset values in SI mode.

Problem Statement: In eService Portal, whenever user is changing status values, he/she should be prompted with confirmation message and based on Yes/No values should be set.
Solution: As in HI client it is cake walk solution to implement where one can use BS "PreSetFieldValue" event of BC. However with SI client under question things become different with architectural limitation. The solution is orchestrated using the DOM events available in SI application. Following piece of browser script code is written on onfocus and onchange events. The key here is to determine the sequene of events. onfocus happens before onchange event for Status column.

general declaration:
var preValue;

function Edit_SList__0__Column__Status__onfocus (applet, id)
{
preValue = document.getElementById(id).value; // Fetch current value of status
}

function Edit_SList__0__Column__Status__onchange (applet, id)
{
if(confirm("Are you sure you want to change Status"))
{
document.getElementById("WriteRecord").click();
}
else
{
   document.getElementById(id).value = preValue;
   document.getElementById("WriteRecord").click();
}
 }

This will set/reset the values of status column based on user consensus. A curious mind by now must be thinking can we have Confirm on button click also. Yes we can. My support(ID 745518.1) already have solution to that.

Happy Crunching!!

Explicit Write in Standard Interactivity

Offlately i am working on SI application and being bombarded by lot of user acceptance issues. I am not sure whether God is really happy or its just a clearance sale that most of the time we are able to find the fix. Recently we were being asked to implement explicit write sort of scenario in standard interactivity portal. In the detail applet for service request user didn't want to click Save button to save the record instead it was required as soon as details in the Description are filled record should auto save.

Again browser script comes to party. As browser script on standard events of Applet/BC doesn't work under SI architecture, only control level events are supported. Ever friendly Alex has beautifully explained the browser script architecture in his recent post. So idea here is to explicitly call the click event for "Save" button on the applet for OnChange event of Description column. Fortunately for us most of the fields on the applet were auto populated and read only so this solution is not that performance taxing.

However the key to this solution remains the HTML attribute property of the "Save" button control. As siebel generates its own SWE html ids(like s_1_1_6_0) so it becomes very important we give custom id to this button in order call it in other events. This can be achieved by adding below attributes to the control in tools.

HTML Atttribute: id=WriteRecord 

Once the id is associated with button control, we can easily call below code from OnChange event:

function Edit__0__Control__Description__onchange (applet, id)
{
if(document.getElementById(id).value != "")
{
document.getElementById("WriteRecord").click();
}
}

This approach though has some inherent disadvantages as this can be only used when controls/columns in the Form/list applet are less. Any other approach/idea/comment to achieve explicit write functionality in SI application is always welcome.

Happy Crunching!!

Illusion in Standard Interactivity

Whenever I am asked to work on siebel standard interactivity it feels like harry potter stranded in those wild mazes. But i can tell you if you play in Java/HTML you can really unearth hidden gems in SI application. Recenty while working on Siebel eSales portal we were asked to implement typical requirement to control button's visibility conditionally. 

For the Open status button should be visible on list applet and for other status values it should be hidden. Once again "WebApplet_ShowControl" server event is critical to its implementation as other browser events of applet are not supported in SI architecture. The idea is to modify the HTML generated at run time to achieve conditional visibility. Below steps are required for ultimate illusion.


1 - In the HTML attribute of the Button Control which we want to make conditionally visible add below property
style='visibility:hidden'
By default button will be hidden and we will only make it visible when status is Open.


2 - Below piece of script is required at "WebApplet_ShowControl" event on the server side of applet.
if ((ControlName == "Test") && (Property == "FormattedHtml"))
 {
var a = HTML.indexOf("visibility");
var b = HTML.indexOf("'",a+1);
if ((a > -1) && (b > -1))
{
var sr = this.BusComp().GetFieldValue("Status");
if(sr=="Open")
var t = "visibility:visible'";
else
var t = "visibility:hidden'";

var HTML2 = HTML.substr(0,a) + t + HTML.substr(b+1);
HTML = HTML2; // Re-Generating HTMLs
  }
 }
Here we are just checking the status value and modifying the generated HTML at run time to make button dynamically visible.

If in first attempt it doesn't work don't get mad at me just clear the cache and watch out for magic. Bet me you will feel like wathcing The Prestige again.

Happy Summers!!