Warp Speed IBM i Modernization with APIs
February 24, 2021
2:00 pm - 3:00 pm
Eastern Standard Time
With high speed, fault tolerant, loosely coupled APIs you can now rapidly extend your IBM i applications with the latest technologies. Until recently, if you wanted to support high speed connections between applications you had to write direct calls to the IBM i database. These were often fragile and hard to maintain. If a change was made to the IBM i data schema, it would break the interface—often in production.
With Eradani’s new high speed connection technology, you can connect via loosely coupled APIs. The loose coupling allows you to make changes to either side without breaking the connection. When you do make changes, Eradani will automatically regenerate the connection code for both the IBM i side and the open source side to ensure everything keeps working.
Now, you can easily take advantage of the millions of Open Source components to enhance your IBM i applications without slowing down your business process.
Easily enhance IBM i applications without slowing down your business processes
Fully take advantage of millions of open source components
Quickly use high speed, loosely coupled APIs to extend your applications (with real world examples)
Chief Executive Officer &
IBM Champion, Eradani
Dan has spent over thirty years leading companies that help customers implement new technologies in legacy environments. Previously, Dan led worldwide software development groups that built highly successful modernization and DevOps tools and was the CEO of Aldon, the leading provider of DevOps tools to the IBM i marketplace.
Vice President,Open Source Technologies &
IBM Champion, Eradani
Aaron has been writing modern applications to leverage open-source technologies on the IBM i for more than 10 years. His applications are part of commercial products that are installed in thousands of IBM i shops. His work combines open-source languages such as PHP, Java, Node.js, and Python with traditional IBM i,technologies to create leading-edge IBM i solutions.
Welcome, everybody, to this webinar on warp speed modernization using APIs. We’re doing this because over the past several months, we’ve seen a big shift in our conversation with IBM i customers around the topic of modernization. The conversation has broadened from a singular focus on user interfacing, creating new web admin, mobile user interfaces, to encompass the many challenges that people face in dealing with this increasingly interconnected world of business, where systems are talking to each other and you have to be able to communicate with other people to be able to do business, to participate in the supply chain. Many of our customers have Windows and Linux applications that they need to connect up to their IBM i system, or they want to be able to call out to public web services to add data to their IBM i systems. So what we’re going to be talking about today is how you can use new technology within your IBM i applications. And this has been really a great move because we’re seeing a real turn away from the idea that you have to move away from the IBM i in order to take advantage of new technology. But in fact, you can API enable your IBM i, and it can then take advantage of all the great new things that are happening out in the IT environment. So we’re going to start out by looking at this move to APIs because it’s happening across the industry. There is an accelerating move to connecting things via APIs. And then we’re going to talk about how you can take advantage of it by rapidly enabling your IBM i programs and data, by API enabling things quickly. And we’re going to also talk about how you can add open source components to your IBM i applications. So what makes this really possible is now we can have very, very high speed API connectors so that we can have connectors that are high performance enough that you can actually integrate calls to open source modules right within a business function. So right within the middle of a business process, you can call out to an API and get results fast enough so it doesn’t slow down your response time. So you can create these very, very high performance and reliable APIs, and we’re going to take a look at how you do that. And then we’re going to talk about how you can make sure that they are easy to maintain over the long term. Because one of the things that customers have called us about is they said, you know what, it was easy to create a couple of APIs on my IBM i, but now that I have lots of them, it becomes very, very hard to keep them up to date. So as we change the data schema or as we change the business functions or as the web services change on the other side, how do we make sure that we keep those things up to date? So I’m going to talk a little bit about those functions using PowerPoint, and then Aaron is actually going to dive in and show you a live application, and he’s actually going to web enable things and show you how the API enablement process works. So just a little bit about APIs. This is actually the growth in API collections that are on the Postman site. So Postman is the most popular place where people set up APIs and create their API collections, the actual code around their APIs. And as you can see, it’s increasing, and it’s increasing at an increasing rate. And this is just the creation of APIs at one particular place. This is Postman. There are lots and lots of other places where people are putting their APIs. This is just giving you a sense of how fast the creation of APIs is growing. The adoption is growing even faster. So the number of API calls that are happening every day are in the many, many billions. So we’re seeing this rapid, rapid growth in the number of APIs that are out there and then the number of calls that are being made to APIs, so the use of these APIs. This is a survey of organizations as to how important are APIs as part of their whole digital transformation strategy. So as you can see, APIs are critical to almost everybody. It’s really a very, very important part of the whole API transformation strategy, and that’s because APIs play a role in almost everything you want to do in transforming your existing environment. And there are lots and lots of use cases. I’ll talk about just some of the use cases that we’ve heard from our customers, so the many things that they’re doing around modernizing their systems.
So the first one, as I talked about earlier, is the first thing we heard from people is they want to be able to use the latest technology to build really great user experiences and responsive GUIs. And so the first thing they wanted to do with APIs was say, I need to API enable my IBM i functions so that I can access them via a modern user interface. So for example, we had a customer, their use case was they said, we have these warehouse managers and we ship our products out to our customers, and the warehouse managers want to know when the shipment is going to arrive. And the way it works currently is they call our company, they get our customer support person, they look up the shipment information on our system, which just tells them the shipment number. They then have to call the transportation company to give them that shipment information. The transportation company then goes and finds out where that truck is, and then they give that information back to our customer support person who then calls the customer to give them the information. The problem is that round trip took a really long time. What they wanted was to give their users a mobile device interface so that the warehouse manager could simply be in the warehouse and he could click on a button and see where the shipment was going to arrive. And so that’s what they did. And that’s actually this little screen you see here on mobile device is actually that application where now a warehouse manager can go on a handheld mobile device and look up his shipment, hit a button, and it will give him a map that shows exactly where the truck is at that moment in time. So it’s actually going out to the IBM i, getting the shipment information, sending that out via an API call to the trucking company, and then getting the map data back. So again, using APIs to get that really, really modern user experience. Then people are also looking to modernize business processes by integrating applications. So for example, we had another customer that they would have customers that would call and ask for copies of old invoices. And the problem is all the invoices were archived on a Windows system. And so what they’d have to do is look up the order on their green screen, get the order number, then go over to the Windows system, key in the order number in order to find the invoice, and then email it out. Now using APIs, they have now made it so that they simply hit a function key on the IBM i, which goes out and calls to the Windows system, sends them the order information, generates the invoice, and emails out the invoice, and then sends a confirmation back to the IBM i. So they’ve automated that entire business process by using APIs. And then we have customers who want to be able to modernize their communication with their end users, with their customers through these APIs. So we have customers now who have their entire order process automated. So the POs come into their system. It automatically then sends information to accounting. So it sets up the billing. It sends information out to the ordering area in order to set up the order to be fulfilled. And all of that is happening automatically in machine-to-machine conversations. We have other customers who have told us that their vendors in their supply chain are now requiring, or their customers in their supply chain are now requiring that they communicate via APIs. In fact, a lot of people are replacing proprietary EDI systems with now open APIs. So even in order to participate in the supply chain, you have to be able to talk to them via these APIs. And then there’s so many great sources of information, of things that you can get and integrate into your IBM i applications by simply calling out to publicly available APIs. These are just some of the ones that our customers have been using, calling to UPS to get transportation information, or calling Magento for point-of-sale integration, or Venmo for payments. All of these are just different things that people are using, calling out to public APIs from their IBM i.
So Aaron, I’m going to turn it over to you. All right. Well, thank you for that awesome introduction and going through all of those topics for us. So as Dan mentioned, I’m going to go through a demonstration of how this stuff actually works. I’m going to go through this application that Dan has up on the screen here where we’re going from a web user interface to an API to the Google Maps API into our RPG programs to get weather forecasting data. And like, again, like Dan mentioned, we’re going through two strategies. But what I want to point out before I start saying anything else is that everything that I say in this entire process is going to go back to one key idea. And that is that we always want to make sure we’re using the right tool for the job. There are a lot of tools that can perform similar functions, right? There’s a lot of capabilities out there that can do just about anything. But the tools that were designed to perform a specific use case are typically going to be more maintainable, more secure, more productive, and more performance than tools that weren’t designed to do that. And that’s part of what I’m going to show you here. So remember, key idea is we want to use the right tool for the job. And if you’ve seen us do any other presentations, you’ve probably heard us say that about 10,000 times. But it really is important. So I’m going to go ahead and share my screen here. And so as Dan mentioned, right, our core business logic right now, we are a weather forecasting company that we’re taking on here. And our core business logic is that we have this get weather forecast program. What that’s going to do is it’s going to take in a latitude and a longitude, and it is going to get us back the weather forecast for the upcoming week for those coordinates. And I’m going to show you real quick, if I hop over to my IDMI, I do a DSPWF, and I’m going to run this with the coordinates of the Eradani address, which is 3789 and negative 122, 28. If I run that, it’s going to store my weather forecast in a school file. And if I open that up, you can see that in my 5250 here, I have dates, low temperatures, high temperatures, and a bit about the weather for today and the following seven days. We’ve got our web user, or sorry, not web user, I jumped ahead of myself there. We’ve got our program here with our core business logic. And again, what we’re trying to get to in modernizing is something more like this, right, where we’ve got this interface where I can go in and I can, I as a web user from my machine, I can run an API call from these applications. I can say, get me the weather, and it’s going to get me that information. So this is our end goal here. From that, from this over to this is what we’re trying to get to. And we’re going to take, over the course of this presentation, we’re going to take two different paths. And I want to reiterate that to make sure that we’re clear about the structure here. We’re going to take two different paths. One is going to be calling through the SQL HTTP functions in RPG. We’re going to be using HTTP post-clob built in, in our RPG code. And in the other case, we’re going to have our RPG program. Everything is running from RPG. We’re going to have RPG reach out to an open source program that is going to execute our Google Maps call, bring the data back, and then go back in and continue with that get weather forecast. So the first step here, again, is we’ve got our program. What we’re going to do is we’re going to change this system so that it looks a little bit more like this, right? We’ve got our adder WF at the top, goes to HTTP post-clob, calls to Google Maps, and then continues in with the get weather forecast logic, right? So take the address instead of coordinates, takes an address, uses Google Maps to get the coordinates, calls our original business logic. The other option is the SPWF is going to go to node, call the Google Maps that way, and then get the coordinates and send it back, right? So it’s the same process, same implementation, same input, same output. The only difference is the top path uses HTTP post-clob, and the bottom uses an open source integration via Eradani Connect. So the first point that I want to cover in here in comparing these two paths, as we’ve already seen that it’s possible, right? I’ve got the web user interface here. I can run this. The first key point that I want to cover is productivity, right? When we talk about different methods of developing something, one of the most important questions is which method is going to allow us to build robust applications fast, right? Because the faster we can build our applications, as long as they’re bug-free, the more time we get to spend on building other features and extending our applications rather than spending a whole bunch of time focused on one particular thing. So in this case- So Aaron, let me just make sure something’s clear, ask a question. So I see here on the web page, you’ve got the address, and then you’ve got the result, but this is not calling from the web page directly to the weather service to get that. It’s actually sending the address to the IBM i. The IBM i is then sending the address to Google Maps. It’s getting then back the latitude and longitude, which it is then sending on to the weather service, and the weather service is then returning that data, and you’re then reading that into this web user interface.
I’m going to pass it back to Dan so that he can wrap this up. Great. Thank you, Aaron. Thanks for taking through that. I just actually brought up some slides just because one of the questions we got, because I know you focused a lot on the ability to integrate open source modules because that is so powerful. But we had a question is, well, if you’re not going to use open source modules, let’s say you just want to call in between your own systems, does it then create any value, or is it only if you’re using the open source modules? And the answer is a lot of the key value actually is just in the ability to create these APIs very, very quickly. Included in Eradani Connect is an API generator. So basically, all you need to do is say, I want to create an API. This is doing it through the command interface, so I want to run this command. Basically, you tell it what method do you want to do. So am I going to get some information, read some information, do I want to post, am I updating, am I sending new information, what’s the function that I want to run, what is the open source function that I want to run. And then there’s this thing called the data model. The data model is what helps us understand what the data looks like. And this is an example of a data model over here on the left, and it is built based on your RPG data description. So this is just a sample data description of RPG data structure, so you can see you’ve got customer ID here is 8P. You can see it’s over here as well, customer ID, 8P. The reason we create this data model is we generate then from that time forward both the RPG side and the open source side of the description of the data, so we can make sure that they stay in sync. This becomes critically important because as you start to build, if you end up with tens or scores or even hundreds of APIs, what happens when somebody goes in and makes a schema change on the IBM i side? How do I know what I have to change? Well, we’ll track that for you and we’ll make sure that the two sides stay in sync, so you don’t break the API because you made a change in one side that isn’t showing up on the other side. So basically, what you’re doing now is you have the ability to maintain all of the data descriptions and ensure that they stay in sync. So again, you run the command. It says here, create the API. We’ll generate the API based on the information in this data model. Oh, actually, I didn’t mean to have this. This is actually a screenshot from our new graphical user interface that’s coming out. So instead of running a command, you’ll be able to fill that data in and then say, just generate the API. So again, so the productivity is here as well. You just generate the API. It builds it for you and you don’t have to worry about building all that code into it. Now, included in that, there’s a whole lot of stuff. So when I do that generation, it not only creates that API definition, but it builds all the code for validating the data. It builds the authentication code for authenticating the user and determining what it is they’re able to do. It generates the connection code to talk to the appropriate connector on the IBM i. It generates all the code for parsing the JSON. It creates the code to actually execute the program, and it creates the code to translate back from parameter data into JSON. So all of that is part of that generation step. So you go in and you say, here’s what I want to generate, and it builds that for you automatically. So just to wrap up, the main things are that using Eradani Connect, the security is built in and you can use the latest in security modules. It’s very easy to maintain because you maintain the information about the API in one place and it generates the code for you. All of the error handling code is built in, so it’s handling anything that comes back and it’s logging everything so you can see exactly what’s happening. And I know we are using very simple data sets here, but it will handle very complex JSON data structures. It’ll handle very complex IBM i data structures, and it can handle all of the translations between the two. And it’s designed to be very, very high performance and handle the asynchronous nature of the open source environment. And again, our people are available to help you with those things. And with that, I’m going to turn it back over to Mitch. Mitch, any other questions? That was the only question I saw. Any other questions come up? Yeah, there is one, a good one from David.
He wrote, it’s about DevOps. He said, I need to create APIs on dev, and then I want to send them to QA. And non-production systems then deploy out to 12 systems. How easy is it for me to create on one system and send and deploy those APIs to another system? Who wants to answer that? Well, let me take a stab at it, and you can fix it up for me. But basically, what’s really interesting is that typically, in developing APIs, you’re developing them on your own machine. You’re actually starting with APIs that are running on your machine, calling out to the IBM i. So you may start there. And then you may deploy it to a server where it will run for test or run for production. And at Eradani, we actually manage all of our code using open source tools. So we’ve got everything running inside of Git and using Make for doing the builds and the deployment. So that’s our open source web code, all of our API code, as well as our RPG, our DB2, our CL code. Everything is managed in Git. We actually keep it up on GitHub. And when we do a build, it builds everything, all the open source stuff as well as the RPG code that needs to be built, anything that actually has to be built because of the changes that were made. It doesn’t build everything, just everything that needs to be built. And we do that via Make. And Make also does the deployment out to the places where it needs to run for that particular stage of the lifecycle. Aaron, do you want to add to that? Yeah, well, I just wanted to bring a real-life example to it. I mean, there is the example of internal at Eradani. But one point that I wanted to mention is one of our customers, in particular, we’ve been working on setting up Azure DevOps with. And basically, they’re now set up. And what they do, they are making APIs using Eradani Connect on their IVMI. And what they do is they write the code on their machine.They just make the code changes. And then on their local development machine, and then they commit it to Git. And then they go to Azure DevOps, and they click the Go button. And that handles the entire deployment process, everything that needs to happen from the build process, formatting, to the code checking, to all the validation, deploying it, restarting the systems, everything that needs to happen. It’s all automated. So to answer the original question here of how complex is it to do this, the answer is it’s extremely simple. And usually, what ends up happening is you write your code, you hit a button, and you’re done. And we can help you set that up, right? I know we’re out of time here, Mitch. So I know there’s one more question. Let me just answer the last question, which is about the pricing model. We try to make a very, very simple pricing model. It is not based on how many API calls. We don’t count stuff. We don’t care about your IVMI serial number, your IVM model number. We don’t tie it to any of that information. It’s really just based on the number of production LPARs that you’re running against. And we can get a more detailed answer for your particular environment.