webMethods ApplinX

Many of you already know how webMethods ApplinX can modernize and transform your outdated and cumbersome green screen user interfaces and workflows into modern web interfaces and APIs that will improve your end users’ interactions with your core applications, improving their overall productivity.

I would like to take this opportunity to bring you up-to-date on some of the major enhancements to webMethods ApplinX 10.7, which will be available October 2020.

Cloud ready. Now!

Before we start talking specifically about ApplinX in the cloud, let’s review some of the many reasons why businesses are moving to the cloud. They all seem to share a common theme: Better efficiency and lower costs than operating in on-premises environments. You’ll be surprised to hear that it isn’t JUST about money, although businesses are always interested in cutting costs. The main drivers of cloud migration are disaster recovery, scalability, high availability and ease of management. I think it’s safe to say that the cloud has matured, it is reliable and has been tested thoroughly - so you no longer need to be a guinea pig for an unproven technology.

When we talk about cloud ready, we’re talking about running the ApplinX server, together with a browser-based, fully functional web emulation, on a Docker container.

For those of you not yet familiar with containers, they are an abstraction at the application layer that packages code and dependencies together. Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes in user space. Containers take up less space than Virtual Machines (VMs)—container images are typically tens of megabytes in size. Containers can handle more applications and require fewer VMs and Operating Systems.

Those of you who are familiar with ApplinX already know that it is ideal for any UI modernization or API enablement projects, whether you have a mainframe with COBOL or Natural applications. It’s also great for rehosting projects for those moving to Linux and looking at container and cloud environments for deployment. It makes no sense to move to a modern platform without also modernizing your user interface. ApplinX can easily provide that and much more.

Running ApplinX as a Docker image allows you to free yourself from installations, configurations, scalability issues - and basically simplifies the whole experience. The functionality stays the same; your end-users will not feel any difference, but the administration of it all, behind the scenes, will make all the difference. Cloud deployments, compared to on-premises installations, are cheaper to maintain, more flexible and agile, less complicated and therefore require less professional know-how. These benefits result in a reduced total cost of ownership (TCO).

ApplinX Web Emulator as part of the ApplinX Docker Image

Starting with ApplinX 10.5, it is very easy to create an ApplinX Docker image to use as a fully functional stand-alone, browser-based web emulation, or as a front-end for your Natural applications running on Linux.

Once you create your image by running a simple script, you can deploy it inside your Docker environment and run it. The whole process takes less than two minutes!

Your web emulation is now running and ready to be connected to your host application. By configuring all the connection details on a web configuration editor, your end users can connect to your application anytime from anywhere.

But that’s not all! Combine your web emulation with a container orchestration tool like Kubernetes and you can easily deploy ApplinX in a server-farm configuration and scale for thousands of users, without worrying about port configurations or load balancing.

Kubernetes makes a cluster of machines behave like one big machine, vital in a large-scale environment, and basically simplifies the administration of many containers spread across clusters of servers. Its filtering and scheduling system selects the optimal nodes in a cluster to deploy containers.

Docker and Kubernetes work together while serving two different purposes. Docker is a platform and tool for building, distributing and running containers. Kubernetes is a container orchestration system that coordinates clusters of nodes to scale production efficiently. It works around the concept of pods, which are scheduling units (and can contain one or more containers) in the Kubernetes ecosystem, that are distributed among nodes to provide high availability.

In the figure below, you can see how ApplinX works in a Docker-Kubernetes environment:

Screen-based test automation for business functions

One of the most exciting things coming with ApplinX 10.7 (in October 2020) is the ability to create automatic unit tests from existing or new procedures. The new Screen Tester within ApplinX tests what is happening on the screen at the business level for any programming language (e.g., Natural, Cobol, RPG, Fortran, PL/I, Assembler) on the supported terminal protocols shown in Table 1.

Table 1: Screen Tester Supported Protocols

This new testing capability allows you to:

• Use your existing developed procedures and auto-convert them into unit tests
• Record the flow of green-screen-based business functions and auto-convert them into unit tests
• Build executable test cases that can be shared across teams and environments
• Record the tests once and provide test assertions—files that contain the input and output parameters that allow you to run a test using different sets of inputs to test all possible combinations
• Run tests quickly and visibly see results
• Support Continuous Delivery by integrating your tests into a build server and running them with every new build (DevOps)
• Allows you to ensure that new developments don’t break existing screen flows

Let me demonstrate a simple test scenario with a Human Resources (HR) application. In the HR application, I go to certain screens and enter the input data for adding a new employee. Then, at the end, I check to see if the employee has been entered correctly into the system. To test this, I store the input parameters and the output parameters in a separate test data file. The same test can run multiple times against multiple test data files.

The new screen tester capability simulates the business user by feeding input data into the business objects then compares the results of the business function against the output data expected. If every character on the screen was compared (i.e., tested), the UI definitions would need to be very detailed. By only testing what is important—input and output—we have saved a tremendous amount of time and cost by eliminating the need to detail entire screens prior to test runs. This approach enables the ApplinX developer to determine what is important. With automated screen-based testing, you will spend less time doing routine tasks and release software faster.

Screen Tester will be added to ApplinX 10.7 (October 2020) and will allow ApplinX developers to develop full DevOps-ready solutions that integrate into the company’s Continuous Integration/Continuous Development process.

Author Bio

Gadi Benedek is a senior R&D Product Manager in the Application Modernization unit at Software AG. After joining Software AG in 2005, Gadi has led multiple projects focused on application modernization and integration, including webMethods ApplinX, Natural Screen Tester, webMethods JIS and webMethods JAI.