Automic Workload Automation

  • 1.  Forced GUI refresh and AE kick events

    Posted Nov 02, 2017 07:13 AM

    I’ve noticed an annoying phenomenon that sometimes happens in the Java User Interface: while I am working with objects in an open Explorer window one or more of the following things will happen, without any action on my part:

    • The folder list in the Explorer window will suddenly refresh.
    • The expanded folders in the folder list will collapse all by themselves.
    • If I try to switch to another folder, this will not work and the view will switch immediately back to the previously-selected folder.

    Long ago, I enabled UCDJ tracing* to try to better understand what is going on. I found that the phenomenon was correlated to an event in the trace called kick. At the time, I did not completely figure out what this ‘kick’ did, but guessed that it had to do with some sort of synchronization activity to notify the GUI of changes in the AE.

    Yesterday I confirmed this hypothesis. I noticed several related new API classes added to the AE v12.0 Java Application Interface: IKickEventListener, KickEvent and KickEventType.

    Based on the documentation of the last of these classes, we can see that there are several types of kick event, and one of the types is TREE_CHANGED. This no doubt refers to changes to the AE folder structure (addition, modification, or deletion of folders). My guess is that the Java GUI runs an IKickEventListener, and listens for kick events from the Automation Engine. When a TREE_CHANGED kick event is received, the GUI automatically forces the folder tree to be reloaded from the AE in its entirety. This can take a few moments, during which the folder tree does not respond normally. The refresh of the window is also handled in a rather ungraceful way, and the GUI often fails to remember which folders were expanded prior to the reload.

    Anyway, that’s my best guess of what’s going on. It would be nice if the GUI handled this sort of thing in a more user-friendly way. I suppose it will not be fixed though, given that the Java GUI has been deprecated in v12.1. Also, I know the AWI works differently in this regard, caching data on the AWI server and loading only chunks of the folder tree at a time. (I suppose behind the scenes, the AWI still runs an IKickEventListener, and reloads the whole folder tree in response to these events, but it can shield the user from jarring UI changes.)

    * If you set the xml=3 trace option in uc4config.xml, you can see all of the XML traffic between the GUI and the AE.



  • 2.  Forced GUI refresh and AE kick events

    Posted Nov 02, 2017 02:51 PM

    I enabled xml=3 tracing for the GUI and then looked at the resultant trace file to see what the kick events looked like. Below are my best guesses:

    1. TREE_CHANGED

    <kick client="0001" idnr="0000000000" system="AE_SYS_1">OFS        </kick>

    (OFS is the table where the AE folder structure is stored.)

    2. ACTIVITY_LIST_CHANGED

    Automic Web Interface
    <kick client="0001" idnr="0000000000" system="AE_SYS1">EH         </kick>
    Java User Interface
    <kick client="0001" idnr="0001665002" system="AE_SYS_1">OH         </kick>

    OH is the table where the AE objects are stored; EH is the activity table. Why activity-list-changed kicks are labeled OH kicks in the UCDJ trace, instead of EH kicks, I do not know.

    3. PROCESSING_STARTED

    <kick client="0001" idnr="0000000000" system="AE_SYS_1">SYS_GO     </kick>

    4. PROCESSING_STOPPED

    <kick client="0000" idnr="0000000000" system="AE_SYS_1">SYS_STOP   </kick>

    5. PROMPT_INPUT_REQUIRED

    <kick client="0001" idnr="0020619002" system="AE_SYS_1">PRMPT      </kick>

    6. HIGHEST_CALL_OPERATOR_CHANGED

    <kick client="0000" idnr="0000000000" system="AE_SYS_1">EOI        </kick>

    7. HOST_ASSIGNMENT_CHANGED

    <kick client="0000" idnr="0000000000" system="AE_SYS_1">HACL       </kick>

    8. KICK_UNDEFINED

    <kick client="0000" idnr="0000000000" system="AE_SYS_1">UNDEFINED  </kick>


  • 3.  Forced GUI refresh and AE kick events

    Posted Nov 03, 2017 05:44 AM

    Michael A. Lowry


    you can also change the value for EH_KICK_INTERVAL in UC_CLIENT_SETTINGS, which controls the refresh interval for the Activity Window.


  • 4.  Forced GUI refresh and AE kick events

    Posted Nov 03, 2017 06:01 AM
    Keld_Mollnitz
    That’s useful information, but I am guessing this setting affects only the ACTIVITY_LIST_CHANGED kicks. (Why these are called OH kicks in the trace, instead of EH kicks, is anyone’s guess.)



  • 5.  Forced GUI refresh and AE kick events

    Posted Nov 03, 2017 06:08 AM
    Yes,

    Michael A. Lowry

    , that's also my guess. We are working with Support regarding various performance issues in general and with the Activity window in particular and this is a very interesting thread and some interesting findings you have come across.....


  • 6.  Forced GUI refresh and AE kick events

    Posted Nov 03, 2017 06:47 AM
    Keld Mollnitz wrote:
    ...We are working with Support regarding various performance issues in general and with the Activity window in particular and this is a very interesting thread and some interesting findings you have come across...
    I’m glad if it’s helpful. See also my other thread, where I documented a series of systematic tests I ran to determine the impact of deployments on GUI performance. I think I have mostly figured it out.


  • 7.  Forced GUI refresh and AE kick events

    Posted Nov 07, 2017 08:18 AM
    I just saw an ACTIVITY_LIST_CHANGED kick event in an AWI-AE trace message:
    2017-11-07 14:00:56,305 ionID=0000000002386086 [TRACE] NOSESSION/- NOUI   [.aetracing.AutomationEngineTraceListener] - <uc-env session="">
       <kick client="0001" idnr="0000000000" system="AE_SYS1">EH         </kick>
    </uc-env>
    Note that here it is labled EH, not OH as in the equivalent UCDJ trace. I do not know if these are different kick event types, but I doubt it. There is no documented kick event type that appears relevant to the OH table.