Tuesday, August 7, 2012

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

Tuesday, July 31, 2012

Changing Font and Color

"Mere color, unspoiled by meaning, and unallied with definite form, can speak in thousand different ways." -- Oscar Wilde
Status bar is a common feature in siebel where color encoding depicts the status of record. I recently encountered similar scenario where i had to display different coloured text based on certain conditions on Form Applet. Browser script clicked me first. But finally this was achieved using configuration. As i struggle to achieve similar result in List applet we will discuss how on Form applet desired could be done. Lets take Service Request entity as an example (offlately this is becoming my favourite entity).

Problem Statement: If SR has some related SR then it should display some text in Red else alternate text in green.

Solution:

a) Go to SR buscomp. Create following fields

Name: PastSRRed
Calculated: True
Calculated Value: "< font color='red' > "+"This SR has related SR." +"< font > "

Name: PastSRGreen
Calculated: True
Calculated Value:  "< font color='green' > " +"No related SR found" +"< font > "

Name: PastSRDisplay
Calculated: True
Calculated Value: IIF(Count("SR") > 0,[PastSRRed],[PastSRGreen]) // In this SR is the name of multivalue link between SR and related SR bc.

b) Go to SR form applet, where text needs to be displayed. Create following control.

Name: PastSRDisplay
Field: PastSRDisplay
DisplayName: PastStatus
HTML Display Mode: DontEncodeData

Compile BC/applet and lookout for changes. But to fetch this on list applet is still mystery for me. Any thought on list applet will be of great help.

Happy Coloring !!

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





Thursday, July 12, 2012

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




Thursday, June 7, 2012

User Keys & Blind Insert

If ignorance is bliss, why aren't there more happy developers?


Recently I found something strange in our inbound integration. For Upsert scenario we received XML data in all Upper Case format. Despite having CaseInsensitive setting set to TRUE for EAI Object Manager the integration was failing. It was because of the fact that user keys are always case sensitive irrespective of setting at OM level.

As a workaround for this we can either use "Force Case" field property at BC level or we can have numeric user keys. 

Another interesting user property we came across insert unique-user-key scenario is "SuppressQueryOnInsert" at IC level to do blind insert. This is real performance boost in scenarios when you are sure incoming user keys will always be unique. Without this user property Siebel first generates SELECT statement which queries for the record with given user key across the table. This user property helps in suppressing this SELECT statement and thus improves the performance by some mile.

Happy Integration!!

Tuesday, May 22, 2012

Thread Bar Updation


Sometimes Simplicity just does not precede complexity, but follows it. Recently while configuring Thread Bar for some views, we faced a trivial issue. Value of the Thread Field defined was not coming in the Thread bar.  We have specified the correct Thread Applet, Thread Field and Thread Title properties for the related views but only Thread Title was being displayed when we drilldown from List view to Form View. Google resulted this issue being faced by other users without fix.
Things got luckier for me when i found a similar article on support web which stated that this is the intended behavior of siebel when the underlying Business Objects of traversing views are same. However as workaround of this issue there are three options:

  1. Have different BO's for List View and Destination View.
  2. Remove thread bar and make use of IE back option.
  3. If it is business critical to have navigation path in thread bar then one can define Source Field and Destination Field in the drilldown from list View to form view. This setting of source field in the drilldown causes Thread Field to be displayed in the Thread Bar. However it comes with its own inherent issue in a way that user can't traverse through record set in Form view. 
Hope this post helps you while configuring thread bar and keeping business object context in mind. Yup simplicity follows complexity.

Happy Configuration!!

Monday, April 9, 2012

Validation Utility Service


Many  times we have wished that workflows could have ActiveViewName function so that we can perform actions based on the current view. For long i have been resolving this by using profile attributes in workflow but GetProfileAttr('ActiveViewName') is not bullet proof, as when we do Reload/Refresh profile attribute it clears out this profile attribute.



In our quest to overcome profile attribute usage, we discovered another siebel gem, rarely talked,business service "Validation Utility Service". This business service contains a method "GetActiveView" which returns active view name. One can directly use this business service in workflow and can get name of active view.

While writing this piece i also came across another siebel blog which talks about fetching active view details using different business service. Hope either of business service helps your cause.

Happy Crunching!!