NextGen Consulting

IT Consulting CRM BSS OSS

Migrating Amdocs CRM Classic to Smart Client (part 1)


Business justification for migration from classic to smart client technology is a difficult subject.  In some respects migration can be seen as having purely IT benefits, such as reduced deployment costs, reduced maintenance costs etc. 

The main business drivers for migration are often based on leveraging new functionality that is available in the smart client, not available the classic client.  This means that a purely technical migration will likely result in limited or no identifiable business benefits, making the business case very difficult to prove. 

In many cases both technical and business drivers arise during the migration assessment.

It is important to understand that although both technical and business drivers for migration are viewed separately, there is an overlap between the two areas, as improved functionality is enabled through the use of the new architecture.

 

Read the full story Migrating Amdocs CRM Classic to Smart Client (Part 1)

 

Advertisement

09/10/2010 Posted by | Amdocs, BSS, CRM, CRM, Smart Client, Technology | Leave a comment

Implementing ‘Got_focus’ Event in Smart Client


Q: Clear Basic provide ‘got_focus’ event for controls but I can’t find the same event in smart client.
Is there any way to implement this feature in smart client?

   

A: You can add your native contol focus event listeners (lost/gained) as follows:
(assuming your control is a textBox named ‘txtCustomerName’)

// Add the following in the form_Load() event handler:  
// define focus event listeners (lost/gained)  
(    (javax.swing.JComponent)this.txtCustomerName.getNativeControl())
             .addFocusListener(new FocusListener()   
{    
// this is the equivalent to Clear Basic Lost_Focus() 
public void focusLost(FocusEvent focusEvent)
{       
// your logic here... 
System.out.println("focus lost");
}    
// this is the equivalent to Clear Basic Got_Focus() 
public void focusGained(FocusEvent focusEvent)
{
// your logic here... 
System.out.println("got focus");
}   
}

);

01/10/2010 Posted by | Amdocs, CRM, CRM, Development, Front End, Smart Client, Technology | Leave a comment

Using Contained Core Business Objects


Q. When working with establish relation, I had a problem with a Bo having many parent, like:

1. We have an exist CaseBo object:  caseBo
2. By using XVO, we create 2 new row to insert: emailLogBo and actEntryBo
3. In which: actEntryBo is child of both caseBo and emailLogBo, emailLogBo also is child of caseBo.

=> how can I insert emailLogBo and actEntryBo to database ?

Note that: Both emailLogBo and caseBo are parent of actEntryBo, so we can’t use actEntryBo.setParentBo(..) to set up relation. So, please suggest how to solve this problem.

 

A.  Note that CaseBo object contains all the logic to do it automatically for you.
All you need to do is to add your new emailLog record to the CONTAINED emailLogBo.
When doing so, an actEntry will automatically be added and related with all relevant BO parties (CaseBo, UserBo, EmailLogBo).

About Contained Business Objects

Many BOs Contain other Business Objects. These contained CBOs are exposed as properties of the containing BO. For example, when a Case BO is created, contained BOs are automatically created for the logs related to the cases, the site and contact that reported the cases, and the installed part identified in the case

These contained CBOs are automatically related to the Case BO, usually as child BOs of the parent BO. They are accessed through CaseBO properties.

Field values for contained CBOs are accessed through properties of the containing BO
The following code shows how to get the first name of the contact who logged a case: String firstName=boCase.getContact().toString(“first_name”); 

     
Note:

  1.  Most contained CBOs are Generic BOs.
       
  2. To reduce network traffic and improve response times, many contained BOs set bo.DataFields and bo.QueryMode to minimize the amount of data retrieved. Make sure to modify the DataFields property of the contained Bo to include necessary fields before performing the query.

 

  
Example: 

String fields= boCase.getContact().getDataFields() + ",e_mail";
boCase.getContact().setDataFields( fields );
boCase.query();

  

Example of adding email log to a CaseBo: 

  
// Add a new row to the contained EmailLog BO.
boCase.getEmailLog().addNew(); 

// Set the note description for the new row.
boCase.getEmailLog().setValue("description",
  "Customer mailed again to ask about the case status"); 

// Commit changes to the database.
boCase.update();
 

01/10/2010 Posted by | Amdocs, Backend, BSS, CRM, CRM, Development, Smart Client, Technology | Leave a comment

Smart Client Messaging


About Smart Client Messaging

Smart Client messaging is far more flexible than its Classic predecessor. Smart Client forms can communicate with other forms by messaging.

See more about Smart Client Messaging…

22/09/2010 Posted by | Amdocs, CRM, CRM, Development, Smart Client, Technology | Leave a comment

Implementing Smart Client Tree Control


Smart Client Tree control displays hierarchical information in an outline structure.

It extends SWING’s JTree base functionality and provides visual presentation to hierarchical data.

Need to display logical model 

 

  

In a dynamic tree control?

Learn how to implement Tree control in Smart Client Java Swing technology.    

Read Implementing Smart Client Tree Control for full story and step by step examples.

 

21/09/2010 Posted by | Amdocs, CRM, CRM, Development, Smart Client, Technology | Leave a comment

How to Upgrade Backend


Q. There is a form, the back end for that form was implemented by Worker Bean.
I’m upgrading that form to a new version by creating derived form and add on some needed features.
What about the backend, Is there any way to upgrade the old Woker Bean?
Note that the new backend should be implemented by XBean.

 

 

A. Using derived form does not require any change in the backend if you do not need any changes or additions to the backend logic.

If you do need to modify the backend code, you can use either of the following options:

  1. Countinue using the WorkerBean and its related SaveBean / LoadBean
  2. Move the logic completely to a new XBean.

 

  1. Countinue using the WorkerBean and its related SaveBean / LoadBean

In this case you need to:

  • Override the original Workerbean.
    Create your own version to the WorkerBean only if your new logic require passing new parameters.
    If there is no change is the parameters, do not override the workerbean, leave the original one.
  • Override the related Savebean (or Loadbean) with a new Save/Load bean.

  

Remember that overriding a backend Bean (WorkerBean, SaveBean or LoadBean) equires:

  • Providing a new name to the new Bean (i,e X1<original_bean_name>)
  • Mapping the original bean name with the new bean name.

 

Mapping

The mapping should be in a backend class called Config.java  located in the package com.<your Organization>.crm

For example: com.nextgen.crm.Config.java

 

 The mapping format for each entry should be as follows:

String <original class full qualified name> + ";" + String <new class full qualified name>

If you have several new entries, seperate them by a coma (,).

 

Example for Config.java which contains two entries:

 

package com.nextgen.crm;
/**
  *
  * @Description Replace OOB Beans with Custom Beans
  * @version NextGen
  * @author 
 **/
 
public class Config {
  // Default constructor
  public Config() {}
 
  //String array mapping baseline classes with custom subclasses
   public static String[] m_MapTable = {
  com.clarify.isupport.contact.savebean.ContactOverviewCIHSB.class.getName() + ";" +
  com.nextgen.isupport.contact.savebean.X1ContactOverviewCIHSB.class.getName()

 ,com.clarify.isales.account.workerbean.CustomerProfileTabCreateSaveWB.class.getName() + ";" +
  com.nextgen.crm.isales.account.workerbean.X1CustomerProfileTabCreateSaveWB.class.getName()
   };
 
  /**
    * @Description Retrieve the mapping of custom subclasses when Weblogic starts
    */
  public String[] getClassMapTable()
  {
     System.out.println("*** New Class Map *** [" + this.getClass().getName() + "]");
     return m_MapTable;
  }
 
} /// Config

 

Updating ASC

Remember that you need to make sure class path of Config.java is configured in your ASC (Amdocs System Configuration) as follows:

Node Path:             /crm/baseConfig/clarifyEnv/user_package
Entry:                 com.<your organization>.crm

Entry example:     com.nextgen.crm

 

 

2.  Move the logic completely to a new XBean

Moving the logic to a new XBean first requires copying the old logic from the Workerbean and its related SaveBean (or LoadBean) to a new XBean.

 

Note the following:

 

  • The Workerbean is used only for passing the data from your front end client to your SaveBean. This data is passed via CDOs, where the XBean gets its data directly using XDOs (practically XVos).
    You shall need to convert your passed data fron CDO to XVo.
      
  • You shall need to copy the SaveBean (or loadBean) logic to the new XBean.  
    This should be fairly easy if you managed to properly convert your data as mentioned in (1).
      
  • You might consider *not* to map the original OOB WorkerBean to your new XBean,  but call it explicitely from your front-end.
    This is to maintain backward compatibility with other front-end code that might use it from other forms.

 

 

Which Option to Use?

Obviously, moving logic to a new XBean is more complex, and needs to be updated with every upgrade to a future release. However, it provides much more efficient code which is easier to maintain.

On the other hand, merely creaying your new versions for the OOB WorkerBean and SaveBean (or LoadBean) is much easier task and backward compatible.

15/09/2010 Posted by | Amdocs, CRM, CRM, Development, Smart Client, Technology | Leave a comment

Smart Client Look and Feel


Smart Client Look and Feel

The “look and feel” (LAF) describes the appearance of UI components. It handles presentation for Smart Client UIF custom controls & states.

It works in conjunction with currently active Swing’s look and feel and Swing’s controls (Only Windows XP LAF supported).

 

 

For full discussion see Smart Client Look and Feel .

 

02/09/2010 Posted by | Amdocs, CRM, CRM, Development, Smart Client, Technology | Leave a comment

Implemnting Lookup Control


About Lookup Control

The Lookup control assists users search for data with which they need to associate.

For example, when creating a new contact, we need to need to associate it with a site to which this contact belongs.
 

The lookup button launches a search form which allows the user to select the relevant record that update the necessary values in the launching form.

The lookup button is often used in create and edit forms, where the main focus object (in our above example – a new contact) needs to be related to another object (site in above example.

The Lookup control allows users to search and associate objects in the application. The control provides standard drop-down button functionality plus additional specific ones. 

For the full discussion, see Implementing Lookup Control.

31/08/2010 Posted by | Amdocs, CRM, CRM, Development, Smart Client, Technology | Leave a comment

Smart Client Run-Time Architecture


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.

Smart Client Architeture

 

Request/Response Manager

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

 

Application

The application object is a script level object that can perform global application tasks like posting modal alerts or expose certain functionality of the workspace.

Workspace

The workspace provides common user interface services to Forms and client side components.

Workspace and application assembly

The Workspace provides the following services:

Startup & Exit

  • Serves as main entry point to application
  • Handles deployment
  • Handles exit, update desktop, user preferences

Desktop Services

  • Loads Application Configuration metadata
  • Manages multiple Applications simultaneously
  • Manages main window, menus, toolbars, tool boxes, status bar and form window
  • Provides Look and Feel / customizable styling for UI controls

Client Services

  • Provides support for login, help, printing
  • Manages background tasks
  • Provides Logging, Exception handling, Operational Measurements
  • Manages forms by providing services to open, close, version, etc.
  • Globalization support

Workspace configuration is XML (workspace.xml). It configures numerous applications and run time parameters, such as list of available application desktops, logging, help, server configuration etc.

WorkSpace and Form Components

Form

A form is a UI object that represents a business level Form and encapsulates the native implementation of the swing form (JInternalFrame in Swing for example). A form usually contains controls and sub forms.

A form manages controls, data models, actions, sub-forms and other components that define the form. The form supports design tools by delegating content creation to a “builder” class which is generated by design tools. It provides published API for application scripting.

Sub Forms are reusable forms that can be placed within parent form

Child Forms relates multiple forms within a single flow

Form Messaging system, allows for application script to communicate with other forms

Dirty Bit Tracking tracks form-modified state

Forms can be launched in work area, in the toolbar pane (toolbar), in the toolbox pane (toolbox). A form can be launched in the main work area. A form can be launched as a modal or none modal. It is by default visible, but can be made hidden by form logic (java application). Global forms are always hidden.

Form Components

Derived Forms

 A derived form is a visually inherited version of a base form. It is a subclass of the base form class. Forms can be derived for providing enhaned user experience either by targeting form variations at different groups of users, or merely improving the form layout and functionality for improved usability.

Form Visual Inheritance

Form Version Selector

The Form Version Selector provides the ability to identify the correct form version at runtime, given a form logical name. A form logical name needs to be resolved to a form class based on an expression that evaluates any run time data such as user or environment properties (practically any data such as user role, locale, context etc).

Specific version of a form can be selected dynamically using the following steps:

  1. Launch action defines a target logical form name to be launched
  2. Logical form name is mapped to physical form name
  3. Physical form name is then launched
  • Selection criteria are specified in rule-based metadata (expressions), evaluated in order until one evaluates to true
  • Rules are stored in XML files as expressions , and are edited by a design-time tool
  • Rules may refer to any contextual data via Path

Version selector

 
 

Controls

Controls are UI objects that are implemented as platform neutral objects. These are Java Swing controls wrapped by additional control functionality, that provides additional features (i.e. two way binding) and insulate application code from native technology. Controls may carry metadata such as:

  • Control Properties – e.g., isEnabled
  • Binding metadata – how control binds to form’s data
  • Validation metadata – specifies constraints
  • Action metadata – defines what to do when control is “clicked”

The controls contain a rich set of UI controls which provide generic support for CRM features such as hierarchical choice lists and role based authorization (RBA). 3rd-party controls may also be used, with limitations.

Supported controls are:

Textual Controls:       PercentBar, Label, TextArea TextField, ObscuredText, TextArea, Currency, Hyperlink

Button Controls:       Button, RadioButton, CheckBox, Menu/ MenuItem

Time Controls:           DateTime, ElapsedTime

List Controls:            ComboBox, ListBox

Grid Controls:           Grid, Search Grid, Grid Footer, Tree, GridTree,

Containers:               CardPane, Panel, TabbedPane, TabPage

Other Controls:         Browser

Search Controls:       LookupButton

3rd-party controls:  Any 3rd party wrapped with Smart Client functionality.

 Controls provide published API for application scripting.

Data Manager

Data manager enables the application framework to work with the datasets associated with an application form. The data manager follow JDNC (Java Desktop Network Components) model, with the following enhancements:

  • A Data Set consists of Data Model objects
     
  • Each data model object contains a set of fields
     
  • A control property can be “binded” to a data model field
      
  • Data retrieved from server-side service request is mapped into dataset
      
  • Data is transferred between controls and dataset, in both directions, automatically
        
  • Data is mapped from dataset and sent to server-side service for form save or other operation
       

Smart Client Data Models

Dataset Features

  • The dataset support Single and Tabular data models
      
  • Data model objects store native binary data and implement a generic get/set interface, not VO-based (classes stay on server)
      
  • Dataset provides published API for form application scripting (code should manipulate data values in model, not in UI controls)
      
  • Support for hierarchical data models
      
  • Virtual data model – reference to model on other form
       
  • Support for data models published from controls
     

Binding Framework

The Binding Framework is the glue module that links the datasets to the controls in a form. It can be easily integrated with any component to provide binding support.

Data binding performs locale-sensitive binary-text conversions as needed between controls and model

Application events are defined for any change in data model value.

The binding framework provides the following capabilities:

  • Value maps, e.g. convert values of 0 / 1 to Inactive / Active
      
  • Property binding. Property binding allows binding a data field to a UI control property other than its value. For example, a data field value can set control property such as visibility, availability (enable/disable) etc.
       
  • Custom handlers for ‘format’ and ‘parse’ during binding
     
  • Trigger fields to trigger binding based on changes in multiple fields
       
  • Custom format string to format the data if the property type is a String
      
  • Published API for manipulation of binding properties by application code (part of Control API)
      

Data Communication Elements

This objects are metadata-driven inter form communication entities applicable between two forms. They provide data transfer (copy by value) and data sharing (copy by reference).

  • The data transfer triggered by a specified event and contains mapping capabilities
      
  • Data sharing is performed via declaration of “virtual data model” in the receiving form. It  automatically hooked up to data model in the publishing form

 

Data Communication Elements

  

Event Manager

The Event manager enables the application layer to establish client side hooks in a technology neutral way and give the ability to execute event hooks in a super class.

Smart Client Events

Validation Framework

Validation framework is used to ensure that the user input is valid before it is sent to the server.

 

Caching and Global Data Manager

The cache framework provides ways to cache metadata on the client side that can be used across sessions.  Global data manager provides a mechanism to store data sets that can be accessed globally across all forms.

 

Action Manager

Action Manager dispatches actions to event handlers and executes metadata-driven behaviors.  Submit actions package the Request payload and process the Response Payload. The actions are built on Swing Action model.

An action is a form element with no run-time UI, which performs a metadata-driven action. There are different Action types for performing different type of activities; each has its own metadata format. Any “executable” control, e.g. a button (‘action controls’) can target an Action. If an Action is disabled or hidden, any ‘Action Control’ targeting that Action is automatically disabled or hidden.

Since Actions defined in a form and are considered as a form component, they have by default a local form scope (in other words, they can be directly used only by the form’s code). However, an Action may be marked “published”. A ‘published’ action name can be referenced from any other form.

Menu and toolbar controls can automatically connect to published actions in the currently active form.  When an action is disabled, it automatically disables connected menu items/toolbar controls.

Action Types

  • Submit Action

Submits request to the server and updates the form with response data; the data is mapped between form’s data models and server side operation (XBean) inputs/outputs (setters/getters); updated data may be auto-broadcast to other forms.

  • Launch Action

Launches new form in ASCF Client workspace; data is mapped between launching form’s data models (current form) and the launched (new) form input data models.

  • Bulk Action

Bulks multiple Submit actions in one server round trip, in one or more transactions, or as individual requests with no transaction, across form and its sub-forms, to possibly multiple back ends.

Bulk Action
  • Sequence Action

Executes multiple actions in a sequence, where the next action in the sequence begins after the current action is fully complete.

Sequence Action
  • Subscribing Action

A subscribing action subscribes to a target action, whose state propagates back to the subscribing action. The subscribing action executes its target when it is executed.

  • Service Driven UI Action (SDUI)

The Service Driven UI Action launches forms determined by a backend UI-driving service. It uses Submit action to execute UI-driving service. The UI-driving service determines next logical form. The launch action is used to populate the next logical form name. The launch action properties may be specified by service. The Service Driven UI Action copies input data models to the launched form’s dataset. It supports data context with contained input data models. It can accept multiple explicitly defined Launch actions (one per possible next logical form) along with a default one and it dynamically creates Launch action if needed.

  • Process Driven UI Action (PDUI)

The process driven UI action launches forms determined by UI-driving service in process-driven UI flow. Any arbitrary process state object can be used. The PDUI updates parent/containing forms with process state. It enables adding of reusable forms to UI flow without design time modifications:

  • Allows any UI control or action in reusable form to trigger flow continuation (overloading).
  • Supports parallel or sequential execution of overloaded control and dynamically created Process-Driven UI action.
  • May return any data model to UI-driving service when flow is continued after the UI step.

Both SDUI and PDUI can launch the next form according to predefined fields contained in an object named ‘UiDescriptor’ returned by the server.

  • Both can use any business logic as UI-driving service.
  • Both do not restrict the use UI-driving service public API.
  • Both action types allow the process state object to have any structure.
  • For both action types, explicitly defined Launch action properties take precedence over Launch properties returned by service.
  • Client Process Driven UI –  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.

Client Application Connector

Client Application Connector (CAC) provides services to invoke, terminate and exchange data between other clients on the desktop that include windows based client like outlook, excel etc., a Java based client or a browser based client.

26/07/2010 Posted by | Amdocs, CRM, CRM, Smart Client, Technology | , , | 3 Comments

Amdocs Smart Client Vs Classic (thick) Client


Classic Client

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

Classic client interacts with its database either directly (2 tier mode) or using the Tuxedo transaction monitor as an intermediate layer which optimize SQL queries and transactions between the client and the database (3 tier mode).

Clear Basic customizations use the form as a base unit, which encapsulates internal data models called contextual objects.

The contextual objects data models mostly follow POMS metadata (database table structure) and are used to bind UI controls with the database objects.  For runtime in-memory data manipulation the ClearBasic extensions provides objects to model database structures either as single record (‘Record’) or list of records (‘List’).

ClearBasic customizations use an interactive development environment (IDE) called UI Editor.  All Classic client form customized components (Clear Basic source, the compiled code,  contextual objects data models and UI visual definitions) are stored in the database.

A form usually represents a visual entity. However, global forms contain global application code which is loaded into memory during classic client initialization. Global form has no visual presentation. Global code has an application scope and can be called from any other form. Global forms can either reside on the client, or on the Tuxedo application server.

Forms can pass information between them by using a message API.  A message can pass list of strings.
Forms can refer to other form by using an identifier. ClearBasic API allows creating parent-child hierarchy between forms, thus providing a facility for a parent form to enforce closing all its children when it is closed.

A form can be stored in several versions. Each form version is related with a predefined group of users called ‘Resource Config’.  This arrangement allows keeping several versions of same form, either under same Resource Config where only the latest version used by the application, or relate each version with a separate Resource Config, hence the application screen relevant form to its Resource Config  related users.  The classic customization environment also supports the following aspects:

  • Sub forms  – forms which share binding data models
     
  • Automatic updates  – form UI and code is cached on the client.  A new customization (both UI and code) can be pulled by the client
      
  • Upgradability – customer customizations are maintained when upgrading to new release.
     

 

Smart Client

Smart Client is pure java application. It uses Java to support powerful client functionality, including Java SWING for its UI presentation layer. The use of Java and its rich graphical SWING functionality provides a very powerful rich client environment.

Smart Client does not access the database directly. Rather, it uses a backend application which is run by an application server (Weblogic or Websphere) to access the database.  This backend application structure also known as J2EE.

The J2EE application environment use newer advanced database access layer called CBO (Clarify Business Objects). The application run on the server called server side code. The server side code is organized in classes named Java Beans. These java beans, also known as XBeans, use CBO to access the database. They use a newer version of the persistence layer called JPOMS (the Java successor of the original POMS).

Smart Client connects to the application server using HTTP protocol, in a very similar way as Web clients connect to their applications server.

Smart Client use Java Network Launch Protocol (JNLP) – a Java mechanism to support zero deployment, either in a push (application server initiated) or pull mode (client initiated).

Smart Client customizations use a framework called ASCF allowing the developer to use a simplified, high level subset of the SWING classes in similar manner as its predecessor ClearBasic does for Classic client.  Development preformed using ASCF Designer, an Eclipse based IDE ( integrated development environment). The ASCF Designer IDE is  implemented as a plug-in extension on top of the open source Eclipse platform.

The development environment, use Java as its programming language, provides a simplified and very powerful SWING customization environment yet resembles in its simplicity many aspects of the legacy ClearBasic environment.

Not surprisingly, the main customization object is form.

A form is a UI (user interface) component used to view and process user data based on business needs. The main constituents of a form are User Interface controls, user data and logic used for interaction of the above components.

The form and its customization entities (UI controls, Data Models, Actions, Events, Data Communication Elements etc) behavior is set at design time using meta data defined as entities properties (I.e. form properties, UI controls properties, Data Model properties, Actions properties, Events properties, DCE properties). This behavior can be later manipulated at run time by the application code.

A form can be derived into many versions as needed.  Each form version inherits the presentation UI as well as its related code and other entities (data models, actions, data communication elements etc).  Additional customization is only needed for any changes from the original look and or behavior.  There can be as many derived (inherited) forms as needed. Smart Client use an object called ‘Version Selector’ to define the criteria to select which version will be used at run time. These criteria use expressions which are evaluated to a logical boolean value (true or false). An expression can practically be simple as any value retrieved from the database or complex evaluation based on run-time and database values.  Expressions are elaborated in a separate post.

Global forms are used as common code containers. They have the same purpose as the Clear Basic global forms.  Although invisible, global forms are standard forms and support all none visual form related customization entities such as data models, actions, events and  data communication elements.

Form can pass information using the Message object. The message object can move Java objects to one or more forms (broadcast).  The object passed with a message can practically be of any type of any complexity.

The form has related entities which are used at runtime: the data set is a collection of data models which are used to bind data to UI controls. This UI – data binding  can be regarded  from user perspective in a similar way to the Classic contextual objects.

Data Models can represent a single record (called Data Model), or set of records (called Tabular Data Model). A data model can use JPOMS driven database metadata (i.e. columns of a database table automatically reflected as Data Model fields) or can be manually arbitrarily defined (similar to the ClearBasic user defined record).

Dada Model Hierarchy: Data Models can be structured in Hierarchical manner. Any Data Model field can refer to any type of Data model or Tabular data model.

Data Model is usually recognized within the form in which it is defined. However, data model can be defined as a Virtual Data Model. A Virtual Data Model can be referenced from any other form. This provides an easy way to share data among forms.

Actions are another important set of entities related with the form.  Actions are used to initiate variety of activities of different types in response to events which may originate either by the user or by application code. The Smart Client framework simplifies the original complex definition of SWING actions. It provides set of selected action types. The most common action types are:

  • ‘Submit Action’ – invoke a server-side code (XBean) to either retrieve or store data
      
  • ‘Launch Action’ – launch another form
       
  • ‘Lookup action’ – invoke database search
       

Other types provide greater flexibility such as:

  • ‘Bulk Action’ – combining several Submit actions into one database transaction
     
  • ‘Sequence Action’ –  allows connecting several actions into a sequential chain
       
  • ‘Service Driven Action’ – launches form as determined by a backend UI-driving server operation. The name of the next form to launch is provided by the operation. For example, Post Case Overview form based on Case type, where Case type to logical form name (LFN) mapping is stored in the data base.
      

Data Communication Elements provide advanced communication mechanism between forms.

Events are usually defined as SWING listener mechanism.  Smart Client framework greatly simplifies the complex SWING listener plumbing. Instead, it provides a selected sub-set of events as properties of forms and their various related entities such as data models actions and data communication elements (DCEs).

Each of these form related entities exposes set of relevant events. For example, the form entity defines the following events:  preOpen, preload, load, postOpen, openFailed, postActivate, preClose, preUnload and postClosed.  Common events used by all actions are actionStart, actionFailed and actionDone.

    

    

Smart Client Vs Classic Client

IT organizations which still use legacy, heavily customized, Classic client implementations, quite often are required to decide about a possible move to Smart Client; they need to assess the potential benefit compared to involved costs in terms of expected efforts and possible risks.

The expected benefits are clear. Can they be quantified?  Let us quickly look at some of these benefits.

  • Product support:  Both Classic client and its underlying database will soon not be supported by their respective vendors.  Moving to latest technologies completely eliminates the risk of using unsupported products.
       
  • Integration   Latest technology natively supports common industry standards (J2EE) as well as vendor’s own Integration Framework (AIF).  These standards offer an up-to-date infrastructure for seamless integration with other products, especially with vendor’s (Amdocs) suit of products such process manager (APM), Ordering, Enterprise Product Catalogue (EPC) and Billing. These facilities greatly reduce integration costs both from development and maintenance perspectives.
         
  • Functionality  Smart Client JNLP / J2EE technology provides robust, scalable application environment.  The enhanced functionality allows for much more efficient development and easier maintenance, thus, significantly increase productivity, accelerate development time and availability (shorten time to market) of supported new business processes.

    

Classic to Smart Migration

   

     

Moving from Classic To Smart Client 

Q:  What additional load does moving from Classic client-> Smart Client put on user/Workstation? If the desktops are old would the performace further degarde if we move to Smart Client?

A:  Moving from Classic client to Smart client should certainly improve performance.

Old Classic Client is a Client-Server MFC (Microsoft Foundation Classes) based application which is connected to a single database.

Smart Client provides the following technical capabilities:

  • 0.5 sec Performance (client)
        
  •  Robust customization environment
       
  •  Upgradeability
      

As well as the following advantages NOT available in Classic client:

  •  Zero Desktop Administration
       
  • Rich Control Set
        
  • Architectural Alignment
        
  • Multi-tiered Customization
       
  • Desktop Integration capability
       
  • Centralized Business Logic
       
  • Access to full CRM application set
       
  • Single UI for applications portfolio

Smart client use latest Java – J2EE and Web Start technologies which only use the code required by the client application. It can be seamlessly connected to several backend databases (I.e. CRM, Ordering) thus providing a unified desktop for the CSR.

The unified desktop eliminates the “Alt Tab” navigation by contextually launching other desktop applications inside the application (i.e. customer interaction) area, thus providing single point of history for all interactions, across all applications, context-driven navigation).

In terms of user experience, Smart Client provides much richer capabilities compared to its Classic client predecessor. – It reduces desktop complexity by hiding legacy screens and incorporating data into a single desktop screen. – Data is accessed from other applications in the background, transparent to the user.   Background tasking capability streamlines tasks flows and eliminate “cut & paste” by automating across nested applications.

Moreover, customization and application maintenance are much more powerfully compared with old ClearBasic technology.  Smart Client provides improved architecture and development tools, faster time to market for new functionality, common UI (look and feel) and tools improves integration capability and support for multi-tiered customizations.

Read more on Migrating Amdocs CRM Classic to Smart Client (Part 1)

08/07/2010 Posted by | Amdocs, CRM, CRM, Technology | 39 Comments

« Previous Entries     Next Entries »

%d bloggers like this: