IBM i and .Net Connectivity With XMLSERVICE

Many businesses are looking for ways to modernize their IBM i applications while maximizing their existing code investments in RPG or COBOL applications. Some contend that using Microsoft development technologies is a bad way to go. They think it promotes replacement of existing IBM i applications or of IBM i itself.

My position has always been that PCs and Microsoft technology are a great way to enhance existing IBM i applications. XMLSERVICE and Microsoft Visual Studio are open source technologies your company can use to modernize, enhance, and augment your existing IBM i code base.

Using Microsoft .Net with XMLSERVICE could ultimately show your management team that your IBM i applications can nicely play with the outside world without ripping and replacing existing systems, thus keeping IBM i firmly anchored in your shop as a long term back-end business server for your desktop, web, and mobile applications.

A Bit Of Connectivity History

My journey with IBM i system connectivity and PC integration started in the late 1980s, when I was asked to help connect a DOS application screen from a Turbo Pascal application to a 5250 screen in a System/36 application so a single data value could be captured from the PC app into a 5250 data entry field. The idea sounded so simple, but at the time nobody was connecting PC applications and 5250 applications. Unbeknownst to me, that one task would launch a career-long interest and journey to help connect PC and IBM i applications and make application developers more productive. This skill set also helped me launch a successful business based on connecting PCs to AS/400, and later IBM i, that would keep me busy with system connectivity for the next 20-plus years. I continue to use my system integration skills daily in my job as director of Document Management Technologies at HelpSystems.

By 1993, the only good way to connect PC applications to AS/400 data was to use PC support with the associated HLLAPI screen scraping or APPC communication APIs. This architecture allowed RPG applications to talk to PC programs. Windows 3.1, Microsoft Visual C/C++, and Visual Basic 3 were the only game in town for building applications to connect a PC to the AS/400. TCP/IP had not been released yet for the AS/400, and IBM had not released any of the system APIs that would later open up the machine to the outside world and the Internet.

Connectivity progressed from HLLAPI, 5250 screen scraping, and the PC support APPC communications APIs, to TCP/IP, FTP, socket applications, and the IBM i database access drivers, and then to HTTP-based Web services as universal communicators. Using Web services is currently the most popular way to communicate with backend systems because Web services typically take in a universal URL, XML, or JSON data stream as HTTP requests and return data. Since all programming languages can make HTTP calls, Web services are the communication method of choice for many web and mobile applications that need to access data remotely or on premise.

As the Microsoft development environment has progressed, something very interesting happened that I find exciting for developers of new applications. Along with XMLSERVICE for data access, one of the compelling reasons to consider writing your modern applications with Microsoft .Net is the fact that the Visual Studio development environment now has a freely available open-source version called Visual Studio Community 2015. Visual Studio Community is the equivalent of the purchased Visual Studio Professional version and is meant to help developers get started with .Net development without any cost. You can use Visual Studio to develop Windows desktop and tablet applications, web and mobile applications, Web services, windows services, MS office add-ins, and more, and all of them can take advantage of live IBM i data. Because of all the application development options, you can use Microsoft .Net for much of your future development. .Net also has a pretty low learning curve.

Background on XMLSERVICE

This brings us to using XMLSERVICE. One of the technical challenges I undertook with some of my personal time over the past two years was to write an open source .Net wrapper layer for the XMLSERVICE API so that .Net developers could begin to use the XMLSERVICE data access APIs from Microsoft .Net without the overhead of installing IBM i Access. I chose to build my wrapper around the XMLCGI interface to XMLSERVICE, which is utilized by exchanging XML packets with the XMLSERVICE API via HTTP post operations. I wrapped all the plumbing so that a .Net developer simply provides a system name or IP address, user, and password and any relevant information to query or update database records or call a CL command to run a job in real-time or submit to batch. XMLSERVICE also lets you call existing programs and stored procedures to pass parameters in and out of an IBM i program similar to the call/parm methods we’ve used for years in RPG and CL. Additionally you can read and write information to data queues, which are a popular IBM i method for queueing data for processing.

As a bit of background on XMLSERVICE itself, my understanding is that Tony Cairns from IBM wrote the open source XMLSERVICE data service layer for IBM i with a little help from others. XMLSERVICE was meant to be an open-source RPG-based, language-agnostic service for allowing applications that can talk to IBM i data services via XML to be written in any language. This method was meant to bypass the traditional overhead of deploying the IBM i Access ODBC drivers for Windows applications or JT400 drivers for Java applications. XMLSERVICE currently has available wrappers for utilizing the data services of IBM i from PHP, Ruby, and most recently Node.JS. Because of my many years utilizing Microsoft development technologies with IBM i to modernize applications, I felt it was important that developers not write off Microsoft technologies as proprietary and bad for IBM i. For that reason, I wrote the XMLSERVICE .Net wrapper to round out the available technology choices for XMLSERVICE.

Getting Started with XMLSERVICE and .Net

Since I chose to utilize the XMLCGI interface for XMLSERVICE, you will need to install the XMLSERVICE library on your IBM i and create an Apache web server instance to funnel calls to the XMLSERVICE program. The first place to visit if you’re interested in setting up XMLSERVICE on your IBM i is the YiPS site, which contains links where the source library can be accessed and can be found here. From the YiPS site you will want to download the current save file, which is located here. After downloading the library zip file, follow the instructions to unzip, upload, and install the XMLSERVICE library located here.

The installation instructions cover uploading and restoring the XMLSERVICE library as well as building the binary program objects that XMLSERVICE needs. The install page also has a configuration section that covers setting up an Apache HTTP server instance by editing the httpd.conf file to set up a CGI link to the XMLSERVICE program. You can also utilize my “Using XMLSERVICE with .Net” presentation slides located at the following link for Apache set up for XMLSERVICE step by step: http://downloads.rjssoftware.com/files/classes/2015/IBMiDotNetWithXMLService.pdf. I typically set up an XMLSERVICE Apache server instance to run on TCP/IP port 30000. Feel free to change the configuration settings as you see fit.

Next Steps

Now that you have the XMLSERVICE program and XMLSERVICE Apache instance set up and running on port 30000 of your IBM i system, I’m sure you’re ready and chomping at the bit to get started playing with some .Net code samples that interact with XMLSERVICE. The XMLSERVICE for .Net API wrapper source and an intro presentation can be downloaded from the following site where I have placed the sample presentation, library save file, and .Net code source: http://downloads.rjssoftware.com/files/classes/2015/xmlservicei-20151203.zip. The ZIP file contains a sample save file for a library named: XMLDOTNETI. We will be using the XMLDOTNETI library programs in a future article. It also contains a readme file named readme-xmldotneti.docx, which gives an overview of how to set up and get started if you want to jump ahead.

In the next article I will provide a dive into the functionality of the XMLSERVICE wrapper API to give you more insight into how it is built and how to use it appropriately. Until then, get XMLSERVICE and Visual Studio loaded up and running (www.microsoft.com/express) and jump ahead if you are feeling ambitious.

Richard Schoen is Director of Document Management for HelpSystems where he spends his time helping customers learn about automating document based processes and implementing automated business processes and system integrations using all of the HelpSystems products. You can contact Richard via email email with questions, comments or article ideas. You can also find Richard on Twitter (@richardschoen) or LinkedIn.