NextGen Consulting

About Smart Client Script Player

Background

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

01/07/2011 - Posted by Yuval R. | Amdocs, APM, CRM, CRM, Customer Interaction Management, Development, Front End, Smart Client, Technology