UiPath RPA Mainframe Automation with Hostbridge
HTML-код
- Опубликовано: 27 июл 2024
- This live session will be all about mainframe automation with UiPath RPA. A UiPath mainframe integration demo will be shown by the very skilled people from Hostbridge Technology.
Hostbridge will show an approach to improve reliability and achieve performance improvements compared to current methods.
When we do mainframe automation like we use to do with UiPath (working in the UI), it causes problems. It's very fragile, slow and it's hard to scale. The solution is to use a federated, RPA platform that runs on the mainframe.
📁 HostBridge Mainframe RPA Guides: www.hostbridge.com/mainframe-...
0:00 What can go wrong in Mainframe RPA automation?
Russ Teubner (CEO & Co-Founder) from Hostbridge explains, how to avoid UI interaction (terminal emulation and screen scraping) because it's easy breakable and costly in system time. Instead, we can use API integration. Jerry Rackley, Director of Marketing, and James Alexander, Director of Technical Services are also in the session.
3:29 HostBridge Technology
A short introduction about the product and the demo. You can use the REST API from Hostbridge with UiPath, but also Automation Anywhere, Blue Prism, and any other RPA tool.
6:02 Mainframe UI automation with UiPath
Russ demonstrates, how to automate the Mainframe with UiPath. Our UiPath robot works in the UI (emulation and screen scraping).
12:33 Mainframe API automation with UiPath
A more simple and efficient approach is to do an HTTP Request in UiPath direct to the Mainframe. We get the result in a JSON, which we can deserialize very easily.
Connect with me:
👥 Facebook - / andersjensenorg
💼 LinkedIn - / andersjensens
💌 Email Newsletter - andersjensen.org/email-newsle...
#uipath #rpa #mainframe
Thank you Anders. I have been looking for a demo to see how mainframe integration and automation is done using any of the RPA tools. It is just to see and learn, and finally got an opportunity to see your video. Its awesome. Thank you Russ for explaining it in detail. You guys are really doing great job on mainframe automation.
Thank you, Karthikeyan. I agree, Russ is awesome and very patient in explaining complicated things. I have a session more with him (and a more active and talking Jerry), I will post within the next few days 🙂 Thanks for all the support. Kind regards, Anders
@@andersjensenorg thank you Anders.. excited to see more videos on such stuffs.
I really enjoyed the demonstration. Very important point that was addressed is the Terminal Emulator and Screen Scraping methods used by the RPA platforms for Mainframe automation is brittle. Needs a lot of support and maintenance to have these solutions running on prod. But having a Restful service that can run on these mainframe clients would be absolutely incredible. It was great and I loved it.
Hey Sourav. Wow!! Simply just a message that made my evening :) Thanks a lot. Kind regards, Anders
Finally 😍😍😍 Thank you so much Anders sir !!! 😄
Hey Abhishek - Thank you very much 😀 Are you automating the Mainframe yourself? Kind regards, Anders
Great video. Sales pitches are great if they are relevant and this surdently is! Tak anders!
Thanks a lot, Casper 🙂
Please Anders can you do an automation itsm bmc remedy 🙏🙏 ..ideally which can automatically assign tickets if it is unassigned
Hey Ashwin. Thanks a lot :) At the moment I'm on paternity leave, but I will look into it, when I get back. Have a great day. Kind regards, Anders
@@andersjensenorg ok thanks..n congrats in advance
Thanks for this Mainframe demo. However, there are a few assumptions where Russ's conclusion are not correct.
Firstly, one should never do a measurement running in debug mode as a baseline.
Secondly, one should run the workflow unattended on the server connected right next to the Mainframe then you have minimal latency.
Thirdly, when you run a script on the mainframe to run the data then you may as well run the script via RPA.
Fourthly, there are so many companies running legacy mainframe applications they can't maintain because the people with the knowledge who did that have already retired. But since everyone still knows to operate these, RPA remains the fastest and reliable way automate it and capture all the data right away into the UiPath Data Service or any other Cloud Database.
Boris, I always like to have you around 😀 I've mailed Russ and asked him to comment. Thanks a lot!
Thank you for your comments! We welcome the opportunity for this dialogue. Our demonstration is a very small example of what occurs on a large scale within some enterprises. Using our analytics tools, we recently discovered a bot that ran for 5 hours on each of 4 servers. Each instance of the bot orchestrated 225,000 CICS transactions for a total of 1 million transactions. The underlying transactions only took 25 minutes to execute. But because the bot orchestrated these interactions via terminal emulation and screen scraping, each instance of the bot took 4.5 hours longer to complete than necessary because of the delays we demonstrated. Using terminal emulation and screen scraping at this scale makes no sense whatsoever. As a result, the organization is actively working to remediate this automation. With this background, let me respond to your comments.
COMMENT: One should never do a measurement running in debug mode as a baseline.
RESPONSE: We ran our demo in Debug mode so viewers could see what the bot was doing. Running the same bot/file (not in Debug mode) results in a time of 47 seconds: a 2 second reduction.
The improvement between modes is small because by default, UiPath imposes delays before/after each mainframe interaction. For example, when the object transmits data to the mainframe, it automatically imposes a 1 second delay before the data is sent, per the DelayMS attribute. Additional delays are inferred by the WaitType attribute, with the length of the delay at the discretion of the Terminal Session object. We can easily determine the minimum total delay imposed by the object by summing all the DelayMS values in the XAML file.
In the example we demonstrated, those waits total 29 seconds. This is the MINUMUM delay imposed by the Terminal Sessions object; it does not include the additional estimated 250 MS implicit delays due to the WaitType=READY attribute on each of the 50 Terminal Sessions object calls, for another 12.5 seconds. Combining the explicit waits (29 seconds) and the implicit waits (12.5 seconds) yields 41.5 seconds of total estimated wait time due to interaction with the mainframe via the Terminal Sessions object.
The remaining 5.5 seconds were taken up by either:
A. UiPath activity apart from the Terminal Sessions object.
B. Network latency.
C. Mainframe processing time.
In summary:
A. Debug mode is 2 seconds slower for that particular bot, but the delays due to Debug mode are inconsequential
B. When using the Terminal Sessions object to interact with the mainframe, significant delays are imposed due to the nature of using emulation and screen scraping as the means of interaction
C. Apart from the Terminal Sessions object (and all other external factors), UiPath is fast -- which is why we really like it!
COMMENT: One should run the workflow unattended on the server connected right next to the Mainframe then you have minimal latency.
RESPONSE: In an ideal world, we would agree! However, this is not how enterprise IT infrastructure is typically configured these days. The first customer who approached us 2 years ago for help optimizing their automations illustrates the current reality. Their mainframe is outsourced to a managed services provider whose data center is in Dallas. Their servers are outsourced to a different firm that maintains the hardware in Chicago. The customer doesn’t have control over where the hardware is located. All they can control is the speed of the network between them (in their case, it’s 1 gbps). As we see more movement to the hybrid cloud, we’ll continue to see this phenomenon of mainframes, servers, and users in different geographic locations. This is the norm in today’s hybrid IT world.
Considering the significant delays using emulation and screen scraping as the means of integration imposes, network latency is not the most significant factor (although all those discrete requests/responses really do clog up a corporate network). Running the HB.js demo using a PC on the same LAN segment as our mainframe would not change the outcome, because network latency is not the most significant factor imposing delay.
COMMENT: When you run a script on the mainframe to run the data then you may as well run the script via RPA.
RESPONSE: Here we disagree, and physics provides the basis of our difference. We demonstrated UiPath invoking a HB.js script running on the mainframe. That script ran the exact same mainframe transactions as did the Terminal Sessions object. However, since the script runs on the mainframe, interactions between the script and the CICS transactions occur at machine (memory-to-memory) speed. The HB.js script invoked and ran the exact same transactions in about 275 MS - total! Running the automation on the mainframe avoids the discrete requests/responses and exploits this speed. Network latency for each request/response is eliminated, and there are other significant benefits.
When interacting with screen-oriented apps via terminal emulation and screen scraping, you must impose delays, as the Terminal Session object does. Why? Because there is no general indicator in the 3270 data stream to signal the mainframe app has finished sending output and is waiting for input. As a result, the Terminal Session object necessarily imposes delays to ensure that an orderly conversation occurs. This is the nature of performing application integration via emulation and screen scraping.
By contrast, because the HB.js script runs on the mainframe within CICS, it has a much different relationship to application, with these benefits:
1. The 3270 data stream is eliminated. The HB.js script interacts with screen-based CICS apps in its “native tongue” using field name/value pairs, not screen row/column coordinates. Application integration via emulation and screen scraping is brittle. Even the slightest change to the screen layout of the mainframe application can cause the integration to fail. The RESTful service built with HB.js we demonstrated completely avoids the use of terminal emulation and screen scraping. This results in faster UiPath bots and more reliable automations. This method doesn’t require ANY application changes.
2. The interaction between the HB.js script and the mainframe app are stateful. HB.js scripts know the exact nanosecond when the app has finished sending output and is ready to receive input. Since there is absolutely no ambiguity about this matter, a HB.js script does not have to impose delays to second guess the intentions of the app. The response time and performance implications are huge. The Terminal Sessions object imposed over 40 seconds of delay because it had to in order to ensure an orderly conversation with the mainframe app. HB.js scripts run in the same context as the mainframe app, where things are very deterministic! This enables execution of the exact same number of transactions in a fraction of the time (275 MS).
COMMENT: There are so many companies running legacy mainframe applications they can't maintain because the people with the knowledge who did that have already retired. But since everyone still knows to operate these, RPA remains the fastest and reliable way automate it and captures all the data right away into the UiPath Data Service or any other Cloud Database.
RESPONSE: We agree and have seen firsthand the skills drain. However, it does not follow that an RPA platform must/should interact with legacy mainframe apps using terminal emulation and screen scraping. The RESTful services approach we demonstrated doesn’t require the integration developer to know anything more about the legacy application. Stated differently, the Terminal Sessions and RESTful services approach both live with the same assumption: the ability to operate the application is all that is required to create the automation. Either way, the integration developer simply needs to understand how to navigate the application.
Delegating the detailed mainframe interactions to HB.js is clearly faster and more resilient. We would argue that it’s actually easier to develop the automation than using the Terminal Sessions object. Why? Because the integration developer doesn’t have to specify all the details as to where fields are located on the screen.
SUMMARY
At HostBridge, we are RPA advocates and have no argument with UiPath or other RPA vendors. Enterprises should embrace RPA and use it to automate business processes, including those that run on the mainframe. However, using terminal emulation and screen scraping as the means of bot interaction with the mainframe is a step backward. At scale, it’s an approach that is slow, expensive, and fragile. Even if the mainframe apps never change, using emulation and screen scraping as the means of integration is slow and costly.
When an organization wants to use RPA to interact with screen-based applications at scale, the default method (Terminal Sessions) is slower, less efficient, and more expensive. The RESTful services approach we demonstrated is highly complementary to UiPath, performs better, uses mainframe cycles more efficiently, and lowers mainframe costs. RESTful services are easy to create using HB.js and easy to invoke via UiPath.
Note: for a more detailed version of this discussion, visit the HostBridge blog.
@jensen have you guys worked with SSH uipath integration?
Hey Avik Pal
Thanks for writing. I'm getting more than 40 questions/comments every day and having difficulty answering everyone (I try my best).
I've created my UiPath Groups, where we all can post and solve problems or hang out around our favorite tool, UiPath. So you're very welcome. Get the addresses here: ruclips.net/video/C6xmGfEL07I/видео.html
Have a great day.
Kind regards,
Anders