Hello, everyone. I’m Caleb, your host for today’s webinar. I’ve been living in the IBM i APIs and integration world for most of my pretty short professional career, and I’ve been loving being a part of the IBM i community. On behalf of the entire Eradani team, welcome. Every IBM i shop must have an API integration strategy in 2022. We hope that your imagination will be opened to a whole new world of integrating modern technologies to connect to your IBM i environment. Speaking today is Dan Magid. He’s been involved in the IBM i community for decades, and he’s presented to hundreds of webinars, spoken at dozens of conferences globally, and he’s a regular published author of articles around bridging the gap between your IBM i and everything new coming from the open source world. Before we get started on our session, and before I hand it over to Dan, we’re going to cover just two brief pieces of housekeeping. Today’s webinar is going to be recorded, and we’ll email a link of that webinar replay at the end of the session. Please share it with your peers. Number two, please submit your questions to the Q&A box or just the chat box, and we’ll be sure to address as many of them as we can at the end. With that, I’ll hand it over to you, Dan.

Great. Thanks, Caleb. Let me go ahead and share my screen here. Okay. Can everybody see the PowerPoint? Yes, we can. Great. Okay, terrific. I’m going to start out with some PowerPoint slides, and then we’ll actually take a look at some real-life stuff using APIs with the IBM i. Welcome to this webinar on why everybody needs an API strategy for the IBM i. APIs are transforming everything about how we do business today. It’s really the next big wave of technology. We had the computer revolution, we had personal computing revolution, we had the internet and the web, we have mobile, and now we have APIs, which is the interconnectedness of business. Basically, everything you do today, you’re using APIs. You go out to Amazon and you look for products, you see a whole bunch of product information about different things, and that information is getting populated on the Amazon site via APIs. If you go out and you make your order and then you want to get a shipping quote, there’s an API call going out to the shipping providers to get information about how much it’s going to cost to do your shipping. When you go to the supermarket, you pay for your groceries. There’s a whole raft of APIs that are being executed as you do your payments. APIs are connecting businesses and they’re becoming more and more integral to everything that we do. I’m going to talk a little bit about why you need an API strategy, the components of an API strategy, some of the challenges involved in APIs, and then we’ll talk a little bit about how Eradani can help you. By the way, if you have questions, as Caleb said, please put them into the chat. Again, just my word for it, pretty much everybody is saying today that the API economy is changing everything that we do. We’re seeing not only that it’s increasing the speed of business and reducing costs, but it’s also cutting the amount of time it takes to develop applications because rather than build everything yourself, you can use functions that have been built by somebody else.This is just a graph of the growth in API collections that are being hosted on Postman. Postman is just a site for hosting APIs. You can see the growth in collections is very, very fast, but that’s actually nothing compared to the speed with which the calls to APIs are growing. Today, there are trillions of calls going out to APIs every day, so trillions of calls, and it’s growing very, very rapidly. This is really changing the way business is being done. If you talk to business managers and ask them, are APIs part of your digital transformation strategy, just about everybody says yes. Everybody recognizes that this is really part of what you have to do in order to take part in what’s happening in business today. IBM is pushing that strategy as well. They’re looking to API-enable the IBM environment so that the IBM I can play in this new world just like everything else. They’re very, very committed to making sure that the IBM I is just as powerful a player as every other platform in the API economy, so you can build APIs and expose your existing applications. Now, their strategy is that it’s a blended strategy, so you’re going to continue to use your RPG, your COBOL, your CLDB2 applications and leverage all the investment that you’ve made in those, but then expose them via APIs so that people can access those capabilities. You don’t have to throw out what you have. You can simply make it available via these API technologies.

Now, when you start to think about opening your system up to APIs, a lot of people get concerned. They talk about, well, gee, if I open up my IBM I to APIs, do I have to be concerned about security? The answer is yes. If you’re going to open up your IBM I to people calling into it via APIs, you need to think about how are you going to secure your system as you give people the access that they need to get the information that they want. And as you can see, pretty much every organization is saying that APIs are going to become the leading place that hackers are going to look to in order to attack systems. So it’s going to be the place they’re going to go. So you really, really want to think about your security strategy. Now, the good news is because everybody knows that this is where people are going to try to attack, there’s a lot of work that’s being done to make sure that the API layers are very, very secure. And there are lots and lots of things you can do to ensure that your system will be safe. So what are the components of an API strategy? What are the things that you need to think about? So whenever we talk to people about setting up their API strategy and moving down the road of implementing APIs, the first thing we want to say is, well, what’s the use case? You don’t want to do technology just to do technology. You want to say, OK, so what is it that you want to do? What is it that you’re trying to do? So what’s the use case that you’re going to support with your APIs? So let’s find what is the value to the business of actually creating the APIs. You can start small. You don’t have to try to API enable everything at once. You can say, I have this one specific thing that I want to do. I want to give my customers access to their orders online. So I want to create an API that will give them mobile access, let’s say, to their orders. Or I want to be able to show them the shipping location of something. Or I want to be able to give them an insurance quote. So there are lots and lots of different things you can choose to do. And you can start small and then expand the APIs that you provide. But we always recommend that you look for something that actually is going to provide some value to the business so the business can start to understand what APIs can do for them. And then once you’ve decided what the use cases are that you want to API enable, you need to figure out, well, so what are the sources of data and functions? Where am I going to get the data for this API? What functions have to be executed in order to give the data to the people who are asking for it? And then in the IBM i world, you have to figure out, do I need to componentize my system? Is there a way to get this data out? In a lot of IBM i environments, the applications are very large monoliths. And it’s hard to go in and run a particular function outside of the entire business process. So are there things I’m going to have to do in order to make that possible? And then what tools am I going to use? What tools am I going to use to API enable the system? What languages do I want to use? What management tools do I want to use? What’s the tool set that I’m going to use in building and maintaining my APIs? And then, of course, security. How am I going to secure the environment to make sure that I completely eliminate the risk of attacks on my system? And how will I manage those APIs? So not only how do I create them, but then how will I get them through my testing process into production? Because APIs, like everything else, have to be managed. So let’s look first at ROI. What’s the value to the business? And there are a whole lot of use cases that we have come across in the IBM i world. These are actual real cases that we have worked with customers on. 

So one of the first things we started hearing about a few years ago, people wanted to API enable their IBM i as part of a modernization effort. So they wanted to use the latest technologies to build the coolest user experiences. And so they needed to be able to build that in new languages and yet still access their IBM i back end, still get the functions and the data from the IBM i. They didn’t want to rewrite the entire application. They simply wanted to create a new way of accessing it. So the API enabled the functions in the IBM i that would support then the new user interface they wanted to create. The other thing we run into a lot are customers who have multiple platforms in their environment. So they’ve got Windows platforms, Unix platforms, Linux platforms, and their IBM i. And they want to be able to share functions across those platforms. So they want to be able to say, I’m doing something on the IBM i, but I now need to execute something on my Windows system, or I’m doing something on the Windows system, and I now need to execute something on the IBM i. I want to be able to make those things talk to each other. And then other customers have started to extend that beyond their own internal networks and extend their API support to their customers and business partners. So they want to be able to process things directly machine to machine rather than having a process where a person has to get involved. So we’re seeing people doing things like, for example, integrating purchase orders directly into their system so that a customer can simply send in an electronic purchase order. And it goes right into the order entry system. It kicks off an acknowledgment that goes back to the customer. And the entire picking and shipping process is completely automated so that nobody has to get involved to look at that order. It’s simply happening as an API process from the customer to the vendor. And I think maybe driven by some of the supply chain problems we’ve been having recently, we’re seeing more and more people who want to automate everything up and down the supply chain using APIs. In fact, some of the major manufacturers have said that if you want to play in their ecosystem, you have to support their APIs. So you have to be able to communicate with them via their APIs. So from the time something is manufactured to its warehouse till it’s put into a container until it’s put on a train, it’s put on a truck, or it’s put on a ship and shipped out, and then it’s delivered to the customer, all of that is being maintained. All of the information about that process is being shared via APIs. The other use case we’re seeing a lot of these days are people who want to put up electronic storefronts. They want to create e-commerce stores using some of the popular platforms out there, so like Amazon or Shopify. And they need to be able to share real-time inventory information so that when you’re on eBay and you order something, you actually know that you have that in stock, that you can ship it. In fact, some of these sites, if you are advertising something that you actually don’t have, will kick you off the site if you’re doing that too often. So you need to be able to ensure that the information showing up on the shopping site is up-to-date with what you have on your back-end warehouse management system. So when you’re sharing information, you want to be able to do that real-time. Or people are doing things like calling out to Google Maps to get location information or mapping or directions information or geolocation information. They’re calling out to their transportation partners to get information about where are shipments. They’re calling out to their payment providers so that they can process payments electronically. So a lot of things you can do to automate business processes using APIs. And then other customers are saying, you know what, I need to have a strategy for starting to use newer languages because as my RPG programmers are aging, I need to make sure I’m going to have a way forward to be able to continue to enhance and maintain my applications. And there are millions of JavaScript programmers out there, but fewer RPG programmers. So if I want to start to adopt this new technology, I need to be able to have a way to communicate between all that valuable RPG code or COBOL code that I have and these new languages that I’m building. And APIs can give you that bridge for adopting the new languages. And then I want to start taking advantage of open source components. The reason application development is so fast these days is people are not writing everything from scratch. Rather than writing everything from scratch, they’re going out to these open source repositories like NPMJS or GitHub or PyPi. And they’re finding components that already exist that they can simply wrap into their application. So they no longer have to write everything from scratch. We were working with a few customers recently that had been using the advanced function print utilities for doing barcode printing and QR code printing. And when IBM ended support for that with 7.3, they had to find another option. And what they found was that there were open source components that did that. And all they had to do was hook those open source components up to their IBM i programs. And they were able, again, to print their barcodes and to print their QR codes. So it’s a way forward to add capabilities, to add functions to your applications without having to write it. So you don’t have to say every time you need to do something new, how am I going to write this? You can start to ask the question, well, has somebody already written this? Is this already available for me? And these are just some of the ROI things that people have been looking at. 

So increasing revenues. We had a customer that they’re an insurance company. And they had a real estate company approach them and say, gee, when people are looking at a property on our website, we want them to be able to get a real time insurance quote for that property. So what they did is they opened up an API to their quoting system for the real estate company. So the real estate company can send them an address. Now, the problem is in order to give an accurate quote, they can’t just use the address. They actually have to have the latitude and longitude of that property. So they then call from their IBM i out to Google Maps to get the latitude and longitude for that property. They then put that information into their quoting system. They then have to call out to a FEMA API to get some more information before they can actually then execute the quote and then return the quote to the real estate company. But by automating all of that, they now have a whole new channel for potential customers where customers who are on that real estate website can go out and get an insurance quote from them. They now have another potential customer. So it’s a new source of revenue for them. Other customers are finding that they can reduce costs by eliminating manual steps from a business process. We had another customer that they kept all of their historic invoices on a Windows system. So they archived all their old invoices on a Windows system. But their order entry system was on their IBM i. And they would have customers who would say, hey, can you get me an old invoice? Can you get me a copy of an old invoice? So they would have to go into the IBM i, look up the customer, find the invoice, and then take the invoice number, go over to the Windows system to get the invoice. And then they would have to email out that invoice. What they did is they used APIs. So now they can put an option right in the IBM i green screen to say, send out this old invoice. It goes out. It calls out via an API to the Windows system, finds the invoice, and emails the invoice out to the customer. So they no longer have the manual process of going to the Windows system to get it. You can also get things out to market faster. So again, if you need to add functions to your applications, you can do it faster because you can use those open source modules to get function into your applications much more quickly. Also, many government agencies are allowing you to do compliance reporting via API. So now you can automate some of your compliance reporting simply by calling out to these government websites and out to their APIs. Once a customer starts using your APIs, they sort of get more tied to you. APIs increase customer loyalty because what you’ve done is made it much easier for them to do business with you. So we’ve seen when people are starting to communicate via APIs, it increases that tie between the vendor and the customer. By creating these new user interfaces, these new modern user interfaces using APIs, you can reduce the amount of training it requires when you bring in new people. New young people, if you’re bringing in their organization, they’re going to want to work on some kind of a graphical user interface, not necessarily through a green screen. And they can learn those much more quickly. And by adopting some of these new technologies, you get increased access to developers. There are a lot more JavaScript developers out there than there are RPG developers. And it also helps you future-proof your applications. Once you create this API layer around your applications, you can support whatever new technology comes out. So if there are new languages or new things that you want to do, you can use those same APIs. You can use the same API you use to build a user interface to talk to an Internet of Things device or to talk to your vendor with an API. So you can add capabilities around your system by simply using the APIs that you’ve created. So there are lots and lots of ways of getting ROI from an investment in an API structure. 

So once you’ve decided on the use case, you have to figure out, OK, so where is the data? Where are the functions that I’m going to provide? And so whether you’re providing APIs for people who are calling in or you are calling out to APIs, you need to think about, OK, so where is the data? Where are the functions? So you think, if I’m going to provide an API, what programs are going to need to be called in order to get the user the data they need? What tables or views or what physical files, logical files am I going to have to make available to get that information? What input fields are we going to require from them? So what do they have to send us? And then what are we going to send them in return? What kind of output data is going to come out of it? And then what data formats are we going to support? Most people who are doing web services these days are looking for JSON data. So you’re not going to be able to send them a DB2 table. You’re not going to be able to send them parameter data. You need to send them something they can read, which typically these days can be JSON. So they may send you JSON, and you may have to reply with that. And then are there multiple steps to the process? So do you have a situation where you’re going to get some data from one place, kind of like the insurance company? We get an address, but then that’s not enough. We have to then go out and get the latitude and longitude. We then have to get the information from FEMA before we can actually give an answer. So is there an orchestrated process that you have to go through with your API? And then are you going to do SOAP APIs, REST APIs, or are you going to use old style EDI? What is the way you’re going to make that data available? Now, most people today are using REST APIs. And then how are you going to authenticate? How are you going to make sure you know who that user is and what it is that they’re allowed to do? And then you have to figure out, OK, so now how are we going to transform the data? So on the IBM i, we’ve got our RPG data structures, our parameters. How are we going to transform that into JSON, into XML, into whatever it is that we need to provide for the end user? And then what kind of volumes are we expecting? Is this one call an hour, or is this we have one customer, they’re a transportation company, and they told us they get a million requests for rate quotes a day. So they’re getting a million quotes a day. We tested that insurance application with 250,000 simultaneous users. So you can have very, very high volumes. You can have very, very low volumes. But how you architect your API is going to be dependent on what volume you expect. And the same thing for if you’re calling out. So that was if you’re making an API available for somebody calling in. If you’re calling out to an API, same kinds of questions. What services? Where is the data that I need? What services am I going to have to call? Is it going to be the weather service, Google? Is it going to be a government agency? Is it going to be my suppliers? Is it going to be my customers? Where am I going to go to get what I need? And what format of data are they expecting? And what inputs are they expecting? And what are they going to give me in return? And the same questions. I’ve got to do that transformation of the data from one side to the other. And I need to know what kind of authentication they’re using so I can ensure that I do the handshake correctly. And then what am I going to do if the service is unavailable? How am I going to handle if there are errors in my process? How do I rescue the requests so that I make sure that they get handled and I don’t lose anything? And then another big question to ask is, is there an SDK, a software development kit for the service? A lot of these vendors are actually providing for you the code to access their web service. So you don’t have to build the code and you don’t have to maintain it. You can just import into your system the code that they’ve already written. And this is just an example here. Here you can see I’ve got this. This is the open weather service. And here’s the information that you can look at. So they show you here. Here’s how to call our API. And here are the parameters that we allow you to give us. So these are the different ways you can call our API to get what it is that you need. And this is the kind of documentation. If you search on just about any API, you’re going to see this kind of documentation where you can get information from them about the API. And one of the other things that you’re going to want to think about is what kind of documentation are you going to need to provide for your API users? So if you’re going to provide an API, what kind of documentation are your users going to need in order to access their API? So you’re going to want to give them things like what are the input parameters? What are the formats that we’re expecting? That kind of data so somebody can easily use your API if they need to. So let me go back over here to the PowerPoint. So now if I’m starting to expose my IBM i code, I need to think about, OK, so do I need to componentize that IBM i code? In other words, do I have a very chatty application where I have to go to the user interface, put some information in, I get something back, and then I have to put some more information in, and then I run some more code, and then I get something back, and you go back and forth multiple times. If you’ve got a big model, it can be hard to say, OK, I just want to pull out a function from that. So you need to think about, am I in that situation where the thing that I want to execute, the service I want to create, actually is in some code that’s built into a big business process that might be difficult to pull out? And so then I have to say, OK, so how am I going to approach that? Can I separate out the code for the function I need from the base module? Can I just create a new way into that process? Do I need to write a new module that will expose just the capability that I’m trying to provide? Can I go directly to the database and do the function just by accessing the data directly? Or if I really can’t get out of that whole user interface conversation, do I want to use IBM’s RPG Open Access to actually create a web service that simulates a user interaction, which is another potential option? And then I want to look to see what kind of tools, what are the right tools for what it is that I’m going to be doing? So what are the right tools to use? And you have lots and lots of options. The really good news is IBM is looking at this blended environment where you’re going to be using different technologies to deliver your applications to your end users. So they want to give you lots and lots of potential options.

So your job is to figure out, well, what’s the right tool for the thing that I want to do? So I want to make sure that, depending on the use case, I want to use the right tool for that. And again, IBM is giving you all these different options. And you’ve got over here on the left, you’ve got things like Angular, React, Vue.js, PHP. These are languages specifically built for building great user experiences, for building the kind of user experience that people expect today. So you can look at those languages. You can use Java for building enterprise kinds of applications. If you’re doing machine learning or analytics, Python is probably the best language for doing that. So it might be something you want to look at. The great thing is IBM is providing support for all these different languages. And so you can choose the right tool for the job for you. Now, you might find that, in your organization, people have already chosen a language for doing the distributed development. So maybe a Microsoft shop, and you’re already using .NET or Microsoft Core. Or you’re a JavaScript shop, and you’re using React to build your user interfaces, or a JavaScript. So you may already have those things. The good news is that you can create APIs that can be accessed by any of these technologies. You don’t have to write specific APIs for each technology. You write your APIs, and you can use whichever technology you want to access them. And IBM is also providing tools to make it easy to use these new technologies. So things like YUM and RPM, these are package managers. So if you’re starting to build applications by assembling components together, these will keep track of all the components that you’re using, the versions that you’re using, to make it really, really easy for you to keep your system up to date. They’re also providing open source tools like Git for doing version control. So you can use those tools to manage your development efforts. And of course, they’re providing support for all of the modern languages and frameworks. So IBM is really investing significantly in making it possible for you to use this new technology. And what web services do is they give you that loose coupling layer that says, OK, I’ve got my RPG code, my COBOL code, my CL code, my stored procedures in a DB2 database. I’ve got all that stuff, and I can continue to maintain that. But I make it available via this web service layer so that I can choose whatever technology I want on the other side to talk to it. So I can talk to it from IoT devices, from web user interfaces, from Windows applications, Linux applications, from different languages. And they just go to that web service layer, and the web service layer takes care of translating things into something the IBM I can deal with and then translating what it gets back from the IBM I back to the open source layer. So as technology changes, you can continue to adopt whatever the newest thing is. So whatever the newest languages are, you can adopt those and use that web service layer, that existing web service layer, to get to your IBM I. Now, we recommend JavaScript for web services, and the reason we do is because JavaScript is built for web services. That is what it’s built to do. JSON, which is the Lingua Franca today of web services, it’s how people transmit data for web services. Something like 80% now of web service communication is done via JSON. JSON is JavaScript Object Notation. It is a JavaScript object. So JavaScript knows JSON out of the box. You don’t have to do any parsing. You don’t have to do any searching for fields. It knows exactly what’s in that JSON object because it is JavaScript. It’s very popular. So JavaScript is a very, very popular language. It’s really, really easy to learn. It’s designed to be easy to learn. And the vendors who are providing code for you to access their APIs, that’s probably the most popular language that they provide that code in. So if you want to take advantage of the code that the vendor provides, they’re going to provide that code pretty much universally in JavaScript.

Now getting information out of JSON in JavaScript, let me just give you a sample of how easy that is to do. So this is a complex JSON message load that’s coming back from Google Maps. Actually, this is from the Weather Service. So basically, you can go in and you can ask for this information. And it’s going to give back this big payload. And you can go in. Actually, I’m going to pull up a different example here. Let’s go in here. So this is the traffic one. So here’s a bunch of traffic information coming from Google Maps. And what I’m going to do is I’m going to open up my developer tools. One of the very cool things about your browser, and I’m just in Chrome here, but your browser has a JavaScript development environment built in. And I can go over here and I can copy this entire JSON payload. And I can paste it over here in my JavaScript window. And just by hitting Enter now, it has actually parsed that entire JSON payload. And I can now look at it as a field. So here, I can see that it’s a multi-level data structure that has arrays within arrays. So each element in an array is another array. And then there’s another array inside of that array. So it’s a very complex data structure to get down then to this field that here’s the street name. So there’s the street name of the street I should be going on in order to get the fastest route. So it’s complex to try to find information in here. But with JSON, if you’re using it in JavaScript, it really isn’t. I can simply say, I want to let this variable. So I can just create a variable. And I want to let that variable equal that same JSON load. And then if I go in and say, OK, show me what’s inside this demo field, you can see I get that same data structure. So it’s already built into that JSON object. And then I can go in and get whatever field I want. So if I want to go in and grab one of those fields, I can just say, let new fields equal. And I’m going to say in that data structure that’s in demo. And I can go in. And it’ll actually even prompt me here to tell me, here’s the fields you can use. I’m going to go into this array. And I’m going to go to the first element of that array. And again, I can select the next level of the array and get the first element of that. And then I can go in and select my DE field, which was where the street name was. And if I hit Enter, and I go in and say, OK, show me new field, I can see that it’s got that street name in it. So that was all there is to, in JavaScript, of going into this incredibly complex string and find the data that I want and pull it out. It’s really just two lines of code to get what I need. So it’s really easy to work with this complex JSON in JavaScript. So that’s one of the reasons that we recommend that people use JavaScript for these kinds of applications.

So let me go back over to the PowerPoint. So those are some of the reasons why we recommend JavaScript as the way to do web services, just easy to work with. It’s very, very popular. It’s got all your security stuff built in. So you can use all the latest in security technologies. And it’s also designed to run in the asynchronous way that the web runs, which is you don’t necessarily know you’re going to get a response immediately back from something that you asked for. And with JavaScript, there’s a lot less to do. If you look at the way you do, if you’re doing RPG, if you’re calling web services from RPG, there’s a whole lot of stuff here to do this. You’re calling from the database, doing an HTTP GET. You’re spinning up the IWS server. And you may need to bring up the Java virtual machine for that. You’ve got to manage your certificates using the digital certificate manager. You then get the data back. You put it into a club in the DB2 database. So it’s just this big sort of blob of data. You use something like you have to use a tool like the Agile then to parse it to try to find the fields you need before you can hand that back to your RPG program. If you do that with JavaScript, you eliminate a whole lot of those steps from the process. And this just gives you a sense of the popularity of JavaScript and why it’s a great language to use. So you can see up here for years, JavaScript has been the most popular language out there. In fact, if you look here, TypeScript actually is just a form of JavaScript. And it’s the fastest growing thing out there. So JavaScript continues to be the most popular language for doing this kind of stuff. And this is actually the popularity of languages for web services. And again, you can see JavaScript is by far the most popular language out there for doing web services. And what that means is the reason popularity matters is you’ve got lots and lots of people out there who know how to do this stuff. There’s lots and lots of code already available to you to make this really easy so you can put up web services really quickly. We had a customer tell us that he used to take when his developers, when his UI developers would ask him for a new service, it would take him days to put it up. Now he can put up a web service during the time he’s actually on the phone with them talking about what they want to do. So you can do it very, very quickly. Lots of developers out there, lots of open source packages that you can use. It’s very well proven. It’s being used by all the largest companies in the world. And again, you get that future proof where once you’ve created a JavaScript web service for your application, you can use it in a whole variety of ways. So just as an example, if you’re going to access AWS, you’ve got to write, if you’re doing it from RPG, you’ve got to write all the authentication, you’ve got to write the messages that you’re sending, you’ve got to do all the serialization of the data, the transformations, you have to do all the error handling, the logging, and you have to maintain it and they are changing these APIs all the time. Whereas if you do it in Java or in JavaScript, they provide all of this code for you. So you don’t have to write any of that code. You simply import the SDK into your application and do the web service call and you don’t have to worry about writing all of that code. So you can get this done. You can get that interface done much, much more quickly. And in fact, Amazon says making REST API calls directly from your code can be cumbersome unless you have a really good reason not to. You should always use the SDKs and they provide SDKs in JavaScript, in Java, and Python. 

So there are a few languages that they provide them in. And this is just an example of one customer who wanted to do a user interface transformation. They were a mortgage company and this is sort of what their original green screen looked like. And they navigated amongst the many panels using function keys. And then if they had to get to another area of the application, they had to navigate out to the main menu and then navigate back through a series of menus. So this is a React version. So this is now a JavaScript version of a new user interface. All the code behind it is exactly the same. Nothing changes about the RPG code. But now you can do things like send the data out as an email or export it to a PDF. Or you can navigate through the data using these tabbed views rather than having to use function keys. You can put images on the screen. You can have shortcuts so you can go directly to some other part of the system rather than navigating through menus. You can put in infinitely scrollable lists of data and export that data Excel. And that’s all using web services and open source components for providing that capability. So you can build it very, very quickly. This is actually another project we did with IBM where our team actually built IBM as a product called Cloud Storage Solutions for IBM i. And what it does is it allows you to move code from your IBM i up to the cloud. So you can move it to the IBM cloud. You can move it to the S3 to the Amazon cloud. You can hook it directly up to BRMS and have your backups just go directly up to the cloud. And that’s all done using APIs. And we were able to build this very, very quickly because we used open source components. So we didn’t have to write the code to do these three controls. We just downloaded a component and plugged it in. We didn’t have to write the code to talk to the Amazon APIs. We just used the Amazon SDKs. So we were able to build this very, very quickly by using JavaScript and open source. This is another example of a customer of ours who’s using APIs. They have these handheld devices in the warehouse. And they need to send data to their IBM i and get data back from their IBM i to the handheld devices. And they use these APIs to do that. They’re even pulling down spool files from the IBM i via an API and printing them on locally Bluetooth connected printers, printers that are connected to that handheld device. So they’re using an API to get the spool file and print the spool file down on these handheld printers. And then we have a lot of customers that are using APIs to feed data into charting engines. So there are lots and lots of open source analytics and charting engines that you can do that will create visual representations of your data. And you can just use an API to go get the data and feed it into those tools so that you can create these graphical dashboards for your data. So that’s sort of creating the APIs, the technologies that you can use to make it fast and to make it easy. Now, let’s talk a little bit about security and authentication and authorization to keep those APIs safe. So these are the basic building blocks of the security environment for the web. So SSL or TLS. And SSL and TLS are basically the same thing. TLS is just the latest version of it. It’s transport layer security. So you have sort of the security layer of transporting the data. Then encryption. So you encrypt the data so that it can’t be read as it’s being sent across the line. There are cipher suites. Those are basically the encryption algorithms that people are using. And you need to make sure that your cipher suites are up to date so you can talk to the people you’re either providing APIs to or consuming APIs from. 

I’m going to talk in a minute a little bit about basic authentication because a lot of IBM users are using basic authentication. Then we’ll talk about encrypted JSON web tokens, your encrypted identification tokens. And then we’ll talk about third party authorization using things like OAuth. And I’ll talk a little bit about multi-factor authentication. These are the basic building blocks of creating that secure environment. Now, the TLS, transport layer security, the idea behind it is that they want to make sure that no one can read your message, that no one has tampered with your message. And for you Marvel fans out there, ensure that they are who they say they are, that you actually know who the person is. And all of this is designed to be done by the TLS, by the transport layer security. So this is just a quick diagram of what that sort of internet architecture is. You’ve got this four layer architecture, which is the hardware, the device layer, the internet layer where the devices are talking to each other and the internet addressing for transporting information. Then the host to host transfer to how do you get information from one host machine to another host machine. And then the application layer where the applications are actually talking to each other. And TLS actually runs in that layer between the transport and the application layer. So it runs on top of the transport layer, hence the name transport layer security. So it’s running on that layer. Now, the reason they do it at that high layer is they didn’t want to make you write special security versions of your security code for every device you might be using. So devices can talk to each other freely. It’s when you start transporting data that you start having to be concerned about how are you going to secure that. And this is just another view of that same thing where you can see you’ve got the physical layer, the network to network layer, the transport layer for host to host communication, and then the application layer where you’re actually using applications to process data. So you want to make sure that that connection, that transport layer is secure. Now, the old way that people were doing this is they were using IBM i credentials. So they were sending IBM i credentials on every web service call. And then if you didn’t want to make the user sign on every time, you actually store those credentials in the browser so that you could reuse them. The problem is that both of those things represent potential risks where somebody could discover the credentials. So every time you send the credentials up and down the wire, they could be discovered. And what we also found is that a lot of people were using 64-bit encoding for sending the credentials. 

Now, encoding is not encryption. The 64-bit encoding algorithm is well-known. Everybody knows it. So the problem is if you encode it using 64-bit encoding, anybody can decode it. So anybody who intercepts that communication can decode it and read what your credentials are. So encoding is not encryption. And the other thing is they were using IBM i native credentials, which means that they were giving people native access to their IBM i. So what we’re seeing now is people are moving away from basic. That’s basic authentication. We’re seeing people move away from basic authentication to now encrypted token-based authentication, where you send the user ID and password once, you get back an encrypted token. And from then on, all the communication is done with encrypted tokens. So if somebody were to intercept the communication, all they would get is this unreadable token. So you’re no longer storing the credentials anywhere. You’re no longer sending the credentials in a way that they can be read. And those tokens can be expired. You can say they last for a minute, for 10 minutes, for a day, for a year. It’s up to you. So this is just a little bit about what’s happening with basic authentication. Because of those security issues, people are deprecating basic authentication. People are no longer supporting it. So this idea of sending the user ID and password every time you run the service, that is going away. And you can see by Google, Microsoft, and all the big API vendors are ending support for basic authentication just because of the security problems. They’re telling you to go to things like OAuth for doing it. 

So let me talk a little bit about, for those who aren’t familiar, what JSON Web Tokens are. So a JWT, this is basically what a JSON Web Token is. It has a header that says, here’s what I am. I’m a JSON Web Token. And then it says, what is the algorithm I’m using for encryption? So it’s going to share that information so the receiver knows how to decrypt what it’s getting. And then the payload, which is encrypted. And then a signature that says, this message hasn’t been tampered with. This is basically a hash that it runs on the message. And when you get them, when you receive the message, you rerun the hash and make sure that they match so that you know that the message hasn’t been tampered with. So the header that identifies what it is, the payload that has the user information, what their role is, what they’re allowed to do. So the JSON Web Token not only identifies you, but it identifies what it is that you’re allowed to do. And that is all sent then to the receiver. So you log in with your user ID and password. The server creates that JSON Web Token, and it sends it back to the browser. You then call back in, or to your API calling program. You then send back the JSON Web Token. The server recognizes it, says, OK, yes, that’s a valid token. And it will send the response back. So again, from then on, you’re communicating with these encrypted tokens. Now one of the issues there, though, is how do I know when you first sent me that user ID and password that you are who you say you are? And that’s where third-party verification comes in. It’s kind of like what you do when you go to the airport and you check in. When you go through security, you show them your boarding pass, which basically is your JSON Web Token. Here it says I’m authorized to get on this airplane. And then you have to show them your ID so that they can verify that you are who you say you are. And today, you even have to use a real ID in order to prove that you are who you say you are. So you have to prove who you are. And that’s basically what things like OAuth do, is they’re doing the same thing. They’re attesting to the fact that you are who you say you are. And there are a lot of OAuth providers. There are a lot of people who do that verification. So for example, you see on a lot of websites, like you see here on this Trello website, you can log in with a user ID and password that they know. Or you can say, no, I’m going to have Google verify who I am, or Microsoft verify who I am, or Apple. So you could use a third party who would say, yes, this person is who they say they are. So this is now using OAuth in order to provide that verification that you are who you say you are. And the great thing is, is if you’re using, again, if you go back to if you’re using JavaScript, the code to do all that’s already built for you. So it sounds complicated, but if you’re doing an RPG, you’ve got to write all of that. But if you’re doing in JavaScript, it’s already built. You can just go up to the NPMJS server, and you can download the OAuth code, and it’s already there. It’s already built.

So that’s a little bit about security. Now managing the environments. And now if you’ve got to manage this stuff using DevOps, I want to be able to move things through some kind of a lifecycle. So I need to move them through some managed lifecycle from development to test to QA to production. I need to make sure my API is pointing to the right stage of my lifecycle. So I want my QA API to be pointing at production. So you can use standard tools like Git, like Jenkins, to actually manage that code as it moves through the lifecycle. And one of the very cool things is you now can even store your IBM i code in these kinds of tools. So IBM now lets you build things directly out of the IFS. So you can store things in version control tools like Git and manage it right along with your services code and do your builds directly from there. And then you can decide what is the deployment strategy you want to use. Do you want to run your API server directly on your IBM i, so all the calls are coming directly to your IBM i and your IBM i is connected to the internet? Or do you want to have some Windows or Linux servers that are sitting out in the DMZ or outside your firewall? They’re taking the requests and then that information is going from those servers to your IBM i, so you have that sort of level of separation. Or do you want to actually put your API servers up in the cloud and have them hosted on AWS or IBM Cloud or Azure so that you can scale up and scale down as you need to and then have those talk to your IBM i? So you can implement this in whichever way you’d like. So there are lots of options in how do you manage the development and deployment of your APIs. So let’s talk real quickly just to wrap up with a couple of things that Eradani can do to help you with this process. So basically Eradani has our Eradani Connect server, which is an API server. And it has built into it a lot of the functions that you need to do the things we’ve been talking about. So it has like load balancing. So if you have very high volumes, it will balance the load across multiple servers. It routes the request to the appropriate endpoints on your IBM i. It has built into it the authentication. So the JSON web token authentication, the OAuth authentication, SAML, Kerberos, LDAP, those are all built in so you can use them. It does the input validation and data serialization. So it will transform data from JSON or XML to RPG data structures and parameters. And it’ll do the same thing on the way back. It has built in all the error handling. It will document your APIs for you. So it’ll actually generate that API documentation that says, here’s how you call the API, and here are the parameters it takes. And it does all of the logging. So it will handle all of that for the APIs that you build for your IBM i. And then if you need to consume APIs, you can simply call out from an RPG program to this Eradani Connect send request function, send it the inputs, and we will then execute the web service call for you. So we will do all the work of transforming the data, of doing the secure handshake with the web service provider, of handling the errors, of handling the asynchronous nature. So if the web service isn’t available, we’ll queue up those requests and then send them out. And then we’ll bring the data back and hand it back to you as RPG data structures, as DB2 data, as parameter data. So as an RPG programmer, you don’t have to worry about all the things you have to do in order to call a web service. The Eradani Connect server will handle that for you. And it’s built to be very, very high speed and very, very secure. So we’ve done a lot of work to make sure that this can handle very high volumes. As I talked about before, we tested this with 250,000 simultaneous requests on a 1.5 core IBM i. We’ve tested it with a million requests a day. So you can handle very, very high volumes with it. And we actually have an integration module that will allow it to integrate with native IBM i change management systems. So if you’ve got a change management system you’re using to move code through a development lifecycle, you can manage the services you’re building with that and tie it right into something like Git.

So let me just go give you a quick view of what that actually looks like. So this is the Eradani Connect dashboard, where you can see a list of what we call applications. Applications are just business functional areas that you can create. And you can have as many of these as you want. And it’s just a way of organizing your APIs. What we have found is once people start building APIs, they find that there are lots and lots of use cases. And they build more and more and more of them. So they get to have lots and lots of APIs. So this gives you a way of organizing them so it’s easy to find the API that you need. And from here, you can go in and you can actually look at the list of APIs that you’ve created. So for this customer’s application, here are the APIs that I have. If I want to, I can actually right from here test the API and see if it’s working. So I can go out and run a test against that API endpoint. And it’ll actually run that for me. And down below, I’ll actually see here’s the data you’re getting back from the API. It also generates that API documentation that I can download and send out to a customer. So if somebody wants to use the API, it will automatically generate that for me. And I can create new APIs directly from here. So I can go in and say, I want to create a new API. Here’s the endpoint. Here’s the name of my function. And then I can go say what I want to API enable. Do I want to API enable a program? Do I want to API enable a table? So I’m going to just search through my libraries. I’m going to find this particular library. And in that library, I can see I’ve got a couple of tables. I’ve got some programs. I can select a table and say, show me the fields. And I can select the fields that I want. And I can then generate that API. So I can generate an API right from my IBM i resources from here. And we also provide you with a dashboard for tracking what’s happening with your API. So you can see what kind of response time are people getting? How much of the CPU is being used? How much memory? How many requests am I getting? So you can track exactly what’s happening with your API. So there’s lots and lots of data here so that you can use to manage the usage of your APIs. Somebody suddenly goes from 10 API calls a day to 1,000 API calls a day. You can go look and see, well, why is that? Maybe there’s a problem in their API call. Maybe you want to shut them off. So you have ways of managing tracking the APIs. If there are errors, you can look at the list of errors. And you can drill in and see what the error was. So there’s lots and lots of data here. You can see for every API, you can see its performance characteristics. So it gives you a really easy way to manage your APIs, to create your APIs, and to then track what’s happening with your APIs. And that’s basically everything I have to say about creating APIs. Now, Eradani has a lot of things we can do to help you with this process. That’s all they do, is they do API enablement of IBM is. So they are experts in both the API technology, the open source technology, and the back-end IBM i technology. So we can help you get this set up. We can help you get up and running with APIs and ensure that you’re setting up a safe, secure environment for exposing your IBM i applications. 

So that’s basically it. Let me take a look and see if we have any questions. I don’t think I see any questions here. So if you have any questions, go ahead and put them into the chat. And otherwise, I think I will turn it back over to Caleb just to maybe wrap up. You’re muted. Thank you. Appreciate it. And thank you for your presentation, Dan. We really appreciate that. And we appreciate all of you for attending as well. Like Dan said, if you have any questions, please feel free to send those over. The chat will be open just for a second here. But you can also send it to info at eradani.com. And we’ll be sure to reach out to you from that field as well. And we look forward to seeing you all next time. So thank you so much.