NextGen Consulting

IT Consulting CRM BSS OSS

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:

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

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.

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)


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:
                                           (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. – 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. and
    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″>   
       exprDescription=”Default Version”

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).
    • 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


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.


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

Role Base Authorization

Role Base Authorization (RBA) is a security feature for AmdocsCRM smart (and thin) client applications.
It facilitates the setup and administration of an organization’s authorization scheme, without requiring customizing the CRM applications.  With RBA, it is possible to create a security model based on the organization’s structure so that the application can precisely apply security that reflects that model.      

 To implement security using RBA, certain areas of the Amdocs CRM applications functionality that require authorization need to be defined. Additionally, the organization model needs to be mapped to the AmdocsCRM applications.    The organization model is built around what people do, their level of responsibility, the people they work with, the teams they belong to, and the business entities (accounts or cases for example) they work on. RBA collectively refers to these factors are as roles.    A CRM application can be regarded as a combination of data and application functionally that enable accessing that data.
RBA allows managing the intersection between the roles that model the organization and the controlled data.    

A simple RBA scenario defines roles which may roughly correspond to job descriptions, and each role is authorized to work with
different parts of an application.    


The figure shows four employees organized into two roles – Account Administrator and Support Administrator.
The Account Administrator role is authorized to work on everything related to Accounts, while the Support Administrator role is authorized to work only on Account Overviews.    

 The advantage of using such Roles to define authorizations is when the organization policy changes, only the authorizations associated with the roles will be changed, and no change at every user level will be necessary.    

Roles are organized into 3 categories:    

  • Global roles provide authorization that spans an entire organization.
    They are equivalent to Privilege Classes used in Classic Client, but a same user may have several global roles and only one Privilege Class
    Global roles are used to authorize access to similar instances of work. You can for example authorize or disable access to all accounts, without specifying which account.
    Global roles are mostly recommended to use. Using Global roles creates the most efficient database queries, hence result with best performance.
  • Team roles associate a group of individuals to a business entity, such as an account or an opportunity.
    Team roles can be used to authorize access to a specific instance of work that a selected group of people can work on.
    For example, for sales operations it is common to form teams of people and assign them to work with particular accounts, or within particular territories, or on specific opportunities.
    Using Team Roles, it is then possible to authorize access to those specifics accounts, territories, and opportunities only to the team members of those entities.
    Team Roles are always defined against a domain object, which is the CRM database object representing the data to control, such as account (bus_org), opportunity or territory.
  • User roles refer to special relationships between a user and an object of the application. For example, the Case Owner.
    User roles can be used very much like team roles, to authorize specific instances of work for selected users. With user roles the implementor needs to identify existing relation between a user and an object instance (established by the application logic) and give it a name. When RBA is used to identify a relation, authorization can be applied to it as well as to any other related objects

When RBA checks to see if a logged-on user is authorized to perform a particular task or to access some data, it checks if the user has a global role, team role, or user role that grants permission to perform the task.      

Multiple roles usage
The following figure shows a global role and an example of teams that are authorized to work on the same types of data, but only on the specific instances of that data for which their team is responsible for.  

                   Global and Team Roles Authorization in RBA        





















The diagram above show two account teams: East Region Account Team and West Region Account Team.
Account Administrator role held by John Stevens is authorized to see all accounts.Each team has assigned employees and two associated roles (Account Manager role and Sales Representative role).  

East Region Account team is authorized to work only on the East Region Accounts, while the West Region Account Team is authorized to work only on the West Region Accounts.   

 The boundaries indicate scope of authorization for each role within the team (depends on team role)    

Using RBA in the API (Application Programming Interface)
RBA can be used to control user interface (UI) elements for Thin client or Smart Client applications.
Using RBA, various types of UI controls such as buttons, menu items, text boxes, tabs, etc can be selectively enabled or disabled, made visible or invisible,  based on the user roles.    dditionally, the data shown as a search result can be filtered. Because RBA can be set up to give different permissions to different instances of data, certain user might sometimes see different UI controls on the same page, as different data are being worked on. For example, a user with permission to work on Corporate Accounts might see buttons enabled on Account Overview pages for Corporate Accounts and not on others, based on his roles and permissions.      


05/05/2010 Posted by | Amdocs, CRM, CRM, General | 1 Comment

AmdocsCRM Releases: From Clarify 11.5 to AmdocsCRM 8.x

Q: Right now I’m working on Clarify thick Client 11.5.

 I need information like what are new versions available (details on new versions of thick, thin and smart clients) and nomenclature followed to represent a specific version of Client.

How are they differentiated from architecture point of view? Where can I get more information of current updates, releases, versions of Amdocs Client?

If we upgrade from thick to thin or smart client what parameters must be considered like DB used, version of DB and all.


Amdocs CRM Releases 

Since Clarify version 11.5, the following versions were introduced: ClarifyCRM 12.1, ClarifyCRM 12.5 and ClarifyCRM 13.1.

 As of ClarifyCRM 13.1, Amdocs changed its name and number to AmdocsCRM 6.0. (That means – both Clarify version 13.1 and AmdocsCRM 6.0 refer to the same release).

 AmdocsCRM 6.0 (Clarify 13.1) was the last version to introduce new functionality for Thin (Web) client).

 AmdocsCRM 7.1 was the first release that offered Smart Client (Java based client).

 However, the first fully matured Smart Client was released on release 7.5 (Italy).


The following versions are currently available:

  • AmdocsCRM 7.5.2  Supported clients: Thin (Web) and Smart Client (JNLP)
  • AmdocsCRM 8.0 Supported clients: Thin (Web) and Smart Client (JNLP)


As of release 7.5.2, a multi language support was added on the database (Oracle) level. This is not supported by classic client.

Note that since version 11.5 the Classic client releases have not added new functionality provided in both Thin and Smart Clients.

For example, the Customer Interaction Manager (CIM) module (call center agent’s main screens) is not provided out of the box classic client.

Architecturally, Classic client is a fat client which connects either directly to the database (2 tier) or use Tuxedo as an intermediate layer (3 Tier). In both cases, all logic is performed mostly on the client using a Visual Basic 5.0 dialect named ‘ClearBasic’.

Thin client and Smart Client use Java J2EE architecture. This architecture separates the application logic between a server side code (implemented as Java Beans) and client side, implemented as JSP / JavaScript for thin client, and as Java / SWING code for smart client.


Supported Platforms:

Server Platform Support

Operating System

  • Solaris 10 patch level: Generic_120011-14 (Sep 07)
  • Win 2003 SP2 current patch
  • HPUX 11iV2 RISC & HPUX 11iV2 Itanium
  • AIX 5.3 TL06 SP1 Patch level: 5300-07-02-0000 (Feb 08)



  • Oracle 10gR2
  • MSSQL Server 2005 SP2 Standard J2EE Server.


JVM/SDK Solaris:

  • WebLogic 9.2 MP1 with Sun Java 2 SDK 5.0 update 12 with the Java HotSpot Client and Server VMs (32-bit)
  • WebLogic 9.2 MP1 with Sun  Java 2 SDK 1.5
  • HP:        WebLogic 9.2 MP1 with HPUX SDK 5.0.08 (32-bit) with Java HotSpot Server VM.
  • IBM:       WebLogic 9.2 MP3 with IBM SDK 5.0 SR5a 32-bit JavaTM.
  • IBM:       WebSphere with IBM 32-bit SDK for Solaris, Java 2 Technology Edition, Version 1.5.
  • IBM:       WebSphere with IBM 32-bit SDK, Java 2 Technology Edition, v1.5.
  • IBM:       WebSphere with HP SDK for J2SE


Client Platform Support

  • Classic Client:        Windows Pro XP SP2 & Vista Business Edition
  • Thin Client:            Windows Pro XP SP2 & Vista Business Edition
  • Smart Client:          Windows Pro XP SP2 & Vista Business Edition



  • Classic:                                  N/A
  • Thin:                                    Internet Explorer 7
  • Smart:                                  N/A
  • JRE Classic, Thin, Smart:          1.5_12


Upgrading from Classic 11.5 to Smart 8.0

For this upgrade you need to consider the following:

  1. Upgrading your current database to Oracle 10gR2 (AmdocsCRM 7.5) or Oracle 11g (AmdocsCRM 8.0).
    This might require possible changes in your data model (for example, moving from ClearCallCenter or ClearSupport modules to the newer Customer Integration Manager data model).
  2. Migrating your application logic from Classic Client to Smart Client.
    This requires updating your customized UI from VB to Smart Client SWING, and updating logic from ClearBasic to Java server side and client side.


Q: This information is very informative. I do have one somewhat related question on this (note – I’m not very technical on Amdocs CRM):

Since the older version of Clarify 11.x (or AmdocsCRM 6.x) and the latest 8.x version, how much has the underlying data model changed?

My understanding is that Amdocs has not been making significant data model changes (new or modified tables/columns)..etc. Is that true?

Secondly, what exactly (in summary) is this ‘ClearSupport modules’ to ‘Customer Integration Manager’ data model change that you mentioned?
Does Amdocs provide a good packaged upgrade path/solution to move to newer versions?

Thank you in advance.


More About AmdocsCRM Releases

AmdocsCRM 6.0 is the same release as ClarifyCRM 13.1 (not Clarify 11.x). Note that between releases 11.x and 13.1 there were several releases, the most significant one was ClarifyCRM 12.5.


Upgrade Path from Clarify 11.5 to AmdocsCRM 8.x

Q:  Does Amdocs provide a good packaged upgrade path/solution to move to newer versions?

In order to upgrade from Clarify 11.5 to AmdocsCRM 7.x or 8.x you need to:

  1. Upgrade your existing database software from Oracle 8.X to Oracle 10gR2 (AmdocsCRM 7.x) or to Oracle 11 (AmdocsCRM 8.x).
  2. Migrate (upgrade) your database scheme (data model) from Clarify 11.5 to AmdocsCRM 7.5. via Clarify 12.5, AmdocsCRM 13.1 and AmdocsCRM 7.1 (full details are provided with each AmdocsCRM release notes which specify the exact migration path).
  3. Migrate your customized UI and logic (code) from ClearBasic to Java (server side and client side).


Technology Changes

Q: How much has the underlying data model changed from Clarify 11.x to AmdocsCRM 8?

The underlying data model has been significantly enhanced, both for the underlying technology and the provided functionality.


Technology Enhancements

New technical features were introduced to enhance performance, sizing etc.

Few Examples:

  • Support larger number of unique records per database table. The old objid primary key mechanism now supports the full 32 bits.
  • Additional key named GUID was added to support unique record string id.
  • Search field object mechanism was added to enhance performance (the search field allows user defined pop-ups to use be used by reference, in similar fashion to application pop-ups, rather than by value.
  • All popup menus are referenced by ref_id rather than by their nominated names.
  • Multi-lingual support was added at the database level.
  • Ability to define a schema object (table or view) using SQL query.
  • The old data dictionary compiling application (ddcomp) was completely rewritten for a much more reliable java code and is now called Schema Manager.
  • The licensing scheme was greatly enhanced. You need a proper Amdocs license in order for your J2EE server side code to properly run.
  • Most importantly, the server side code exclusively use CBO (Crm Business Objects) to access the data in the database. These CBOs were upgraded to use JPOMS, replacing the old POMS.
  • Clarify Process Manager (CPM) was replaced with Amdocs Process Manager (APM). APM provides much more sophisticated functionality, and can work with any other Amdocs products (it is largely used by Ordering).
  • Smart Client technology now allows the front end UI to interact simultaneously with several backend applications.
    For example: CRM and Ordering.
    In other words: Both CRM and Ordering share e unified desktop front-end UI.

Note that until lately (version 7.5), most these changes impacted the new J2EE technology, but still allowed legacy Classic client to co-operate with the same database. However, Classic legacy code was not updated to take advantage of the newer enhancements.


Functional Enhancements

1.     Billing Manager

Since Amdocs acquired Clarify, they decided that the Clarify UI (initially Classic, then Thin/Web, now Smart Client) to be used as a front end UI for all Amdocs Products.

Initially, main efforts were spent for adding UI screens and logic to provide seamless integration with billing functionality. (Billing Manager module, support Amdocs Billing or any other 3rd Party billing).


2.     Customer Interaction Manager (CIM)

Although legacy Clarify provided a Call Center module (Clear Call Center), it appeared that the data mode used for CCC (Clear Call Center) was inefficient nor flexible (i.e. – it created a Case record for each interaction).

A completely new data model and supporting UI screens and logic were introduced. The CIM model creates a light Interaction record for each interaction with a customer.

An interaction is NOT a workflow object, but merely a data record that stores the following call related data:  Title, Notes, Direction (outbound, inbound), Channel (800), Media (call, email, or chat). 

Each Interaction is related to one or more TOPICS. A topic is an issue raised by the caller. Each topic is categorized by at least two call reasons (identifiers), a possible, not mandatory, linked related Workflow object (such as Case), and a result code.


In practice, each topic may potentially initiate a call center process, such as an Order.

One of the most important CIM features is the ability of the call center agent to handle several interactions simultaneously. Each interaction with a caller is identified by caller’s name. The agent can toggle among several on-line interactions (each has its own different caller) while holding the caller on the line. When switching from one interaction to another, all interaction related data and UI is automatically switched as well and exposed to the agent.

An interaction can be used with an Anonymous Caller as well.


3.     Multi Media Integration

AmdocsCRM now supports a sophisticated integration module with external Interactive Voice Recognition (IVR) systems. It allows call center agents to accept calls, put calls on hold, transfer calls among them etc.

All IVR control is performed from the agent’s desktop. It also supports alternative media such as conducting a live chat etc. 

The multimedia integration also allows passing IVR parameters automatically to the interaction screen.


4.     Ordering Integration

As of release 7.5, ordering module UI and front end logic is integrated with CRM UI. It is possible to initiate an order process directly from CRM interaction screen with a single button click.


5.     Enhanced Support Module

There were many enhancements to the support module here is one of them:


SLA (Service Level Agreement) Manager

Tracking service level agreements (more on this in a separate post).


Role Based Authorization (RBA)

Control UI and backend permitted user activities according to their Global, Group or User Roles.(See more on this in Role Based Authorization).


Case Types
Case types are not only 3 keyword identifiers stored with a case record, but a whole definition which allows different screens to popup according to the type of the case.



Yes – in order to support all above changes (and many, many more) Amdocs have added significant enhancements to the underlying data model.


ClearSupport Vs Customer Interaction Manager

The ‘ClearSupport’ module is a separate module from ‘Customer Integration Manager ‘(CIM). They use completely different (although compatible) data models.

You should regard the Customer Interaction Manager module as an enhancement to the Support module.

From business process perspective, any customer call starts with the ‘Customer Interaction Manager’ to handle the call (interaction).

An interaction may, or may not, propagate to a process handled by the Support module (i.e. a service call).

For example – if a customer calls to ask a question and immediately get an answer, only Interaction record needs to be created, no Case is created (this is sometimes called ‘Done in One’).

On the other hand, if a customer calls and complaints about a service, or a billing issue, where the issue can not be immediately resolved, a process needs to be initiated to handle the issue. A Case record is then created, and the Support module handles this Case according to its type until the issue is resolved and the Case is closed.


04/05/2010 Posted by | Amdocs, BSS, CRM, CRM, General | 4 Comments

NextGen Consulting – IT consulting services

Welcome to NextGen Consulting.

We provide IT consulting services to organizations who use Clarify or Amdocs CRM products.

Having over 10 years with full life cycle of Clarify / Amdocs CRM projects, we offer flexible variety of services aimed both at the telecom and the enterprize organizations.

Our people have hands-on implementation expertise with Clarify Classic Client, AmdocsCRM thin client, and Amdocs CRM Smart Client.

We offer your organization this expertise to help you migrate from either Classic or thin to Smart Client, or simply provide high level design, low-level design and customization to fit your organization needs.

For further information view profile at
or contact Yuval Rashelbach at


24/02/2010 Posted by | BSS, CRM, General, OSS | 1 Comment

%d bloggers like this: