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

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

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

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

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

Reload Profile Attributes

There are times one has to wear multiple hats as part of job, definitely a mandate if you are married. Sometimes a Manager has to work as team lead or vice versa.

Typically such scenarios are easily handled in siebel using "Change Position" concept. However trouble starts when you have used persistent profile attributes in the search scenarios which fails when user opts for changing position specially if search is based on profile attributes like Job Title, Position Type.

Recently we faced similar scenarios as one of the user had two roles. We used "Division Name" profile attribute to display list of employees while picking SR owner. Trouble started when user did change position and for the other position intended list of employee was not coming. Division Name profile attribute is available in personalization profile BC using join and loaded in session when user logged in. The issue is profile attributes doesn't refresh when you do change position. Even a call to "LoadUserAttributes" method after "Change Position" failed to refresh this attribute.

However one cool thing this method does is it returns correct output for DivisionName function. It doesn't refresh other profile attributes which are pulled from joins but it reloads calculated profile attributes based on functions like PositionName, DivisionName and OrganizationName. This was good for us as we based the profile attribute on DivisionName() function and bingo, the resultant set of employees was perfect.  Hope it helps if you are struggling with similar scenario or planning to use profile attributes in search conditions.

Awaiting some alternate tips in order to refresh profile attributes.

Happy Reloading!!