Siebel Open UI Architecture (Siebel Open UI Training – Part 2)
In our previous article, we have discussed about what is Siebel Open UI and its benefits. Here we will talk about Siebel Open UI Architecture and its various building blocks. Also we will discuss architectural difference between Siebel HI and Open UI client.
Siebel Open UI Architecture key components:
It includes all components of traditional Siebel client, plus Open UI specific components.
- Application Object Manager(AOM)
- Siebel Web Template(SWT) file
- JavaScript(JS) file
- Cascading Style Sheet (CSS) file
- Open UI client
– Proxy
– Presentation Model
– Physical Renderer - Manifest file
We will discuss all these one by one.
1. Application Object Manager (AOM)
– This is the most important server component. In Open UI, it behaves exactly the same way like our traditional Siebel client. AOM processes user requests with the help of other components like Data Manager, Siebel Web Engine.
– In our previous module, we have already discussed that below two parameters must be set to TRUE for Open UI Object Manager component.
EnableOpenUI = TRUE
HighInteractivity = TRUE
Our Recommendation: Instead of updating the existing object manager directly, copy it and add above two parameters to enable Open UI mode . Also you create a new virtual directory in Siebel Web Server to support Open UI Object Manager.
2. Siebel Web Template(SWT) file
– Siebel Web Template file defines the layout and format of the elements to display on UI. It provides the placeholders for Siebel objects like views, applets, controls but does not contain any data. These SWT files are nothing but HTML files with Siebel tags. Siebel Open UI uses newer version of SWT files that no longer contain any explicit layout information.
Original SWT file has explicit tags like tables, boundaries where Open UI SWT file has ‘div’ tag. It allows CSS files to control the layout.
– SWT files are located under \siebsrvr\WEBTEMPL
- WEBTEMPL folder contains original SWT files
- OUIWEBTEMPL folder, inside WEBTEMPL contains Open UI related SWT files
- CUSTOM folder, inside OUIWEBTEMPL contains all custom SWT files
To know more about Siebel Web Template, read this: Overview of Siebel Web Templates
3) Cascading Style Sheet (CSS) file
– CSS is a style language that defines the layout of web pages, such as font, color, height, width
– Benefits of CSS:
- Reusable, one CSS file could be used for multiple web pages
- Modify style definition in one place and change will be reflected in all web pages
- Different layout for different media types like mobile, desktop
- Easy to build, notepad is sufficient to write css file
– Open UI uses CSS to build the layout of HTML files dynamically.
– CSS files are located in the web server under \webmaster\files\<lang> and \eappweb\PUBLIC\<lang>\FILES.
– For Siebel developer client, path is \client\PUBLIC\<lang>\files.
4) Java Script (JS) file
– JavaScript is a client side programming language used in web applications. It enhances the users experience of the web pages.
– In Siebel Open UI, JS files are used to add client side businessand validation and render the application in the web browser
– Oracle provided JS files deliver out of box functionalities. Developers can build custom JS files to leverage the functionalities.
– Beside Javascript, developers can use JQuery also.
– JS files are located in Siebel Server under \siebsrvr\public\<lang>\<build>\SCRIPTS
- SCRIPTS folder contains original (High Interactivity) JS files
- siebel folder, under SCRIPTS contains Open UI related vanilla JS files
- custom folder, under \SCRIPTS\siebel contains all custom js files
- 3rdparty folder, under SCRIPTS contains all 3rd party provided js files
– For Siebel developer client, JS files are located in \client\<lang>\<build>\SCRIPTS
Note: Traditional browser script is different from Open UI related JavaScript. Developers can use both in Siebel Open UI. But Oracle recommends to use JavaScript only for client side validation.
5) Siebel Open UI client:
– Open UI client is a Siebel engine that runs within the browser to enhance user experience and data validation
- Binds data to the presentation layout
- Caches data locally
- Applies client side business logic
– It consists of 3 elements
- Client Proxy
- Presentation Model (PM)
- Physical Renderer (PR)
5.1) Client Proxy
– It works as an interface to the Siebel Server.
– It gets run-time data and metadata from Siebel server and passes it to Presentation Model.
- Run-time data is the actual data from Siebel database that users see in views/applets
- Metadata specifies the column name and other details like required, readonly
– It is Oracle provided and must not be modified by users.
5.2) Presentation Model
– It is a JavaScript file that determines what business logic to be applied on metadata and run-time data coming from Siebel server.
– It captures client interactions such as
- Did the user leave a control?
- Did the user click on the link?
– It is collection of Properties and Method
- Properties: It contains information about current state of each user interaction.
- Method: It defines the characteristics that modify the state of the object. For example – if user chooses value A for the field X, then apply method to hide field Y.
– It supports different logic for different platforms
5.3) Physical Renderer
– It is a JavaScript file that Open UI uses to render application on the browser
– It can display the same set of records in different ways
- List Applet
- Carousal
- Calendar
- Mind Map
– Like Presentation Model, it also supports different behaviors for different devices like Desktop, Mobile
6) Manifest file
– It uses an unique key to determine which JavaScript file/s to download to the client
– Earlier version of Siebel Open UI Innovation Pack 2013 (8.1.1.11) has three manifest files under \seibsrvr\OBJECTS directory
- Core_manifest.xml: As delivered listing of JS files and should not be modified by developers
- Custom_manifest.xml: It specifies the key name and JavaScript file mapping
- Manifest_extensions.map: It is the place to register Applet/key combination
– From Open UI Innovation Pack 2013, you do not need to modify manifest file anymore. Rather you configure it from Open UI client itself – Administration-Application||Manifest Administration.
We will discuss more about Presentation Model, Physical Renderer and Manifest File in subsequent modules.
Graphical presentation of Siebel High Interactivity Architecture Vs Siebel Open UI Architecture (Source: Oracle)
Major changes in Siebel Open UI Architecture:
- Open UI supports all modern browsers, not just Internet Explorer
- ActiveX controls are replaced by JavaScript controls
- ActiveX proxy is replaced by JavaScript proxy
- In Siebel Open UI Architecture, layout is not part of Siebel Web Templates any more
So far we have discussed various building blocks of Siebel Open UI Architecture and how it differs from Siebel HI client. If you have any doubt, please fell free to comment below.
Next we will discuss the architectural flow with an example – Navigating to My Opportunities view. Suppose you have clicked on ‘My Opportunities’ to open My Opportunities View. Now Siebel Open UI performs below steps to render ‘My Opportunities View’ on the browser.
Step 1: Presentation Model passes the request to the client proxy
Step 2: Proxy sends the request to Siebel Server
Step 3: Siebel Server processes the request and sends the result back to proxy
Step 4: Proxy reads the manifest file and downloads all required JS files
Step 5: Presentation Model applies the business logic on the result set and sends it to Physical Renderer
Step 6: Physical Renderer prepares the final HTML file with the reference of CSS files
Step 7: Result is displayed on the browser
Step 1: Presentation Model passes the request to the client proxy
– Presentation Model captures the event ‘on mouse click’ and sends the request to client proxy
Step 2: Proxy sends the request to Siebel Server
– First proxy checks the client cache memory for the necessary data to fulfill client request
– If required data is available in the cache memory, it directly goes to Step 4. Otherwise proxy sends the request to Application Object Manager on Siebel Server to get the record set.
Step 3: Siebel Server processes the request and sends the result back to proxy
– Application Object Manager processes the request and sends back the record set to proxy
– Record set contains metadata and runtime data
- Metadata: Object definitions like Columns, Applets, Views
- Runtime data: Actual user data from Siebel database
Step 4: Proxy reads the manifest file and downloads all required JS files
– Proxy reads the manifest file and downloads all JS and corresponding CSS files to display opportunity records.
Step 5: Presentation Model applies the business logic on the result set and sends it to Physical Renderer
– Once data is received and files are downloaded, Proxy sends the notification to Presentation Model
– Presentation Model executes JS files to apply business logic on received data
Step 6: Physical Renderer prepares the final HTML file with the reference of CSS files
– Presentation model sends the notification to Physical Renderer to generate HTML files with the reference of CSS files.
Step 7: Result is displayed on the browser
– The final HTML page ‘My Opportunities View’, embedded with JavaScript, CSS and Data, is displayed on the browser.
This ends our module 2 on Siebel Open UI Architecture. Hope you have got a fair understanding!
If you have any question regarding Siebel Open UI Architecture, Please feel free to comment below.
Keep in touch, follow TechOneStop on Facebook / Twitter / LinkedIn / Goolge+.
<< Module 1: Siebel Open UI and its benefits Module 3: Presentation Model Customization >>