“Don’t turn on link spec. or force active flags to TRUE” - they say.

“It will be a performance hog” - they say.

You kept on wondering that it is indeed true. Not any more.

Cheeky opening statements aside, why exactly people are afraid of these two properties. Let’s find out.

What are Force Active and Link Specification properties? #

Siebel application has thousands of fields, and it makes absolute sense to query only the information that is required to perform a distinct task. As Siebel follows a relational data model, that implies that only data from specific tables will be queried when users request for the specific information by navigating to a view, or by performing an action.

Is queries generated by Siebel with her specific tables and required columns from those tables. Both force active and link specification properties provide a way for you to always include predefined fields/columns whenever the business component is initiated. It does not matter whether those fields are present on the UI (or have been pre-activated in the script).

You can turn on these two properties by just setting two flag against the fields in Siebel  Tools.

If these two properties to the same darn thing why exactly are there two properties, you ask?

Yes, there is a difference.

Force active is localised to the business component. The fields get “activated” only when the business component in question is initiated.

Force active is set to true When the special fields are required from script, or from workflows, even if the field is not exposed on the applet.

The general notion that force active property always impacts the system performance is wrong. Imagine this: if you are fetching 60 fields from S_ORG_EXT, does it really matter if you fetch two additional Text fields from the same table? Of course it does matter when your force activating a joined field - especially if it is an indirect join where you are using multiple tables/columns to fetch the target value.

On the other hand, link specification makes the feed available to the child business components as well. If you initiate the child BC, you can also access the parent fields that have link specification set to true.

You use link specification property on the field when -

• you want that field value to be available to set as a pre-default/post default value in the child component fields.
• you’re using the parent field value in a calculated field of the child component. For example set the opportunity status depending on parent account type.
• you’re using the parent field value in a user property in child business component. For example make the opportunity status “read-only” if account status is “Inactive” (You should use “Parent Read Only Field” User property if you’re wondering how to do that)

Although link specification also keeps the field active in all queries, You should generally consider it as force-active++. The property activates the field value even when you’re dealing with the child components.

Performance wise, this behaves very similar to force active. You may not be excessively worried when the field is on the base table, but you have to be really careful if you’re dealing with a joined/multivalue field. This may have cascading impact to the performance across multiple views.

In summary: avoid excessive usage of force active/link specification properties. But at the same time don’t be afraid of using them when necessary.