Building Terminal Automations

In order to create libraries around terminals, it makes sense to leverage the IBM EHLLAPI since you can reattach to the terminal.

  • Two DLL: 1. EHLAPI32.dll with nothing check 2.pcshll32.dll with enhanced checked.
  • If we are leveraging an existing connection do we close the connection after each action from a library?
    image
  • There are timeouts that can break the attachment. How do we fix this?
  • My understanding is not to have multiple sessions running, is this correct?
  • Are there other best practices to consider?

Can someone review this?

@Chris_Surati
in our libraries, shared XAMLs we received the terminalConnection as an in argument. All activities inside the library did not close the connection.

Opening/Attaching and Closing the connections was managed by the initial calling code

On managing parallel sessions A,B,C we did a small RnD but stopped due it was not needed. But with the session identifier there were not confused and clear adressable. So give a try and play

the Attachment can be disturbed and failling when the inner action (e.g. Step in a library) was failling with throwing exception and the caller part was not proper closing the conection. Then a Bot restart ended with Error: Connection Error and the session required a terminal client disconnect / connect

1 Like

@ppr

I did notice if the screen resizes then the session needs to be closed and reopen. We have been playing the closing of connection at key steps. However to your point we are not closing the connection each and every time.

We found multiple sessions seems to cause crashes. So that means are avoiding having multiple session running.

We found the same issue when an exception occurs within an action the connection error starts to occur.

Thanks!

When an exception occurs, we are performing init steps for logging into systems again, which creates the connection to pass into the process.

The connection should also be global to the project (in Main.xaml) so you can exit the Process section (for example if you are using the REFramework) and maintain the connection for the other transactions.

I have found that it’s ideal to only work with one terminal session during the process. This especially becomes complicated when you need to perform certain hotkeys on the window that isn’t compatible with the terminal send activity.

To ensure only one session is used, we planted a soft kill routine (in Kill Processes section AND in the Terminal Logon .xaml) that runs a Do While loop until no Terminal windows exist. This soft kill routine also exits any screens that could lock up the system for whatever reasons depending on your system.

So that’s kind of how we work it.

Regards.

I think creating a robust Logon .xaml for your Terminal stuff / Library is the key to making it work well.

We resolved this with a new automation to resize the screen on demand. It’s now the only time we close the connection.

Agree, @ClaytonM! Building on a robust library is the key. I cant wait until these start incorporating ui models.

1 Like