NextGen Consulting

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.

 

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.

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.

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.

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

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). 3^rd-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

3^rd-party controls:  Any 3^rd 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
     

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

 

  

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.

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.

• Sequence Action

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

• 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 Yuval R. | Amdocs, CRM, CRM, Smart Client, Technology | Amdocs Smart Client, CRM, Smart Client | 3 Comments