WEBINAR

All right, everybody, we’re going to go ahead and get started. It’s one minute past. Thank you for being here. Good morning, good afternoon, and evening, everyone. Welcome to today’s webinar, Using APIs to Empower Your RPG. By the end of this session, we hope your imagination will be opened up, a whole new world of APIs that can work with your IVMI application. My name is Mitch Hoffman, and I’ll be your moderator. I’m so excited to be hosting over 100 people on the webinar today. Our speakers are Dan Magid, well-known in the world of IVMI because of his long history working in the community. He’s presented at hundreds of webinars, spoken at dozens of conferences globally when that was a thing in person, and is a regular published author of articles around open source, cloud, DevOps, APIs, and, of course, the IVMI. Dan began his career at IBM working with System 34s and went on after his father, Al, of Aldon, to take the helm of the business before becoming CEO of Eradani and moving into the open source world. Aaron, our second presenter, has been working with open source for over a decade. He leads Eradani’s open source team. In fact, he wrote his first open source project for IVMI when he was 14 years old. Aaron is proud to be a fresh face of IVMI and a 2020 IBM champion, and is a third-generation Magid carrying on the traditions of our great platform. Now, before I hand the session over to our speakers, a couple of quick points. Number one, our webinar is being recorded. We’re going to email a link to the replay at the end of everyone’s session. Please feel free to share with your peers. And number two, once again, we’re breaking attendance records, so we’re not going to be able to do live Q&A, but please chat your questions to us. At any time, send your messages to the panelists, and we will go through them at the end of the session. The chat window is on the bottom of your screen in Zoom, and in the bottom right, you can type. We’ll go through as many as we can at the end of the hour. Now, without further ado, I’m going to kick things off by welcoming the chief evangelist of Eradani, Dan Magid. Dan, over to you.

Great. Thanks, Mitch. I appreciate the introduction. All right. We’re going to be going through a whole lot of stuff. We’re going to be moving really quickly today. I know for those of you who are on the East Coast of the United States and in the center of the country, this is kind of lunchtime, so it’s time to wake up because we’re going to really move. Oh, anybody who’s ever heard a presentation that I do knows that I like to start with this slide, and that is the slide of the mythical IBM i versus the real IBM i, and people who think of the IBM i as a green-screen-only system limited to RPG and COBOL and CL and DB2, there’s so many more things you can do, so that’s the mythical IBM i. The real IBM i is I can do just about anything on the IBM i that I can do on any other platform. I can build modern user interfaces. I can do mobile. I can do web, and I can create APIs, so I can use APIs to integrate my IBM i with the greater ecosystems of applications across industries, and that’s what we’re going to talk about today. So, I’m going to talk a little bit about why, why do you want to do APIs, what are the benefits to you, and then we’ll talk about calling IBM i APIs from open source, so calling into the IBM i and then calling out from the IBM i to APIs, talk a little bit about the synchronous world of the IBM i versus the asynchronous world of the API environment, and then we’re going to go through several real-world examples. When I’m done going through the PowerPoint, then Aaron is actually going to give you a demo of doing this, so he’s going to show you how you can quickly create APIs both to call into your IBM i and to call out from your IBM i, and he’ll talk a little bit about how you manage that kind of development. So let’s get into it. So, I always like to start an API presentation with this. This is a memo that Jeff Bezos sent out to everybody at Amazon back in 2002, and what he said was, from this time forward, all development teams will expose all functionality through services interfaces, and there’s some details about technically how to do that, but down at the bottom here, you can see number six, anyone who doesn’t do this will be fired. Thank you, have a nice day. So, that became sort of the mantra of Amazon, and a lot of people point to this as the reason behind Amazon’s success, because by having these services interfaces to all of the components of their applications, they can be extremely agile, they can change their business and simply reuse all of the software that they’ve built for new functions, new capabilities, so they can rearrange the components into new configurations to take advantage quickly of emerging opportunities. So they move very fast, because their technology is so flexible. So that’s part of the reason we want to talk about APIs, is to increase your agility and your flexibility. So there are different kinds of APIs, and again, there are APIs for calling in your IBM i, so that may be your business partners who need to get at your data, or who want to send information to you, or customers who want to find out information about their orders or the business that they’re doing with you, people who have mobile devices that want to be able to access your applications, you know, point of sale systems that need to access your applications, so there are a whole lot of reasons why you might want to expose functions on your IBM i via APIs. And then the same thing going the other direction, as an IBM i developer, you might want to take advantage of all of the information that is available in our increasingly interconnected world. So you can call out to your transportation providers to see where your shipments are, or you can call out to the weather system to find information about the weather, or connect with your suppliers in your supply chain. Integrate your apps together, so call into other enterprise applications to get data into your system, or provide them with information from your application. So a whole variety of reasons why you might want to connect. And these are some of the ones we’ve actually seen in the real world. So we’re seeing customers who are connecting to things like Watson for doing machine learning and analytics, people who are connecting with members of their supply chain so that they can participate in the automated supply chain, people who are adding open source components to their applications so they can assemble applications from open source components, people who are accessing publicly available web services to add function and information to their applications. A big one we’ve seen a lot of lately are people who are adding devices in the Internet of Things that are talking for IBM i, and then, of course, people who are adding the latest in user interfaces.

So let me go through a couple of those examples in the real world. So this is an advanced UI example where we had a customer that had a green screen application for tracking shipments, and their customer said, we’d really like to have a graphical user interface to that. We want our warehouse managers to be able to go down into the warehouse and know exactly when the truck is going to arrive so they can make sure all the right people are at the loading dock at the right time, and they want to be able to do that from a tablet device or a desktop. Originally they tried to do a sort of screen scraping version of that. So they used a screen scraping tool, and they got something like this, which did not make their users happy because it didn’t look like a web or a mobile interface. It looked like a green screen on the web. So instead what they did is they exposed the green screen functions via APIs and then wrote a native Node.js application or a React application that talked to it, and so you get a very advanced looking application, a very modern looking application to access that green screen data, and it’s responsive so that you can look at it from a mobile device, a tablet, a desktop, whichever interface makes the most sense for what you’re trying to do. So by creating APIs, I have a lot of flexibility in how I want to expose that information. This is actually IBM’s Cloud Connector system, their application for connecting the IBM i to the cloud for moving files up and down to the cloud, and it’s a native Angular application talking to the IBM i and to the cloud. So from here, you can move things up to the cloud and just give you a sense of the productivity of doing this in open source versus doing things in the standard green screen way. Our team built this for IBM, and it took us about nine months to build the green screen version of this. To build the Angular application took about four days, and that’s because in the open source world, we simply downloaded components, wired them together to create this user interface. So it was very, very fast to put together. In the Internet of Things, we’re seeing more and more devices that are being connected to the IBM i. So as I talked about before, people working in the warehouse who need to get information directly from the IBM i. So they’re using these handheld like Zebra devices and talking to the IBM i. Smart appliances, we’re seeing customers who have warranty systems, and they’re actually having the appliances in their customers’ homes talking to their system to keep them up to date on the performance of those appliances. We’re seeing people who have field service people who are going out to do inspections or do repair on devices who can enter information directly from the location where they are into the system and get the latest information when they are actually on site. Lots and lots of wearables, especially in the medical field where people are tracking their patient’s health via wearable devices, or you have smart utilities where people are tracking power usage. Here where I am in California, the power company actually is putting all kinds of Internet of Things devices on all their power lines so they can track whether the power lines are breaking so that they can avoid some of the fires that we’ve had out here recently that were caused by downed power lines. And then connected transportation, where people want to get real-time information about where is their shipment on the road right at this time, or where is it on the ocean right at this time, or where is it in the air? They can get that information real-time coming from Internet of Things devices in the transportation carriers. This is just an example of something we just did with a customer where they’ve got the handheld Zebra devices. They’re entering information to the IBM i from those devices. They’re retrieving data from those devices. Now, they used to do this via just a terminal emulator, so they had a green screen interface which limited how much information they could show. It also limited their flexibility in what kind of an interface they could provide their users. Now, it’s an angular application talking to their IBM i. And what’s really interesting is they actually are pulling down spool files from the IBM i and printing them to a locally attached Zebra printer that’s attached via Bluetooth. You get all of that happening just by using these API connections to the IBM i. In doing that, you have to have a way to say, okay, I need to get to the IBM i, so the first thing I’m going to have to do is authenticate you and make sure I know who you are, and so I need to decide what kind of authentication am I going to use for that, and I’m going to talk about that a little bit more in a second. And then I need to figure out what connection technology do I want to use, because there are lots of options about how to connect to the IBM i, you can use ODBC, you can use IDB, which gives you direct IBM i database connections, XML service, which lets you call programs, so there are lots and lots of different connection technologies. And then you have to do the transformation of the data that the handheld device understands into data that the IBM i understands, run the IBM i functions, and then pass back the data and transform that data back into some format that the user interface understands. So that’s calling into the IBM i for web services. Let’s talk a little bit about calling out from the IBM i. So we’re seeing lots and lots of use cases for this, and almost on every phone call I have with a customer, I learn about new things. So these are just a couple of it, I just talked to a customer that is a food distributor, and their concern is they have to know when they’re shipping their food items, do they need to use a refrigerator truck, and that is going to be based on the temperature along the route. So they call out to the weather API, get all the temperatures along the route to make the decision of what kind of a truck are we going to use to ship this order. We have another customer that’s a vacation rental company, and they wanted to provide people who are browsing their website with temperature information around the properties that they were looking at. And again, they’re calling out to the weather service to get that information. We have a lot of customers that are looking to get Google Maps information, so we have an insurance company that in order to give an accurate quote, they need to have the exact latitude and longitude of the property they’re quoting for, but all they had in their database were addresses. So now they send an address down the wire to Google Maps, and they get back the exact latitude and longitude so they can do their quoting process, which is all in RPG. We have other customers that are looking to maximize the efficiency of the routes for their transportation, and so they’re getting directions, distance, as well as traffic information directly from Google. These are some of the other ones that we’ve run across recently. We have customers that call out to public services with vehicle VIN numbers to get information about the vehicles, sales tax inquiries to help me understand what’s the sales tax for a particular place in the country, food, nutritional information, demographic census information. Lots and lots of different things, even including people who call out to the Chuck Norris joke API to get Chuck Norris jokes. So when you’re doing these services, you have a decision to make about how am I going to do the service? How am I going to create the service? Do I create the service in RPG, or do I create them in open source code? What we find is it makes sense to use the right tool for the job, so use the tool as it’s designed to do. 

When you look at open source versus RPG, RPG is a fabulous language for doing transaction processing, for doing business processes. Open source products are really designed, open source languages are designed to do things like web services. They’re built to do web services. They know how to deal with JSON. JSON is JavaScript object notation, so obviously parsing JSON in JavaScript is really easy, but you have similar libraries for things like Python, so you can very easily parse that JSON. You can also download the latest in authentication components. You can get the latest in security, the latest in cipher suites, and there’s lots and lots of pre-built API connectors. You can go out and get an API connector that is already built to do the thing you want to do. You want to talk to your transportation carrier, there’s probably already an API to do that. You want to talk to Google, there is an API to do that. You want to talk to Watson, there’s already code written to do those things, and these things are designed to run asynchronous. Some of the reasons, some of the critical difference why you might want to move the services code into something like JavaScript or Python is these languages are asynchronous and event-driven, whereas RPG is synchronous and procedural. There are lots of open source packages available, like the security packages, like the API packages, and they handle the flexible data that you tend to get from web services out on the web. The data that you get from web services is not predictable, which is really hard for the IBM I to deal with directly. How do I deal with data? It doesn’t come in nice structured forms that my IBM I expects. What we recommend is you use your RPG for all of your business logic, and you use open source for web APIs and UIs. I want to talk just real briefly about this idea of synchronous versus asynchronous, because there’s a lot of confusion about this. I talk to a lot of customers about asynchronous, and you say, in asynchronous, I can send out multiple function calls simultaneously, and I don’t have to wait for one thing to be done before I do the next thing. Then people say, well, I can’t do that because I have to do step one before I can do step two before I can do step three. In this coffee example, I have to take the order before I know what coffee to make, and I have to make the coffee before I can deliver it to the customer. That’s looking at this as if I’m taking one thing at a time. The advantage of asynchronous is not that you’re going to make those three calls together, because obviously, you have to do them in that order. It’s when I’m getting multiple calls simultaneously. The web languages are designed to work in an environment where you are getting lots and lots of calls simultaneously. That’s where asynchronous actually makes sense. That’s where it provides value, and that is that I can take order one, and I don’t have to wait for the barista to make the coffee or for it to be delivered before I can take order two. I can take order one, take order two, take order three. Meanwhile, the barista is making coffee, and they’re delivering it to the customer. By the way, when I finish taking order three, I as the cashier am now available. I can also help to make coffee. You can see I can really shorten the timeline of dealing with all of the requests that are coming in. I’m not allowing resources to remain idle during that period of time. That’s what the promise of asynchronous is. As I’m taking lots and lots of requests, I can start up lots and lots of requests very quickly and very easily. My performance will be much better. I’ll be processing things much faster. In fact, we worked with a customer that went from synchronous to asynchronous, and they took a call that was taking them 16 seconds down to two seconds just by changing that. You can dramatically improve your performance. You have much more capacity to handle requests, and it’s a whole lot easier to manage than threading. Most JavaScript modules are asynchronous. If you’re writing your APIs asynchronously, they’ll work together well. You can integrate those. JavaScript programmers, this is what they’re going to be looking for. That’s what they understand in an asynchronous environment. Finally, a little bit about security. The other thing that I’ve run into as I talk to IBM i users is there are a lot of people using basic authentication, and there are a whole lot of reasons why you might want to be concerned about using basic. This is just some notes that have been posted by companies like Microsoft and Google, which is they’re disabling basic authentication. They’re disabling the basic authentication because of security issues, so Google, Microsoft. This is MuleSoft. One of the big API providers is deprecating basic authentication. Apigee, another one of the big API providers, is deprecating basic authentication. This is what Apigee says. Basic authentication is the least secure of the supported authentication methods. Your credentials are not encrypted or hashed. They are base 64 encoded only. Instead of basic authentication, Apigee recommends that you use OAuth2 or SAML. They’re asking you to use more advanced authentication. You’re going to find that you no longer will be able to connect to these services using basic. These are the issues. With basic authentication, your credentials are often stored in the browser, which means they can be discovered. You’re sending your user ID and password on every API call, which means that they can be discovered. Often, those are native IBM i credentials that somebody might be able to discover. Base 64 encoding is not encryption. It can be decoded. In fact, I pulled this down from the web. There’s a website called Base64Decode.org, where you can go and you can find out exactly how to decode base 64 encoding. If you’re sending stuff that’s base 64 encoding, somebody can very, very easily decode what you’ve encoded. These are some of the issues with basic authentication that I’ve run into with customers. The other issue is that you need to have an up-to-date cipher suite, and the open source modules are constantly updating their cipher suites. The problem we have in the IBM i world, if we’re doing direct API calls from our RPG, if we’re on a back version of the operating system, we’re going to get rejected by many of the API providers because the cipher suites are out of date. They’re concerned that you’re going to introduce a security vulnerability to them. They’re going to check and see, do you have the latest? The problem for IBM, of course, is that they’re putting the cipher suite updates into their releases and into the technical refreshes and into the PTFs, but you have to download those and install them. You have to be completely up-to-date all the time in order to have the latest version of the cipher suite.

Again, if you move that into open source, you can keep all of that stuff up-to-date, even though you might be on a back version of the IBM i. This is just a little bit about how people are doing this today versus how you can do it with open source. If you’re calling from RPG, there’s a whole lot of things you might need to get involved in doing that. One of the things, if you’re using HTTP GET, you’re doing it out of the database. You’re actually calling into the database, having the database do the web service call, which is really an unusual thing to do in the open source world. It’s a very, very strange way to do things. Then you’re running through IAWS. You’re starting at the JVM to actually run the calls. You’ve got to use the digital certificate manager to manage the certificates for security. You run the web service. You get the data back and put it in the Db2 database, and then you have to use something like the Agile to try to parse the JSON and then send it back to your RPG. What we’re trying to do is eliminate a lot of these steps from the process and move those out into open source so that you can do all of that stuff using pre-built modules that are easily available in things like JavaScript, Python, PHP, and the other open source languages, so dramatically reducing the amount of steps, the amount of technologies you have to get involved to make this happen, and keeping you on the latest of these things. You can use this to aggregate multiple API calls. Rather than making one API call at a time, you can make multiple API calls and use your JavaScript or your Python to aggregate those and send them out together. You can easily download components. If I want a security component, I can just go out to NPM, and here I’ve got OAuth 2 components that I can just download. I’ve got an Azure authentication component, a Google authentication component. I just download them and use them. If I need new functions, I can go right up to PyPi, and look, I’ve got a Watson connector right here. I can just pull down the Watson connector and add it to my application. It’s really easy to go out and find components to add to your applications. Then, finally, maintaining the APIs can often be the hardest part of this entire process. It can be really difficult to maintain the APIs when you start to get large numbers of them. I have the data description in each of my programs, and then I’ve got the data descriptions in my JavaScript or my Python or my.NET. What happens when those things change? We’ve got to make sure that everything stays up to date, so that I’m not getting partial data or I’m not accidentally getting the wrong data. By putting things in open source, what we’ve done is we’ve created this ability to change all of your data descriptions in one place. We have this YAML file where you can go in and say, I’ve changed the length of the VIN number, or I’ve changed the length of one of my other fields. You change it here, and we will generate then for you the RPG code, the CL code, the JavaScript code, the Python code that’s required to allow you to then keep those things in sync. You just include that code in those programs, and that way, they will always be up to date with the latest version of the data descriptions. Okay, so that’s the overview of the process. We talked a little bit about calling out from the IBM i and calling into the IBM i using open source. Now, I’m going to turn it over to Aaron, and he’s going to show you how it all works.

Okay. Great. Thank you, Dan. Okay. I’m going to go through a demo of this system, and basically, what we’re going to do is we’re going to go through really four key points here. We’re going to talk about what the code actually looks like to call in. So, if you remember from what Dan said, that’s if we have an open source program, we want to be calling in and accessing RPG resources, CL programs, DB2 data, et cetera. That’s really the making APIs function in here. Then we’re going to circle back, and we’re going to talk about calling out, which is the case where we have an RPG program, and what we need to do is get that talking to a web service or to an open source program through any other system. We’re going to look at the interface generators and how that actually works, and then we’re going to take a little dive into how we can use these same concepts to get into not just APIs, but into other areas of modern technology, like modern DevOps and systems like that. But the key thing that I’m going to emphasize throughout the whole presentation here is the central philosophy that getting into open source is going to unlock productivity for your applications. Dan mentioned this earlier when he was talking about, for example, the ICC GUI application that our team built, the Cloud Connector GUI. When we wanted to build that system using purely IBM i technologies, we had to write a lot of those components ourselves, and the application took about nine months to build. When we got to the open source system, that application took about four days, because the reason for that is that once we have open source, we’re able to then pull in modules. Our RPG code talks to open source code, and the open source code can run through all the modules and do whatever we need it to do using those packages. So that allows our RPG or our CL or whatever other systems we have to take advantage of the open source community. I just want to give you guys an idea of the size of this community here. If I go over to NPMJS, which is the Node Package Registry, this is just for Node.js, we’ve got as of now 1.4 million open source packages available for Node.js that are being downloaded. I’m waiting for them to get to 100 billion downloads a month, but they’re at 95 billion downloads a month right now of these open source packages. The number of packages here, the capabilities that are available, are constantly growing, and it’s a very active community. So if we can get our code into that, that’s going to unlock a lot of potential. So let’s take a dive into this with calling in. So for the first part of this discussion, we’re going to look at if we want to get open source calling into an RPG program. So I have an RPG program here. You can see it’s an extremely complex RPG program. This is our core business logic where we take in a number, we multiply it by 40, and then we put it into our output parameter. Now I want to say up front, I’m keeping this program very simple for the purposes of the explanation. I was actually implementing a program call probably a couple of weeks ago where our customer wanted us to call a program that took 1,147 parameters in its program call. That was largely data structures and various different types that we had to work with. So just remember the concepts that we talk about here will generalize to basically any use case. So looking at this program, we’ve got our RPG program, and where we want to get is something that looks more along the lines of this. So we want to get to a modern system, a web-based system, where I can type in a number, I can hit the button, it’s going to call my RPG program, which if you remember, multiplies numbers by 40, and then get me that output back, and it’s going to do all of that through a REST API. And I can actually show you the REST API if I go directly here. You can see that what I actually got back from my API call was some JSON data that came back from that call. And again, the reason we want to do that is that open source technologies and most modern systems understand how to make API calls. That’s what they’re built to do. That’s how they transfer data. So if we can get into APIs, then any other system on the planet will know how to talk to our systems. They’ll know how to integrate. And now we can start building all kinds of integrations with those modern systems. So the question, naturally, that we want to answer is, I have an API here, but how did I actually do it? How does this API function? And so that’s what we’re going to hop into now. On my IBM i, I have a Node.js application running. That is how I created my API. And the reason we use Node.js, as Dan mentioned, is Node.js and JavaScript programming language in general was designed for the world of APIs. It was created for the internet. And so the language itself understands the capabilities and the pitfalls of that environment really, really well. It understands how to work in an event-based system. It understands how to handle the Cypher suites. It actually ships with Node.js, ships with the latest Cypher suites and the latest public certificates so that you don’t have to manage those yourself. It understands how to work with these technologies. So we have a standard Node.js application. And what I did to make this call is I have this code right here. And this code is formatted, so it’s on three lines of text. But realistically, this is one line of code that is running this RPG program. And that is one of the primary goals in the designs of the connectors that we’re working with here. What I want to be able to do is work with my RPG programs, my DB2 data, and all of my IBM i resources using the standards of the language that I’m working with. So in this case, I have a JavaScript function. I say open a connection. Well, before I do that, I import a module. This is downloaded from the Node package manager. I open a connection. I tell it to execute my program, and I pass in some JSON as the parameters to my program. And it’s going to then execute that with the JavaScript standards, promise-based standards, asynchronous systems. And then it’s going to give me back JSON data from my RPG program and handle everything in between. And I think the best way to illustrate the benefits of doing that is by talking about the team, actually, or the project that we were working on that I just finished with a team last week. We had a project to build with a modern web application talking to IBM i resources. And what we did is we got a team of college students. The oldest person on the team is 20 years old. They are all still current students. And they were able to build a modern, secure, performant web application that works with RPG programs, that calls to DB2, that runs commands, that does everything it needs to do with OAuth-based authentication. They were able to do that in a matter of days. They didn’t have to learn about the IBM i. They didn’t have to go through rigorous training. And this application is built for a major car manufacturer. This is not just a little application. This is an application that I’m not going to name it, but I would guess that most of us probably have one of these in our driveway. So these are serious applications, and it opens up the capabilities for us to reach into that talent pool and that technology pool to work with these technologies very, very easily. And the same is true on the RPG side. If we go back to my RPG program, this is one of the reasons why I want to use this simple RPG program. As you can see in here, there’s nothing in here that’s managing APIs or parsing JSON or doing authentication or anything. It’s five lines of code. There isn’t much room in here for any of that kind of stuff. So you can see that the RPG program is also working with the standards that it was built to work with. It’s not working with these asynchronous web API standards that are foreign to the RPG programming language. And that’s one of the key design principles here. And the way that we do this, the way that we get this connectivity working, is we get a short description of the RPG program or the action that we want to run on the IBM i. That can be a command call, that can be a program call, it can be a SQL database call, a whole bunch of things. And for the case of this example, this is what the model looks like for that call. And these models can be generated from that YAML specification that Dan mentioned. Basically what I have to do is, naturally, as you can imagine, I have to give it the name of the program. I give it the library here. Obviously, it will load from my library list if I don’t specify that, but I’m choosing to specify it here. And then I give it a little bit of information about the parameters, right? We’ve got two parameters in this program. They’re both packed decimals, one’s 15.0, one’s 16.0. And one of the points that I want, that helped our young developers work with this, is that these specifications handle most of the communication on their own. So for example, this specification knows that these parameters are packed decimals, which means that in JavaScript, when you pass in a number, JavaScript has one number type. It doesn’t have an integer or it doesn’t know the difference between integers, floating points, packed, zoned, et cetera. It doesn’t understand those. What it has is number. So this connector is then able to translate that into the correct binary encoding for the RPG program, which is actually a really complex thing to do when you’re trying to get between the communication tech, between the standards in the different languages. And along that same vein, we have a couple of configuration options here that make things easier. Like the most popular one is the one I have in this demo is the default value. That allows me to say, if I don’t provide a value for this parameter to the program, use this default value instead of, you know, instead of just having it blank. Because naturally if I omit a parameter to the program and it’s not specifically configured for that, it’s going to fail on the call. And in a program like this, it’s not going to do a huge amount, right? Because we only have two parameters, but the key benefit, I mentioned earlier, I was implementing a call with 1,147 parameters. Only three of those in that example, only three of those parameters were actually used as live input parameters from the API. The rest of it was for other use cases.

They had consistent constant values or they were output parameters. So basically the difference is because of that default value, my code for that call was this, it’s five lines, right? It had three parameters in the middle there instead of one. If I didn’t have those default values, this section would have to be 1,147 lines long, right? So I didn’t have to specify every single input parameter to that program. Instead, I did it in five lines of code, right? And that again is really what we’re aiming for here is to make it as simple as possible to get robust integrations between those technologies. And then the last thing that I want to mention, because again, remember the central philosophy that we want to keep things open to open source. The rest of the application outside of these three lines of code is just a standard JavaScript application. It is an express-based application, expresses the most popular web service framework for Node.js. It’s what basically everybody uses. There are no requirements on the system to do things in a proprietary way. And that is something that I want to emphasize here because what that means is that you can work with young developers, you can work with modern developers, you can work with open source modules because your system is standard.

Okay, so basically just a quick recap of that before we move on and switch directions, right? What we saw is a call and a web API wrapping an RPG program. So that means an open source program that’s calling an RPG program. That open source program happened to be a web API, but it could be anything else. And we have a standard application that’s easy to configure for our modern developers. Okay, so now let’s flip directions and say, well, what if we want to call out from RPG code? Now, again, in the same philosophy, the most common use case that we see that people get into when they start looking at this technology is they want to make a web service call, right? Let’s say that we have a particular API, like for example, a weather API, which I have open here. We have a weather API. We want to get the upcoming weather forecast for a particular area. We actually built this demo for a cabin rental company that actually needed this information. And what you get back from the API after you’ve gone through their authentication process and handled all of the steps in getting that done is something that looks like this. You get back this massive set of complex and variable JSON data. This is something that in my experience has been somewhat difficult to work with in RPG. On the flip side, when we work with it in something like JavaScript, right, JSON is JavaScript object notation. Naturally, JavaScript understands it pretty well. And if we just look at this JSON structure for a second, I have it expanded, you can see that there are layers to this structure. There are nested objects. There are arrays that are of different lengths. There are character fields, numeric fields. There are these character fields have no specified length. They may vary. We have a whole bunch of variable data that we have to work with if we’re going to work with this application. And so when we make the web service call to this API, again, remember the central philosophy that we work with is do the web service call with open source code. And the reason we want to do that, again, is if I open up the JavaScript code, I’m going to show you the JavaScript code that actually makes that web service call, that JavaScript code is right here. This is all of the code that we need to call that API, put in JSON parameters as input, parse the JSON output into objects in our code, basically data structure variables that we can work with. This is the entire thing that we need. So this is a really simple thing to do from open source code. So the demonstration that I want to point out is actually a vehicle demo. We had another company that we were working with where what they wanted to do is call out to a government API that provides information about a vehicle. We give it a VIN number. It’s going to tell us what kind of vehicle is this. We want to know, is it a gas-powered vehicle, is it electric, what’s its engine type, some information along those lines. And what I want to be able to do is just run my program. I’m going to run a CL program, pass in the VIN number, and it’s going to get me back. This particular VIN number refers to a gas-powered vehicle. And I want to point out that that sort of flashed by really quickly, but what happened in there is my CL program called out to a web API through an open source program. And remember, we do the web API calls in open source so that the open source program is able to take a lot of that complexity out of the call. In my CL code, which I’m going to show you in a second, this is three lines of code. This entire web API call, including getting the parameters back as variables so I don’t have to parse the JSON, dealing with the authentication, dealing with everything else, three lines of code. I want to show you that real quick. We go into my CL program here. This is the source code for the CL program that I just showed you. The three lines of code that we need are, number one, ECC send request.

This is a program that is provided as part of the Eradani Connect system. It is the Eradani Connect client send request program. When you call this, you pass in a whole bunch of data as parameters, and it’s going to then send that to an open source program to execute your API call, your IoT device communication, your Google Maps lookup, your open source functions, whatever it is you need to do. It’s going to ship that over to the open source program. So that’s number one. And then number two is ECC receive response. When the open source program is done running its API call or running its action, whatever it needs to do, we call ECC receive response. That gets us the result back as parameter data, and this is the point that I want to emphasize in this code. I’m not getting back JSON here. I’m not getting back any sort of complex structure. What I am getting back are variables that I can work with. If I scroll down to the code that actually sends the message that you saw in the green screen with the data, I have an ELEC level variable, that is electrification level. That’s one of the parameters that comes back from the API. I have a fuel type primary, fuel type secondary variables that I’m working with. There is no JSON parsing in this entire system. And that gets into the third line of code that matters, is how do we actually do that? How do we break that information down? And the answer is this part right here. So this is where we include, if you remember from Dan’s presentation, he mentioned that we create an interface, we generate the interface code, and then we include that in our CL program. This code includes everything that we need, and I can actually pull it up here, includes everything that we need to take the data from the open source program and break it down into the variables that we want. Side by side with that is also JavaScript code generated by the same generator that handles sending the data and reading the data on the open source side. So what that means is that because of this include in my CL source code, if I change the interface, I don’t have to worry about that in my CL code itself, it just updates. And the next time I recompile, it’s going to pull in that updated source code. And this is something that we developed originally, and actually, as with a lot of the Eradani product line, this is something that we actually originally developed for internal use by our team. Because we were doing web API calls, we were talking to open source. And what we found is that we would write a whole bunch of programs that would call the same API. And then at some point, the API would change or we’d add a parameter or parameter length would change. And if we had 10 programs that were calling that API, we would change nine of them. And at some point, we would forget to change number 10. And what that would do, if we were lucky, if we were lucky, the parameter issue would be on a on a numeric field, and then we get a decimal data error and the program would crash.

Right, that was that was the lucky case is having a program crash. If we were unlucky, it would be a character field that would suddenly start getting truncated. And that program would silently truncate our data for a couple of weeks before we might realize that one of the programs is not working properly. Right, so having this interface generator completely solved that problem for us, we, we just regenerate the interfaces and we’re and we’re fine. And to illustrate that, so I have my display vehicle program. I’m gonna pull this up here, I’m going to put in a different VIN number, this particular VIN numbers for a gasoline powered vehicle, I’m going to pull up one for a Tesla. Right, so I’m gonna pull up an electric vehicle and I’m sorry, just exit it out. I’m going to update the VIN number and the model year and run that. And I got back the information, but to illustrate the point that I was making, we got battery electric V back from our API call, right, that is not the complete string, that is not the complete data from this call, that is truncated. And this is what would happen. The program works, but it truncates our data on the return call. It works for some cases, but then we try it with a new VIN number and all of a sudden we have a problem. So what would I do if I want to make that change? I’d come into my interface, actually let me, before I say that, before we had these tools, what I would do is I’d go through every single program that calls this API and I would have to make sure that the data is synchronized and that everything is up to date with those programs and with the interfaces. With my generator, what I do is I come over to the electrification level, which is the parameter that’s being cut off. And I say, you know what, I want to make this 35 characters. I save it, I go to my terminal, and I say, generate interface, VIN API. So it just regenerated the interface. And if I check the status of my repository, you can see that a couple of files have been modified. It modified the CL include, the JavaScript include, the RPG include, and the YAML file because that’s what I have it configured to generate. And if I look at that CL include again, you’ll notice that electrification level is now 35 characters and all the other parameters and all the other code has been updated to work around that problem. So what I’m going to do real quick is I’m going to now push that up to the server. I’m just going to say, I’m going to change this to 35 characters, I just give it a little message so that I know what it was doing. Push that. And then what I’m going to do here is I’m going to come onto my server. This is an SSH connection into my IBM i where I ran the demo. I’m going to update the app. That’s going to pull down the latest code. It’s going to recompile my programs, and then it’s going to restart my JavaScript server so that it has the updated code. And one of the things to note here, if you notice, we just got a whole bunch of compiler output here. I just did that change using exclusively open source tools, and I’ll circle back to that in a second so that we can talk about it some more, but full open source deployment process that is using Git and Make for the deployment of my application. Okay, so the application has restarted. You can see it’s listening and it’s been initialized. That’s how I know that it’s running. And I’m going to run that call again. And look at that. Now we have BEV, battery electric vehicle. We get the whole thing this time, right? So that was able to update my interfaces and get everything working so that I made that change. It synchronized the JavaScript. It synchronized the… I don’t have an RPG program, but it would have synchronized RPG and CL as well. And all I had to do was recompile and I get the updated form of my API. And that’s going to handle, again, all of the dependencies in that list that I changed the include, but it knows, all right, I changed the include. It needs to update the CL program and it’s going to go through and it’s going to recompile everything that I need. And this is something that we automate oftentimes. I kept it as relatively manual for this particular conversation, but this is something that we automate with customers a lot. So just a quick recap of that, right? So what we did here is we set up a CL program to call out to a web API. And again, remember the central philosophy here is that APIs are the gateway, right? We start with an API. We start by getting our CL program to call those APIs, but we do it this way by calling to open source because once we’re in open source, you can start bringing in all kinds of open source functions into your application. It doesn’t have to be web API calls. It can be IOT applications. It can be XML parsing. It can be authentication mechanisms. It can be whatever you want that you’re calling out to in these programs. And it can be web APIs if that’s what we want to work with. And so the last thing that I wanted to mention is just a really quick comment about the deployment system here that I used. So you may notice that if I scroll up here in the system output back to the compilation, only two programs, only two objects were rebuilt. This application has many, many more functions, many more RPG programs, many more CL programs than just these two. But the system knew that it just had to rebuild the two that it rebuilt. And it did that using fully open source tools, right? 

When we work with open source DevOps processes, we can manage things with Git. The traditional limitation has been our build process. And that’s something that we’ve solved using a makefile, using another set of open source tools that we’ve actually described in a couple of our webinars thus far. And the last thing I want to mention is that, again, I did this as a relatively manual process. I actually had to go onto the server and run one command to update my application, which qualifies as relatively manual. We actually just finished working with a customer to automate that entire process through Azure Pipelines. So they have pipelines set up where they write their code, they push it up to the central system, and it then handles the automation for the entire process of rebuilding, restarting, recompiling, doing everything it needs to do to update their applications. So they’re now using modern technology with API calls in and out, with modern DevOps tools, with modern systems that young open source developers can work with, and they’re roping open source technology into their application. Aaron, thank you for the… Yes, yes, that’s what I’ve got for you here in the demonstration. I’m going to turn things back over now to Dan and Mitch to close this up. Well, we have Q&A to go through now. Thank you for the great presentation, Aaron.

Question one, does Connect track the API activity if a process is consuming too much of an API? Does Connect help us throttle this activity, track what processes are using the API, and et cetera? Can one of you talk a little about the difference between Connect and, I guess that would be an ESP, right? Dan, do you want to answer that? So if I understood the question there, we’re talking about tracking the activity in our API calls and tracking the… We’re tracking the API calls and throttling and doing all of the functions that we have around that. Because of the footprint of EradaniConnect, that is something that we can do in our open source application because at the core, what we have is an open source application. So yes, I mean, we can absolutely do that, we can absolutely set that up, and we’d set it up with open source modules to handle that. Right. There are already open source modules available to do all kinds of API management tasks, and you can just simply integrate them into the API that Eradani Connect creates. Thank you. Next question. I don’t even… I don’t know what this means. Can you handle complex data structures, arrays, and results set? Yeah. Yes. So yes, absolutely. And the program I talked about with the 1,147 parameters use all of those things. We just keep this demo simple for the purposes of the demo. Okay. All right. There we go. How do we find the right APIs for what we need? Let’s give Dan a chance to answer a question. Dan, you want to take a turn? Sure. You’ve got to turn on your camera, though. So that’s one of the great things about open sources. You can just go out on the web, and you can find all kinds of sources for any kind of module you can imagine. So when we were building that cloud connector interface for IBM, we found the tree structure components already built. We found the connector to AWS already built. We found the connector to IBM iCloud already built. And we simply did searches on those sites, and what’s really great is the sites also tell you things like, when was the last time this thing was updated? How many people are using it? So that you know if something’s being downloaded a million times a week, it’s very well tested, and it’s very secure. You can see that if it was updated yesterday, it’s being kept up to date. If it wasn’t updated since nine years ago, it’s probably not up to date. So there’s lots and lots of information you can find out about these modules just by looking them up online. Good answer. Thank you. Does anybody want to send in any other Q&A? We have a lot of people on this meeting. Feel free to chat questions. Here’s a private one that was sent to me. Our business process is a step-by-step process. Why can’t do things out of order, so wouldn’t async just complicate things? Our business process is a step-by-step. And totally, absolutely, most business processes or many business processes are like that. So that’s that sort of issue of where the value of async comes in in that situation is not that you would do those steps out of order, but if you have a business process that might be requested by multiple people simultaneously, so where you’ve got a web interface now into whatever that business process is, and each request has to go from step one to two to three to four to five, but I can take multiple requests simultaneously and I can fire off step one for the first request, step one for the second request, step one for the third request. I can do all those simultaneously. I don’t have to wait for the first request to go through step one, two, three, four, five, before I can have step one for the second request. I can send them all simultaneously. So each process will be going through step by step, but I can have multiple processes going on simultaneously. Message me if that didn’t answer your question. Thank you, Dan. Any other questions from anybody? You know what? It’s 8 o’clock. I don’t think we have time. Feel free to email me questions, and I’ll get them to Dan and Erin and get them sent back to everybody. The recording of this event will be emailed and shared with everybody. We appreciate all your questions. We’ve had a record number of people stay the whole time, so great job, Erin and Dan. You gave an exciting presentation, and I hope everybody understands the potential of opening up and bridging your IVMI and connecting it to the world of APIs. Have a great afternoon. Great. Thanks, everybody. Have a great afternoon.