How to Optimize Siebel Application Login Time

Recently, we've had a lot of users complaining about the homepage taking too long to load. Why does the login page take long to load? What happens when the login page loads. Below are some of the tasks that Siebel performs while loading the application.

- Verifying Application Schema Version
- Loading / validating State Models (checks whether or not the expiration date is greater than current date)
- Verifying State Model values for transition
- Loading / Validating Personalization rules and rule sets for each event on applets, Business Components, - - Business services and application
- Loading / validating user profile data.
- Loading / validating System preferences
- Loading localized data (Phone format, date format, time zone, currency etc)
- Loads user reporting hierarchy
- Loads application view-responsibility data.
- Message Broadcast (This can be inactivated by inactivating the Message broadcast bar)

The reason behind such a behavior is that some of the static data (localization, license keys etc) and SRF data that are common to all business components are initialized for the object manager process with the first task or user login request. It is this initialization of tasks that causes the delay in service to the first user.

Setting the “OM - PreLoad SRF Data” (PreloadSRF) parameter to TRUE will trigger the loading of this global data for the object manager process when it is initialized upon starting the services. Now the first login should be faster as the burden of reading the static data is pushed to the component startup phase.

NOTE:  After setting the parameter to TRUE, you must recycle the services for the parameter value to take effect.

If setting the parameter at the enterprise level, all the object managers in the environment will automatically inherit the parameter value (unless an administrator has specifically set the value on the lower object manager level).

Also, if this parameter is set to be TRUE in conjunction with the MinMTServers parameter, the static data will be loaded for the number of object manager processes specified for the MinMTServers parameter when the component is initialized. This way there will be no delay in service for a large volume of users since the minimum required multi threaded object manager processes would already be initialized.

M.O.S Reference:  Doc ID - 476878.1

The Siebel Blackbook

How to Stop a BusComp_PreWriteRecord

Many a times we find ourselves in a situation wherein we think our configuration is correct, but why the hell can I not see my changes. Tiny things make a big difference in Siebel and we spend hours trying to figure out whats going wrong, and more often than not its just a silly property that we may have overlooked :)...read on

When the current record of a BC has beeen modified, the user cannot step off the record without either saving or undoing the record. (Under normal circumstances, saving is done automatically when stepping off, so the user does not need to save the record manually.)

When calling RaiseErrorTest in BusComp_PreWriteRecord, or when returning CancelOperation from this event, the current record does not get saved to the database; however, it remains modified, and thus the user cannot step off the record. For the user, after clicking away the custom RaiseErrorText message, it may appear as if the system suddenly gets unresponsive as they cannot step forth and back anymore, and unexperiences users may not know how to escape this situation (by e.g. undoing the current record or by modifying the record until it saves successfully).

If, on the other hand, the script calls UndoRecord before raising an error, all changes are lost, which might lead to a negative user experience.

This is why Bookshelf recommends to not using RaiseErrorText within BusComp_PreWriteRecord.

If you observe a situation where it seems necessary to cancel an ongoing WriteRecord operation in the BusComp_PreWriteRecord event handler, then depending on your scenario you may want to consider these alternate approaches:

1. Verify the changes earlier

Some scenarios might allow verifying the changes to the current record earlier, such as in BusComp_PreSetFieldValue() or at applet level. However, consider that unless a BC field has the "Immediate Post Changes" flag set to TRUE; changes in the UI will not reach the BC (and thus not trigger BusComp_PreSetFieldValue()) until the user saves or steps off the record.

2. Verify the changes later

In BusComp_WriteRecord(), it is possible to use RaiseErrorText() since raising an error here does not cancel any pending operation - the WriteRecord already has finished. In this scenario the wrong data is already committed to the database, so either the user needs to navigate back to the record and modify it appropriately, or an internal process needs to identify and clean up the record later. (This depends on your particular scenario.)

3. Use Siebel Task UI

Siebel Task UI allows to guide the user through a set of operations before saving the result. As per the Task UI documentation, "Task UI's wizard-like user interface guides the end user through task execution, allows navigation both forward and backward within task execution, and allows task execution to be paused and resumed as needed."

This process can make use of "transient" business components, which means that the data does not get stored to Siebel tables until the task is finished successfully.

Thus the Task UI seems suitable to implement the desired two-step process of saving contact data to an external system first and then to the Siebel database.

Cheers!

Get and Set value of Profile Attributes Profile Attributes from the Application

The other day I was doing a development task related to scripting. I was using a lot of Profile Attributes in my logic. However, I had to put alerts in my code to check whether the profile Attributes were being set correctly. I had to revisit the code a lot of times. That's when I came accross this trick on Siebel Unleashed.

javascript:alert(theApplication().GetProfileAttr("Login Name"))


Place the above code in the address bar of your Siebel Application as below and hit Go.

A popup is displayed with the value of the Profile Attribute.

You can go either a GetProfileAttr or even a SetProfileAttr

 javascript:alert(theApplication().SetProfileAttr("TEST", "Only Siebel"))

This trick can very well be used for debugging purposes.

Cheers!