Automate Your Mainframe With Any RPA Tool

Robotic Process Automation (RPA) provides a quick and inexpensive way to automate business processes. But there’s a catch. You can’t, and shouldn’t, automate all processes. There are specific processes that are better suited for RPA than others. There are some processes that simply can’t be automated with RPA.

Forrester’s Rule of Five

According to Forrester, there are certain attributes associated with business processes that make them more appropriate for RPA. Forrester’s Rule of Five suggests that you should look for tasks with fewer than:

  • Five decisions made
  • Five applications accessed
  • Five hundred clicks

Mainframe Automation

Some also believe that there are certain types of data sources that are difficult to automate. One of those is mainframe applications using “green screens”. These applications require a desktop terminal emulator for users to interact with the applications, and the navigation of these applications can be very complex. Most mainframe applications wouldn’t meet Forrester’s Rule of Five.

Emulator Interaction

The way RPA tools automate mainframe applications is to interact with the same terminal emulator used by end users. There are typically two ways to interact with an emulator and many RPA products only support one of them. The two ways to interact with an emulator are:

  • Extended High-Level Language Application Programming Interface (EHLLAPI)
  • Screen scraping the emulator screen

EHLLAPI is much more accurate than screen scraping but is still difficult to use and doesn’t provide full functionality. Also, depending on the age of the emulator, it may not support the same calls built into the RPA tool. Because of this complexity, as well as the complexity of the mainframe processes, many RPA companies consider automating mainframe processes to be an advanced feature that requires a more advanced programmer.

Some RPA tools use screen scraping which is the same way they interact with Citrix applications. You have to know the screen coordinates of objects and data in order to interact with the screen. This is very inaccurate and should only be used as a last resort and for very small tasks.

There’s A Better Way

There is another way to automate mainframe applications, and it works with your existing RPA tool. Instead of interacting with a terminal emulator, why not interact directly with the mainframe the same way a terminal emulator does? OpenConnect has been providing mainframe connectivity products for many years and has the technology to automate mainframe applications without a desktop emulator.

How it Works

OpenConnect technology connects to the mainframe using TN3270, the same protocol used by terminal emulators. The software maintains a persistent session with the mainframe and handles all of the screen mapping. The difference is there is no actual screen. Everything is in memory and the raw data is processed directly instead of sending to a screen for human, or robot, interaction. This reduces overhead and dramatically increases performance.  Because it’s server-based, it will support thousands of concurrent sessions on a single platform.

ConnectiQ is a product that includes this technology and works well for integration with RPA tools. ConnectiQ does not rely on an API to interact with the mainframe application. It has access to the raw 3270 data, so it “sees” every attribute and every character making it more accurate than technology that uses an API or screen scraping.

Design Tasks Without Code

A task designer tool called Configure is provided to create the tasks that interact with the mainframe screens. It’s designed to be used by people who know the applications and processes, not programmers. Configure allows you to create tasks that perform common functions. Tasks can call other tasks allowing for reuse of common functions and reduction in time to deliver value. Once the tasks are complete, you simply deploy to the server and mark it as available to the services. Version control is provided natively and allows you to support multiple versions for each environment.

Users can access the tasks through web service calls using SOAP or RESTful services. This allows customers to integrate mainframe application data into any application including customer portals, mobile apps, front-office applications, back-office applications, and RPA robots.

ConnectiQ Provides Flexibility & Value

RPA tools provide methods to call web services to retrieve information. ConnectiQ provides the complex navigation of mainframe screens with high accuracy. Whether the mainframe applications are 10% of the process or 100% of the process, ConnectiQ is the right solution to embed mainframe applications into your RPA strategy. The tasks you create for RPA can also be used for other external applications such as customer/partner portals which provides even more value.

Mainframe Modernization: Start With the User Interface

What is mainframe modernization? It depends on who you ask.

The mainframe is an interesting beast. In fact, just as the term mainframe modernization means different things to different people, so does the term mainframe by itself. The core of the mainframe includes the operating system, applications, and access interfaces.

Let’s take a standard mainframe environment. The mainframe is running CICS or IMS. Users access the applications using a terminal emulator, also referred to as a “green screen.” If you talk to a system architect, he might use the term mainframe modernization to mean converting back-end applications to be more modern. If you talk to an end user, he/she will tell you it means an easy-to-use graphical interface. Those are two completely different visions.

Most large organizations’ IT departments take the architect’s view — modernizing the back-end mainframe. This could consist of converting COBOL code to Java, or running COBOL applications under a Linux environment, or converting the database from IMS to DB2 to make it easier to integrate with external applications. All of this takes time, possibly years, and lots of money. So, you have to ask the question: “What’s the goal?”

Hide in Plain Sight

If the goal is to reduce costs, you should look at the back end to find ways to modernize and reduce MIPS costs. However, if your goal is to improve productivity, usability, and overall cost of operations, you should consider updating the front end (user interface) first. To do that, you need a layer of abstraction. That’s a software layer that understands how to communicate with two different layers while hiding the layers from each other. As an example, you could have a modern Web-based user interface that communicates with legacy “green-screen” applications. The UI doesn’t know it’s communicating with “green screens,” and the “green screens” don’t know they’re being converted to a Web interface.

Here’s how you might implement this solution. You want to first design your user interface without regard for the mainframe’s communications protocol or architecture. Simply design your user interface using standard UX practices. Now, you need a layer of abstraction — a layer that knows how to talk to the mainframe, using the standard native protocol, and communicate with the new user interface. If you decide, as most companies do, to create a Web-based user interface, you would use the standard Web architecture used by all your internal Web applications. Maybe you use J2EE or Microsoft, or maybe your standard is Struts or Ruby on Rails. Whatever it is, just design your Web application the same way you would if it were using a standard relational database.

Can We Talk, Mainframe?

Now you need a way to communicate with the mainframe “green screens.” There are several options available. OpenConnect has one called ConnectiQ. It’s a server-based platform that communicates directly with the mainframe, using the TN3270 protocol. It consumes the raw 3270 packets and interprets them in memory. It then converts that information into standard Web services that can be called and consumed by your Web application. The user interface doesn’t know it’s talking to an old legacy mainframe application, and the mainframe application doesn’t know it’s communicating with a modern Web-based user interface. In other words, you have a layer of abstraction; get it? In this case, the layer of abstraction is ConnectiQ. The Web application simply communicates with ConnectiQ, using standard Web services.

Why is the layer of abstraction so important? Because, once you have the new UI in place, you can start working on modernizing the back end applications, databases, and network interfaces. Again, that could take years, but you already have a nice, intuitive, easy-to-use, easy-to-learn user interface which should be saving money; so maybe the urgency isn’t quite as great.

The key is: once the back end is modernized, you simply change your layer of abstraction so it now communicates with the new back end. Users don’t see any changes — other than, perhaps, better performance. In the example above, you would remove ConnectiQ and use different Web service calls in your Web applications. This approach also allows you to modernize a little at a time. You can move an application, or function, at a time and have a mixture of Web service calls to ConnectiQ and the new mainframe interface. Again, the users don’t know the difference. They’re just using a nice, new, modern interface.

The benefits of this approach are numerous — including improved user productivity, simpler and faster training to bring people onboard more quickly, better and more timely customer support, and access from any Web browser so work-from-home users don’t need any special software.

Macros, Schmacros

Let’s also talk about a very serious problem related to mainframe terminal emulators: macros!

Almost all terminal emulators provide a macro interface that allows a user to press a “Record” key and record a set of keystrokes. She can then play back the recording any time. For example, a common problem is copying data from one screen onto another one. The macro would be recorded to navigate to the first screen, copy specific fields, navigate back to the original screen, and paste the data into that screen.

This option saves a lot of time, and users can create their own macros. However, that’s actually the problem. You end up with hundreds or even thousands of user macros running. Most aren’t written correctly. Macros are not “intelligent,” and have no way to know if they’re working correctly. If a user hits the “Play” button while on the wrong screen, the macro is still going to try to run. In some situations, this can actually cause harm.

So, why am I talking about macros in a mainframe modernization blog post? Simple: if you modernize your user interface, you can provide the same benefits that macros provide without the risk of users creating their own, possibly harmful macros. You now have control.

Users will ask for changes that help them be more productive. That’s great, and now you have a centralized way to provide those changes. The best part is that all users benefit, not just the one person who knew how to create a macro.

Front First,Back Last

Here’s the bottom line. Please your users first to improve quality, reduce costs, and improve employee satisfaction. Then, look for ways to modernize your back end. But remember, you don’t have to modernize your back end after you modernize the front end. If users are more productive and operations costs are down, you already may have achieved the results you sought. Also, you already know how to maintain the back end. So why introduce new technology, processes, and procedures if you don’t have to?