NextGen Consulting

IT Consulting CRM BSS OSS

Smart Client Look and Feel


Smart Client Look and Feel

The “look and feel” (LAF) describes the appearance of UI components. It handles presentation for Smart Client UIF custom controls & states.

It works in conjunction with currently active Swing’s look and feel and Swing’s controls (Only Windows XP LAF supported).

 

 

For full discussion see Smart Client Look and Feel .

 

02/09/2010 Posted by | Amdocs, CRM, CRM, Development, Smart Client, Technology | Leave a comment

Implemnting Lookup Control


About Lookup Control

The Lookup control assists users search for data with which they need to associate.

For example, when creating a new contact, we need to need to associate it with a site to which this contact belongs.
 

The lookup button launches a search form which allows the user to select the relevant record that update the necessary values in the launching form.

The lookup button is often used in create and edit forms, where the main focus object (in our above example – a new contact) needs to be related to another object (site in above example.

The Lookup control allows users to search and associate objects in the application. The control provides standard drop-down button functionality plus additional specific ones. 

For the full discussion, see Implementing Lookup Control.

31/08/2010 Posted by | Amdocs, CRM, CRM, Development, Smart Client, Technology | Leave a comment

Setting Search Grid Properties


 

Q:  I want to set the style for Search Grid control, but I don’t know how set it?
Could you tell me to set the style for Search Grid controls?
for example:  Set the width of columns, scroll…

 

 

Grid Properties

General Grid properties set the overall Grid control behavior.  For example:

  • autoResizeMode
    Sets the auto resize mode of a grid.
     
  • gridColumnSequence
    Sets the column sequence by the input column name order, the column sequence is an ordered collection of column names.  The order of this collection represents the order of columns in a grid like display. The column orientation, either from left to right or from right to left depends on the end users locale setting. The column order string is delimited by comma.
     
  • preferredRows
    Sets the preferred height of the control in logical units. In other words, define Setting the value to -1 restores the default behavior.Scrolling will be set according to the number of records provided in the Display Tabular Data Model (TDM) versus the grid height. If the number if the total height of rows to be displayed is larger than the Grids height – then scroll bars will be displayed (you can limit the number of retrieved records from the database by setting the application’s workspace variable gridDefaultNumRequested to your preferred capacity (the default is 20).

 
 

 Column Properties

Each Search Grid (or any simple grid) column is directly related with a UI control (I.e. label, textbox or a dropdown). The column’s control properties set the column rendering attributes such as column width etc. 

When setting Grid’s column controls properties, note that within the column main properties, you will find a property named ‘control’. This ‘control’ can be expanded to reveal a group of sub-properties. Both types of properties set the way the column will be displayed. However, note the difference behavior impact between ‘main’ properties and ‘control’ properties which have similar name. 
 

For example, assuming we need to display a three columns Grid. We need to add three Label controls under the Grid control (drag 3 label controls and drop them under the Grid control).

 
The following label column ‘main’ properties (marked in red) will set the following behavior:
 

  • Title 
    Column title
     
  • columnSpan
    Indicates by  how many columns this column is to be spanned.
    Value   1 or 0 means no span.
    Value of  -1 means span the whole row.
     
  • Visible
    Sets the visibility of the entire column space:
    When set to  false the whole column space is removed (our example grid will show only two columns).
     

 Control Properties

The following are ‘Control’ properties (marked in green):

  •  horizontalAlignment
    Sets the horizontal alignment of the (optional) icon and text.
     
  • horizontalTextPosition
    Sets the horizontal position of the text relative to the icon.
     
  • preferredColumns
    Sets the column width.  Setting the value to -1 restores the default behavior (defined by grid’s property).
     
  • Visible
    Sets the visibility of the column contents. Does not remove column space.
    When set to false the column space remains in Grid (our example grid will show three columns), but column content will be empty.
     

For complete list of properties, follow the Smart Client designer properties tooltips, or read programmer’s documentation.

 

 

Look and Feel

Smart Client Framework also provides a Look and Feel control using Style sheet. This sets the UI controls appearance on the screen. The style sheet defines styles, each style group set of display attributes. In order to apply a style to specific Grid, the Grid’s style property needs to be set to the style name.

The following L&F style attributes can be applied on a Grid:

  • Border
    The border for a search grid is applied around the table, including the column titles. It does not surround the search grid header (the area containing the Search Now button etc.). In order to set a border around the entire search grid, place the search grid in a panel and apply the desired border to that panel.
     
  • alternateRow
    A 24-bit number; 3 X 8 bits RGB components  I.e.: Red -> 0xff0000
    Used to paint row’s background alternately between table’s background color and the specified alternate backgroundColor.
     
  • rowHeight
    Row height in pixels. I.e.: 18
     
  • gridColor
    Color             a 24-bit number; 3 X 8 bits RGB components  I.e.: Red -> 0xff0000
     
  • showGrid
    Boolean         true or false
     
  • showHorizontalLines
    Boolean         true or false
     
  • showVerticalLines
    Boolean         true or false
     
  • backgroundSelectionColor 
    Color    3 X 8 bits RGB components      I.e.:  Red -> 0xff0000
     
  • textSelectionColor
    Color             a 24-bit number; 3 X 8 bits RGB components  I.e.: Red -> 0xff0000
     
  • backgroundHighlightColor
    Color             a 24-bit number; 3 X 8 bits RGB components I.e.:  Red -> 0xff0000
     
  • textHighlightColor
    Color             a 24-bit number; 3 X 8 bits RGB components I.e.:  Red -> 0xff0000
     
  • focusBorderColor
    Color             a 24-bit number 3 X 8 bits RGB components  I.e.:  Red -> 0xff0000

 

For more information see the full discussion on Look and Feel.

 

26/08/2010 Posted by | Amdocs, CRM, Smart Client, Technology | 4 Comments

Smart Client Deployment Architecture


25/08/2010 Posted by | Amdocs, CRM, Smart Client, Technology | 2 Comments

Smart Client Run-Time Architecture


The Smart Client architecture is built on an infrastructure that provides the following:

  • Have an application workspace
     
  • Launch application forms
     
  • Communicate with the server
      
  • Manage data binding between datasets and the form’s controls at both directions.

The client side infrastructure is described by the following set of components.

Smart Client Architeture

 

Request/Response Manager

The request/response manager works with different communication protocols (i.e http) to submit the request from the client and to handle responses back from the server.

 

Application

The application object is a script level object that can perform global application tasks like posting modal alerts or expose certain functionality of the workspace.

Workspace

The workspace provides common user interface services to Forms and client side components.

Workspace and application assembly

The Workspace provides the following services:

Startup & Exit

  • Serves as main entry point to application
  • Handles deployment
  • Handles exit, update desktop, user preferences

Desktop Services

  • Loads Application Configuration metadata
  • Manages multiple Applications simultaneously
  • Manages main window, menus, toolbars, tool boxes, status bar and form window
  • Provides Look and Feel / customizable styling for UI controls

Client Services

  • Provides support for login, help, printing
  • Manages background tasks
  • Provides Logging, Exception handling, Operational Measurements
  • Manages forms by providing services to open, close, version, etc.
  • Globalization support

Workspace configuration is XML (workspace.xml). It configures numerous applications and run time parameters, such as list of available application desktops, logging, help, server configuration etc.

WorkSpace and Form Components

Form

A form is a UI object that represents a business level Form and encapsulates the native implementation of the swing form (JInternalFrame in Swing for example). A form usually contains controls and sub forms.

A form manages controls, data models, actions, sub-forms and other components that define the form. The form supports design tools by delegating content creation to a “builder” class which is generated by design tools. It provides published API for application scripting.

Sub Forms are reusable forms that can be placed within parent form

Child Forms relates multiple forms within a single flow

Form Messaging system, allows for application script to communicate with other forms

Dirty Bit Tracking tracks form-modified state

Forms can be launched in work area, in the toolbar pane (toolbar), in the toolbox pane (toolbox). A form can be launched in the main work area. A form can be launched as a modal or none modal. It is by default visible, but can be made hidden by form logic (java application). Global forms are always hidden.

Form Components

Derived Forms

 A derived form is a visually inherited version of a base form. It is a subclass of the base form class. Forms can be derived for providing enhaned user experience either by targeting form variations at different groups of users, or merely improving the form layout and functionality for improved usability.

Form Visual Inheritance

Form Version Selector

The Form Version Selector provides the ability to identify the correct form version at runtime, given a form logical name. A form logical name needs to be resolved to a form class based on an expression that evaluates any run time data such as user or environment properties (practically any data such as user role, locale, context etc).

Specific version of a form can be selected dynamically using the following steps:

  1. Launch action defines a target logical form name to be launched
  2. Logical form name is mapped to physical form name
  3. Physical form name is then launched
  • Selection criteria are specified in rule-based metadata (expressions), evaluated in order until one evaluates to true
  • Rules are stored in XML files as expressions , and are edited by a design-time tool
  • Rules may refer to any contextual data via Path

Version selector

 
 

Controls

Controls are UI objects that are implemented as platform neutral objects. These are Java Swing controls wrapped by additional control functionality, that provides additional features (i.e. two way binding) and insulate application code from native technology. Controls may carry metadata such as:

  • Control Properties – e.g., isEnabled
  • Binding metadata – how control binds to form’s data
  • Validation metadata – specifies constraints
  • Action metadata – defines what to do when control is “clicked”

The controls contain a rich set of UI controls which provide generic support for CRM features such as hierarchical choice lists and role based authorization (RBA). 3rd-party controls may also be used, with limitations.

Supported controls are:

Textual Controls:       PercentBar, Label, TextArea TextField, ObscuredText, TextArea, Currency, Hyperlink

Button Controls:       Button, RadioButton, CheckBox, Menu/ MenuItem

Time Controls:           DateTime, ElapsedTime

List Controls:            ComboBox, ListBox

Grid Controls:           Grid, Search Grid, Grid Footer, Tree, GridTree,

Containers:               CardPane, Panel, TabbedPane, TabPage

Other Controls:         Browser

Search Controls:       LookupButton

3rd-party controls:  Any 3rd party wrapped with Smart Client functionality.

 Controls provide published API for application scripting.

Data Manager

Data manager enables the application framework to work with the datasets associated with an application form. The data manager follow JDNC (Java Desktop Network Components) model, with the following enhancements:

  • A Data Set consists of Data Model objects
     
  • Each data model object contains a set of fields
     
  • A control property can be “binded” to a data model field
      
  • Data retrieved from server-side service request is mapped into dataset
      
  • Data is transferred between controls and dataset, in both directions, automatically
        
  • Data is mapped from dataset and sent to server-side service for form save or other operation
       

Smart Client Data Models

Dataset Features

  • The dataset support Single and Tabular data models
      
  • Data model objects store native binary data and implement a generic get/set interface, not VO-based (classes stay on server)
      
  • Dataset provides published API for form application scripting (code should manipulate data values in model, not in UI controls)
      
  • Support for hierarchical data models
      
  • Virtual data model – reference to model on other form
       
  • Support for data models published from controls
     

Binding Framework

The Binding Framework is the glue module that links the datasets to the controls in a form. It can be easily integrated with any component to provide binding support.

Data binding performs locale-sensitive binary-text conversions as needed between controls and model

Application events are defined for any change in data model value.

The binding framework provides the following capabilities:

  • Value maps, e.g. convert values of 0 / 1 to Inactive / Active
      
  • Property binding. Property binding allows binding a data field to a UI control property other than its value. For example, a data field value can set control property such as visibility, availability (enable/disable) etc.
       
  • Custom handlers for ‘format’ and ‘parse’ during binding
     
  • Trigger fields to trigger binding based on changes in multiple fields
       
  • Custom format string to format the data if the property type is a String
      
  • Published API for manipulation of binding properties by application code (part of Control API)
      

Data Communication Elements

This objects are metadata-driven inter form communication entities applicable between two forms. They provide data transfer (copy by value) and data sharing (copy by reference).

  • The data transfer triggered by a specified event and contains mapping capabilities
      
  • Data sharing is performed via declaration of “virtual data model” in the receiving form. It  automatically hooked up to data model in the publishing form

 

Data Communication Elements

  

Event Manager

The Event manager enables the application layer to establish client side hooks in a technology neutral way and give the ability to execute event hooks in a super class.

Smart Client Events

Validation Framework

Validation framework is used to ensure that the user input is valid before it is sent to the server.

 

Caching and Global Data Manager

The cache framework provides ways to cache metadata on the client side that can be used across sessions.  Global data manager provides a mechanism to store data sets that can be accessed globally across all forms.

 

Action Manager

Action Manager dispatches actions to event handlers and executes metadata-driven behaviors.  Submit actions package the Request payload and process the Response Payload. The actions are built on Swing Action model.

An action is a form element with no run-time UI, which performs a metadata-driven action. There are different Action types for performing different type of activities; each has its own metadata format. Any “executable” control, e.g. a button (‘action controls’) can target an Action. If an Action is disabled or hidden, any ‘Action Control’ targeting that Action is automatically disabled or hidden.

Since Actions defined in a form and are considered as a form component, they have by default a local form scope (in other words, they can be directly used only by the form’s code). However, an Action may be marked “published”. A ‘published’ action name can be referenced from any other form.

Menu and toolbar controls can automatically connect to published actions in the currently active form.  When an action is disabled, it automatically disables connected menu items/toolbar controls.

Action Types

  • Submit Action

Submits request to the server and updates the form with response data; the data is mapped between form’s data models and server side operation (XBean) inputs/outputs (setters/getters); updated data may be auto-broadcast to other forms.

  • Launch Action

Launches new form in ASCF Client workspace; data is mapped between launching form’s data models (current form) and the launched (new) form input data models.

  • Bulk Action

Bulks multiple Submit actions in one server round trip, in one or more transactions, or as individual requests with no transaction, across form and its sub-forms, to possibly multiple back ends.

Bulk Action
  • Sequence Action

Executes multiple actions in a sequence, where the next action in the sequence begins after the current action is fully complete.

Sequence Action
  • Subscribing Action

A subscribing action subscribes to a target action, whose state propagates back to the subscribing action. The subscribing action executes its target when it is executed.

  • Service Driven UI Action (SDUI)

The Service Driven UI Action launches forms determined by a backend UI-driving service. It uses Submit action to execute UI-driving service. The UI-driving service determines next logical form. The launch action is used to populate the next logical form name. The launch action properties may be specified by service. The Service Driven UI Action copies input data models to the launched form’s dataset. It supports data context with contained input data models. It can accept multiple explicitly defined Launch actions (one per possible next logical form) along with a default one and it dynamically creates Launch action if needed.

  • Process Driven UI Action (PDUI)

The process driven UI action launches forms determined by UI-driving service in process-driven UI flow. Any arbitrary process state object can be used. The PDUI updates parent/containing forms with process state. It enables adding of reusable forms to UI flow without design time modifications:

  • Allows any UI control or action in reusable form to trigger flow continuation (overloading).
  • Supports parallel or sequential execution of overloaded control and dynamically created Process-Driven UI action.
  • May return any data model to UI-driving service when flow is continued after the UI step.

Both SDUI and PDUI can launch the next form according to predefined fields contained in an object named ‘UiDescriptor’ returned by the server.

  • Both can use any business logic as UI-driving service.
  • Both do not restrict the use UI-driving service public API.
  • Both action types allow the process state object to have any structure.
  • For both action types, explicitly defined Launch action properties take precedence over Launch properties returned by service.
  • Client Process Driven UI –  Script Player
    This action is used to drive a client side script player.  The process that maintains the state and drives the next form to be posted is a client side light weight process. The client who runs this light weight process is Amdocs Process Manager (APM) client.

Client Application Connector

Client Application Connector (CAC) provides services to invoke, terminate and exchange data between other clients on the desktop that include windows based client like outlook, excel etc., a Java based client or a browser based client.

26/07/2010 Posted by | Amdocs, CRM, CRM, Smart Client, Technology | , , | 3 Comments

Amdocs Smart Client Vs Classic (thick) Client


Classic Client

Classic client was created by Clarify as a Microsoft application using MFC (Microsoft Foundation Classes). Classic client behavior (customization) uses a licensed Visual basic 5 library named BasicScript, developed by Summit software. This library was further enhanced by Clarify Corporation to support the original CRM metadata layer named POMS (persistent object management system).  The enhanced VB5 customization library is known as ‘ClearBasic’.

Classic client interacts with its database either directly (2 tier mode) or using the Tuxedo transaction monitor as an intermediate layer which optimize SQL queries and transactions between the client and the database (3 tier mode).

Clear Basic customizations use the form as a base unit, which encapsulates internal data models called contextual objects.

The contextual objects data models mostly follow POMS metadata (database table structure) and are used to bind UI controls with the database objects.  For runtime in-memory data manipulation the ClearBasic extensions provides objects to model database structures either as single record (‘Record’) or list of records (‘List’).

ClearBasic customizations use an interactive development environment (IDE) called UI Editor.  All Classic client form customized components (Clear Basic source, the compiled code,  contextual objects data models and UI visual definitions) are stored in the database.

A form usually represents a visual entity. However, global forms contain global application code which is loaded into memory during classic client initialization. Global form has no visual presentation. Global code has an application scope and can be called from any other form. Global forms can either reside on the client, or on the Tuxedo application server.

Forms can pass information between them by using a message API.  A message can pass list of strings.
Forms can refer to other form by using an identifier. ClearBasic API allows creating parent-child hierarchy between forms, thus providing a facility for a parent form to enforce closing all its children when it is closed.

A form can be stored in several versions. Each form version is related with a predefined group of users called ‘Resource Config’.  This arrangement allows keeping several versions of same form, either under same Resource Config where only the latest version used by the application, or relate each version with a separate Resource Config, hence the application screen relevant form to its Resource Config  related users.  The classic customization environment also supports the following aspects:

  • Sub forms  – forms which share binding data models
     
  • Automatic updates  – form UI and code is cached on the client.  A new customization (both UI and code) can be pulled by the client
      
  • Upgradability – customer customizations are maintained when upgrading to new release.
     

 

Smart Client

Smart Client is pure java application. It uses Java to support powerful client functionality, including Java SWING for its UI presentation layer. The use of Java and its rich graphical SWING functionality provides a very powerful rich client environment.

Smart Client does not access the database directly. Rather, it uses a backend application which is run by an application server (Weblogic or Websphere) to access the database.  This backend application structure also known as J2EE.

The J2EE application environment use newer advanced database access layer called CBO (Clarify Business Objects). The application run on the server called server side code. The server side code is organized in classes named Java Beans. These java beans, also known as XBeans, use CBO to access the database. They use a newer version of the persistence layer called JPOMS (the Java successor of the original POMS).

Smart Client connects to the application server using HTTP protocol, in a very similar way as Web clients connect to their applications server.

Smart Client use Java Network Launch Protocol (JNLP) – a Java mechanism to support zero deployment, either in a push (application server initiated) or pull mode (client initiated).

Smart Client customizations use a framework called ASCF allowing the developer to use a simplified, high level subset of the SWING classes in similar manner as its predecessor ClearBasic does for Classic client.  Development preformed using ASCF Designer, an Eclipse based IDE ( integrated development environment). The ASCF Designer IDE is  implemented as a plug-in extension on top of the open source Eclipse platform.

The development environment, use Java as its programming language, provides a simplified and very powerful SWING customization environment yet resembles in its simplicity many aspects of the legacy ClearBasic environment.

Not surprisingly, the main customization object is form.

A form is a UI (user interface) component used to view and process user data based on business needs. The main constituents of a form are User Interface controls, user data and logic used for interaction of the above components.

The form and its customization entities (UI controls, Data Models, Actions, Events, Data Communication Elements etc) behavior is set at design time using meta data defined as entities properties (I.e. form properties, UI controls properties, Data Model properties, Actions properties, Events properties, DCE properties). This behavior can be later manipulated at run time by the application code.

A form can be derived into many versions as needed.  Each form version inherits the presentation UI as well as its related code and other entities (data models, actions, data communication elements etc).  Additional customization is only needed for any changes from the original look and or behavior.  There can be as many derived (inherited) forms as needed. Smart Client use an object called ‘Version Selector’ to define the criteria to select which version will be used at run time. These criteria use expressions which are evaluated to a logical boolean value (true or false). An expression can practically be simple as any value retrieved from the database or complex evaluation based on run-time and database values.  Expressions are elaborated in a separate post.

Global forms are used as common code containers. They have the same purpose as the Clear Basic global forms.  Although invisible, global forms are standard forms and support all none visual form related customization entities such as data models, actions, events and  data communication elements.

Form can pass information using the Message object. The message object can move Java objects to one or more forms (broadcast).  The object passed with a message can practically be of any type of any complexity.

The form has related entities which are used at runtime: the data set is a collection of data models which are used to bind data to UI controls. This UI – data binding  can be regarded  from user perspective in a similar way to the Classic contextual objects.

Data Models can represent a single record (called Data Model), or set of records (called Tabular Data Model). A data model can use JPOMS driven database metadata (i.e. columns of a database table automatically reflected as Data Model fields) or can be manually arbitrarily defined (similar to the ClearBasic user defined record).

Dada Model Hierarchy: Data Models can be structured in Hierarchical manner. Any Data Model field can refer to any type of Data model or Tabular data model.

Data Model is usually recognized within the form in which it is defined. However, data model can be defined as a Virtual Data Model. A Virtual Data Model can be referenced from any other form. This provides an easy way to share data among forms.

Actions are another important set of entities related with the form.  Actions are used to initiate variety of activities of different types in response to events which may originate either by the user or by application code. The Smart Client framework simplifies the original complex definition of SWING actions. It provides set of selected action types. The most common action types are:

  • Submit Action’ – invoke a server-side code (XBean) to either retrieve or store data
      
  • Launch Action’ – launch another form
       
  • Lookup action’ – invoke database search
       

Other types provide greater flexibility such as:

  • Bulk Action’ – combining several Submit actions into one database transaction
     
  • Sequence Action’ –  allows connecting several actions into a sequential chain
       
  • Service Driven Action’ – launches form as determined by a backend UI-driving server operation. The name of the next form to launch is provided by the operation. For example, Post Case Overview form based on Case type, where Case type to logical form name (LFN) mapping is stored in the data base.
      

Data Communication Elements provide advanced communication mechanism between forms.

Events are usually defined as SWING listener mechanism.  Smart Client framework greatly simplifies the complex SWING listener plumbing. Instead, it provides a selected sub-set of events as properties of forms and their various related entities such as data models actions and data communication elements (DCEs).

Each of these form related entities exposes set of relevant events. For example, the form entity defines the following events:  preOpen, preload, load, postOpen, openFailed, postActivate, preClose, preUnload and postClosed.  Common events used by all actions are actionStart, actionFailed and actionDone.

    

    

Smart Client Vs Classic Client

IT organizations which still use legacy, heavily customized, Classic client implementations, quite often are required to decide about a possible move to Smart Client; they need to assess the potential benefit compared to involved costs in terms of expected efforts and possible risks.

The expected benefits are clear. Can they be quantified?  Let us quickly look at some of these benefits.

  • Product support:  Both Classic client and its underlying database will soon not be supported by their respective vendors.  Moving to latest technologies completely eliminates the risk of using unsupported products.
       
  • Integration   Latest technology natively supports common industry standards (J2EE) as well as vendor’s own Integration Framework (AIF).  These standards offer an up-to-date infrastructure for seamless integration with other products, especially with vendor’s (Amdocs) suit of products such process manager (APM), Ordering, Enterprise Product Catalogue (EPC) and Billing. These facilities greatly reduce integration costs both from development and maintenance perspectives.
         
  • Functionality  Smart Client JNLP / J2EE technology provides robust, scalable application environment.  The enhanced functionality allows for much more efficient development and easier maintenance, thus, significantly increase productivity, accelerate development time and availability (shorten time to market) of supported new business processes.

    

Classic to Smart Migration

   

     

Moving from Classic To Smart Client 

Q:  What additional load does moving from Classic client-> Smart Client put on user/Workstation? If the desktops are old would the performace further degarde if we move to Smart Client?

A:  Moving from Classic client to Smart client should certainly improve performance.

Old Classic Client is a Client-Server MFC (Microsoft Foundation Classes) based application which is connected to a single database.

Smart Client provides the following technical capabilities:

  • 0.5 sec Performance (client)
        
  •  Robust customization environment
       
  •  Upgradeability
      

As well as the following advantages NOT available in Classic client:

  •  Zero Desktop Administration
       
  • Rich Control Set
        
  • Architectural Alignment
        
  • Multi-tiered Customization
       
  • Desktop Integration capability
       
  • Centralized Business Logic
       
  • Access to full CRM application set
       
  • Single UI for applications portfolio

Smart client use latest Java – J2EE and Web Start technologies which only use the code required by the client application. It can be seamlessly connected to several backend databases (I.e. CRM, Ordering) thus providing a unified desktop for the CSR.

The unified desktop eliminates the “Alt Tab” navigation by contextually launching other desktop applications inside the application (i.e. customer interaction) area, thus providing single point of history for all interactions, across all applications, context-driven navigation).

In terms of user experience, Smart Client provides much richer capabilities compared to its Classic client predecessor. – It reduces desktop complexity by hiding legacy screens and incorporating data into a single desktop screen. – Data is accessed from other applications in the background, transparent to the user.   Background tasking capability streamlines tasks flows and eliminate “cut & paste” by automating across nested applications.

Moreover, customization and application maintenance are much more powerfully compared with old ClearBasic technology.  Smart Client provides improved architecture and development tools, faster time to market for new functionality, common UI (look and feel) and tools improves integration capability and support for multi-tiered customizations.

Read more on Migrating Amdocs CRM Classic to Smart Client (Part 1)

08/07/2010 Posted by | Amdocs, CRM, CRM, Technology | 39 Comments

Smart Client Derived Forms – Best Practices


About Derived Form

A derived form can visually inherit from a base form, or define the layout itself. Externalized resources are inherited from the base form. The application code file is a subclass of the base application code file. The form metadata (.uiff file) describes the changes to the base form it derived from.

Use Derived Form for

Any customization that extends or overrides existing layout, any customization that extends or overrides existing functionality, or any customization that need to implement several forms that share common layout or functionality, yet differ in certain aspects.

Derived Form XML – .uiff

Boolean attributes for elements used in processing derived forms:

uifinherited 
Applies to all UI elements.
It is set when an element is inherited from a base element.

uifremoved
Applies to removable collection elements such as
– Data Model Rows in a Tabular Data Model
– Property Bindings
– Trigger Fields
– Request/Response Map Items
– Data Comm Items
– Bulk and Sequence Actions
It is set when a collection element is removed from a base collection.

Uiforder
Applies to ordered collection elements such as Grid Columns, Tree Node Templates, Tab Pages, Menus, Bulk and Sequence Actions.
It is set if an ordered collection is re-ordered in the derived form.

Breaking the Layout

Breaking the layout may result of any of the following activities:

  • Add or remove a row or column from a base panel’s layout
  • Move a base control
  • Change spanning of a base control
  • Drop a new control into an empty cell in a base panel’s layout

The user is notified when an action force the layout to be broken

Removing Base Control

Attempting to delete a control defined in a Base form panel or tab page moves it automatically to the unused controls parking lot.
The following collection elements defined in a Base form cannot be removed from their parent collection in a derived form:

  • TabPage
  • Card (panel) in a Card Pane
  • Grid Column
  • VoFieldDef for a manual data model
  • Field Value pair for initializing a singular data model
  • Data Model / Tabular data model
  • Action Element
  • Data Comm Element
  • Single Select Group
  • Tree Node Template

When Deleting a Base Form Control

If a derived form made the same deletion the deleted element  is flagged as “uifremoved”, an informational message is posted in the problems view and upon save, the derived form no longer reference the deleted element.

If a derived form made updates to the same element, a warning is placed in the problems tab.

Keeping Visual Inheritance

To keep visual inheritance of an existing base form, add a panel container to a base card pane, add all new controls there. Add a tab panel to a base tabbed pane, add all new controls there.

Plan for Visual Inheritance

When creating new form, add one or more panels or card panes and associated panels to cover all root panel areas. Layout your new form with an area for the base form specifically using a card panel or tabbed pane for customization or derived forms to add functionality.

13/06/2010 Posted by | Amdocs, CRM, CRM, Technology, Uncategorized | 3 Comments

Upgrading AmdocsCRM Smart Client form (Part Two)


Preface

The original out of the box AmdocsCRM application quite often contains forms which deliver none-optimized user experience; these forms display too much information and lack context sensitive functionality. For certain business scenarios part of the displayed information is either irrelevant or overloaded.

These forms do not take full advantage of the rich client capability provided by the Smart Client underlying Java SWING technology.

In this two part posts I try to demonstrate how the SWING technology can vastly enhance user experience and improve usability by merely rearranging form layout and adding simple logic to it.

In part one I have demonstrated the first steps in upgrading an original, out of the box, Smart Client create case form.

I created an inherited version of the original form, created a form version selector to redirect the application to the newly created inherited form, verified the inherited form, then started to rebuild the new version by first moving all original controls to a parking lot (the ‘Unused Controls’ area), and rearranged the form layout.

Note that all the logic provided with the original form (dataset, code) is still active in the new form, but since all original controls are invisible (moved to the unused controls), I can invoke the new form but can not interact with it yet due to the hidden controls.

A new grid was defined for the root panel: One column and two rows. The single column has a predefined width size (initial form width size of 800 pixels) and will stretch itself (‘growable’) to allow it expand to the full screen width.

Assuming the minimal form height is 600 pixels, the first row was defined to an initial constant height of 555 pixels and growable to provide space for the main form area, while the lower row was defined as a fixed (none growable) 33 pixels height to provide exact space to contain the form’s buttons.

Each of the two rows was populated with a card panel UI control on which second level panels may be added. This gives the flexibility to add several fully overlapped panels under the card panel. Each of these panels can later expose different sets of controls according to the business process context. This paradigm allows for enhanced user experience by exposing only context relevant information at a time. This time we placed only a single panel under each card: crdMain / pnlMain for the main area and crdButtons / pnlButtonsMain for the lower row.

For the lower row buttons area, the new layout is simple: I redefined the panel’s (pnlButtonsMain) grid to contain a single row having a constant height of 22 pixels, and a horizontal strip of ten none-growable columns, each was set to have an initial constant width of 60 pixels (some width size were extended laters).  One column (marked with red arrow) was set to growable, to allow the buttons strip to expand to full width of any form / screen size.

 

Next we need to place all relevant controls in their new locations. All relevant original buttons (those previously moved to ‘Unused Controls’) were moved back from the ‘unused controls’ area to their new locations on on pnlButtonsMain:

 

The upper, main area (pnlMain) was subdivided using the following 5 X 5 grid:

The numbers in red denote the column / row fixed size and an optional (G) whether they are growable.

Note the spacer rows (5 fixed pixels width / height) that initially leave nine real estate rectangle areas (areas A – I), each populated with its own card panel and one or more flipping panels attached to it (eventually, these nine areas are reduced to five dispayable areas).

The three main columns are growable and have similar stretching relative weight. The similar stretch weight guarantees they will evenly stretch within the size of their containing form.

Display Topics

Each area within these columns will be used to display one topic (group of related controls) per panel.

A card panel can display a single panel at a time or flip panels according to some business logic. Each panel practically displays a group of related controls (called topics).

The division to distinct areas provides a convenient, readable view, allowing the human eye to easily capture and grasp each topic’s content.

Reducing the Number of Display Areas

In order to reduce the number of topics, some adjacent areas were defined to share a single card panel (a card panel can occupy one or more neighboring areas). Thus areas A and B share the card panel crdMainA, areas D and E share crdMainB and areas G, H & I share crdMainC.

Placing the Controls

All card panels, except for cardMainC, currently relate with only one panel which is dispaled by default (in other words, they do not flip panels).

Let’s have a further look at cardMainB / pnlMainB1

 

The panel pnlMainB1 layout use a 1 X 3 grid; a single fixed 125 pixels height row, and two subareas, having 220 and 240 pixels width, separated by a 5 pixels devider. Each display area use its own panel: PnlMainB1Inner (Case Type) and pnlCaseIndicators (Case Indicators).

Each of these panels has its own grid layout i.e.: Case Type. Once the grid layout was defined, I was then able to move back the original UI elements from the unused controls to their new location.

As mentioned, the original logic still works with these controls; there is no need to write any new code for them.

Now let’s view the lower card panel crdMainC:

Under this card panel we find pnlMainC1 and pnlMainC2. Unlike the previous example, where the two subpanels were placed on a parent panel grid, each at its own space (therefore displayed together), here we find two panels directly located under a card panel. This layout allows only one of them to be displayed at a time (since both occupy whole parent card panel space).

Each of these panels further carries its own layout hierarchy to support exact layout.

We need now to add logic that will allow the application to respond to user selection and expose the panels, each at a time. In order to provide this interactive functionality, a hyperlink control was added at the upper right corner of each panel.

On pnlMainC1, a hyperlink labeled ‘Details’, on pnlMainC2, a hyperlink labeled ‘Notes’.

Clicking on the Details hyperlink should trigger the application to display pnlMainC2 and Clicking on the Notes hyperlink should trigger the application to display pnlMainC1.

First we had to associate an action – an action object that is invoked when a hyperlink is clicked – to each of these hyperlinks. We associated both hyperlinks with the selectTabPanels action

Here is the selectTabPanels action definition:

And here is the code associated with the action’s start event. This code is invoked when actions associated controls (the Details and Notes hyperlinks) are clicked:

Note that the actual control (hyperlink) that was clicked and triggered the event is identified out of the event data. The name of the panel to be displayed is retrieved from the user data associated with the clicked hyperlink. The User Data programmatically added to the control when the form is initialized:

The actual panel replacement performed by the updateControls() method:

There are numerous additional features that were added to the upgraded page but not described in this post due to space limits.

To watch the new form in action, click the following link Create Case. 

31/05/2010 Posted by | Amdocs, BSS, CRM, CRM, Smart Client, Technology | 7 Comments

Upgrading AmdocsCRM Smart Client Form (Part One)


Upgrading AmdocsCRM Smart Client form (Part One)        

One of the common business requirement is to upgrade an out of the box form and either add more functionality or merely change its appearance to enhance the end user experience when interacting with this form.  In the following example I shall illustrate how easy it is to make such enhancement.    

I will show how a simple OOB (out of the box) form can be enhanced using form inheritance capability of the AmdocsCRM Smart Client.        

I shall also demonstrate how user experience can be greatly enhanced by combining several separated forms into a single form by exploiting Java SWING panel elements.        

Let’s look at an OOB Create Case form:    

          

The above form was re-designed to provide better UI usability:        

Re-designed Create Case:    

              

 Note that the entire UI arrangement was changed:      

  •  Many unnecessary items were removed from initial screen (form) layout.
    The screen is less crowded, more logically arranged for easier readability
  • Caller details were moved to the lower part of the form, since usually this information is automatically populated from the CIM (Customer Interaction Manager)
  • Removed items remained accessible only when needed
  • ‘Case type’, ‘Case Indicators’, ‘parent-child’ and ‘contract’  were re-arranged vertically for easier human eye capture.
  • All buttons were moved to the lower part of the screen
  • The lower part of the form is used in three different ways:

–     The default form (displayed above)
–     Clicking the +/- (shown in red circle) expands the notes field to capture the full lower part space:
           

  
–     Clicking the ‘Details’ link replaces completely the lower part of the screen to reveal other items which previously occupied expensive portions on the main form;
                 

    

–     Clicking the ‘Notes’ hyperlink takes the user back to display the ‘Notes’ again, either in their short or expanded form.        

      

Customizing a New Layout
The new layout was achieved without changing the original (out of the box) logic, but merely adding minimal code to support the enhanced appearance.         

The necessary steps to re-arrange an OOB form are:         

  1. Create a new Smart Client project in your Eclipse Smart Client Designer IDE.
    Make sure to include AmdocsCRMSource.jar in the project’s class path.
  2. Using the Eclipse package explorer, identify the original (out of the box) form’s package name (com.amdocs.crm.isupport.kcase) and full Logical Form Name (LFN) com.amdocs.crm.isupport.kcase.casecreate in the jar file AmdocsCRMSource.jar.

         

3.        Open the selected form’s layout (right click the OOB form’s name ‘CaseCreate.uiff’ and select ‘Open’)           

4.       Click the ‘Derive Form’ button
             
           to open the form inheritance dialog:        

         

Note that the base form full logical name (package + form name) is already
selected and can not be changed (marked in red ellipse): com.amdocs.crm.isupport.kcase.CaseCreate
        

5.       Fill the necessary parameters in the New Derived Form dialog:        

Source Folder:       Browse to the source folder in your project.          

Package:                    This should be your customized package name.
                                         It is a good convention to keep the original package name structure,
                                          however, replace the company name part with your company name.
                                         Thus, our package name will be com.nextgen.crm.isupport.kcase         

Form Name:           It is a good practice to use same name as the original, adding an ‘X1’
                                          prefix to emphasize the customization level:
X1CaseCreate
                                           (next inheritance layer for this form will use X2CaseCreate etc).
Design Notes:       Add a short description for your customization.           

6.      Click ‘Finish’.          

7.      Look at your source folder in your project at the package explorer:          

          

8.    A new package was added, plus four files that represent your newly inherited form:       

  1. X1CaseCreate.java – new java class file, which extends the original OOB form
     logic. You may leave this form as is (no additional code), override methods or members in the original class, or add your new logic here.
  2. X1CaseCreate_en_US.properties and X1CaseCreate_en.properties
    resource bundle files that stores all your localized strings.
  3. X1CaseCreate.uiff – an xml file that extends the original CaseCreate.uiff xml file.
    the .uiff is an XML file which defines the UI layout and form related dataset.

           

9.      In order to direct the application to use our inherited form at run-time, we need to define a version selector object.  A version selector is an xml file that must have similar Logical File Name (original package and form name) of the form we are about to override. The version selector file allow defining an expression that evaluates in memory application values at run time (usually they represent cached database field value i.e. login_name = ‘yuvalr’) and a target Logical File Name that represent the form to use if the expression evaluated to ‘true’.
A version selector may contain several entries of expressions – LFNs (they are evaluated until one evaluates to ‘true’.      

  • We shall create a new package in our source folder. The new package name should be exactly as the original OOB form package: com.amdocs.crm.isupport.kcase  

     

         

 and define our new package:     

    

      

       

Under our new package we define the following XML file: CaseCreate.uifvs          

<?xml version=”1.0″ encoding=”ASCII”?>
<VersionSelection designerVersion=”7.5″>   
  <Rows>  
    <Version
       exprDescription=”Default Version”
       expression=””
       physicalName=”com.nextgen.crm.isupport.kcase.X1CaseCreate”     
       type=”form”/>
  </Rows>
</VersionSelection>          

In the package Explorer it looks like this: 
         

Note the following;          

  • The version selector file should be named exactly as the original inherited form name.
  • The version selector file should be located at package which has exactly the same as the original (inherited) package name.
  • The package should reside in our project source folder
  • Our version selector file contains only a single ‘default’ row, which includes:
    • Version description
      exprDescription=”Default Version”
    • An empty expression (empty expression always defaults to true).
      expression=””
    • A target phisical target file name “com.nextgen.crm.isupport.kcase.X1CaseCreate”

At runtime, when the application looks for the original form, a version selector mapping class is evaluated (remember: the version selector has similar name and package as the original form).          

Since its default entry (row) is always evaluated to true, the application use our inherited physical target form (X1CaseCreate).          

  • We still need to make sure that the application finds our version selector before it finds the original form, otherwise the original form will be used and the application will never be able to evaluate our version selector.

To make sure the version selector is used before the original form, we need to set the project’s class order in a way that it looks for our customizations (source folder) before the original oob class (located in AmdocsCRMSource.jar).          

  • We open our project’s properties dialog and select the ‘Order and Export’ tab:

Note that the .uifgenjava folder contains the final source code. This ‘final’ source is automatically created by an application generator utility. It is then build, complied and run.          

10.      Now it is time to see if our inherited form indeed used by the application;
            we shall add a form event handler. We use the ‘form_load’ event handler and add our own code in its stub to print our inherited form name to the console.       

11.       Double click X1CaseCreate.uiff.
             The default view tab (designer) displays the inherited UI layout – it still looks like the original form:
                    

        

  • On the ‘Controls’ UI layout pane, select the ‘Form’
  • On the lower ‘Properties’ pane, select the ‘Events’ tab – it shows available form events. Select the selection icon in the ‘value’ column. The Application Code Editor is opened and displays the ‘form_load’ event handler stub that is automatically added to our inherited class.
  • We add to the ‘form_load’ event handler the following line of code:
    System.out.println(“…  X1CaseCreate   …”);

           

12.       Let’s run the application and try to create a Case.       

       

If our form is used, the console should display the text
‘…  X1CaseCreate   …’          

       

Indeed – our inherited form is now invoked.          

13.     Now it is time to modify the layout.
           In the UI designer view, we first move all main panel components to the unused controls area;       

       

  We are left only with the default ‘root’ panel (all other panels were moved to unused controls);       

        

 If we run the application now and try to create a new Case, an empty form will be displayed.          

        

14.     Now it is time to modify the layout.
           First we change the root panel into two main sections:          

  • Main form area
  • Lower buttons area

We now add two card panels (crdMain and crdButtons) under root, one for each main area:         

       

        

Within each of the card panes we add a panel (pnlMain and pnlButtonsMain) 
A ‘Card Panel’ allows adding several panels underneath. Only one panel can be displayed under a Card panel at a time.
This capability will allow us in future to expand functionality at a will, by adding more panels and swap them as necessary. Currently we use only one default panel under each card.         

(To be continued. )         

                  

  

13/05/2010 Posted by | Amdocs, CRM, CRM, Smart Client, Technology, Uncategorized | 2 Comments

Implementing Role Based Authorization


Implementing Role Based Authorization

The three ingredients required to compose an RBA security mechanism are:

  • Controlled operations (functionality)
  • Controlled data
  • User roles (Global, Team, User)

 
A matrix match of all tree components will allow controlling functionality and or controlled data. Both depend on specific data instance (object) and the user role that are evaluated at run-time.

In order to implement RBA one has to identify the functions and data to be controlled, the roles that should be granted access to those functions and data, and the rules that determine when access is granted.

A.   Identifying controlled functionality

For example, let’s assume the following functionality needs to be restricted:

  • View accounts
  • Create opportunities
  • View opportunities
  • View selected tabs in the Opportunity window
  • Change Case status

 

Business functions can be defined in terms of basic operations or UI elements in the CRM application modules. These business functions are defined as Controlled Business Objects.

Restricted Data

Restricting data visibility (for a specific database object), requires identifying that the database table related with that object. The CBO Data Service (JPOMS) controls access when retrieving the data from the CRM database. You do not need to identify application components for the view function.

Restricted Operations

In order to restrict functions (application components) that performs the business operations, certain application elements need to be identified:

  • The UI component and server side code (worker bean, XBean) handle requests to perform the business function
  • The services or processes which performs the business function
  • The status transitions associated with the business function

 

To control the operation of adding team members on the Account Overview page the following application components are identified:

  • The UI component to be controlled for this function is the Team Members tab on the Account Overview page
  • The server side code (worker bean) that handles the operation is com.clarify.isales.team.workerbean.TeamRoleAddWB.

 

Smart Client administrator UI screens allow identifying the application components which perform specific functions related with specific data object.

B.   Identifying the affected data – Controlled Objects

This is the data affected by the controlled operation. For example, filtering accounts data (restricting access to viewing account records), affect the database table bus_org.

The table containing this data represents the controlled object.

When setting up RBA, the controlled objects define the previously defined controlled business operations.

Instance-specific operations

Functionality related with existing data in the database, and which are authorized for some objects and not authorized for other objects, are called instance-specific functions.

  • For the “view opportunity” business function, the opportunity table represents the controlled object.
  • For a “modify forecast item” business function, the frcst_itm table represents the controlled object.

 

Global functions

Certain business functions that do not operate on existing data in the database are called global functions, such as:

  • Create operations, since there is no object instance yet present in the database (I.e create territories or accounts).
  • External call functions that call external systems (such as services and processes that launch third-party software).

 

Global Control Object

Since global functions do not affect existing database data, their related controlled objects are a special object called global. When setting up RBA, these business functions are defined under the default global controlled object.

C.   Grant Access to Controlled Objects – Define Roles

Who should have access to this functionality and what is the context in which authorization is to be applied to the controlled functionality?

RBA use roles to identify who has access to controlled functionality and data.

For example, allowing the members of an account team to view the opportunities under their respective accounts. An account team member has a role and opportunities related with accounts represent the context in which authorization is applied.

Additional conditions that should be used to restrict access

In order to further restrict access to functionality and or data, an expressions or combination of roles are used.

Setting Permissions 

After determining the data to control and the roles, we should set the kind of permission granted to allow roles to access controlled business functions.

For a given role, any one of the following permissions can be assigned to a controlled business function:

  • Grant permission with no condition
  • Do not grant permission at all
  • Grant permission with a condition.

 

Authorization Matrix

Authorization Matrices are the place where you will map controlled business functions to the roles.

It is possible to grant access to roles associated with authorization matrices by assigning permissions to different roles in different authorization matrices. Thus, a sales administrator global role in the Global Roll Matrix (GRM) can have a single permission and a sales manager in an account Team Role Matrix (TRM) may have a different permission for the same business function.

Granting an unconditional permission 

When assigning the ‘Grant’ permission to a role, that role is given a permission to perform the controlled business function. ‘Grant’ permission overrides all other permissions.

Once a user has a Grant permission for a function, that user is permitted to perform that function even if he is not granted permission in any other authorization matrix for that controlled function.


Denying permissions 

 ‘Not Granted Here’ permission

When the ‘Not Granted Here’ permission is assigned to a role, it means that permission is denied for that role with regard to the controlled business function using that authorization matrix.

Not Granted Here means that the function is not given permission by this role here. However it does not mean that users with that role cannot perform the function.

‘Not Granted Here’ is a non-restrictive permission. If the users have permission for this controlled business function under a different role, that Grant permission overrides the ‘Not Granted Here’ permission.

Not granting permission is not the same as denying permission. RBA uses the combination of all matrices to determine the permission for a business function. If any matrix grants permission to a role, that role is allowed to perform that controlled business function even if user also has another role that does not have permission.

Granting a Conditional Permission Using an Expression 

When a role is assigned with ‘Expression’ permission, it grants or withholds permission to the controlled function depending on the result of an evaluated expression.

If the expression evaluates to true, the role is assumed to have ‘Grant’ permission and if the expression evaluates to false, the role is assumed to have ‘Not Granted Here’ permission.

The Smart Client administrator UI provides special UI which allows using a ‘path builder’ to compose the expression.

Example:

Use the expression: 

  • $focus:name=‘Account1’   –  to allow accounts with name ‘Account1’
  • $User:login_name=‘sa’      –  to allow only user ‘sa’

 

                                                                  Path builder to help writing the expression

How Permissions Are Evaluated 

Permissions are evaluated using the user roles, the business function, and the object instance.

Global roles are checked first to see whether the user is assigned any of the global roles that are permitted to perform the function (Global Roles for a user are known by the CRM application when the user logs in). If a user is not assigned any global roles that are permitted for the business function, every TRM and URM are checked for the business function to see if the user is assigned a role with permission for that function.

 Identifying Authorization Matrices

Which authorization matrices should be used to assign permissions to different roles for the controlled functionality?

Assuming we would like allow an opportunity team member (team role) to view accounts associated with opportunities. The authorization matrix used for the opportunity team will be the Opportunity Team Role Matrix. The authorization matrices for different roles must be identified.

An authorization matrix determines which roles have permissions to which business functions. As an example, an authorization matrix for an “Opportunity Owner” authorization domain may specify that the opportunity owner has access to the “view opportunity” business function for that opportunity.

Based on the types of roles used, RBA can use three types of Authorization Matrices:

  • Global Roles Matrix (GRM) for global Roles
  • Team Role Matrix (TRM) for Team Roles
  • User Role Matrix (URM) for User Roles

 

When setting up RBA, a grid-like UI is used to implement the authorization matrices.

When all  RBA settings are ready, they should contain at least one GRM and one or more TRMs and URMs.

When users try to use a controlled business function, RBA uses the combination of all matrices to evaluate if they are permitted to access the controlled functionality.
A user who is granted permission in any one of the matrices has access to that controlled function.

Users not granted permission in any of the matrices are denied access to that controlled function.

Using the Global Role Matrix (GRM) 

The Global Role Matrix (GRM) relates the controlled business functions with the Global Roles.

The GRM is checked first for evaluating permissions when the user logs into the CRM application.

 The GRM is accessed through the following CRM Administrator UI screen:

 

                                                                               Global role Matrix window

Controlled Objects and business functions are added into the matrix using the ‘Controlled Objects’ UI tab. They are added from the global pool of controlled objects defined in the application.

Using the Team Role Matrix (TRM) 

The Team Role Matrix relates controlled objects and functions with Team roles; enabling the function for users in the team with the role specified.

The CRM application already provides several pre-defined TRMs for Account, Opportunity, and Territory objects.

If a user has multiple roles within the same team, the effective permission is the sum of all the permissions granted for that user in that team.

Using the User Role Matrix (URM) 

The User Role Matrix relates controlled objects and functions to user roles; enabling the function for users with the particular role (ex: case owner)

The URM is a special kind of TRM. The only difference between them is that a TRM uses team roles previously defined, while the URM uses roles assigned by the application logic.

The URM is accessed through the following CRM Administrator UI screen:

 

                                                                            User Role Matrix window

Performance Considerations

Enabling Authorization affects the performance of the CRM applications (due to multiple checks for evaluating permissions).

Here are some guidelines for minimizing performance penalty when implementing RBA:

  • Use global roles if possible. Checking permissions for global roles is faster than checking them for team and user roles.
  • Define as few controlled business functions as possible (use combination of functions…).
  • Define as few team roles as needed. If two team roles have exactly the same authorization policy, combine the two roles.
  • Do not duplicate permissions when one role is a superset of another role. Instead, assign user to both roles.

 

Disabling Authorization 

RBA is enabled by default for Amdocs CRM applications. However, you can disable authorization checking using RBA at the following levels:

  • To disable RBA for at the applications level, use the DisableAuthorization configuration item, and set it the ‘1’.
    As a result, RBA will not be active at all for all roles and all functions.
  • To disable RBA for a global role, use the Disable Authorization for this Global Role check box on the Role tab of the Global Role Matrix window in the Administrator UI.

06/05/2010 Posted by | Amdocs, CRM, CRM, General, Uncategorized | 4 Comments

%d bloggers like this: