Standard Interactivity in Open UI
By Vishal Thilak on Feb 02, 2013
Are you upset about an SI Siebel View embedded in a High Interactivity application doing a complete view refresh every time you operate on it? Or are you wondering why Open UI refuses to display certain pre-existing applets? Or why Applications which were completely Standard Interactivity based, do not work properly in Open UI? This post is for you...
Let me explain what we mean by Standard and High Interactivity modes.
Standard interactivity (SI) means that the server sends completely data bound HTML content to the client browser. This is just like a normal website which does page navigations and redraws your complete Siebel view area.
The flicker noticed is a blessing:-)
As all of you might have seen, a HI list applet will refresh just its records when you operate on it. It could also enable/disable UI controls with no repainting.
The general downsides of a Siebel SI applet/view are:
a) Complete View refresh on any operation on Applets
b) No standard focus handling among the controls of the Applets and between the View and rest of UI
c) Limited control over the data shown in the client, since it is in a data bound page served up in one shot from the Siebel server. You can tie browser scripts to specific HTML events emitted from the page and react to it. You will not be able to participate to a complete extent in the various phases of data preparation and post back to server
d) Even a single applet being SI makes the complete view SI, in a sense demoting all of those otherwise HI applets to SI
e) Limited support in terms of dynamic UI, since any UI change will require a server roundtrip
Now that we know what these interactivity modes are and their pros and cons, let us see how a Siebel Server decides when a Siebel View is designated to operate in one of these modes.
A View becomes SI if any of the below criteria are met:
1. Contains one or more Applets which are not bound to a Business Component
2. Contains one or more Applets whose “Class” properties points to a Class which derives from classes that implement the base functionality of Standard Interactivity
3. Contains one or more Applets whose associated Class have “High Interactivity” set to 1
4. Contains one or more Applets with User property: High Interactivity Enabled = N
5. Contains one or more Applets outside of a View i.e. not associated to a view web template other than standard popups (MVG/Pick/Assoc). eg., “About Record”
6. The server side Renderer implements Standard Interactivity
7. Contains one or more Applets with a portlet in it
8. Product Catalog style layouts
In Open UI, we elevate all applets which do not belong to category 6 to High Interactivity, automatically. In other words, the “configuration” surrounding steps 1- 5 that you would have done to explicitly make an Applet/View SI, will not work in Open UI.
Now coming to what happens to applets which fall under category 6. These will presently be blocked in Open UI and remainder of the view will function as a complete HI view.
This is what you will see for those applets:
Views that expose portlets and catalogs will also function as HI with respect to the applets other than those.
Applets for which you see a message above, are being progressively migrated, so we will have to wait :-)
Lastly, as far as customizations done on a GA Siebel application are concerned, the claims above hold good. If you have some rendering customizations via browser/server scripts, done on applets falling under 6, these Applets will have to be migrated to the High Interactivity style rendering of Open UI first, after which the customization may work as is, but most probably will need to be re-looked at and rewritten using the new client stack.
Until next post, bye .