Терминальное соединение UiPath - внутреннее против EHLLAPI?
Я пытаюсь автоматизировать в терминале AS400 с помощью UiPath.
У меня возникают проблемы со стабильностью, когда экран "мигает", что может привести к ошибкам. Это выводит журнал трассировки: "XMLScreen:Render BUGBUG XMLScreen.Field пусто".
Я соединяюсь с внутренним UiPath и задаюсь вопросом, может ли это быть причиной моей проблемы. Я искал часы, но не могу найти никакой информации о том, в чем разница между внутренним UiPath и IBM EHLLAPI. Единственное различие, которое я знаю, состоит в том, что EHLLAPI использует уже существующий сеанс терминала.
Является ли один способ подключения в целом лучшим выбором, чем другой, в отношении стабильности и почему?
Все материалы очень ценятся!:)
0 ответов
Два варианта работают совершенно по-разному.
EHLLAPI работает с существующим установленным программным обеспечением IBM i Access for Windows или IBM i Access Client Solutions (ACS). Это очень специфичный, надежный и хорошо зарекомендовавший себя собственный API-интерфейс IBM, который никоим образом не использует Telnet. Вам необходимо убедиться, что поддержка EHLLAPI включена (например, http://www-01.ibm.com/support/docview.wss?uid=nas8N1010639 для ACS).
Возможно, ваша организация использует сторонний эмулятор, например Rumba - я думаю, что EHLLAPI поддерживается некоторыми из них.
Внутренняя опция UIPath запускается и записывает в сеанс TN5250, который звучит из документации так, как будто у вас мало контроля (например, повторное сопоставление клавиатуры).
Я бы посоветовал вам воспользоваться EHLLAPI, если вы можете (т.е. если у вас установлен подходящий продукт IBM или сторонний продукт, как указано выше).
Но вы абсолютно уверены, что вам вообще нужно это проверить? У вас нет доступа к исходному коду IBM i, который потенциально позволил бы вам написать подходящую программу для собственного запуска? Для меня большая честь сказать это, потому что всегда возникает проблема с чисткой экрана приложений IBM i (например, появляются панели, которые вы не ожидаете, особенно во время входа в систему или в случае возникновения ошибки).