NextGen Consulting

IT Consulting CRM BSS OSS


NextGen Consulting

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…

View original post 1,886 more words

03/05/2012 Posted by | Uncategorized | Leave a comment


NextGen Consulting

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.

 

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.

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

View original post 1,832 more words

20/03/2012 Posted by | Uncategorized | Leave a comment

Using CBO Application


Q: I have a CRM console application, this is some code snipet:

Application app = new Application();
Session session = app.createSession();
session.login("sa", "sa");

Everytime i run it, i get error at line : app.createSession(); it says something like it could not find ASC configuration ….

Do I miss some configuration some where? How to make console program works?

Using CBO Environment

The code snippets above use CBO functionality which is used by Amdocs CRM application.

While CBO initiates its operation, it looks for an initialization configuration file named ‘clarify.env’. This file contains several important definitions, such as JDBC connection information, which are mandatory for its operation.

One of the parameters included in clarify.env tells the application the location of Amdocs System Configuration (ASC) data. This data can be located either on disk as XML files or stored in the database instance indicated by the JDBC connection parameters.

The clarify.env is located in a directory called ‘bin’ which contains all relevant application dynamic runtime libraries (*.dll for windows, *.so for Unix flavors).  This directory could be located anywhere provided the operating system has its path defined correctly

For example:   Assuming our ‘bin’ directory is located at the following path:

C:\CRM800\Apps\crmApps\bin_abs_crm_800\

(Windows) – we need to make sure this path is included in a system variable named ‘PATH’.

Once CBO understands where the data is located, then it looks for certain parameters within these data to determine its connections with CRM database (and possibly other database instances used by other applications).

In other words:  In order to properly use the CBO layer the application must:

  1. Know its ASC data location
  2. Extract and use proper resource definitions (such as the CRM database connection) from the ASC data 
    regardless the location of the ASC data (on disk or in the database).

Here is an example for a full clarify.env file:

##########  C:\CRM800\Apps\CrmApps\bin_crm ################
 ##### Used for Initial Connection ######
jdbc_db_name=CRM800
jdbc_db_server=localhost
jdbc_db_port=1521

######### Conf file location ######################################
# -- FOR DB READ - #####
#   
#    Used here to read from file.
#    to read and store in db, comment the following line
config_file_location=C:\CRM800\apps\server\dbadmin800\config\_main_abs_crm
##############################################################
 ######### Conf file type ##############################################
# -- CURRENTLY SET TO RETRIEVE PARAMS FROM  baseConfig       -- #####
# baseConfig      - Used for Smart apps     
# baseConfigThin  - Used for thin apps
crm_config=baseConfig                                             
###################################################################
 app_server=weblogic
app_server_datasource=CRM800_XA_DataSource
app_server_nonxa_datasource=CRM800_NXA_DataSource
app_server_password=weblogic
app_server_login_name=weblogic
unicode_db=y
login_name=sa
db_password=sa
db_name=CRM800
db_server=localhost
db_driver=Oracle
db_type=oracle90
Predef_User_Name=sa
Predef_User_Password=sa
clr_loc=1033

machinerole=Server
dataaccesslocation=InProc
unicode_app=y

charsetconvert=n

;    The following class path config works for Core CRM
;----------------------------------------------------------------------------
Java_Classpath=C:/CRM800/Apps/CrmApps/lib_crm_app/acfglib.jar;
C:/CRM800/Apps/CrmApps/lib_crm_app/ClfyCore.jar;
C:/CRM800/Apps/CrmApps/lib_crm_app/AmdocsCore.jar;
C:/CRM800/Apps/CrmApps/lib_crm_app/jdom.jar;
C:/CRM800/Apps/CrmApps/lib_crm_app/ojdbc14.jar;

jar_path=C:/CRM800/Apps/CrmApps/lib_crm_app
java_args=-Xms512m -Xmx512m
;----------------------------------------------------------------------------

##### Use the following to switch-on Trace log ####
trace=Y
tracekeys=sql,lpoms,config,apm

##### Use the following to switch-on ASC log ####
# enable_asc_log=true

##### Other Parameters #####################
JAVA_HOME=c:\Java\jdk150_12
billing_app_id=ACM
provisioning_app_id=PROV
fulfillment_app_id=FC
urm_default_pool=13
user_admin_priv=System Administrator
weblicense=on
java_pool_size=50m
large_pool_size=60m
output_charset=UTF-8
NLS_LANG=AMERICAN_AMERICA.AL32UTF8

In order to run a console application, you do not need the full clarify.env file, since some of the parameters above refer to an application server (Weblogic) environment.

Here are explanations for the most important parameters:

  • jdbc_db_xxx
    JDBC connection parameters, required for some initialization work (I.e. access and search  ASC data).
     
  • config_file_location
    ASC files location on disk. Omitting this parameter means that the ASC data is stored in the database instance indicated by the above JDBC parameters.
       
  • crm_config 
    The location of CRM parameters within the ASC data.  The location is indicated by a node name.

     Examples:

crm_config=baseConfig         – Used for Smart apps  (/crm/baseConfig)

crm_config=baseConfigThin  – Used for thin apps      (/crm/baseConfigThin)

  • app_server_XXX     
    Application server (Weblogic, Websphere) connection parameters
        
  • unicode_db 
    Defines whether the database is Unicode.
                
  • login_name, db_password, db_name, db_serve, db_driver, db_type, Predef_User_Name, Predef_User_Password
    Connection parameters used by Classic client or console applications.
      
  • clr_loc
    Defines the application locale (1033 is US_EN)
        
  • Java_Classpath, jar_path, java_args, java_pool_size, large_pool_size
    Parameters used by Java environment
       
  • Trace
    Used to switch-on Trace log
       
  • enable_asc_log
    Used to switch-on ASC log
       
  • NLS_LANG=AMERICAN_AMERICA.AL32UTF8
    Locale parameter used by CBO
     

CRM Configuration in ASC 

Use the ASC editor (an eclipse plugin) to manage (view / edit) the CRM database connection definition.

As mentioned above, the CRM root node is defined by the clarify.env parameter ‘crm_config’.

Assuming our CRM root is defined as ‘crm_config=baseConfig’,
the following database connection parameters are defined in ASC node /crm/baseConfig/Aif.  These parameters mainly used by an application server:  

DataSource: CRM800_XA_DataSource
JdbcDriver: oracle.jdbc.xa.client.OracleXADataSource
DatabaseUrl: jdbc:oracle:thin:@localhost:1521:CRM800
UserName: <user name>
Password: <Password>
 

 

13/08/2011 Posted by | Amdocs, Backend, CRM, CRM, Development, Uncategorized | Leave a comment

Using Paths and Expressions in Smart Client


Smart Client Run-Time Focus Objects  

Smart Client Named Collections

Named Collection data path handler enables resolving an item by name within a named collection, such as

 $Form:Controlset:Controls:MyDateControl

 

Named Collection Data Paths

 A named element in a collection can be extracted from a java object by using two path items:

  • The first identifies the collection,
  • The second identifies the item’s name

 

 An example data path is as follows:

$Dataset:DataModel:myDataModel

The $Dataset context type contains a collection that can be accessed by:

getDataModelByName("myDataModel")

 

The followings Smart Client runtime elements are implemented as Named Collections:

 

Example:

The following path resolves to a Grid column control in the current Form using Named Collection:

 $Form:ControlSet:Control:caseOverviewGrid:GridColumn:caseTitleCol:ColumnControl

where:

  • Form                         is the starting context and it specifies a UifForm context type
  • ControlSet                 is a member in UifForm
  • Control                      is the accessor collection name for ControlSet
  • caseOverviewGrid       is the name of the Grid control
  • GridColumn                is the accessor collection name for the caseOverviewGrid object
  • caseTitleCol               is the name of GridColumn inside the caseOverviewGrid grid control
  • ColumnControl           is a property in GridColumn which specifies the contained UifControl for the     GridColumn control.

 

Example:

The following path resolves to a logical form called com.nextgen.GlobalUtils:

 $Workspace:Form:com.nextgen.GlobalUtils

where

  • Workspace                           is the starting context and it specifies a Workspace context type
  • Form                                   is the accessor collection name for Workspace
  • com.nextgen.GlobalUtils         is the name of the Form.

 

Data Path Contexts

Data Model,  Data Provider

 

Form,  Control,  Action

 

                               Create Data Request Map

 

                                Choice List Action Request Map

 

Input, Workspace, Locale, WorkspaceForm

 

 

 

 

ContainingFormDataModel,  OpenerFormDataModel,  TopLevelFormDataModel,  Form

 

  

ServiceInput, ServiceOutput,  Bindable, Control, DataModel, Input, Relative

 

13/05/2011 Posted by | Amdocs, APM, CRM, CRM, Development, Front End, OSS, Smart Client, Technology, Uncategorized | Leave a comment

Implementing Double Click event in Search Grid


Double click event is implemented in the Search Grid (or simple Grid) using activationAction event handler.
The activationAction sets the action to be launched when a cell in a row is double clicked. This action is executed if and only if the cell is not editable and the corresponding column control of the cell is not an action control (hyperlink or button).

See the Implementing Double Click event in Search Grid for a step by step example.

30/08/2010 Posted by | Uncategorized | Leave a comment

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 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

Front End Client Technology


This time we would like to hear which client technology your organization employ, and whether you consider moving from legacy to latest technologies.

09/05/2010 Posted by | 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: