Siebel Fluid Form Applets

Making Siebel Form Applets really responsive and fluid, that was Duncan’s goal. Duncan, part of Oracle’s Siebel development team brings solutions to the table that make you think and wonder. Although Siebel OpenUI is said to be responsive, that does not hold very well for form applets. The idea was to maximize the real-estate for form applets based on available screen-width. Fully fluid.

So… say from something like this:

fluid_before

Towards something more like this:

fluid_after

Much cleaner, isn’t it? And fully fluid!

You can find, follow and contribute to his work in progress on the OracleSiebel!

– Jeroen

 

Advertisements

https://github.com/OracleSiebel/

What kind of blog title is this?


https://github.com/OracleSiebel/ConfiguringSiebel


Yes, Oracle’s Siebel Development is starting to use Github to promote collaboration with the Siebel eco-system. As primer, to provide some insights into the DISA Extensibility Framework which will be provided as part of Innovation Pack 2016.

disa_diagram.png

Just browse to https://github.com/OracleSiebel/ConfiguringSiebel/tree/master/ExampleCode/DISA to get a primer. Be prepared for Innovation Pack 2016. It’s to be released shorty 😉

ConfiguringSiebelDISA_Github

To top it, you will find an actual code example to practice it yourself – gathering some basic system info through DISA and expose in the Siebel client.

– Jeroen

 

Saving Siebel Data – Poor Man’s Approach

Quite a bit has been said and written about data-loss prevention in web applications in general, and Siebel in specific. On My Oracle Support, the SiebelHub as well as by myself . A truly water-tight solution has not been identified so far, to overcome the problems related with that ‘nasty’ back-button.

Adding to the array of possible approaches this time a poor man’s save button. Now, what I want to prevent at all times is having save buttons all over the place, like seen in other web applications. That just makes no sense if you ask me, and looks too much Siebel 7.0 or Standard interactivity 😉

Therefore I decided a while back, to implement a simplistic ‘Save’ button which would linger through the application. Always. And always at the same location.

If you think of it, especially when running Siebel on touch-based devices, having that Save button would be a big plus. You don’t want to use CTRL+S on a tablet. Not such a bad thing after all?

Functionality-wise it should do little more than invoking the WriteRecord() method for the view’s active applet. It should at a minimum check whether it’s allowed to invoke it, to prevent run-time errors. Further, should it not interfere with Siebel’s standard error reporting mechanism (e.g. ‘Required Field missing’ or such).

The button should have a translated text. When clicked after effectively invoking the WriteRecord, the active applet’s border should glow up red using a CSS transition. That’s about it.

IP 16 Note: Siebel development decided on a similar path, in case uncommitted data is detected, to change the active applet’s box-shadow in red. Very similar to what I did here.

So, what does it all look like?

The solution consists of a little bit of postloader code, to add the button and its functionality. I decided to mimic a standard Siebel button, so that’s what I did when creating it. It’s a HTML button, not a Div. Further as always a bit of CSS. CSS uses an animation, to animate the box-shadow property of the applet to let it glow up in red while at the same time increasing the blur.

See code and CSS below.

save_button_js

save_button_css

As always, you can grab the postloader and the CSS here.

– Jeroen

 

 

 

 

 

 

 

/

 

Siebel IP16 – DISA Extensibility Framework

Innovation Pack 2016, exciting times! Couple of posts have been shared by Darshan, Richard, Alex and myself on the new extensibility framework: DISA.

Desktop Integration Siebel Agent

Initially released with IP15.9/14.15 back in February, DISA served to replace like-for-like functionalities previously implemented using (insecure) Java Applets. One of the most visible: replacing the Java Applet based in-line attachment edit-and-save-back feature. Further: CTI Hoteling and Send Mail (F9) using Outlook instead of the Siebel email client will be added with IP16. Who knows what follows!

Truly exciting: with IP16 – Siebel will open-up and document the DISA API for customers. Meaning endless extensibility options. Advanced interactions between Siebel and the desktop (bi-directional) will be possible. Although DISA itself communicates in a secure way with Siebel, the developer has due to nearly unlimited access to the desktop its responsibilities.

Below a high-level architectural overview of the DISA framework.

DISAFramework

DISA uses a message-based approach to communicate between Siebel and the ‘client’ through a (secure) WebSocket connection. The DISA ‘client’ is a Java ‘plug-in’ which will have full access to the desktop. That means as simple as it sounds, Siebel could run a command-line operation, start an application, have access to the local filesystem, … Multiple plug-ins can be made available. These should be separately deployed. Not difficult to imagine a DISA plug-in to ‘deploy’ at run-time a custom plug-ins from a certain location. Either brand new ones, or updated ones.

So yes, if you don’t own them yet – you need to get access to or learn Java 🙂 As a starter, Oracle will be providing some examples through Github. Going forward the ConfiguringSiebel repository on the OracleSiebel Git will serve for this purpose. Oracle’s Siebel development will further supervise the Git and motivates the Siebel developer eco-system to share, add & commit! So jump along the bandwagon!

https://github.com/OracleSiebel/ConfiguringSiebel

– Jeroen

Siebel IP16 – Global Override Support (UAYOR)

globaloverrideshr2

You want to make enhancements to Siebel with a global reach? Depending on the type of implementation with Open UI you have several options:

1) You could use opt for a control plug-in wrapper, if the customization should affect functionality of controls. Examples could be enhancing the out-of-the-box functionality of check-boxes, text-area controls, turn a picklist control into a slider or adding placeholder text to the ‘search’ fields. The plug-in wrapper framework introduced in IP14 truly is an amazing gift as part of the Open UI extensibility portfolio.

2) Although with care and consideration, a postload solution could be appropriate. Postload as it implies is a piece of code which the OpenUI framework executes ‘post’ loading a view. Since Siebel is not a single-page application, postload executes on every view navigation (= HTTP Post). I used it to ‘fix’ a bug, create the pinnable views solution or to add a logout button.

3) Sure, you could opt to add your custom Presentation Model or Physical Renderer to all of your applets through standard Manifest Administration functionality. But well, that honestly is not what I mean by ‘global’.

4) The use of the SiebelHub’s Siebelhub.js ‘Overdrive‘ method. The Siebelhub.js arrived a few months ago on Github. Want to propose your enhancements, just make a first commit! Together it can be made even greater.

5) And well, option 5. That is the Manifest override of the ‘DEFAULT LIST APPLET’, ‘DEFAULT FORM APPLET’, ‘DEFAULT CHART APPLET’, ‘DEFAULT TREE APPLET’, ‘DEFAULT VIEW’ or ‘DEFAULT WEB PAGE’. And although I was happy to learn about this feature introduced a long with IP14, it has bitten me a couple of times. This option is not for the faint of heart. One tiny typo, and you might not even be able to login anymore. But that can be overcome, by ensuring an easy exit. Just employ an expression for the associated custom file, which disables the custom override for a particular user. Or just replace the defective file with an empty skeleton.

But most importantly, the Manifest override has a nasty side-effect. It overrides all (yes, all) seeded applet specific presentation models or physical renderers. If you like it or not. So in case a particular applet has a ‘seeded’ presentation model or physical renderer, your custom override will override that one to. Well – that is the status-quo for IP14/15.

For IP16 development choose to change the ‘evaluation’ order of global overrides. Such that it will not break the ‘seeded’ renderers. The image explains how it will work going forward. In effect a custom override will not override, once a specific seeded presentation model or physical renderer exists. So what global overrides would fit this model? Think of adding double-click behavior or adding the glyphified navigation buttons.

All said, development did earmark this option with the UAYOR label 🙂

– Jeroen