Reblogged from NextGen Consulting:

• 
• 
• 
• 
• 
• 

Classic Client

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

Read more… 1,919 more words

Reblogged from NextGen Consulting:

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 

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

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

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

 

Request/Response Manager

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

Read more… 1,892 more words

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

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

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

Using CBO Environment

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

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

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

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

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

C:\CRM800\Apps\crmApps\bin_abs_crm_800\

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

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

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

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

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

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

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

machinerole=Server
dataaccesslocation=InProc
unicode_app=y

charsetconvert=n

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

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

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

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

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

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

Here are explanations for the most important parameters:

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

     Examples:

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

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

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

CRM Configuration in ASC 

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

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

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

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

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

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

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.

Expression examples:

$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
    
• Flows
     
• 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

Expression Syntax

Expressions combine operands which take the form of paths, literals or other expressions.

Examples:

$Focus:subcase2case:casereporter2contact:first_name

‘Billing Dispute’

?Sales.GetLeadTime

$Var:ContactObjid

The following describes an expression. Uppercase and quoted elements are lexical constants.
Keywords are case-sensitive:

Examples:

not ($Var:Score > 0)

5 * ($Focus:score + 1)

Binary operators

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 )
    

Examples:

if ($Var:CaseType contains 'Sales')

then

‘Sales Queue’

else

‘Support Queue’

Unary operators

The values for UNARY are ‘-‘ and ‘NOT’.

Unary has a higher precedence than OP.

Functions

ANY, EVERY

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.

Return value

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:

$IterativeContextName:CdoColName:<Path>

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 Functions

count( exp )

Takes an expression returning a row set, and returns the count of rows.

countFlex(exp)

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. 

Date Functions

currentDate()

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)

Example:

dateAdd(‘d’, currentDate(), 3)

dateDiff( units, startdate, enddate )

Subtract two dates, returning a signed number of units, default is seconds.

Test Functions

isNumber( exp )

Returns true if the expression is numeric according to Session.fromString(cboTypeDecimal)

isNull(exp)

Returns true if the expression is null

isUnknown( exp )

Returns true if the expression is unknown (see below)

Conversion Functions

toNumber( exp )

Convert the expression to a number – expression should be a string or a number.

Uses Session.fromString(cboTypeDecimal)

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

toFocusObject(exp1, exp2)

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.

Examples

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.

Date Intervals

The intervals for date calculations are one of the following:

y (years), m (months), d(days), h (hours), n(minutes), s (seconds = default)

Constants

Constants are defined as numeric, or string.

1. All numeric constants must be represented in locale independent format.
    
2. All string literal must be represented in locale independent format.
    
3. String must be delimited single quotes (‘’). The following escape sequences may be embedded inside a string:  \n \r \t  \’
    
4. #<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.
    
5. true is used to represent Boolean true value
    
6. false is used to represent Boolean false value
    
7. null is the null value
    

Null values

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

Named Expression evaluates to NULL

Constant

Constant is a Null Literal

DataPath Value

A CboError from DataPath or DataPath returns a null as a value

Unknown values

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

Examples

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

Exceptions

The followings list the exception type and conditions under which exceptions will be thrown by Expr.

Using Expressions – Examples

1. 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:
     
   
       
       
2. 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:
         
   
     
        
            
3. 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.
           
   
         
     
              
4. 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:
       
   
       
        
5. 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.

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

Examples:

1)    $Site points to a site Focus object. 

countFlex returns the number of defined flexible attributes.

countFlex($Site)

2)    $Focus points to an order_action Focus object. countFlex returns the number of defined flexible attributes
        with eflags bit 8 (External System) set.

countFlex($Focus, 08)

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 )
 

Named Expressions

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:

? domain.name(<ParamName>:=expression,...)

Named expression is an expression that has been defined in the database. Use the CRM Administrator module to manage Named Expressions

 Syntax:

?[Domain].[Name]

• Domain        – logical grouping
• Name           – User-friendly name
• Expression   – the actual expression itself

Example:

?Sales.TaskDueDate

Named Expression Parameters

Overview

The Named Expressions parameters mechanism addresses the following:

1. Use multiple parameters syntactically
      
2. Support parameter type checking during Expr evaluation phase
        
3. Support UI design time type validation for parameters
      
4. 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:

$Param: ParamName

Database Schema Definition

Expression information is stored in table_expr as follows:

TABLE_EXPR

Parameter information is stored in table_expr_param as follows:

TABLE_EXPR_PARAM

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:

?morder.isHandset(Territory:=’EastCoast’, DeptId:=12)

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.

?morder.isHandset(Territory:=’EastCoast’)

The above expression assumes the default value of parameter DeptId is specified in the database.

?morder.isHandset(DeptId:=12)

The above expression assumes the default value of parameter Territory is specified in the database.

?morder.isHandset

The above expression assumes the default values of parameters Territory and DeptId is specified in the database.

Dynamic Expressions

Dynamic path modifiers,  the Path modifier determined at runtime.

Usage:

A value assigned to the $Var.

Assign ‘C123’ to $Var:SubCaseId

 

The $Var is used in the iteration

$Focus:case2subcase:case(id=$Var:SubCaseId):title

Reference Path

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:

$$Var:CasePath

$Db:case(objid=2435463534):title
 

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.

Background

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.

Summary

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

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:

1. Restricting a path or a portion of the path to a unique result.
2. 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.

1. LocalJdbc data sources use inproc JDBC API and the database driver is located on the same machine.
2. 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:

1. 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.
2. 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)

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:

1. Fixed context             – these are global and not runtime dependent.
2. 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)

AIF Characteristics

• Portable across application servers (WAS & WLS)
• Integrate / interoperate with Enterprise Service Bus (ESB)s/EAIs
• Provide protocol – neutral service invocation API
• Service definition customization and upgrade
• Leverages standards and pervasive technologies
• Uses existing integration foundations as much as possible
• Allows gradual adoption by Amdocs products

AIF Architecture

AIF is a cross portfolio foundation platform – there is no UI. It is tightly integrated with other cross portfolio foundations:

• APM  (Amdocs Process Manager) for composite operations
• ASC   (Amdocs System Configuration) for system configuration
• ASM  (Amdocs Security Manager) for security to enable cross portfolio single-sign-on

AIF Integration with 3rd Party

AIF provides an abstraction layer that enables application code to execute functionality provided by external components or systems in a protocol-independent manner. It supports the following protocols

• Local Java (POJO)
• Local & remote EJB (statefull and stateless)
• SOAP over HTTP (Web services)
• Tuxedo
• Asynchronous one way (JMS)

Services are defined in a central Service Repository and are managed via a service management UI

AIF provides data mapping, logging, auditing and monitoring infrastructure independent of the application code. A simulator is provided to facilitate client unit testing. It is monitored by JMX.

AIF Components

AIF infrastructure components include:

• Service Repository UI - 
  A central tool for defining, maintaining and storing Amdocs service definitions
       
• Service Repository
  Holds detailed technical descriptions of services. Service definitions are stored on disk files and deployed to the database for access by the consumer API infrastructure
    
• Service Consumer
  A protocol-neutral API for invocation of services
      
• Service Provider
  Code generation tool for exposing services via standard protocols: EJB, JMS, SOAP over HTTP, SOAP over JMS, POJO
      
• AIF can export its service definitions to any UDDI registry using the published UDDI API. However, it does not provide a UDDI compliant registry
    

Service Repository UI Components

Operation
A business operation is a discreet function that performs a single task. Operations are passed input parameters, and may optionally return output parameters, and faults. An operation corresponds to a Java method

Signature
These are the input, output and faults parameters which are defined for an operation. The signature refers to the names and types of these items, but not to any specific order (parameter ordering is typically required only for RMI protocols).

Interface
A logical grouping of operations. An interface corresponds to a Java class or interface.

Service
Published functionality provided either by an Amdocs application or an external system. A service is an implementation of an interface provided by some service providers. It is a  physical implementation of an interface (e.g. EJB service)

Binding

A physical attribute for an operation of a service;. e.g. EJB bindings define the method name and parameter order

The Service Consumer

Consumer application code uses the service consumer API to invoke a service operation. The consumer is unaware of who provides the service, where they are located, or how the service is invoked.

The Consumer supports the following protocols: POJO, EJB, JMS, Web Services and Tuxedo. Logging, auditing and monitoring is performed by the infrastructure. Details about the service are read from the service repository. Physical details (server URL etc) are taken from runtime configuration

The Service Repository

The Service repository defines operations, interfaces and services

Service definitions are defined in XML files, and deployed to a database for access by the service consumer API infrastructure (in CRM, the database table is aif_operation)

Service Definitions are edited using an eclipse plug-in. They can be created manually, by importing EJB interfaces or by importing WSDL.

The Service data model is based on WSDL2.0.

The services repository is fully compatible with 3rd party service repositories or registries via WSDL import/export and Java code (EJB interface)

Service Definition

A Service is physical implementation of an Interface. The Service name is unique within an Interface. Each Interface may have several Services, each representing a physical implementation of the Interface

Binding represents physical attributes of an operation within a Service. Each Operation within the Interface has a corresponding Binding within each Service.

Services are defined in two parts:

1. Static design-time definition which define the contract, implementation and protocols.
2. Dynamic run-time deployment configuration, defined in the AIF repository.

The AIF repository stores information such as JNDI names. These names are defined in the central configuration repository (Amdocs System Configurator – ASC)

The run-time configuration data can be changed independently of the AIF repository, giving operational flexibility.

AIF Configuration

AIF uses ASC to define its configuration items. AIF configuration includes AIF internal configuration, such as the JDBC connection it requires to access the deployed services, and definition of resources used by services defined in the repository

AIF is typically configured in some common node, and then inherited by the applications that use it:

/amdocsCommon/Aif

/crm/baseConfig/Aif (inherits /amdocsCommon/Aif)

The AIF Service Lab

The AIF plug-in for Eclipse provides a full blown UI for creating, testing and deploying AIF services.