Overview

Robotic Process Automation (RPA) is a fancy new buzzword for well-established approaches and tools aimed at improving operational efficiency for simple data entry tasks. It started as a set of basic screen scrapers and script execution tools back in the 80s and 90s, and gradually grew into robust modern platforms offering rich process engineering tools, often complimented with image recognition and AI-based just-in-time decision support. At the same time, these RPA platforms and surrounding services do take some time to launch and scale, and tend to be rather expensive. We developed IBM i infoRPA connector as a lightweight and easy-to-implement alternative or a supplemental tool that customers can leverage to, for example, quickly develop an API that interacts with IBM i (formerly known as AS/400, iSeries) green screen application directly from within Mulesoft app.   I’ve seen quite a few articles lately listing various underlying scenarios in different verticals, repeating the same point that manual steps are error-prone and automating them is generally a good idea. If you enter your dealer requests in both CRM and legacy applications, automating it would be much better. If you are in the insurance domain and manually create or update claims, automating it would improve the process. If you operate a hospital and have to key in the same chart data into three different systems, RPA could help. And so on and so forth. In this article we will walk through just one use case, entering or updating the sales order. I am confident our readers have the sufficient mental capacity to extrapolate the scenario we discuss here to their respective industries and contexts without trying to list them all here.   

Use Case 

Suppose we are a distribution company and our Warehouse Management System is a commercial off the shelf IBM i based application. Most order entry and fulfillment operations require some sort of manual data entry via terminal emulators or specialized scanners. As our business scales, we are looking to automate the order entry and status update based on the external events originating in CRM, eCommerce, or other sales channel applications.   We decided to create a REST API that the external systems could call with order data, and pass that information to the green screen ERP. We don’t want to introduce another system, operate additional infrastructure or invest heavily into specialized RPA tools. We just want to “call” the green screen apps directly from our Mule app, pass the data into it, and get the results back.  

API POST Request — Create an Order

This is a simple typical REST API that takes the order details as input, creates an order, and returns back the newly generated order ID. Below is an example of API request and response:
Request Response: 

IBM i green screen flow 

When a user works with the back-end ERP, they first select or create a new customer, then create new order for that customer. Below are sample screenshots for a test ERP we used for this demo. The real-world ERP screen flow will likely be different but it gives you an idea of how the infoRPA connector works:  

• The first user needs to log into IBM i terminal emulator and add the required libraries to the library list (in most cases this is done automatically as part of the login script and default library list associated with each ERP user ID) 

• We call the ERP order maintenance program and need to provide or look up a customer ID. This will be a starting point for our order entry flow. We will return back to this point after each order is created via the RPA script.  

• Upon entering a customer number to be created or updated, we are directed to the Customer Orders screen.

• The user must press F6 to create new Sales order, then enter multiple order line items 

• Once all order lines are completed, the user presses F10 to submit the order  

IBM i RPA connector for MuleSoft 

We will leverage Infoview IBM i RPA connector to simulate the user actions we went through above, map the input and output data into script variables, and implement basic flow controls such as loops and conditional processing. The connector is intended to be very straightforward and does not require any special knowledge of the IBM i internals.  

Connection Configuration 

The connection configuration includes the positions for the user ID and password and supports both open text and TLS connections, and an initial set of commands that can be executed each time a new connection is established (i.e. new user is logged in). The connection can be reused between the calls to improve overall performance, as user login is a rather expensive operation.   

Connector Operations 

The connector supports the in-line command string and external macros. The command string can be static or a variable and represents a sequence of comma-separated keyboard actions (such as keys, data typed into input fields, or capture of the areas of output screens). This could support simple screen navigation flows. In case user interactions are more complex and require dynamic flow controls such as loops or conditional processing, the connector supports Python-based macro scripts. Both simple operational sequence and Python macros support mapping the input and output parameters to Mule variables, making it easy to pass the data to green screen bots and to get the results back to the Mule app.  

Sample Mule Flow

Execute Script Config: 

Key String (Full):

“call cdcordcmtc,[enter],[SET_INFIELD 29 10],:<uri>,[enter],[enter],[pf6],[MACRO],[pf10],[GET_SCREEN 15 4 8 1 orderNum],[GET_SCREEN 2 24 13 1 orderStatus],[pf12],[pf3]” 

1. call cdcordcmtc – enters this string into the first default input field (same one as shown in a screenshot above) 
2. [enter] – simulates pressing enter key 
3. [SET_INFIELD 29 10] – sets the input field to the location at X: 29, Y:10 on the greenscreen 
4. :<uri> – a ‘ : ‘ followed by text within <> symbols indicates an input parameter. The connector will search the input parameters for a key matching the text within the brackets. If the key is found, the ‘:<uri>’ in the keystring will be replaced with the value associated with the key. 
   1. In this case the URI param of value ‘7777’ is used, and is placed as a string in the new input field  
5. [enter] – simulates pressing enter key
6. [enter] – simulates pressing enter key, sometimes two enters are needed to appropriately progress the screen  
   1. this is a tn5250j issue, not a connector issue 
7. [pf6] – simulates pressing F6 key 
8. [MACRO] – Runs the Python Macro file referenced in the ‘Macro File’ input field.
   1. 1. The file itself needs to be stored in the src/main/resources folder of a mule project
      2. File contents:

   

   1. 1. Runs using Jython. The code above is the Jython code utilizing the Tn5250j java library (the same library as our connector uses).  
   2. 1. Macros should be saved for more advanced green screen interactions. Utilizing if statements, loops, etc. To execute an action. 
   3. 1. The code above uses an input parameter specified in ‘Macro Input Parameters’ (which is the payload from the API request) to loop through items and write their contents to the greenscreen. 
9. [pf10] – simulates pressing F10 key 
10. [GET_SCREEN 15 4 8 1 orderNum] – Grabs the text within a rectangle and stores it in ‘orderNum’, which can be found in the attributes.screenOutput field of the mule message as a java HashMap. The rectangle in this example is: 
    1. Top Left corner -> X Pos: 15, Y pos: 4
    2. Length: 8
    3. Height: 1
11. [GET_SCREEN 2 24 13 1 orderStatus] Grabs the text within a rectangle and stores it in ‘orderStatus’, which can be found in the attributes.screenOutput field of the mule message as a java HashMap. The rectangle in this example is: 
    1. Top Left corner -> X Pos: 2, Y pos: 24
    2. Length: 13
    3. Height: 1
12. [pf12] – simulates pressing F12 key 
13. [pf3] – simulates pressing F3 key 

Conclusions

As you can see, it is fairly straightforward to automate the manual IBM i green-screen data entry directly from within the Mulesoft app, with no need to purchase, implement and run any additional systems or applications. We decided to open source this product to make it accessible for mid-market and SMB IBM i customers that could not otherwise afford comprehensive but expensive and difficult-to-implement commercially available RPA tools. Everybody can try and operate our RPA connector for free, however, we do offer rapid implementation services, commercial support, and custom feature development. Please contact our sales team to schedule a quick demo and discuss the details. Below is the link to the connector documentation and the sample MuleSoft demo application we reviewed in this article.