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
- Go back (a process step)
- Get log details
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
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
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.
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.
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”
Calling the below API on the liteProcInst gets the log details.
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).
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
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:
The $Dataset context type contains a collection that can be accessed by:
The followings Smart Client runtime elements are implemented as Named Collections:
The following path resolves to a Grid column control in the current Form using Named Collection:
- 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.
The following path resolves to a logical form called com.nextgen.GlobalUtils:
- 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
An expression is a single Boolean or arithmetic expression that can be evaluated by a special expression evaluation class. The operands in an expression are literals (numbers and strings), paths or functions.
An expression string is analogous to an Excel formula. It encapsules logic, data access, calculations etc
sub-expressions mechanism allows an expression to be defined once with a known name, and then re-used in other expressions.
$Focus:site2contact_role(primary_site=1):role_name = ‘Employee’
dateAdd(‘d’, $Focus:required_date, 3)
If ($Var:Churn = ‘High’) then ‘Gold’ else ‘Silver’
Expressions are a generalisation of the path concept that has always been in Clarify. There are several places in the application where a Boolean expression is stored in the database in three fields – path, operator and value. Expressions are stored as a single text field, containing the expression. All string comparisons are case insensitive.
Expression use ‘contexts’ to read and write data. Its syntax includes functions, operators, operands, logical tests and literals. They can be created dynamically at runtime.
Where Expressions are Used
- Extensively used by Amdocs Process Manager
- Input parameters for Services (Process Manager and Rule Manager)
- Order Management Standard Edition Eligibility rules
- Role Based Authorization
- Flexible Attributes Templates
How Expressions are Used inby APM
- Most places in APM that expose properties that are used directly at runtime
- Operation inputs / outputs
- Pre and post data assignment
- Conditional junctions
- Dynamic subprocess
- Dynamic service
Why Use Expressions?
Expressions encapsulate business logic easily without implementing complex processes. The processes become easier to build, manage, understand and maintain.
Expressions provide improved runtime performance and ease of monitoring
Expressions overcome various Process Manager constraints. Business processes become easier to build, manage, understand and maintain by reducing need to extend code or datamodel.
Expression allow using user-friendly naming, easier implementation and testing
Expressions combine operands which take the form of paths, literals or other expressions.
The following describes an expression. Uppercase and quoted elements are lexical constants.
Keywords are case-sensitive:
not ($Var:Score > 0)
5 * ($Focus:score + 1)
The values for OP are supported, shown in order of precedence:
- Strings are delimited by single quotes
- String Concatenation ( + )
- Escape ( \ ) characters: Newline ( \n ), Return ( \r ), Tab ( \t ), Single quote ( \’ )
- Constants: Boolean true ( true ), Boolean false ( false ), Null ( null )
if ($Var:CaseType contains 'Sales')
The values for UNARY are ‘-‘ and ‘NOT’.
Unary has a higher precedence than OP.
any(<Collection-Path>, ‘$IterativeContextName’, exp) every(<Collection-Path>, ‘$IterativeContextName’, exp)
Takes a Collection-path which returns an array of objects (i.e com.clarify.webframework.CdoCol), iterates through each element from the array and assigning the element from the array to the context named $IterativeContextName.
Then it evaluates the expression which may contain a DataPath with a context name of $IterativeContextName.
The any function iterates over the row, access a value from each row and evaluates the value against some rule specified in the any function. As soon as a row from the table whose values cause the rule to evaluate to true, any function will return immediately with a true.
The every function is the opposite of any function. As soon as a row from the table whose values cause the rule to evaluate to non-true, every function will return immediately with a false.
The countWhere function iterates through each element in the Collection and for each element, applies the element from the context to the Expression and increments the total count value by 1 if the Expression evaluates to a boolean true, else no increment. The result from countWhere is an Integer object.
any, countWhere and every take a Collection-path which returns an array of objects or a com.clarify.webframework.CdoCol, iterates through each element from the array and assigning the element from the array to the context named $IterativeContextName. Then it evaluates the expression which may contain a DataPath with a context name of $IterativeContextName. Multiple any/every functions are allowed in a single expression.
any and every returns a Boolean object
countWhere returns a Integer object.
If the Collection-path returns a CdoCol, then to address the individual Cdo within the expression, the Path must be prefixed as follows:
If the Collection-Path expression returns null or unknown is set as a result of evaluating the expression, then unknown will be set to true and a Boolean false with be returned.
The following rules determine the return value for any function:
The following rules determine the return value for every function:
any($Focus:case2subcase, ‘$subcase’, $subcase:status2gbst_elm = ‘Open’)
count( exp )
Takes an expression returning a row set, and returns the count of rows.
Returns number of defined flexible attributes based on flags value.
Please see bellow for more details.
countWhere(<Collection-Path>, ‘IterativeContextName’, exp)
Iterates through each element in the Collection and for each element, applies the element from the context to the Expression and increments the total count value by 1 if the Expression evaluates to a boolean true, else no increment.
Returns the current date/time, using Session.getCurrentDate().
dateAdd( units, date, interval )
Add a number of units to a Calendar. Default is seconds
Interval: y (years), m (months), d (days), h (hours), n (minutes), s (seconds)
dateAdd(‘d’, currentDate(), 3)
dateDiff( units, startdate, enddate )
Subtract two dates, returning a signed number of units, default is seconds.
isNumber( exp )
Returns true if the expression is numeric according to Session.fromString(cboTypeDecimal)
Returns true if the expression is null
isUnknown( exp )
Returns true if the expression is unknown (see below)
toNumber( exp )
Convert the expression to a number – expression should be a string or a number.
toDate( exp )
Convert the expression to a Calendar.
Expression should be a string or a date. Uses Session.fromString(cbotypeDateTime)
toJavaDate( exp )
Convert the expression to a Date. Expression should be a string or a Calendar. Similar to toDate but returns value as a Date.
toDisplayString(exp1, exp2, exp3)
Converts the expression (exp1) to a localized string. Exp2 and exp3 are optional parameters.
If the object type for exp1 are: GregorianCalendar or Date Java class, then Session.toDateString is called.
Exp2 will be PictureString parameter. If Exp3 is specified, then it will be the MaskString parameter.
If the object type for exp1 is Money object, then Session.toCurrencyString is called.
If the object type for exp1 are BigDecimal, Float, Integer or Double, then Session.toNumberString is called.
Otherwise, the default toString() is returned
Convert arbitrary strings to Focus Object.
toFocusObject function can be used to convert arbitrary strings to Focus Object for passing to services.
Exp1: can be either a database Object Name or an expression. If it is expression then it should be given in such a way that the evaluated result value of this parameter should resolve to a DB Object Name.
Exp2: can be either a DB Objid or an expression. If it is an expression then it should be given in such a way that the evaluated result value of this parameter should resolve to an Objid of the row in the corresponding table.
toFocusObject function takes 2 parameters. These parameters can be either expressions or they may be just a table name and Objid. If the parameters are expressions then it will evaluate these expressions and constructs a new Focus Object based on the evaluated values of the input parameters.
Input expressions should be evaluated to the proper table name and corresponding Objid of the row. The return value of this function will be a FocusObject of type com.clarify.sam.FocusObjectImpl. It returns null if there is any exception.
A: toFocusObject ('user', $case:case_wip2wipbin:wipbin_owner2user:objid)
The above expression returns a focus object of type “user”
B: toFocusObject ('con’ + ’tact', $case:case_reporter2contact:objid)
The above expression returns a focus object of type “contact”
If we know the Objid of the focus object then we can also specify toFocusObject function like below:
C: toFocusObject ('contact', ‘268435501’)
The above expression returns a focus object of type “contact” which will have the table name as ‘contact’ and Objid as ‘268435501’
Site which has an objid from CDO / XVO
D: toFocusObject(‘site’, $Cdo:myCdoVariable:siteObjid)
CDO to XVO type conversion is already supported, so a real bona-fide site CDO could be passed
where an XVO parameter is needed.
toString( exp )
Convert an expression to a string. Uses Session.toString.
toInteger( exp )
Take the integer result of an expression, discarding the fractional part.
The intervals for date calculations are one of the following:
y (years), m (months), d(days), h (hours), n(minutes), s (seconds = default)
Constants are defined as numeric, or string.
- All numeric constants must be represented in locale independent format.
- All string literal must be represented in locale independent format.
- String must be delimited single quotes (‘’). The following escape sequences may be embedded inside a string: \n \r \t \’
- #<nmToken> is identified as string literal whose value will be looked up in table_string_db in current locale using <nmToken>. Exception are thrown if lookup is failed.
- true is used to represent Boolean true value
- false is used to represent Boolean false value
- null is the null value
Experssion returns Java null in the following conditions:
If <operand1> then < operand2> else < operand3>
- operand1 is not a Boolean class
- operand1 is a Boolean class and operand2 or operand3 is a null< operand1> AddOp < operand2>
< operand1> MultOp < operand2>
- operand1 is null and operator is Mul/Div/Mod.
- operand1 is null and operator is Add/Sub and operand2 is null
- operand1 is not null and operand2 is null and operator is Add/Sub/Div/Mod
- operand1 is not null and operand2 is null and operator is Mul
Unary < operand >
Operand is NULL
Named Expression evaluates to NULL
Constant is a Null Literal
A CboError from DataPath or DataPath returns a null as a value
There are some circumstances where a path cannot be evaluated. In these cases, the result of the expression is not known. For certain cases, it may be possible to default a value (for example Process Manager returns the first row when multiple rows are returned when a single row is expected).
- A single row is called for, but multiple rows are returned. For example, a path traverses a one-to-many relation with no qualifier, and is not used in a Count() function. The first value returned by the database read is returned – the value is known
- No database row is returned - A relation is not set (Data path returns null value)
- The field or item is not defined - A path tries to access a field (e.g. in a CDO or CBO), property or attribute that is not defined.
- Flexible attribute not defined - The path refers to a flexible attribute that does not exist
- DataPath returns null value - A data path that returns a null value is also considered an unknown value
When a path cannot be resolved, it will have the value unknown. Any expression involving an unknown value becomes unknown. Unknown is returned from the expression evaluator.
The followings list the exception type and conditions under which exceptions will be thrown by Expr.
Using Expressions – Examples
- The Collection-Path is a hashmap that points to an array of hashmap. ‘Tables’ is a key in the contextMap and the value of ‘Tables’ points to a HashMap called Tables.The TablesHashMap has a key called ‘Products’ whose the value is an array of hashmap.
The following illustrates an example on how to setup the contextMap properly:
The context “Tables” from above is setup similar to a database table as follows:
- The collection-path is a hashmapthat points to an array of Focus objects. ‘NewCases’ is a key in the ‘Row’ hashmap and the value of ‘NewCases’ is an array of Focus objects which points to a case object.The following illustrates an example on how to setup the contextMap properly:
- The collection-path is a rowset path that returns an array of Focus objects (which points to a site schema type).
$Focus is set to a case object.
- The collection-path, $CdoCases:openCases, returns a CdoCol which constains a collection of Cdo objects. $CdoCases is set to a CdoManager in the contextMap.
The following illustrates an example on how to setup the contextMap properly:
- The example illustrates how to use countWhere. Using the context “Tables” from example1, the following countWhere expressions returns:
countFlex Syntax: countFlex(Path [, eflags [, enumType])
Path is a DataPath that returns a valid focus object (with valid DbObjectName and objid). If an array of focus objects are return, countFlex returns the count for the first element from the array.
If Path is the only parameter specified, then it returns the number of defined flexible attributes.
eflags is an optional parameter, if specified, returns the number of defined flexible attributes whose flexible definition flags value matches (bitwise) with eflags. eflags can be any expression.
If eflags < 0, then eflags is ignored.
enumType is an optional parameter and have one of the following values:
If enumType is not one of the above values, then the set should be the defined flexible attributes set.
If enumType and eflags are defined and have valid values, then the flexible attributes set defined by enumType should be used to match against the eflags value.
If Path evaluates to a valid path and focus object returns a valid object, then a count value is returned, else a null is returned and Unknown is set to true.
The followings list the exception type and conditions under which exceptions will be thrown by Expr.
1) $Site points to a site Focus object.
countFlex returns the number of defined flexible attributes.
2) $Focus points to an order_action Focus object. countFlex returns the number of defined flexible attributes
with eflags bit 8 (External System) set.
3) The first element from the Focus array should be used to evalaute against the eflags value
(pre and post set). The flexible attribute set is restricted to attributes which have Data.
countFlex( $OpenCase:case_reporter2subcase, 3, cboConstants.cboFieldSetHasData )
In order to facilitate an easy to use end user interface, expressions are able to contain named-expressions, stored in the database.
A named-expression is denoted by a domain and a name.
Optional parameter(s) can be specified with named-expression. The domain is a logical grouping of named-expressions to enable different applications of the same name. Recursive Named Expression is not supported.
The syntax is:
Named expression is an expression that has been defined in the database. Use the CRM Administrator module to manage Named Expressions
- Domain – logical grouping
- Name – User-friendly name
- Expression – the actual expression itself
Named Expression Parameters
The Named Expressions parameters mechanism addresses the following:
- Use multiple parameters syntactically
- Support parameter type checking during Expr evaluation phase
- Support UI design time type validation for parameters
- Support UI design time retrieval of parameter list for a given Named Expression
Parameterized Named Expression Syntax
?domain.name( <ParamName> :=expression, ...)
<ParamName> is the parameter name.
Multiple parameterized Named Expressions are allowed inside a single expression, but all ParamName must be unique within the Named Expression. Parameter name/value pairs are mandatory.
For basic Java type (java.*), Expression do type checking and conversion to the type as defined in TABLE_EXPR.Type and throws an error if type checking or conversion fails.
For non basic Java types, Expression just do type checking.
The followings list the exception type and conditions under which the exception is thrown by Expr during the prepare phase:
Parameter Binding Variable Syntax
To facilitate binding the identifiers from the Named Expression to the actual expression text defined in table_expr.Expr, parameter binding variables are created.
The syntax for parameter binding variable is:
Database Schema Definition
Expression information is stored in table_expr as follows:
Parameter information is stored in table_expr_param as follows:
Optional Parameters in Named Expressions
This feature allows named expressions to contain optional parameters, which means if any parameter is not specified in the named expression, then default value of the parameter will be substituted in the missing parameter. If the default value cannot be converted to the expected data type then the result of the expression will be unknown.
While parsing the sub expression, if parser finds any parameter is missing then it tries to get the specified default parameter value from table EXPR_PARAM.default_value. If it finds any default value for the missing parameter then it substitutes the default value in the missing parameter. If the default value cannot be converted to the expected data type then the result of the expression will be unknown.
Suppose existing expression component handles named expression like:
Optional parameter feature allows the above expression to be specified in the following ways:
?morder.isHandset(Territory:=’EastCoast’, DeptId:=12 )
The above expression is same as the expression without optional parameter.
The above expression assumes the default value of parameter DeptId is specified in the database.
The above expression assumes the default value of parameter Territory is specified in the database.
The above expression assumes the default values of parameters Territory and DeptId is specified in the database.
Dynamic path modifiers, the Path modifier determined at runtime.
A value assigned to the $Var.
Assign ‘C123’ to $Var:SubCaseId
The $Var is used in the iteration
An expression that points to a path
Build the path:
- Set the process variable CasePath with the contents of Case title field.
- Case record is identified by the variable CaseObjid:
Assign ‘$Db:case(objid=’ + $Var:CaseObjid + ‘):title’ to $Var:CasePath
Use the path:
Caching iterative data path values inside array functions
Expr object contains an array of objects which hold cached data path values. Attempt to get data path value from cache, if not present, and then cache it. Incrementally cache data path array values as they are iterated over.
The cache is optimized — if data path values are not reused within the expression, then they are not cached. However it may not be possible to predetermine if data path values will be reused (e.g. reference path) so must cache it those cases.
Array functions like ‘any’ and ‘every’ are iterates over the row, access a value from each row and evaluates the value against some rule specified in the function. When it iterates over the row the condition (rule) may have an expression and expression may refer to the same data path more than once. In these cases currently, when each time it encounters the same data path in the condition it calls Datapath.readItem API to read the path value.
By caching the data path value once it read, then the next time when it sees the same data path in the condition (rule) then it will get the path value from the cache instead of calling Datapath.readItem API, so the performance of expression evaluation can be improved while handling array functions.
While evaluating array function, when it first time encounters a data path in the condition it gets the path value by calling Datapath.readItem API and stores data path value in cache. It uses the key as a combination of Collection-Path plus column name of IterativeContextName plus iteration row number.
For example, in the following example ‘every’ function iterates through each row and executes the rule. In this example data path $eachcase:title is refereed twice, so while executing each row first time it gets the path value by calling readItem API and stores it in the cache, then from the second time onwards for the same data path it gets the path value from cache.
every($Row:case, '$eachcase', ($eachcase:title = 'Test LAB') or ($eachcase:title+'-'+'LAB Test' = 'First case from thin client-LAB Test'))
Cache will be cleared once the expression is evaluated and its lifetime is only for the current expression.
Next Part: Using Paths and Expressions in Smart Client
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.
In addition to the basic syntax, path relations can have modifiers, specified using round brackets ( and ) after the relation.
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.
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.
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”
With case focus specifies to login name of case originator
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.
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.
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.
To identify a record in a database, JdbcFocusObject should be provided with the following parameters:
- Server Action Manager (SAM)
- Resource name,
- Table name
- 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.
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.
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’).
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
Schema information for relations and prop-names are now defined in ASC (Amdocs System Configuration) under the Path
The following two resource types are supported by Server Action Manager (SAM) for JDBC:
The configurations for these resource types are located in the ASC (Amdocs System Configuration) under the path
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.
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.
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.
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:
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.
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.
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.
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”).
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.
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
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:
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
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.
- Last name of contact for subcase
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:
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:
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)
- 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)
Q: How to enable/disable menu bar in workspace?
Is there any way to enable/disable menu bar in the workspace programmatically?
A: You can selectively enable / disable specific menus.
Use the following code to disable the entire menu bar.
You can also selectively display or hide each menu
( replace the setEnabled() with setVisible() )
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 (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 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.
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.
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.
Common persistent desktop areas which keep important information always available and enable easier navigation.
Contact Management Components
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:
- Account ID
- First Name
- Last Name
- Account Name
- Customer ID
- Customer Alias
- Alternate Contact Method
- 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 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 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.
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.
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:
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.
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
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
Amdocs Smart Client Framework (ASCF) provides a rich set of functionality to allow flexible and attractive UI.
It is often required to allow the user select an option from a context pop-up menu. The context pop-up menu should be displayed when the user right clicks the grid.
Unfortunately, as of Amdocs CRM release 7.5.2, this visual requirement is not directly supported.
Look at Implement Context Menu in Data Grid to learn how to add this functionality.
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
- Migration Techniques