| Siebel CRM Configuring Siebel Open UI Siebel Innovation Pack 2015 E52417-01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM Configuring Siebel Open UI Siebel Innovation Pack 2015 E52417-01 |
|
Previous |
Next |
View PDF |
This topic describes the differences that exist between the high-interactivity client and the Siebel Open UI client. It includes the following information:
"Comparison of Customization Capabilities Between High Interactivity and Siebel Open UI"
"Summary of Differences Between High Interactivity and Siebel Open UI"
The Siebel Server uses SWE (Siebel Web Engine) tags in SWE templates to create the screens that it displays in the high-interactivity client that a Siebel application uses. A control is a contained, user interface element, such as a menu, toolbar, grid, combo box, and so on. The red borders in Figure 2-1 identify some of the controls that the Siebel Server renders.
A typical Siebel CRM Web page includes several controls that Siebel Web Template (SWT) files define. For example:
Menus
Toolbars
Predefined query lists
Screen tabs
Applets
In high interactivity, each of these controls, or a group of controls, occupies an HTML frame. High interactivity positions the HTML frame and uses the position and dimension information that the HTML markup contains in this frame to hardcode them into place. High interactivity gets this information from the SWT files that it processes to render the page layout.
A high interactivity client is a type of Siebel CRM client that resembles a Windows client. It supports fewer browsers than standard interactivity, but it includes a set of features that simplify data entry. For example, page refreshes do not occur as often as they do in standard interactivity. The user can create new records in a list, save the data, and then continue browsing without encountering a page refresh. For more information about high interactivity and standard interactivity, see Configuring Siebel Business Applications.
A SWE template allows you to customize a high-interactivity client only according to the capabilities that the SWE tags provide. For example, you can add a custom list applet to a view, but you cannot modify the individual objects that this list applet contains. You cannot modify a list applet to render as a carousel because a view web template can reference an applet, but it cannot reference the objects that the applet contains, and you cannot modify the ActiveX controls that do render these objects.
Figure 2-2 illustrates how Siebel CRM uses repository metadata to render objects in a high-interactivity client. For example, Siebel CRM uses:
View metadata that resides in the repository on the Siebel Server to render a view object in the client.
Applet metadata and Siebel CRM data that reside in the repository to render an applet object in the client.
Figure 2-2 illustrates how a standard, custom rendering capability is not available on the high interactivity client because Siebel CRM uses a SWE tag that it gets from the Siebel Server to render each control, and you cannot modify these tags in the client. The configuration on the client is for the most part a black box configuration. You cannot modify it, or it is difficult to modify objects in the client without using Siebel Tools to do custom binding.
Siebel CRM uses a SWE template to render each applet directly from the Siebel repository to the user interface in the client, and each applet references a business component to get Siebel CRM metadata and data from the repository. This configuration does not allow you to customize how Siebel CRM renders this applet unless you use Siebel Tools to modify the repository. For example, you cannot use JavaScript in the client to distribute data from a repository applet across more than one pane in a Siebel screen, such as displaying the address of a contact in a pane that is separate from the pane that displays other contact details, such as the contact name and phone number. You cannot use an alternative configuration, such as your custom configuration or a third-party configuration, to bind the Siebel business layer to user interface objects, except through Siebel Tools.
Only one view that displays content typically exists in a Siebel screen, and you cannot add more views unless you use Siebel Tools to modify the repository. Siebel Tools specifies the configuration for each instance of these objects that determines how Siebel CRM binds the object to the Siebel Business Layer. For example:
To bind the command that a menu item or toolbar button calls
To bind the business component and business component fields that an applet references to get Siebel CRM data
You can write scripts on the Siebel Server or the client, but these scripts only allow you to customize how Siebel CRM processes the requests that it receives from the user interface. They do not allow you to customize rendering.
For more information about applets, business components, views, the Siebel repository, Siebel metadata, Siebel Tools, the Siebel Object Hierarchy, and so on, see Configuring Siebel Business Applications.
Siebel CRM does the following to render a Siebel Open UI client:
Uses HTML div elements and HTML tables in SWE templates to determine physical layout instead of the HTML frames that high interactivity uses. Siebel Open UI does not use div elements to structure a page. The entire page hierarchy that Siebel Open UI uses is a hierarchy of div elements. Siebel Open UI does not use the HTML frame.
Uses cascading style sheets (CSS) to specify position, dimension, and styling for HTML elements, such as font color and font type, instead of the HTML code that high interactivity uses. This styling does not apply to the objects that an ActiveX control renders in a high-interactivity client, such as a list applet.
This configuration is more closely aligned with current guidelines for Web design than the configuration that high interactivity uses. Siebel Open UI allows you to customize how Siebel CRM renders individual objects in the client without having to use Siebel Tools, and it allows you use an alternative configuration, such as your custom configuration or a third-party configuration, to bind the Siebel business layer to user interface objects. Siebel Open UI allows you to customize an existing SWT file or create a new SWT file.
Figure 2-3 illustrates how the Siebel Server uses SWE tags that reside in SWE templates to render div containers on the Siebel Server. For example, it renders a swe:view tag as a view container. It does the same rendering on this server for Siebel Open UI that it does for high interactivity.
Figure 2-4 illustrates how Siebel CRM uses a presentation model, which is a JavaScript file that resides in the client that specifies how to handle the metadata and data that Siebel Open UI gets from the Siebel Server. Siebel CRM then displays this information in a list applet or form applet in the client. The presentation model provides a logical abstraction of the metadata, transaction data, and behavior for part of the user interface. Siebel Open UI includes a presentation model for each significant part of the user interface, such as the application menu, toolbars, screen tabs, visibility drop-down lists, applet menus, different types of applets, and so on. The presentation model does not render the HTML in the user interface.
Figure 2-5 illustrates how Siebel CRM uses a physical renderer, which is a JavaScript file that Siebel Open UI uses to render the user interface. A physical renderer contains instructions that describe how to render the physical presentation and interaction for a user interface element, such as a grid, carousel, form, tree, tab, menu, button, and so on. Each physical renderer references a presentation model, and it uses the metadata, data, and behavior that this presentation model defines to render an object in the client. For more information about presentation models and physical renders, see "About the Siebel Open UI Development Architecture".
Siebel Open UI uses the presentation model and the physical renderer to separate the logical user interface from the rendering. This configuration allows you to modify the user interface without having to modify the logical structure and behavior of the client. For example, you can modify the physical renderer so that it uses a third-party, grid-to-carousel control to display a list applet as a carousel without modifying a presentation model. For more information about this example, see "Customizing List Applets to Render as Carousels".
You can use the physical renderer of a control to implement a variety of configurations so that Siebel Open UI can render this control at nearly any physical location in the browser and with your custom logic. You can use the physical renderer to display different parts of the same applet in different physical panes in a Siebel screen. For example, you can configure Siebel Open UI to display a temporary recycle bin that uses data from the presentation model to render data in a pane that is physically separate from the data that the list applet displays. For more information about this example, see Chapter 4, "Example of Customizing Siebel Open UI."
You can use the presentation model to modify the logical behavior of the user interface without modifying the physical renderer. For example, you can modify a presentation model to add a list column in a list applet so that it iterates through list columns and renders them without modifying the physical renderer. This column can reside on the client even if the Siebel Server contains no representation of it.
You can customize at the control level writing plug-in wrappers that govern how a control should appear and behave when a certain set of conditions are satisfied. A checkbox appearing as a flipswitch on mobile devices is an example of this type of implementation.
Siebel Open UI and high interactivity implement the physical user interface differently:
Siebel Open UI. The SWE renderer that Siebel Open UI uses structures the physical user interface through HTML div elements instead of the HTML frames that high interactivity uses. This configuration allows you to use cascading style sheets to do the layout for these div elements instead of hard coding the position of HTML frames. It simplifies reconfiguring the HTML for different user interface themes.
High interactivity. Uses a hierarchy of HTML frames. This hierarchy makes it difficult to reconfigure the rendered HTML to support different user interface themes.
Siebel Open UI uses the same browser proxy configuration that high interactivity uses. This structure uses the Siebel Object Hierarchy that includes applications, views, applets, business objects, and business components. It implements each of these objects in JavaScript. These JavaScript objects render HTML and handle user interaction through DOM events. Siebel Open UI uses no ActiveX controls to render the physical user interface.
The applet object that resides in the proxy contains all the same metadata and data that it requires to render the physical user interface that high interactivity uses. For more information, see "About Objects and Metadata".
In some situations, Siebel Open UI gets more data locally from the proxy or the client, or it creates metadata in the client. A presentation model specifies how to display this local data. It also provides an interface to the proxy.
Siebel Open UI uses a physical renderer to implement the binding that exists between a predefined JavaScript control and the Siebel Object Model that resides in the proxy.
To create the HTML DOM structure for a JavaScript control, the renderer uses the metadata and data that Siebel Open UI populates into the client proxy. The renderer uses methods that reside in the presentation model to access this metadata.
High interactivity and Siebel Open UI share the following customization capabilities:
Metadata configuration for all user interface objects resides in the Siebel Repository.
Layout configuration of user interface objects resides in SWE templates.
Some server scripting capabilities exist to render custom configurations.
Table 2-1 summarizes some of the significant customization differences that exist between high interactivity and Siebel Open UI. For a more detailed comparison, see Article ID 1499842.1 on My Oracle Support.
Table 2-1 Summary of Customization Differences Between High Interactivity and Siebel Open UI
Browser scripting for proxy objects resides in the client. For more information, see "Browser Script Compatibility".
