Enable advanced filters - Siebel doesn't play fair

What do you do when you need a filter, and a slightly different behaviour, as compared to what is provided by the base BC in Siebel?

If you have been a good citizen of Oracle, you will enable search specification on the applet. Then, you start worrying about how to implement the differing behaviour. If you want to play bad, you will use some scripts in applet load (or similar) to exhibit some funky behaviour.

It is only after the initial design that you start noticing all the idiosyncrasies that go with “common” BCs.

The filters start failing in one or the other popups. The behaviour of the main BC starts kicking in some issues for the new applet. Picklists of course make your users cry foul since they display more values than what you intended for the new applet. You will start thinking on whether it was a good decision to use an existing BC in the first place.

Common problem, common enough solution, and things that we have learnt to live with and apply solutions in patches. No big deal.

But, think about what would Siebel do in such a situation.

Well, they just go about creating a new class.

Take an example. Navigate to Communications > Communications List. You will see an applet here - “Comm Inbound Item List Applet”, based on our beloved “Action” BC.

Though the applet is based on Action BC, you will see that the view shows only activities of two types - “Email - Inbound” and “Email - Outbound”. For those who have time on their hands, you can expose the Type field on the same applet and can see that only these two types are visible even in Query mode.

Siebel does this through specialised class and user properties.

“Comm Inbound Item List Applet” is based on class “CSSSWEFrameInMail”. This class supports a user property called “Allowed Activity Types”. By default this user property has the value:

"Email - Inbound", "Email - Outbound"

The class and user property cause appropriate filters to be displayed in the Communications view. If you want more types (e.g. “Fax”), just add that value against the above user property and voila, records with the newly specified type start appearing in the view.

There are thousands of specialised classes and user properties in Siebel. This is one of the examples where a potential configuration task has been circumvented with the underlying class.

Not a good architecture, but works just fine for Siebel developers.