A VLF-ONE system IIP (eg: DF_OSYSTM) may now contain redefinable methods that permit advanced control of RAMP sessions:
| avRAMP_StartSession |
Executes just before a session starts. It allows the aXes URL, user and password that will be used to start the session to be changed. |
| avRAMP_ProcessAVSIGNALEVENT |
Is a new faster and simpler way to intercept AVSIGNALEVENT signals fired by your RAMP scripts. This is the recommended way to communicate state information from your RAMP scripts into your RDMLX code. |
| avRAMP_QueryCanClose |
Allows a RAMP session to respond to a uQueryCanClose request just like any normal VLF-ONE command handler can. |
| avRAMP_QueryCanExecute |
Allows a RAMP session to control whether a RAMP session request to execute will be allowed. |
| avRAMP_EndSession |
Executes just after a session ends. The primary roles is to clean up any custom object reference in the session instance manager. |
| avRAMP_SHOW_CURRENT_FORM |
Executes when a RAMP script executes the SHOW_CURRENT_FORM function. |
Each method is passed a set of parameters that allow it to identify the RAMP session, the RAMP session instance manager and the command handler involved.
The session instance manager (class VF_SY120O) object passed contains a new avRAMP_Reference property which allows you to associate custom information with a RAMP session instance.
Example 1 – Locking and 'off the path' tracking
Imagine that you create an Visual LANSA object named #MySessionInfo that contains properties:
In avRAMP_StartSession you set avRAMP_Reference to refer to a newly created #MySessionInfo object.
In avRAMP_EndSession you reset avRAMP_Reference to null to destroy the #MySessionInfo object as it is no longer required.
In avRAMP_ProcessAVSIGNALEVENT you watch for signals LOCK (with an accompanying lock message in the payload), UNLOCK and UNKNOWNSCREEN that are signalled from various places in your RAMP scripts.
In avRAMP_QueryCanClose and avRAMP_QueryCanExecute you then use #SessionInfo.Locked, #SessionInfo.LockMessage and #SessionInfo.OnUnknownScreen to accept or reject Framework screen navigation requests based on the state that your RAMP session is in.
Example 2 – 5250 screen usage heatmap
Imagine that in your system's IIP you defined a collection of totals, keyed by screen names. This keyed collection is going to be used to count how many times RAMP destination screens are visited.
In avRAMP_ProcessAVSIGNALEVENT you watch for signal DESTINATION that is sent by your RAMP destination arrival scripts.
Using the screen name supplied in the event payload you update the screen usage collection.
Additionally, your IIP contains a private method named DumpScreenStats. It attempts to send the screen usage collection details to your server for storage in a database table that you will later use to produce some screen usage heatmaps. After the details are sent the screen usage collection is emptied.
Method DumpScreenStats would probably be executed periodically from a timer firing inside your IIP and from the IIP's standard avCloseMAINWindow method.
Example 3 – Adding details to the URL used to start aXes
To add &DEVICE=MYDEVICE parameter to the URL used to start aXes:
Note that you need to be at EPC142005 hotfix level 1 or later to do this.