Many of you probably remember my last, unforgettable TECHniques article about webMethods ApplinX – “Moving to the Cloud, reaching for the stars - published in the first issue of 2020. What? You don’t’ remember this over all the events and challenges of this past year? I can’t imagine. Well let me take this opportunity to remind you a little of what the ApplinX team worked on during 2020, despite the crisis, and will be delivering with the April 2021 release.
In a nutshell, we kept YOU in mind and delivered features and functions that would, hopefully, make YOUR life easier, such as:
- Giving you the freedom to choose your own front-end technology for your web application with REST APIs—so you can detach the ApplinX logic from your web application technology.
- Printing directly from the host, without the need to install Java on new client machines, or update Java versions on existing client machines every time a new version is released.
These are just two examples on what we’ve worked hard on this past year, so that you won’t need to work as hard.
With the release of ApplinX 10.7, you have a whole new approach for using ApplinX web frameworks. Until this release, you only had the web application framework in Java®/JSP or .NET® to select from to develop your web enablement solution.
Our new REST APIs allow for direct communication with the ApplinX server to CONNECT and DISCONNECT a session, GET a screen, UPDATE a screen and SEND KEYS to the host. The response can easily be incorporated into a front-end application of your choice. This can be Angular, React, or any other framework you choose. It’s completely up to you or your organization.
The new REST API supports SWAGGER so you can use your favorite SWAGGER editor to easily get all the information about the operations and models of the API or to generate an out-of-the-box new client (in your favorite language) that consumes the API. You no longer need to worry about aging web applications that need to be updated based on someone else’s schedule. You won’t need us to fix any occasional bugs or missing functionalities, you get FULL responsibility and ownership of your front-end solution.
Figure 1: The ApplinX REST API as shown in a SWAGGER editor
Now let us explore what’s possible with this new approach. Well, everything is possible.
We like to think of modernization as a spectrum. On one end you have a fast, “instant” solution—a one-to-one HTML representation of the host screen rendered on the fly by the ApplinX server. On the end of the spectrum, you have a fully modernized web application that no one would ever know that there’s a legacy green-screen application working behind the scene.
As seen in Figure 2, the “instant” version of a screen, in this case, a list of Yachts, is an HTML page.
Now let’s take the same screen and modernize it using Angular. The more eye appealing and user-friendly result can be seen in Figure 3.
Figure 2: The “instant” version of the Yacht-List screen
Figure 3: The “modernized” version of the Yacht-List screen
Can you believe it’s the EXACT same screen? We didn’t change anything in the green screen application, ApplinX takes the same data from the host and you can just reuse this data to populate it into this modern front-end framework.
In this next example, you can see the standard search functionality of the application in the “instant” format (Figure 4) and the “modernized” format (Figure 5). Which version do you think your users would prefer?
Figure 4: The “instant” version of the Search screen
Figure 5: The “modernized” version of the Search screen
Of course, there are many possibilities in between. As I mentioned – it’s a spectrum. Using wizard-based GUI transformations or other customization options allow you to continuously work on the application at your own pace – combining instant with modern frameworks. It’s not an all or nothing approach, you choose which parts of the application are modernized first to best accommodate your users.
The print solution of ApplinX is evolving. ApplinX previously handled print sessions using applets but when the leading browsers stopped supporting it, we had to support a different technology – Oracle’s WebStart. Now, as this technology is being deprecated, we went back to the drawing board and re-designed the print solution, and as always, with our customer’s best interest in mind.
To address one of the main complaints about the requirement to install Java on the client machine, we have moved the print session to the ApplinX server. Installing and maintaining Java versions on each client station was time consuming and required the organization to handle and maintain sometimes hundreds of stations. By moving the print session to be handled by the ApplinX server itself eliminates the Java requirement and makes the whole implementation easier.
We have added 3 new APIs to the existing baseobject APIs: GXActivatePrinterRequest(), getPrints() and endSession(); and using these will give you an additional means of activating IBM Z or IBM i AS/400 printer sessions. This approach is “zero-client footprint”, that is, there is no software footprint on the client platform. The code snippet in Figure 6 provides an implementation example.
Figure 6: Code example of using the Print API
Another exciting improvement coming with ApplinX 10.7 in April 2021 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.
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 Integration 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
The new screen-testing 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. ApplinX 10.7 allows developers to develop full DevOps-ready solutions that integrate into your company’s Continuous Integration/Continuous Development process.
Figure 7: The ApplinX ‘Manage Test Data’ editor with an illustrated JUnit Tests results.
ApplinX is also cloud-ready as of version 10.5. 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.
Those of you who are familiar with ApplinX already know that it is ideal for any UI modernization or API enablement project, 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.
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 experience 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).
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 or COBOL 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!
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. You can see an illustration of how ApplinX works in a Docker-Kubernetes environment in Figure 8.
Figure 8: ApplinX deployed in Docker containers on a Kubernetes cluster
Gadi Benedek is a Product Manager in the Application Modernization unit at Software AG. He has been with Software AG since 2005 and is involved in multiple development projects focused on application modernization and integration. He is responsible for development strategy and management of webMethods ApplinX, Natural Screen Tester, webMethods JIS and webMethods JAI products.