siebel

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...

"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...

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 popula...

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 ...