Over the last month, since the general availability of the Siebel Innovation Pack 2012 (Patch 8.1.1.9 / 8.2.2.2), many posts and even entire new blogs have surfaced with more or less detailed information on the future user interface for Siebel CRM, namely Open UI.
Yours truly has also stepped up the knowledge ladder and shared his insights on Open UI Architecture and how to extend Open UI with the new JavaScript API.
Inspired by a very good article by Open UI development team member Chandan Das Gupta, I would like to take the opportunity of raised attentiveness in the Siebel community to discuss the role of browser scripting in Siebel Open UI.
With Siebel Open UI, developers have it in their hands to manipulate the browser UI in unprecedented depth. With this great opportunity to bend and hammer the UI to meet your user's perceived requirements comes great responsibility.
What nobody can possibly desire is a loose collection of JavaScript files which throw overboard all good manners of professional programming.
So let's reiterate what the role and reason of browser side scripting in enterprise class applications like Siebel CRM really is (and what it is not):
1. Never implement business logic in the UI layer
There is absolutely no justification for writing browser script that implements business logic. In Siebel CRM, we have business components, their fields and business services like Data Validation Manager to accomplish a centralized store for business logic.
For example, browser script is absolutely NOT the place to implement field level validation such as dates or email address validation etc.
Why?
If you really ask why, consider for a moment what Siebel CRM really is. It is always integrated with other systems and integration always happens on the business layer side (or database layer, when you use EIM). So you must implement business logic on the business layer to support the EAI interfaces. Let that be your reason number one for not writing business logic code in browser scripts.
2. Use UI layer scripting only to work with the UI
Browser scripting, be it in "traditional" Siebel clients or the brand new Open UI client, is intended to do whatever you think you need to do with the UI artifacts in the browser. Here are some (in my humble opinion) justified uses of browser-side scripting:
Conditionally modifying the appearance and behavior of forms, lists, fields and labels, etc. For example, changing the background color of a text box, changing column labels or hiding buttons can be accomplished easily with Open UI.
Displaying complex user dialogues. Sometimes, the server-side options for communicating with the user are not as bi-directional as we would like them. It should not be overdone, but a certain amount of custom dialogues can be implemented fairly easy with browser script. And I am not talking of a bunch of alert() calls in your script...
Enhance and enrich the user experience. With Open UI, we have full command over the physical renderer and therefore we have almost no limits when it comes to creating new user interface models such as carousels, hierarchy charts, draggable applets, etc. However, always ensure that these efforts have a solid business justification and are more than just showing off what you can do ;-)
3. Think twice but never code twice
Whenever you find you are copying code from one place to another, you should immediately take your hands off the keyboard and think again. Is it really worth to breach the re-usability mandate of good coding? Never forget, that in Siebel CRM, we have business services (which we can also call from the browser script). In addition, we can write browser script functions that we can call from various places.
4. What happens on the server stays on the server
So you need to parse a record set, update or create records in Siebel CRM? That is the domain of the object manager. So be careful not to reinvent the wheel and try to outsmart the Siebel server with JavaScript.
Summary
I know the above post is a bit of a rant and may put off some people, for which I apologize up front should that be case. My intention was to provide some food for thought. Especially with a new framework such as Open UI there is a certain learning curve for all project team members. But just because we have a new UI framework, we should not forget our good manners and our responsibility we have as a programmer who has the privilege of extending an enterprise class software application.
have a nice day
@lex

3 comments:
Nice article!
Completely agree with you on this @lex. I have become somewhat aggrieved with the level of "fanaticism" that has accompanied the release of Open UI. Sadly not all the people I have spoken to seem to realise either the importance of the points you make, or the simple fact that Open UI will not "make Siebel a winner" at a given customer site. It's all about the why, not the what!
So what we have is central business rules in Drools. We can either call them over the wire or we now have the ability to "compile" then into js files and use in Open UI. Putting rules close to UI makes for a much better user experience. This we use for certain capturing where we use Siebel to capture data that we are NOT the master of. All Party validations (Siebel is Party master) is done on the business logic side.
Post a Comment