I'm trying to automate in an AS400 terminal using UiPath.
I experience stability problems where the screen "blinks", which can cause errors. This outputs a trace log: "XMLScreen:Render BUGBUG XMLScreen.Field is blank".
I am connecting with UiPath internal and wondering if that might be the cause of my problem. I've searched for hours, but cant find any information on what the difference is between UiPath internal and IBM EHLLAPI. The only difference I know is that EHLLAPI uses an already existing terminal session.
Is one way of connecting generally a better choice than the other regarding stability and why?
All inputs are greatly appreciated! :)
The two options work completely differently.
EHLLAPI works against existing installed IBM i Access for Windows or IBM i Access Client Solutions (ACS) software. It is a very specific, solid, and well established IBM proprietary API that does not use Telnet in any way. You would need to ensure that EHLLAPI support was enabled (e.g. http://www-01.ibm.com/support/docview.wss?uid=nas8N1010639 for ACS).
Your organisation may perhaps be using a third party emulator, e.g. Rumba - I think EHLLAPI is supported by some of these.
The UIPath internal option starts and writes to a TN5250 session, over which it sounds from the documentation as if you have little control (e.g. re keyboard mappings).
I would suggest you go with EHLLAPI if you can (i.e. if you have a suitable IBM or third party product installed as above).
But, are you absolutely certain you need to screen scrape this at all? Do you have no access to the IBM i source code, which would potentially allow you to write a suitable program to run natively? I feel honour bound to say this, because there is always grief with screen scraping IBM i applications (e.g. panels appear that you are not expecting, especially at sign on time, or if an error occurs).