We have seen what Open UI is and how it is different (but not so different) from what Siebel has been doing so far. Let us look at a bit of architecture aspects of Open UI.
Siebel Open UI Architecture
I find it better to explain visually – so first off, here’s the diagram. As in many posts, putting the customer (which is user in our case) at the top is deliberate :).
Next, we try to first go through each of the components and have a brief understanding of what it does. I have no intent to explain the full 9 yards, that is for the documentation.
1. Client (or Presentation Layer)
Siebel is accessed from a browser (as was the case since Siebel 7). The client consists of –
- DOM: Document Object Model (or DOM) is part of the browser on the client machine that allows itself for manipulation so that users can interact with data through the browser. DOM is standardized, but variations exist across browsers.
- Physical Renderer (PR): This is the component responsible to render user interface on the client. PR selects controls for specific data elements (e.g. date, picklist control), chooses how to lay out the data (carousel, list). PR knows the layout information PR provides the isolation between data and how data is displayed. PR finalizes the HTML that is displayed on the web browser
- Presentation Model (PM): Presentation model is the back-end processor for the client. PM takes the data and client-end logic passed by server through the proxy, and passes the data to PR. PM will set properties of the fields while passing data to PR. PM
PM will enforce actions and apply logic rules for the data entered/updated and pass it along to the proxy if everything is ok. For example, what should happen when user clicks on button, what will happen if user text in a number field, etc. PM handles the logic that was being done by Siebel Browser Script in ActiveX.
Proxy gets the data handed over by the client, and passes it on to server for processing and storage
2. Server Layer
Siebel client communicates with the server through intranet or internet, using HTTP or HTTPS protocols.
For stand-alone (remote/developer) clients, siebel.exe satisfies the roles of webserver and Siebel server, and this has not changed. The files for the client are stored in <client-root>/public/<language>/files.
Cascading Style Sheets (CSS) provide the look and feel of the UI. CSS in Open UI is not limited to setting colours as was the case in HI, but gets more powerful by having the power to handle layouts, and UI element styles. HI CSS files are separate from the Open UI CSS files, but both exist in the same directory.
- Allow only a date less than today’s date in “Open Date” field
- Display “State” field only when “Country” is “India”
Siebel server architecture has not changed. Open UI is enabled on any HI object manager by changing the parameter “EnableOpenUI” to “TRUE”. This can be done on the Component Parameter for server, and in the specific configuration file (CFG) for client. Client CFG can be found in <client-root>/bin/enu.
Open UI components can co-exist with HI components. For example if you have emedical_enu running on HI, you can clone the same component on the server, enable Open UI on the new component, and run both object managers (OM) on the same database. All the rules for creating and maintaining application OMs are applicable for Open UI OMs. Standard Interactivity OMs continue to function as-is and can co-exist with Open UI as well as HI OMs.
We look at two key components of Open UI on the server side below.
Apart from CSS, JS changes outlined in earlier sections, the other significant change for Open UI is in Siebel web template (SWT) files. SWT files have historically provided the placeholder for applets within a view, and for controls/list columns within an applet. Developers map the controls/list columns and create the user interface in Siebel HI. SWT files abstract the HTML layer, and dictate the layout of the UI.
SWT files for Open UI is separate from the SWT for HI. Instead of providing the exact place holders for mapping controls to applet and the exact layout, SWT files now let the CSS files decide the layout.
SWT files are stored in <siebel-server-root>/WEBTEMPL. Open UI web template files are stored in <siebel-server-root>/WEBTEMPL/OUIWEBTEMPL. A custom sub-folder under OUTWEBTEMPL can be used for custom changes.
Manifest files are stored in <siebel-server-root>/OBJECTS/, and consist of:
- core_manifest.xml – lists out of the box (OOB) JS files
- custom_manifest.xml – developers can add their custom files here
- manifest_extensions.map – applets are mapped to unique keys that determine the JS mapping for the individual applets
What can be customized?
Developers can add or extend functionality by:
- carry out Siebel customisations including adding screens, views, applets and the corresponding business/data layers
- create/update CSS files (or collate them in a ‘theme’) to change the look and feel of the UI
- create and update Siebel web template files
- update custom manifest file
Developers cannot/should not customise:
– proxy JS files
– Oracle-provided application JS files – this can get lost during upgrades
– update Siebel-provided SWT, manifest files
Siebel Open UI thoroughly refreshes the front-end architecture, while maintaining the robust, proven back-end on the server side. I will outline more of Siebel Open UI components with examples and case studies through the next few weeks (or months!).
The architecture diagram is created using LucidCharts, a browser based diagramming tool. The diagram is completely free, and released to the public domain. Go ahead, copy it and use it for the benefit of humanity! An attribution in the form of link is appreciated, not required.