Siebel Open UI: Show / Hide Mandatory Controls – Configurable and Dynamic

Hello everybody! I’m back here after a while. Hope everyone is doing good. So, for past couple of weeks I am attending a training on Siebel Open UI. It’s like a long time dream come true. I am an amateur web developer and a Siebel consultant by profession. So when you get an opportunity to customize the long familiar Siebel Blue Screen (no pun intended) with all the power of HTML, JavaScript and CSS you feel like a kid in front of the Christmas tree on the merry morning.

After some random tampering with the UI, I thought of developing something working which can really be shown off in the real world. I got a nice opportunity when I came across one of the requirements from a Project for which I am currently working, for which the solution I thought can be built using only Open UI architecture. Forget about Siebel eScript, browser script etc., welcome to the world of JavaScript!

The Requirement:

In the Service Request More Info View there are two applets. Service Request Detail Applet and Service Request More Info Applet.

Based on the values of certain fields in the top applet we need to

1. Show or hide certain fields in the bottom applet.
2. Show mandatory icons against labels in the bottom applet.
3. Validating said mandatory fields for IS NOT NULL before WriteRecord and show standard error message.

You are free to choose fields and values on both the applets as you see fit for your own implementation.

This should be done in such a way that this behavior should be entirely data driven.

You change data, the application behavior changes in real time.

You should use only Open UI JavaScript files, maybe some Siebel UI Configurations like Applet Web Templates.

The Solution:

Part 1: Data Driven Framework

So, we need to build this thing entirely data driven. How do we do that?

By traditional Siebel approach we should insert something in some custom table, then expose that table through business layer on Siebel UI so that for future enhancements this data can be modified through Siebel UI.

As I said earlier, I was avoiding anything Siebel while doing this. So I chose the data model for JavaScript, JSON. Now you may ask what is JSON? Excerpt from Google.

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition – December 1999.

So I visualized the data model as a parent child relationship, where the parent records will hold the field names and values from the top applet and the child ShowControls records will hold the field names for the bottom applet and corresponding true or false, where true means to show the field on UI, otherwise hide it. Same with child IsMandatory data. So here is a snapshot of the data model.

So as you can see, when in the top applet the values for INSProduct, Area, SubArea are Auto, Brakes and Squeaking correspondingly, in the bottom applet only Reproduce, SRType, RootCause and EscalationTime fields should be shown, while Impact and Urgency fields should be hidden.

I hope that now you’ve got some idea about how we’re planning to configure our data, I will explain a bit later how are we going to use this model.

Part 1.1: Breaking the Rules.

In Siebel I had to remove all the white spaces from all the controls’ names which were involved in this JSON file. Assuming all the readers of this post are familiar with Siebel, I leave at the reader’s discretion how to do it.

Part 2: Writing Basic Physical Renderers and Presentation Models.

So we’ve two applet for this scenario for which we’ve to write PRs and PMs. So I started with writing basic PR and PM for both of the applets with only extending from Siebel base PR and PM and then extending the Init method of both. Nothing fancy yet. For example I am giving snapshots from the Service Request More Info Applet as we will control the UI behavior later from the Service Request Detail Applet.

Part 3: The Pseudo Code.

We will write all our relevant stuff in the Service Request Detail Applet. Maybe this is not a good practice in production, but of course, with more time it could be more streamlined further.

Glossary

• SDPM: Service Request Detail Applet‘s PM.
• SDPR: Service Request Detail Applet‘s PR.
• SMPM: Service Request More Info Applet’s PM.
• SMPR: Service Request More Info Applet’s PR.

A brief walk through of what we are going to do here.

1. First, we will build another JSON where we will store Siebel configurations. This will help to keep our implementation configurable later.
2. Next we will call Ajax to read that information in SDPR.
3. Next we will configure SDPM to call SDPR’s ChangeLayout on OnShowSelection and OnFieldChange(control, value) for every field on the Service Request Detail Applet.
4. On the SDPR’s Init we load the layout configuration data from the JSON built in step 1 earlier.
5. On SDPR we’ll get SMPM.
   Similarly we’ll get SDPM in SMPM.
6. Then we build an object fetching the Control values from SDPM for all the controls whose name match the control names from the parentvalues of our JSON layoutconf data.
7. We loop through all the instances of layoutconf.parentvalues and if any one of them matches the values which are selected in the Service Request Detail Applet we fetch the corresponding child layoutconf.showcontrols and layoutconf.ismandatory.
8. We loop through all the controls from the Service Request More Info Applet and apply JQuery show() / hide() methods for them based on the true / false values available in the instance of layoutconf.showcontrols.
9. We again loop through all the controls from the Service Request More Info Applet and append Siebel vanilla Red Asterisk (*) if we find true value in the instance of layoutconf.ismandatory for that control.
10. Then we modify SMPM to validate before WriteRecord that all the controls having true in both layoutconf.showcontrols and layoutconf.ismandatory are NOT NULL. If NULL we throw alert and do CancelOperation.

Part 4: The Actual Code.

Part 4.1: Siebel Configurations JSON

For portability purposes I’ve kept the file in PUBLIC/enu/FILES/custom directory. The data inside it looks like this. Pretty self explanatory.

Part 4.2: Ajax Call to Read Siebel Configurations Data

We write a separate function in the PR called setenvvars() which reads the Siebel configuration information using Ajax call and logs the error in case of failure.

It also returns true or false based on the result of the Ajax call.

This call happens in synchronous mode, so beware of putting large data files here.

Part 4.3: Calling ChangeLayout on OnShowSelection and OnFieldChange(control, value)

In the PM we write below to bind pmBinder in case of ShowSelection and FieldChange. We toggle the Boolean value of pmBinder in all cases.

Part 4.4: Loading the layout configuration data from the JSON built in step 1

We are going to do this both in the Init methods of Service Request Detail Applet’s PR and Service Request More Info Applet’s PM.

We load the JSON file through Ajax call and store the whole JSON object in a local variable called layoutconf.

Keep in mind that we fetched sieb_langcode and sieb_scriptpath from the siebel-app-custom.js in part 4.2.

Part 4.5: Getting access to the other Applet’s PM / PR

So it’s simpler than I thought, it follows the architecture of vanilla Siebel, Application, View, Applet, Control like that.

Part 4.6: Getting the values of desired Controls from the Parent Applet

We do this in two files.

1. SDPR to manipulate UI. (Show / hide Controls and mandatory *)
2. SMPM to validate before WriteRecord.

To do this we build an array and store all the fields’ name from the first instance of the layoutconf.parentvalues in that array.

Then we fetch the actual fields’ values, whose names are stored in the above array, from the Service Request Details Applet and store them in a new object. The code looks like this.

Part 4.7: Matching ParentValues and getting corresponding child ShowControls and IsMandatory

We do this by looping through all the instances of layoutconf, we compare the layoutconf.parentvalues with the values from the Service Request Detail Applet using JSON.stringify method, whenever we find a match we fetch the showcontrols and ismandatory objects locally and break the loop.

Part 4.8: Showing / hiding controls on Service Request More Info Applet

For this part we use a method to check if JavaScript objects are empty or not. Here is the small method.

For the next part you’ll have to inspect the Siebel control elements using the Developer Console of Chrome (F12).

Below is what the Label of a Siebel Control looks like. We hide this by selecting the element by the id value.

And this is what the input field looks like. We hide this by selecting the element by the name value.

The next part to show / hide controls, I will have to explain with the help of pseudo code.

1. IF showlocalcontrols is empty then show all the controls in the applet. Also show the parent tr.
2. ELSE
   1. For all the controls having value as false in showlocalcontrols hide the Label, Input field and the parent tr.
   2. For all the controls having value as true in showlocalcontrols show the Label, Input field and the parent tr.

Part 4.9: Showing * for Mandatory Controls on Service Request More Info Applet

We follow the same approach from the previous step.

1. IF mandatorycontrols is empty then remove all the * from all the controls.
2. ELSE
   1. For all the controls we remove the *.
   2. For all the controls having value as true in mandatorycontrols show the *.

Notice how we are using the Siebel vanilla icon_req.gif to show the *. Also notice the use of siblings() method to select adjacent elements in the HTML.

Part 4.10: Validating mandatory controls before WriteRecord in Service Request More Info Applet

For this we use SMPM’s AddMethod method to bind our custom method PreInvokeMethod to execute before vanilla InvokeMethod.

Then, we check the method name inside, if it’s WriteRecord we trigger our validation. We loop through all the controls in Service Request More Info Applet, for every control we check in layoutconf, if we find both showcontrols and ismandatory to be true, we validate the control’s value to be NOT NULL, if validation fails, we throw error via alert method and finally trigger CancelOperation.

The validation error message looks exactly like vanilla error message. We even copied the SBL Error Code.

Part 5: Pros and Cons.

Pros:

• Configurable list of fields and values for the Parent Applet. If in the future the requirement changes from 3 fields’ values to 5 fields, just changing the JSON by adding new field names and values in the parentvalues part will do the trick.
• Configurable list of fields and values for the Child Applet as well. Changing values true / false only in the JSON will affect UI without touching any of the code. Also controlling visibility of other fields are simply a matter of adding stuff to JSON.
• Defaulting of the Child Applet layout in case of Parent fields’ values does not matches with any record in JSON.
• If some control is needed on Child Applet to be shown irrespective of Parent Values, simply add the control in Siebel Applet Web Layout and omit that in our JSON.
• Any changes, fix to the framework does not require Siebel restart. Simple JS file deployment and Clear Cache on browser will do the trick.
• Future improvement plan to control Mandatory Inputs in the child applet the same way by introducing new child in JSON called isMandatory.
• Using Open UI we can even expose the JSON layout configuration data on Siebel UI the same way we show some other external data.

Cons:

• Controls that needs to be controlled should not have any white space in their names.

Part 6: The Source Code

The whole code and data files are available here.

I really hope you find this post useful, especially if you’re new to Siebel Open UI development. Please feel free to leave a comment if you have any questions / suggestions.

Happy coding. Have a nice day! 🙂