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:
- Know its ASC data location
- 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>
About Smart Client Script Player
Background
A Smart Client form can define a Launch Action to allow manually launching another form in the workspace.
For automated processes, Smart Client infrastructure provides three alternate actions which allow automating the selection of the next form to be launched;
- Process Driven UI Action (PDUI)
- Service Driven UI Action (SDUI)
- Client Process Driven UI Action (CPDUI)
Process Driven UI Action (PDUI)
This action is used if the form launch is based on a process running on the server. This is typical to a Wizard Form which requires the process state to be maintained and communicated to either the launching form (or other forms subsequently posted) that might continue the process. The Order Management process is a good example for process driven UI.
Service Driven UI Action (SDUI)
This action is used if the next form to be posted depends on a UI driving service.
Client Process Driven UI Action (CPDUI) – 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.
Amdocs Process Manager (APM) Design tool is used to define the Script metadata. APM Client interacts with APM Server to get the metadata to the client and maintain the state.
The Client Process Driven UI (CPDUI) Action interacts with APM Client to launch Smart Client forms in the client workspace. These forms can be either dynamically constructed forms (E.g., Question and Answer script forms) or standard Smart Client forms already created at design time. These pre-designed Smart Client forms are invoked by a special script step known as Show page step)
The CPDUI Action communicates with APM client, to either start or proceed with a client process. Whenever the CPDUI needs user interaction, it yields back to itself and pass required inputs (process variables). The action processes the inputs and dynamically generates and posts a ‘script form’ for user response.
The target form can have another CPDUI action, which collects and validate user inputs associated with the action and submit the details back to the APM client.
To facilitate communication between the APM client and the CPDUI action, the process variables in the APM client are mapped (at design time) to the Data models in the next launched (target) form.
When APM client is running along with Smart Client, APM client interacts with APM server (via Smart Client and Smart Server) to get Light Weight Process metadata or to invoke a service (AIF service or any other service) as part of the process execution. In fact – The Smart Client acts as a host for running Light weight processes.
Smart Client normally uses a Submit Action to submit to the server and get the response back. This functionality is utilized for retrieving the metadata and invoking any server side service.
Similar to the PDUI action, the Client Process Driven UI Action launches a form based on the logical form name (LFN) input data section. At script design time, the Script Designer refers the form’s input data section as show context area. At run time, any input retrieved from the process can overwrite the form’s default launch action properties.
Running Scripts from Smart Client form
Client Process Driven UI Action Can be added to any Smart Client form like any other action, and can be invoked by a user action or using application code. The Client Process Driven UI Action defines various operations:
- Get a lite process instance
- Start running
- Proceed
- Abort
- Go back (a process step)
- Get log details
Process Navigation
After getting response from the process, the Client Process Driven UI Action always invokes a launch action to launch a form based on inputs from the process, except when the process’ return status indicates abort/completed.
If the process returns with completed or aborted state, then it sends a message to its opener form indicating the new status. If this action is overloaded by a PDUI action, (in case the lite process was part of a server process), then, it invokes the dynamically created PDUI action and passes the ‘proceed context’ details (to allow the original server process continue).
The execution of the Client Process Driven UI Action is considered ‘done’ after the action launches the form or if the process is completed or cancelled and the action sends a message to its opener forms.
The action passes the Lite Process Instance (LPI) got from a “GetProcess” operation to all the launched forms. LPI is stored as a property of the launched Smart Client form to allow all CPDUI actions in that form access this Lite Process Instance.
While a Lite Process Instance is being executed, it may respond to one of the following UI steps:
- Show page step
- Prompt step
At runtime, the process might call for a UI step. This UI step can either a show page step or prompt step.
Show Page Step
A show page step dynamically invokes a Smart Client form by:
- Creating a Launch action
- Setting the launch action’s properties according to the properties provided by the process (in other words: it passes relevant process variables to the launch action properties)
- Launching the target form (the target form is a standard Smart Client form which was previously set as a show page step in the process definition)
- The show page can be invoked either in Synchronous orAsynchronous modes. In Synchronous mode, the Client action overloads existing actions in the form to return data back to Opener form (Script Player) which continues process. For example, clicking Save button in Show page form executes Save Actionand continues client process from Script Player form.An Asynchronous mode, returns data to Opener form right after the Initial Load Action of the Show page form is done and continues process
Prompt Page Step
A prompt step uses a dynamic form generator to create the prompt form.
- The prompt form can be displayed either in the toolbox or workspace area (exact location is set at design time by the process designer
- The prompt form is based on the prompt info defined at design time in the process
Launch Script in Toolbox Area
UifLiteProcessHost Class
The UifLiteProcessHost supports information storage (and retrieval) on the client’s disk. It also supports submitting server requests issued by the lite process instance.
The Smart Client RequestResponseManager is used to submit request to the server.
The UifLiteProcessHost provides the following functionality:
- Get the required or latest version of lite process instance definition from the APM server and store it in the client
- Submit an AIF operation request to the server based on the client host
To get a Lite process instance from the process definition, the Client Process Driven UI Action calls the static API getLiteProcInstFactory(), which returns a process instance factory which is used to create an instance of a Lite process instance.
For example, the action may use the following call to create an instance of the required process:
UifLiteProcessHost.getLiteProcInstFactory(procName, version, deployCount().create().
Lite process instance
A Lite process instance is an instance of a lite process definition downloaded from the APM server. The client can run multiple instance of the same process definition at the same time.
For example, when user runs ‘Script A’ once, an instance of Script A’s LiteProcInst is created and used until the script is done.
Types of Operations
GetProcess
The inputs to get a client lite weight process are Process Name (mandatory) and Process version – (optional); If not provided, the latest version of the process is used.
Accessing a client process involves getting the LiteProcInst (LPI) based on the lite process definition retrieved from the relevant APM client (CRM) database or from APM server.
After getting the LPI, the defaultLaunchAction specified in the action is invoked. The default Launch Action should give a valid Logical File Name with any required input data.
Additional input required for the process is information regarding the launched form; whether the form should be launched as a Main WORKAREA form or as a TOOLBOX form.
The action fires an event including this information to the application code before launching the defaultLaunchAction. This allows the application code to take advantage of both potentially adding a LaunchMapItem, and pass this as an input to the launched form and use form version selector, which could return the appropriate physical form name to be launched on the WORKAREA or TOOLBOX.
Single light process instance per form
When launching the form (executing the defaultLaunchAction), the LPI instance is passed internally through the launch action to the launched form and cached. Any other CPDUI action in the launched form will always use this LPI instance for any other operation involving the same process, which means only a single lite process instance can be used on a form.
Consider an example where the launching form is a Script listing form and the user selects a particular script and clicks play. The play button will be associated with the CPDUI action that has:
- Operation: “GetProcess”
- DefaultLaunchAction: launch action where LFN = “
The Client Process Driven UI Action retrieves the Lite process Instance and the target launch area (where to launch this form – WORKAREA or TOOLBOX).
The CPDUI pass this information to the defaultLaunchAction and executes the launch action. The launch action launches the script player form, and sets this Light Process Instance to scriptPlayerForm.LiteProcInst.
If the client process was part of a server process, then PDUI action would dynamically create this action with operation “GetProcess” and use the ShowContext details to get the process name version etc.
As already mention, the Launch action would pass the Show context data and Proceed Context data to the launched form, and if required, overload any existing action in the launched form as described by the Action descriptor. The Proceed Context can be passed back to the server after the client process is done.
Start, Proceed, Back, Abort, Restart, ShowLog
All operations other than “GetProcess” should not provide the process name, version as input. If the action’s operation type is set to one of Start, Proceed, Back, Abort, Restart or ShowLog, then the default Lite Process Instance which is already available in the Form (where the action is defined) is used.
LiteProcInst provides APIs to run, proceed, back, cancel the process, which is used to perform the operation.
Restart
Restarting the client process has to clear out the logs created so far, and initiates the process as if nothing happened in this process instance. A process can be restarted before it is complete. It can be done even after a child script is executed, in which case it goes back to the main process that was originally started by the user. Restarting is not possible, after a show page step.
Abort
Aborting a process also requires a Feedback message from the user. It’s up to the application to get this feedback and set it to the action if the operation = “Abort”
ShowLog
Calling the below API on the liteProcInst gets the log details.
LiteProcInst.getLiteProcInstHistory()
The output from the API can be set to a data model in the launched form and displayed as a list (See output processing below).
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
Database Path Contexts (Part 2)
The previous part Data Paths and Expressions (Part 1) described the data path concept and its usage in various areas cross the CRM and its peripheral applications.
Database path contexts include paths with focus object as context, as well as absolute paths (Database contexts).
BO context object can serve as focus object as well and the path can be a BO context path.
Path Modifiers
In addition to the basic syntax, path relations can have modifiers, specified using round brackets ( and ) after the relation.
Using Conditions
A condition modifier must be specified when there is a need to refer to a single target instance when traversing OTM or MTM relations
The modifiers serve two purposes:
- Restricting a path or a portion of the path to a unique result.
- Resolving the starting point for an absolute path.
1. Restricting a path or a portion of the path to a unique result.
For example, consider the following path that traverses from a case, to the sites for its contacts:
Since the contact2contact_role relation is one to many, this path might return several site_ids. The path can be modified to restrict the result as follows:
Note role_name is unique for each contact / contact_role / site combination. Therefore this path will select a single item.
The SQL for this path would be:
2. Resolving the starting point for an absolute path.
For example:
Using Aliases
Alias must be specified when it is necessary to differentiate between two different paths to the same target object. For example, a case query for Owner = ‘jdoe’ and Originator=‘jsmith’ uses the case query properties:
The following SQL query is generated by the query:
Property Name Path
Property names are defined in the prop_name database object.
Example:
Assume case property “Originator” is path to case originator login name i.e. prop_name is “Originator” and path_name field is “case_originator2user:login_name”
Path:
With case focus specifies to login name of case originator
Flexible Attributes
A Flexible Attribute may be used to terminate a path definition:
Here bandwidth is a previously-defined Flexible Attribute for site_part
Run Time Path Types
The class CoreDataPath (amdocs.core.datapath.CoreDataPath) provides methods for reading and writing data using data paths.
A data path defines the location of a data item within a specified context object.
A path starts by identifying the context object, and consists of one or more path items, separated by colons (:), that lead to the required data item.
For example:
This defines a data path using a context object named Var, with path items Customer and Address that lead to the data item State.
The context object name is prefixed with a dollar sign ($).
Context objects are passed to the API using a java.util.Map with the context names as the keys. Paths that do not specify a context name use the default context passed to the API methods. The type of the context determines the mechanism by which the path items are evaluated.
The following context types are supported for all application frameworks:
With the exception of JDBC paths, the appropriate evaluation mechanism is used to evaluate each item.
Thus, in the example above, $Var might refer to a java.util.Map, that holds a simple value object keyed by “Customer”. The path might be evaluated by
JDBC paths use the reference path mechanism for switching between evaluation mechanisms – this is explained in more detail below.
Indirect Paths
An indirect path is a path that defines a (String) data item that contains a path. Indirect paths start with a dollar, and must also specify a context name (the default cannot be inferred). Thus indirect paths start with “$$”.
For example, suppose a JDOM element contained the following structure:
The path $Elem:State will evaluate to the string “$Var:Customer:Address:State“.
The path $$Elem:State will evaluate to the actual state.
JDBC Paths Contexts
The jdbcDatapath use JDBC mechanism to access external databases.
This includes paths with focus object as context as well as absolute paths (JDBC contexts). Context name is used to resolve a Context object at runtime.
The context type JdbcFocusObject ( amdocs.core.JdbcFocusObject) can identify JDBC data.
JDBC Path Data Sources
JDBC database is configured as a SAM (Server Action Manager) resource and is identified by a resource name defined in ASC.
The exact ASC node is /AmdocsCommon/Aif/Connections/SamConnection.
Two types of JDBC data sources are used.
- LocalJdbc data sources use inproc JDBC API and the database driver is located on the same machine.
- ContainerManaged JDBC data sources have the drivers located on different server and have the benefits of connection pooling, J2EE transactions etc. Amdocs CRM support both Local and Container Managed JDBC data sources.
The jdbcDatapath is using JDBC mechanism to access external databases. This includes paths with focus object as context as well as absolute paths (Jdbc contexts).
Context name is used to resolve a Context object at runtime.
JdbcFocusObject
To identify a record in a database, JdbcFocusObject should be provided with the following parameters:
- Server Action Manager (SAM)
- Resource name,
- Table name
- Table-filter.
Comments
- If the table name is empty or null then the path is considered to be absolute data path.
- If table name and table-filter are given, then the path is a relative path starting with the row identified by table-filter.
- The method JdbcFocusObject.isAbsPath() indicates that the path is absolute (a TRUE value).
If it returns FALSE it indicates that the paths is relative.
Amdocs / Clarify CRM databases have rich metadata for relations and prop-names. This simplifies datapath string specification.
For JDBC databases, metadata for relations and prop-names are defined in the Amdocs System Configurtion files (Prior to release 7.5 it used to be provided in an external JdbcSchema.xml file).
The metadata is optional. The syntax allows relation information to be specified in-place. If metadata is provided then a logical relation name can be given in the path.
At runtime, datapath evaluats the relation name to physical relation information. For pre 7.5 releases JdbcSchema.xml must exist in same directory as ClarifyEnv.xml.
JDBC Path Modifiers
In addition to the basic syntax, path relations can have modifiers, specified using round brackets (and) after the relation. The modifiers serve 2 purposes:
A. Restricting a path or a portion of the path to a unique result.
For example, consider the following path that traverses from an employee, to the publisher for its address:
Since it is possible that two different employees named John Smith will be in more than one publisher, this path might return several addresses. The path can be modified as follows:
The publisher name is unique for each publisher, this path selects a single item. The SQL for this would be:
B. Resolving the starting point for an absolute path.
For example:
Relation Traversal
RelationInfo is a path syntax element that defines how multiple tables are traversed. Each token specifies either the physical relation info used for joins or a logical relation name. If a logical relation name is given then the Context object provides an API to resolve this to physical relation info.
Inner joins are used to traverse tables. The inner join is evaluation as follows:
- First token is field list from previous table.
- Second token is current table name
- Third token is field list belonging to current table
These 3 tokens are separated by two forward slash characters
Fields within a field list are separated by plus character. Typically the join includes one field from each table. But it is possible to have multi part join keys.
An optional filter can be added. The filter applies to current table.
Examples
Path:
Refers to id_number field on the Case object (Database path)
Path with relation:
Refers to the handset field on the attrition object, related by the age and city of the customer (assume that the focus table object holds the table customer with the filter name = ‘John Smith’).
Absolute path:
Refers to the field price plan on the customer object, where the customer id is 91460.
Absolute path with relation
This path selects a single item, even though it is possible to have more than one person named John Smith (since publisher name is unique for each employee).
JDBC Reference Paths
A reference path combines two paths into a single item.
- The first half of path can defines a JDBC focus object context
- The second half defines a path from that JDBC focus object.
The reference operator ‘->’ separates the two components of the path.
The reference operator (->) conforms to the following rules:
- Left hand side path of context operator must be non-database path and right hand side path must be Jdbc focus object based database path with no context name.
- Left hand side path of context operator must resolve to JdbcFocusObject to be used as context object for JDBC database path on right hand side of context operator.
Reference path example:
Specifies equip_id field of user object. Jdbc object is specified by Hash map path
The Context name Var must resolve to valid context object instance at run time.
Using Path in Configuration Settings
JdbcSchema
Schema information for relations and prop-names are now defined in ASC (Amdocs System Configuration) under the Path
/amdocsCommon/amdocsCore/Core/DataPath/Jdbc/Schemas
JDBC Resources
The following two resource types are supported by Server Action Manager (SAM) for JDBC:
- LocalJdbc
- ContainerManagedJdbc.
The configurations for these resource types are located in the ASC (Amdocs System Configuration) under the path
/amdocsCommon/amdocsCore/Core/DataPath/Jdbc/Resources
More on JDBC Data Pathes
JDBC paths enable data items to be accessed from a JDBC database. There are two types of path;
relative and absolute.
To explain these paths, consider this simple database schema:
The database defines books, their authors and organizations that deal with them.
The role of the organization is one of “publisher”, “retailer” and so on.
Relative Paths
A relative path is used when the context object is a JdbcFocusObject.
The context object identifies a row in a database table – the path specifies how to get data starting from that row.
The simplest relative path consists of the context name, followed by a column name.
For example:
A JDBC focus object might define a row in the book table. The book’s title is defined by:
Joins are specified using a relation specification. The syntax of a relation is:
For example, the author of the book is defined by:
Note the relation from table Books to table Author: auth_id/author/id
If a join is through a one-to-many relation, a filter may be added to a relation to specify a unique row.
The syntax of a filter is:
For example, the publisher of the book is defined by:
If a join condition requires concatenated keys, the concatenation is made using the plus sign (+).
The syntax is
The join condition is constructed like this:
Multi-part keys are specified using multiple plus signs.
Absolute paths
An absolute path is not used with a JdbcFocusObject.
Instead, the context name must be one of the JDBC data source names defined in ASC (Amdocs System Configurator) repository by the Core/JDBC/DataSources node.
The starting point of the path is a database. The first path item specifies a table name.
Suppose that the above database was defined as BooksDb. The path
returns an array of JdbcFocusObject with an entry for each book in the table.
Absolute paths are typically used with a filter. Thus, the author of “Lord of the Rings” is defined by:
Logical Schema
JDBC paths can be simplified by defining a logical schema in the ASC (Amdocs System Configuration) repository by the Core/JDBC/Schema node. The schema defines relation names and property names.
A relation name associates a name to a join condition, for example book2author can be defined for the book table as auth_id/author/id. This enables the author of a book to be defined by:
A property name defines an entire path.
For example the property publisher can be defined for the book table as :
This enables the publisher of a book to be defined by:
Note that an exclamation mark is used to introduce a property.
If a property name contains invalid characters (spaces or colons for example) it must be enclosed in double quotes.
For example:
Reference Paths
A reference path consists of two parts, separated by ->.
- The first part of the path may use any context type, and must resolve to a JdbcFocusObject.
- The second part of the path is a JDBC path.
For example:
If $Var refers to a Map, then theMap.get(“BookRow”) contains a JdbcFocusObject defining a row in the book table. The above path will return its author.
HTTP Servlet Request Attributes
An attribute can be extracted from the Servlet request using an @ in front of the path item.
For example:
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 name of the item.
The java object’s class must implement either amdocs.core.datapath.INamedCollection or
amdocs.core.datapath.INamedCollectionExt or extend amdocs.core.datapath.NamedCollectionExt.
An example data path is as follows:
The $Dataset context type, represented by a java object which is an INamedCollection, contains a collection that can be accessed by getDataModelByName(“myDataModel”).
Next: Using Expressions (Part 3)
Data Paths and Expressions (Part 1)
About DataPath
A DataPath is a mechanism for defining data stored in a database (Amdocs CRM database or external database) or application memory structure such as Smart Client.
Paths identify data items related to a focus object
Data path may describe a database field, XML Node, HttpServletRequest, BO, LoadBean, any POJO (Plain Old Java Object) or run-time data structure such as Java Map, Xdo or Cdo. The data path is defined relative to a known starting point known as the context object known also as Focus Object.
Path Definition
A Path consists of a series of relations terminated by a field. A colon (:) is used to separate the relations and the final field. A path that is just a field identifies a field on the focus object
Path Context
A context refers to the source of data where the data path originates. For example, in the path given below, the context is a focus object given by $Case:
$case:case_reporter2site:cust_primaddr2address:address
The contexts are of two types:
- Fixed context – these are global and not runtime dependent.
- Run time context – names that must resolve at run time to context object instance.
Data Path Fixed Contexts
Data Path Run Time Contexts
Focus Object
The focus objects is not explicitly part of the path but is determined by context. For example: the focus object for a Case query is Case, for a Subcase query it is subcase, for a Smart Client form it is a reference to a specific form.
Path Examples:
- Last name of contact for subcase
subcase2case:case_reporter2contact:last_name
The path starts at a beginning point (Subcase), traverses through the database, and locates the object at the end (contact’s last name)
- Site Id of the currently logged-in Smart Client user:
Dataset:DataModel:emplUserDM:p_site_id
The path starts at a beginning point (global form named CrmGlobal), traverses through the form’s Dataset, the data model emplUserDM and locates the object at the end (site_id)
The run-time beginning point defined as:
$WorkspaceForm:com.nextgen.crm.workspace.CrmGlobal:
Where are Paths used in CRM?
Paths and Expressions are widely used both at servers and clients across the CRM environment and its complementary peripheral applications such as Smart Client and Process Manager.
The following list and example demonstrate the most notable areas where paths and their derivate expressions are used:
- Database Queries
- Business rule properties
- Auto-destination rules
- Smart Client form elements
- Smart Client version selectors
- Role-based Authorization
- Pre-filters for selection
- Routing rules
- Extended Filters
- Output parameters of Services
- Define where the results should be stored
- Used within expressions (will be elaborated)
Usage Examples
- Database Queries
The following example use path to define the CBO relatedFilter property
- Business rule properties and recipient aliases – prop_name object
The following example shows the definition of a property named ‘Originator’ related to the a Case focus object. The focus object named here ‘Object Type’:
- Auto-destination rules – rule object
The following example shows a path used within an Auto Destination Rule. The implicit focus object here is the Case object. The Case focus object is explicitly defined in table_rule.title field.
- Smart Client form elements: Forms, Actions, Data Models, Communications
The following example shows path used in Smart Client Action’s Request Map definition:
- Smart Client version selectors
This example shows the use of a path within a condition expression defined for selecting the form version to be displayed. The focus object is $WorkspaceForm.
- Role-based Authorization
Path used as part of an expression which defines conditional authorization role. The focus object is $Var.
- Pre-filters for selection
The focus object in this example is the table ‘con_bus_role’.
The path filter a role related to specific address identified by a Vo primary key (objid) passed from the client.
- Routing rules
The following example shows a path used within a routing rule. The focus object (called here ‘source type’) is a Case.
- Extended Filters (XFilters)
The following example shows a path used within an extended filter to describe named properties (called here ‘friendly name) which define business entities by their absolute path from the focus object – a view named opp_view_xfilter.
- Used within expressions
See also Version Selector, Conditional Role Base Authorization, pre-filter and Routing-Rule examples.
See next part: Database Path Contexts (Part 2)
Contact Resolution Management
Numerous managers have gotten “First Call Resolution Forever” and/or “Done in One” tattooed on their necks.
The majority of conversations about FCR center around two things:
- The huge potential impact of First Call Resolution (on operational costs, customer satisfaction and agent satisfaction / retention);
- How to measure this mega-metric accurately
See the original full discussion in Greg Levin’s Rev Up Your FCR Rate.
In his article, Greg discusses the following list of tactics to increase First Call Resolution efficiently:
- Excellent agent training and tools
- World-class workforce management processes
- No conflicting performance objectives
- Incentives around FCR goal achievement
- Agents empowered to improve FCR-related processes
Amdocs Customer Interaction Manager (CIM) provides an excellent platform for achieving these goals.
Contact Management
Contact management (or CIM – Customer Interaction Manager in Amdocs terminology) refers to a unified desktop application that enables customer facing agent (or CSRs -Customer Service Representatives) to effectively manage media exchanges with their customers.
The user interface is context-driven, and provides agents with immediate access to all relevant information to assist them end up the interaction in timely manner while having satisfied customers.
Relevant information refers to customer information (personal and / or organizational), interaction history (previous contacts) and service history (previous case handling), products and subscribed services, usage of services, service level agreement(s), likes, habits, social behavior, billing information etc.
Customer Interaction Manager combines with Multimedia Integrator to provide a multimedia interface for variety of communication channels such as interactive voice response (IVR), computer telephony interface (CTI), email, and smartphones applications (not provided with core product – requires customization). The Multimedia Integrator displays an application toolbar that agents can use to efficiently manage inbound and outbound voice, and other media exchanges.
Contact Management Concepts
The contact management, focused on the interaction paradigm, is based on the following key Concepts:
Interaction
Interaction is defined as an exchange of information between a single customer and the agent (or CSR – Customer Service Representative), using one or more channels. The interaction provides a full view of the customer data.
Unified Desktop:
The desktop UI seamlessly provides one front end used by customer facing agents (front of house) which is shared among several applications, covering variety of domains such as CRM, Billing, Ordering, Product Catalogue, Installed Repository Management, and Social Behavior Analysis.
Increased Efficiency:
The shared front end desktop provides an immediate access to any required information during customer interaction. Immediate information access is achieved by minimized key strokes, reduced eye and mouse movement and focus on actionable data. These facilities allow agents to focus on customer service and quickly address raided issues.
Toolboxes:
Common persistent desktop areas which keep important information always available and enable easier navigation.
Contact Management Components
Find Caller
The Find Caller module is used to help the agent quickly identify the source of an incoming call and effectively link it with the relevant contact, service and product.
Depending on the context of the exchange, the agent can seamlessly employ, within the shared desktop, variety of complementary backend services to assist them quickly complete the interaction.
The Find Caller performs different database queries according to the context of the interaction. If the Multimedia Integrator is enabled, it automatically launches the Find Caller feature for inbound calls. If this application is not enabled, the agent can enter contact details and activate the search manually.
A manual search can also be used for outbound calls, for example when used in conjunction with a predictive dialing application.
Find Caller functions in Contact Manager in the same way as in other CRM Smart Client applications, and posts the Search: Contact and Account window as the default search option.
When a valid Billing Manager Client license is installed, Find Caller provides extended search functions for billing, subscription and mobile phone information.
- Each CRM Smart Client application that deploys Find Caller uses its own server side search (i.e. Worker Bean) to launch the function. For Amdocs Customer Interaction Manager, the generic Find Caller worker bean FindCallerWB is extended by the application-specific worker bean FindCallerCIMWB.
- Multiple applications can launch their special version of the Find Caller form. For example, Billing Manager, FindCallerWB is extended (by the Billing Manager worker bean FindCallerBMWB) to load its Find Caller version.
The following UI forms are commonly used by the contact manager module:
- FindCallerToolbar. Displays the current contact and account information on the application bar.
- FindCallerCimSearch. Contains the UI controls used for extended searches.
Find Caller Search Criteria
As discussed above, the Find Caller module provides two core search types:
- Customer Interaction Manager Search
- Billing Search
Each search type has two presentations, one for basic searches and one for extended searches.
The default Customer Interaction Manager search form contains the following search fields:
- Phone
- Account ID
- First Name
- Last Name
- Account Name
- Customer ID
- Customer Alias
- Alternate Contact Method
- Mobile
- Serial Number
- Billing Arrangement ID
- Financial Arrangement ID
Automatic Find Caller
When the Multimedia Integrator is enabled, Find Caller is conducted automatically for incoming calls, and populates mobile phone number and subscription fields accordingly, when the details exist in the database.
Anonymous Caller
Anonymous Caller is a caller who cannot be identified.
In the case where the initial Find Caller search does not find contact details in the database, Customer Interaction Manager allows the agent to assign the caller as Anonymous Caller. Details are then set to anonymous data and the agent enters new information for this caller.
Reason Codes
Reason codes refer to a three level hierarchical attributes structure which systematically describe the reason for the call and resulted action. These attributes can be later used for BI analysis.
Reason codes drive downstream processes and can launch relevant activities if necessary
Few reason codes examples are:
Visually, above reason codes are implemented as drop down lists, as shown in the following pictures:
Reason Codes Selection Flow
The Reason1, Reason2, and Result drop-down menus are formed by a hierarchical, user defined pop-up list (UDPL). When an CSR selects a Reason 1 topic, the application updates the list in the Reason 2 drop-down menu. The CSR can then select a Reason 2 topic that is specific to requirements.
In addition to the predefined lists of reason codes provided with the application, customized combinations of reason codes can be customized to implement any specific business logic requirements.
Topics
A topic represents set of reason codes, their result action and a possible linked object. An interaction may have one or multiple issues raised from one customer enquiry. Each issue represented by a topic. A Topic comprised of two reason codes and a result action code. Topic Tracks the issue(s) for the interaction.
Context Manager
An important part of the contact management is the Context Manager. The context manager allows handling several open interactions concurrently by providing the agent the ability for quick context switching between callers while they are on the line.
Interaction context gathers all information presented to the agent during the course of an interaction. Context switching refers to the ability to serve several calls simultaneously while keeping their complete interaction information immediately available by merely selecting the caller name.
The instant context switching (less than 1 sec) is technically achieved by caching all information in memory once it is retrieved from its persistent storage.
In the following pictures, the following two contexts are displayed:
Visually, above contexts are implemented in the UI as follows:
Context 1
Context 2
Action
Action specifies a result activity which is part of a topic. An action can be a single, short-duration activity, presenting a form, creation of a workflow object for a long duration handling process, or a complex business process which may drive one or more workflow objects.
Workflow Objects
Known also as workflow tasks, these objects represent continues task which may involve more than one owner during their life time. A workflow object represents any type of long duration task. Example for long duration tasks could be service assurance issues (cases), scheduled activities (Action Item), Change process (Change Request), Opportunity, Sales Quotation (Quote), Order, etc.
A workflow object has a lifecycle, starting from its creation until it is closed. At any point of time a workflow object is owned by single owner. Ownership can be transferred between owners via intermediate parking lots named Queues.
Ownership is transferred only by mutual handshake process known as ‘Dispatch – Accept’.
A workflow object has several attributes which are continuously updated either explicitly or implicitly to reflect its handling position. The most notably attributes are ‘Condition’ and ‘Status’.
Only owners are allowed to change the workflow object’s status. Status changes must follow specific rules known as ‘Status Transition Map’. This map comprised of pre-defined set of rules which specify, for each status, one or more allowed target status values and the allowed role to perform the change.
Contact Management Implementation
Contact Management (or Customer Interaction Manager) UI is implemented using Amdocs Smart Client, a rich client architecture which provides flexibility of a Web application. Smart Client applications are deployed over the web and require minimal client-side installation. The front end UI is automatically updated without user intervention while providing the look and feel of a native desktop application.
Contact Manager UI provides the agent with the following operational areas:
- Find Caller form
- Interaction Home
- Customer Overview toolbar
- Multimedia Integrator toolbar
- Interaction toolbox
Contact Management Events
The Interaction Home page has Quick Action buttons for the several predefined events, such as Case, Action item, Literature request, Sales Opportunity, Sales Quote, Order, Pending credit and Promotion
The standard CIM implementation provides a number of predefined events.
- The agent can trigger these events either by selecting a combination of reason codes or by clicking a Quick Action button on the Interaction Homepage.
- Each Quick Action button (or reason code combination) uses a Launch Action function to launch the following sequence of events:
- It may launch an application form (I.e. CRM or Ordering applications)
- It may launch an automation process (backend driven or UI driven)
- It retrieves attributes from the Context Manager and passes them either to the launched form or process.
This technique can be used to launch any window from any Amdocs CRM application in the interaction flow.
Implementing an Event with Reason Codes
Customization can add more functionality to the application or can tailor the application to meet any specific needs. Some commonly customized items include the following:
- Launch actions
- Launch wizard scripts
- Interaction Home form
- Toolbars
- Toolboxes
Interaction Management Process
Process Design Questionnaire
- Who do your call center agents interact with?
- Customers only? Dealers? Partners?
- What types of interactions are received / sent out?
- What is the structure of the call center?
- What is the number of Agents?
- Will these users be divided into functional groups?
- Will users have access to some forms/commands/data and not others?
- Number of Call centers?
- Where are they located?
- How many agents are there at each location?
- What is the number of interactions handled per agent per day?
- How do you measure your call center agents?
Generic Interaction Management Process – part 1
Generic Interaction Management Process – part 2
Generic Interaction Management Process – part 3
Generic Interaction Management Process – part 4
Generic Interaction Management Process – part 5
Sample Implementation Decisions
Implementing Asynchronous UI
When designing an application front end UI, it is always highly desirable to provide friendly, intuitive and pleasant user experience while they are interacting with our application.
One of the most annoying phenomena happens when the UI seems to be freezed while waiting for a lengthy task to complete.
In order to enhance user experience and avoid possible frustration, it is recommended to provide an interactive visual feedback which continuously updates the human user about the current status of the task, while allowing them to continue free interaction their UI.
In the following example I shall demonstrate how to divert a task to a separate thread and allow the user to continue interacting with the UI for other tasks. I shall also show how two independent front end tasks can interact one with each other without interfering UI operations.
Read the full story on Implementing Asynchronous UI
Migrating Amdocs CRM Classic to Smart Client (part 2)
When considering migration of legacy Amdocs Classic client implementation to Smart Client technology, it is important to understand several aspect which might impact such migration.
The first part of this discussion we discussed the business and technical drivers for migration from Amdocs Classic to Smart Client technology . We discussed the preliminary information needed for migration assessment, as well as the required resources for such assessment.
This part further describes the following migration assessment and implementation aspects:
- Migration Assessment Planning
- Migration Project Planning
- Phasing
- Migration Techniques
Read more at Migrating Amdocs CRM Classic to Smart Client (Part 2)
About
Welcome to NextGen Consulting.
We provide IT consulting services to organizations that use either Microsoft Dynamics 365 or Amdocs CRM (or legacy Clarify) platforms.
Having over 17 years with full life cycle of CRM projects (Dynamics 365 / Power Apps, Amdocs CRM / Clarify), broad enterprise and telecom industry knowledge, in-depth experience with OSS / BSS, CRM, Service Assurance, Marketing and Sales business processes, we offer flexible variety of services aimed at both the telecom and the enterprise organizations such as:
- Provide complete turn-key solutions ( Amdocs Smart, Thin, Classic clients, Microsoft Dynamics CRM)
- Subcontract Design and development
- High level business design and documentation
- Detailed level technical design and documentation
- Develop design to a deliverable solution using agile methodologies
- Improve user experience (UI design and implementation)
- Design and Development Management
- Create user workshops for business analysis and requirements gathering
- Provide training for developers and business users
- Design complete solution architecture
- Inspect external provider deliverables
Our people have hands-on implementation expertise with implementing various business processes using rich selection of front end technologies such as Microsoft Dynamics CRM and Amdocs CRM (Smart Client, thin client, and Clarify Classic Client).
We can use this expertise to help your organization migrate existing legacy application to a newer platform, or simply provide any level of design (high level, low-level) and implementation to fit your organization needs.
Join our LinkedIn Smart Client Group to get immediate updates and share your ideas, needs and comments.
See more on Yuval Rashelbach.
For further information view profile at http://il.linkedin.com/in/yuvalr
or contact Yuval Rashelbach at yuval.rashelbach@nextgencon.com
NextGen Consulting 