Technical Description · Technical Description: Dynamic fields Page 3 of 12 1 Executive Summary 1.1...

eC4u Expert Consulting AG * Karlsruher Str. 88 * D-76139 Karlsruhe Tel +49 (0) 721 46476-200 * Fax +49 (0) 721 46476-299 * www.eC4u.de

Aufsichtsratsvorsitzender: Steffen Deufel Aufsichtsrat: Elmar Buschlinger * Marc Schmidt-Thieme

Vorstand: Marc Koch * David D. Laux * Jens Rehwinkel * Steffen Scheurer (VS) Landesbank Baden - Württemberg * BLZ 600 501 01 * Ktnr. 402 017 2

Sitz der Gesellschaft: Karlsruhe * Amtsgericht Mannheim * HRB 109355 Ust.-Id.Nr.: DE 813 148 717 * Steuernummer: 35001 / 02478

ec4u expert consulting ag * Zur Gießerei 19 – 27 B * 76227 Karlsruhe

Tel +49 (0) 721 46 476 100 * Fax +49 (0) 721 46 476 100 * [email protected] * www.ec4u.de

Vorstand: Steffen Deufel, David D. Laux, Jens Rehwinkel

Aufsichtsratsvorsitzender: Elmar Buschlinger * Aufsichtsrat: Prof. Dr. Christoph Müller, Dr. Klaus Neb

Landesbank Baden-Württemberg * BLZ 600 501 01 * Konto 402 017 2

Sitz der Gesellschaft: Karlsruhe * Amtsgericht Mannheim * HRB 109355 * Ust.-Id.Nr.: DE 813 148 717

Technical Description

ec4u expert consulting ag

Zur Giesserei 19-27B

D-76227 Karlsruhe

Dynamic fields – hide and show objects during runtime

Version: 0.9

Authors:

Vyacheslav Soynikov

Markus Schneeweis

Kay Stecher

Technical Description: Dynamic fields of 12

Content

1 Executive Summary ...................................................................................................................... 3

1.1 Opportunity Hunting ................................................................................................................. 3

2 Technical Design ........................................................................................................................... 4

2.1 Business Issue ........................................................................................................................ 4 2.2 Requirement ............................................................................................................................ 4

2.2.1 New functionality: customer call planning ....................................................................... 4 2.3 Solution: Hide Controls via LOV („the switchable control“) ..................................................... 5

3 Implementation .............................................................................................................................. 6

3.1 Architecture.............................................................................................................................. 6 3.2 Description of the Architecture ................................................................................................ 6 3.3 Steps of implementation .......................................................................................................... 7

3.3.1 File postload.js, function ShowHideControls ................................................................... 7 3.3.2 File utilities.js, SiebelApp.S_App.LookupDescription ...................................................... 8 3.3.3 File utilities.js, SiebelApp.S_App.HideControl ................................................................. 8 3.3.4 File core_manifest.xml ..................................................................................................... 9 3.3.5 File custom_manifest.xml ................................................................................................ 9 3.3.6 List of Values ................................................................................................................. 10

3.4 Result: Screenshots .............................................................................................................. 11 3.4.1 Log on with entitled user X ............................................................................................ 11 3.4.2 Log on with non-entitled user Y ..................................................................................... 11

4 Advantages in a nutshell ............................................................................................................ 12


1 Executive Summary

1.1 Opportunity Hunting

Oracle introduced Siebel Open UI December 2012.

Open UI provides a single framework able to support

- desktop and mobile devices in

- connected and disconnected mode use

using common standards. Matching UI paradigms allow moving between devices, while the actual UI is rendered optimized for each specific device and provides deep device integration. The new client implements standards features such as HTML5 and JavaScript and is able to provide a native look and feel for devices capable to support advanced standards.

The latest versions of Internet Explorer such as Internet Explorer 9/10, Google Chrome, and Mozilla Firefox will fully be supported via standards. This platform will also support Android and IOS platforms such as iPad, iPhone, Android phones and tablets, RIM, Windows Phone as well as other standards compliant client and mobile platforms.

With these Improvements comes the ability to provide extended scripting capabilities through Java Script and Java Framework integration.

We can use these new capabilities to explore new areas. In our good old Siebel world it was always a complicated exercise to show and hide fields during runtime. The only chance to overcome this challenge was to use User Properties. The obvious issue with that approach is that this requires a new compilation and further on a complete deployment process. The functionality of User Properties is also restricted in terms of the flexibility and the ruleset.

The obvious option with Open UI is the extended Java Script framework that allows to manipulate the appearance of single fields with a broad variety of options. This functionality is way mightier than anything we had before.

This document describes a practical usage of this approach of one of our projects. This is not a theoretical description but a real-life scenario that was successfully solved with Siebel Open UI.


2 Technical Design

2.1 Business Issue

Imagine you could switch on or switch off a button on your CRM application without the necessity to compile any more. Imagine further you could switch on/off the button using simple configuration like LOV. This is in all sense of the word “dynamic”. As we supply you with such dynamic we call this: dynamic development.

In many projects the development processes are still ongoing even after the go Live. This may generate tangible overhead due to Bug Fixing activities and Production Support. This is mainly but not restricted to the fact that typically various clones of the Siebel Repository are required. Which leads not only to extra effort and costs but also to quality issues because of the synchronization between the different Siebel Repositories.

To keep things simple and – as a consequence - to reduce effort it would be very helpful to switch on/off objects real-time using List-of-Values (LOVs).

2.2 Requirement

We want to ensure that Bugfixing and Development do not interfere with each other. Parts of the application which are still under development should not have any effect on or even destabilize the production environment.

The main prerequisite comes here: We do not want to have clones of the applets/views. We believe this requirement cannot be accomplished without using the new features of Open UI.

Technically the assumption is that new Applet controls should only be visible to developers and key users/testers without duplicating any Siebel objects. Both, the list of entitled users as well as controls to be hidden should be able to switch on/off in real-time using LOVs.

2.2.1 New functionality: customer call planning

The new functionality is described as follows:

A click on a button within the “Teamkunden Entry Applet” opens a calendar popup in which the appointment for the customer call can be inserted. This leads to the following services being started:

Already existing customer call appointments of the account manager are retrieved from the Exchange server.

The Google API calculates the route to the customer of each single appointment

One or several existing appointments are then returned which would fit smoothly into the calculated route.

Those appointments are presented to the account manager who can check the route via the embedded Google Maps Applet and decide whether this would match his planning or whether he or she needs different appointments.

As a consequence, the account manager can visit several customers in one day with the benefit of having an optimized and therefore time-efficient journey.

We believe that also the Google API and route calculation could be a hot topic for many

customer but we believe that it’s important to keep the focus here on dynamic development.

Therefore we may cover details of these topics in another Technical Note.


2.3 Solution: Hide Controls via LOV („the switchable control“)

To fulfil the requirement above a key element is to hide/show the relevant controls without compiling a new SRF.

Independence is the key: customer call planning is autonomous from any existing functionality as it is implemented using new services. Assume the next Go Live is straight ahead and the implementation is not accomplished yet. Nevertheless, the button for the customer call planning is already in place on the existing applet. The aim is to switch on/off the button depending on the username via derived data dependencies – not implementation.

There would be no necessity to compile any more. We call this: dynamic development.

And how is this done? Do not stop reading…


3 Implementation

Let us give you a big picture first:

3.1 Architecture

3.2 Description of the Architecture

You can use the functionality to switch on/off controls on several applets. To avoid duplicated scripts there is only one script within the whole application available sitting in the file postload.js. Once loaded it will be available in the whole application.

Within the file postload.js the function HideShowControls verifies whether or not the current user is entitled to see the switchable control using the file utilities.js.

The utilities.js is a collection of useful functions and is loaded as part of the application in the custom_manifest.xml. All functions of the utilities.js will then be accessible from all Open UI scripts as child of the SiebApp.S_App object.

Using the Siebel Business Service ec4u Utility BS – a collection of useful scripts – the descriptions of the LOV type DYN_CON_SETTING are retrieved. The field description is used instead of the field value which does not support the necessary amount of characters for all the names of applets and controls.

The service returns the values of

ALLOWED_USERS

APPLETS

CONTROLS

from the field description.

There is now a 3-step validation:

1. The function HideShowControls in the file postload.js verifies if there is an applet from the list in the active view available.

2. In case there is one it will be verified if there is any control from the list used in this applet.

3. In case there is a control found in the list it is verified if the user logged in is found in the list of entitled users.

a. If the user is found in the list the control will be displayed.

b. If the user is not found in the list the control will be hidden.


3.3 Steps of implementation

3.3.1 File postload.js, function ShowHideControls

This is the content of the file postload.js.

Name of LOV (hidden)


3.3.2 File utilities.js, SiebelApp.S_App.LookupDescription

The file utilities.js is a collection of different methods one of which we use within the current

context. The one we use here is the SiebelApp.S_App.LookupDescription.

3.3.3 File utilities.js, SiebelApp.S_App.HideControl

The file utilities.js is a collection of different methods one of which we use within the current

context. The one we use here is the SiebelApp.S_App.HideControl.

The function GetInputName() delivers for the buttons an incorrect name (possible product defect?). Therefore, we decided to add the suffix _Ctrl.

The standard file postload.js remains unchanged. The file has been copied into the custom directory and has been modified in here instead. To ensure the clone of the file will be loaded we need to add it into the file core_manifest.xml.


3.3.4 File core_manifest.xml

This is the content of the file core_manifest.xml.

3.3.5 File custom_manifest.xml

The reference to utilities.js needs to be added within the file custom_manifest.xml in the tag PLATFORM_COMMON and the section Desktop:

<PLATFORM_COMMON>

<PLATFORM Name="Desktop">

<FILE_NAME> siebel/custom/theme.js </FILE_NAME>

<FILE_NAME> siebel/custom/Utilities/KKDUtilities.js </FILE_NAME>

</PLATFORM>


3.3.6 List of Values

There are several entries for the LOV type DYN_CON_SETTING needed in order to be able to dynamically switch on/off controls.

There are three different Language Independent Codes available for the LOV type DYN_CON_SETTING:

Type LIC Description

DYN_CON_SETTING APPLETS Containing a list of all applets which are holding switchable controls.

DYN_CON_SETTING CONTROLS Containing a list of all switchable controls.

DYN_CON_SETTING ALLOWED_USERS Containing a list of all users which are entitled to see the switchable controls.

The corresponding values have been entered into the field description. Please note: The field description is used instead of the field value which does not support the necessary amount of characters for all the names of applets and controls.

In this example, the control Kundenbesuchsplanung within the applets Account Entry Applet Teamkunden und Account Entry Applet will only be visible to user X. For all other users the control Kundenbesuchsplanung will not be visible.


3.4 Result: Screenshots

3.4.1 Log on with entitled user X

This user is listed in the list of entitled users.

The button Kundenbesuchsplanung is visible:

3.4.2 Log on with non-entitled user Y

This user is NOT listed as entitled user.

If you log on with user Y the button Kundenbesuchsplanung is not visible:


4 Advantages in a nutshell

Using the technique described above will result in having those advantages compared to an Active X solution:

No. Advantage Description

1 No clones There would be no need of any applet and/or control clones in order to show or hide controls.

2 Higher flexibility Real-time switch on/off of controls without any deployment.

Development will not affect production as buttons leading to areas still under development can easily be hidden during development and simply shown on the GUI by activating the corresponding LOV in production after end of development.

3 Less complexity No need to hide controls via user props, scripting etc.

4 Less effort Having many switchable controls can be achieved with minimun effort.

5 Less costs No SRF change necessary.

No separate deployment to switch on/off controls necessary.

We simplified the customer requirement to convey the idea of dynamic programming with Open UI without . In the end the rules can be changed easily as well as the number and the type of objects. The next step is to replace any customizing/scripting to switch Applets/Controls/whatever on or off or set fields to mandatory/optional.

The real frontiers of this approach is not yet visible to us and we are happy to discuss either the details of this approach or the cool ideas you may have to improve it.

Technical Description · Technical Description: Dynamic fields Page 3 of 12 1 Executive Summary 1.1...

Documents

Transcript of Technical Description · Technical Description: Dynamic fields Page 3 of 12 1 Executive Summary 1.1...