NextGen Consulting

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 Yuval R. | Amdocs, CRM, CRM, Technology