February 28, 2016

Dynamically change start-up view for group of users

Requirement: To have a different start-up view for certain group of users in application.

Siebel sets start-up view of all the users using Application property which is a static view and the only way default view can be changed is by end user by updating user preferences. 

Solution: To make the view dynamic and override the user preferences following script can be added to Application_Start event of Application to redirect all the users to a specific view based on their responsibility.  These views can be used to show statuary information or terms and conditions.

Script queries Employee BC for logged in user and search for specific responsibility and executes a go to view if specific responsibility is found. Similar script can be used to change other part of the application. Feel free to share in comments below if you have come across similar behavior in your implementation.

var EmployeeBO = TheApplication().GetBusObject("Employee");
var EmployeeBC = EmployeeBO.GetBusComp("Employee");
var userResp;
with (EmployeeBC)
{
ActivateField("Login Name");
ActivateField("Responsibility");
var UserName = TheApplication().LoginName();
SetSearchSpec("Login Name", TheApplication().LoginName());
ExecuteQuery(ForwardOnly);
if(FirstRecord()){
userResp = GetFieldValue("Responsibility");
}
return (CancelOperation);
}
if( userResp == ""){
{
TheApplication().GotoView("");
}else{
return (ContinueOperation);
}


Hope it helps

February 18, 2016

Siebel Open UI Interview Questions plus bonus jQuery tips

Question 1 : What are different layers of JavaScript classes in Open UI ?

Answer: Siebel Open UI framework provider 4 different type of js files , proxy, presentation model(PM), physical renderer(PM), and plugin wrapper(PW). Out of these only PM, PR and PW are recommended to modify and extend. Proxy is an interface between Siebel server and browser, thus should never be changed.

Siebel Open UI Architecture

Read more

February 06, 2016

JavaScript Execution Sequence of Siebel Open UI


Hope everyone remembers Siebel event model explained by +Alexander Hansal 
No doubt that is one the best post in Siebel blogosphere till date, in case you haven't read it, I would recommend you to go through it here. This model still holds true and has helped many businesses to model processes. However with introduction of Siebel Open UI there are few more events available for customization on browser side. 


In this post I will show you how Open UI invoke different events and methods on custom PM and PR JavaScript files.

For this proof of concept I have created and associated PM PR files with some logging for all the applets and views. I have also wrote some browser script in applet load event in tools. Following summarizes what I found.

Sequence of JavaScript Execution in Open UI

What I found out that view PM layer is the first in sequence of execution, it is executed even before preload event. Thus all the data is available in preload to build the UI. Preload.js is not the event if someone is looking to execute at very start of view building.

Sequence of execution breakdown
Breakdown of events shows that List applet are executed first by Siebel Open UI (even if they are child objects). I suspect it is done to improve performance.

Additionally Applet load event are executed at last. Thus technically it is possible to override events available in "pre" Open UI era browser scripts in Open UI.

Points to be noted here that:

  1. Prelaod.js is not the first thing which gets executed during a view load.
  2. Open UI executed PM layer for view first and then applets, however for PR layer, applets were loaded first then view.
  3. Open UI also seems to execute list applet code first than form applet irrespective of hierarchy in tools!!
  4. After all the processing of PM PR layers(including view), Siebel at last executes applet load event of tools browser script.
Console Outputs:






Hope this will help developers to know the correct event they need to code and execution sequence in which Siebel will execute the code.


For this experiment I have created following PM / PR files .
  • OpportunityFormAppletPM
  • OpportunityFormAppletPR
  • OpporunityContactListAppletPM
  • OpportunityContactListAppletPR
  • OpportunityDetailContactViewPM
  • OpporuntiyDetailContactViewPR
  • OpportunityListViewPM
  • OpportunityListViewPR
  • OpportunityListAppletPM
  • OpportunityListAppletPR

All files I have used is available will be available for download soon.

Thanks to Duncan Ford for helping us in getting us code ready by creating the beautiful template generator.

Happy to discuss in detail on slack community or in comments below.

February 04, 2016

Chrome's hidden menu for Open UI

If you are working on css or js changes for Siebel Open UI, you would be struggling with browser caching. I have noticed some cache even when I am using incognito mode of chrome.

Out of frustration one might end up installing chrome app/plugin to forcefully clear cache. One of them is "Clear Cache" 

Interestingly chrome has now created a very discreet "Empty Cache and Hard Reload" option for developers. To see this option open developer tools by pressing F12 and then press and hold reload button. I have been using this option from past one week and it worked every time as expected.

Chrome Hard Reload for Open UI


Please be mindful that this is an hidden menu and only shows up when chrome's developer tools are open.


Happy coding :)

January 23, 2016

My top 5 Siebel Mistakes in 2015

I received a very candid email from a reader, asking me what mistakes I make in Siebel development and how do I overcome those?

Surprisingly I had a long list of mistakes, and I wasn't doing anything about it. So I decided to write this post to attempt on reducing these mistakes.




I believe in learning from mistakes, thus I challenge all my readers to list down their mistakes and leave them in comments below. Remember no one is perfect, so don't be shy and leave comment.

1. Using InvokeServiceMethod in calculated fields.


This is biggest performance degrader.I regret this one the most, I used this trick to calculate an status of opportunity and it turned out to be biggest technical debt of all time. No one want to fix it now and it is stuck there churning away time, memory and CPU every time it is referred.

2. Not checking CountRecords() Or FirstRecord() before get field value.

This is one of my most frequent mistake in Siebel. It goes unnoticed because the logic works for mostly all scenarios but one, what if there are no records retrieved from query? Siebel is going to throw it back to you, logic won't proceed and service will halt making you accountable.

So please don't be a Jim and always check for record count or First Record before proceeding.


3. No comments

Leaving no comments on blog post is ok, but leaving no comments in script is a big no no. Have your ever noticed how much easy it becomes if there is one of two line of comments in script? just one or two line makes it so convenient for developer to understand the code without going into details.

My self plead guilty of committing this some time.

If I have to create a standard I will try to use following template for comments:

/*
[jim] [25 Dec 2015] [ added code for xxxxx reason, code is invoked from xxxxx places]
*/

simple isn't it? Please share in comments below what type of comments you use.

3. Not nullifying objects after use.

Developers believe that ST script engine will clear up memory for them. But no memory leaks are real still in Siebel 8. So please Jim don't make that mistake again.

4. Try catch finally block
This is the only way for keeping some dignity, and we still avoid it to save time.  Do you also make that mistake?

5.  Using profile attributes.


They work like magic in some scenarios, but it is so difficult to trace them back, and using it in Open UI is like calling Mayhem. Please share your thoughts on this. How do you trace back the creation of profile attributes?

Please don't forget to leave your list of mistakes in comment below.