All right, well, welcome, everybody, to this webinar on API infrastructure operations and architecture. And I’m going to start out talking pretty basically about APIs and how they’re being used in the IBM i environment and what the impact is that APIs are having on computing in general, because they are really transforming the whole technology landscape. They’re changing the way business is being done. So I’m going to talk a little bit about that. And then we’ll get in and talk specifically about different use cases in the IBM i world, so different ways people are using APIs. And then we’ll talk about security for APIs, because APIs have become the most popular vector for attacks on systems. And we’ll talk a little bit about API management and monitoring, and then a little bit about managing the development and deployment of APIs. So this webinar is going to focus more on operations and infrastructure on APIs rather than development of APIs, which, if you want more about that, we actually have a couple of webinars that focus on that.

So let’s get in and talk a little bit about the trends in APIs and what’s happening with APIs right now. So I traced the evolution and the popularity of APIs back to this memo that came out from Jeff Bezos over at Amazon. And he put this out. This memo came out in 2002. And what he said was he said, from this time forward, all teams will henceforth expose their data and functionality through services interfaces, meaning you cannot build any functionality for Amazon if you do not provide it with an API interface for people to talk to it. And then down here, number six, it says anyone who doesn’t do it will be fired. And thank you, have a nice day. So it really became a founding principle of Amazon and how they developed their applications. And a lot of people point to this as really the idea, the concept that made Amazon such an agile organization. They were able to move from marketplace to marketplace and to business to business because they were able to repurpose the code that they built just by simply rearranging the modules that they were using. And they’ve continued that to this day. If you want to do business with Amazon or use Amazon as a business channel, they provide literally thousands of APIs for interacting with their systems to allow you to automate the process of doing business with Amazon. So APIs have really become universal connectors between applications, between companies, between organizations to allow people to share data and to share functions machine to machine in real time. So we can do business very, very fast. If you think about when you go to Amazon and buy something, there are literally dozens of APIs being executed every time you do something. So when you look for an item and you see a list of items, Amazon is actually pulling the data about those items from their partner’s system. So they’re pulling in that data via APIs. When you go to get a price, they do an API call to their business partners to get price quotes. You want to schedule your shipment, they do API calls out to the shipping providers to get information about shipment costs. So there are constant API calls being made. If you place an order, that goes to the vendor to make sure that they reserve that item so they don’t sell the same item twice. So there’s the constant communication going back and forth via these APIs. And you can do the same thing in your IBM i environment. So you can use a few things for APIs, you can use all kinds of things for APIs. They can be the central switching station basically of all access to and from your IBM i. And companies are very, very rapidly adopting this. So APIs are becoming part of companies’ digital transformation efforts. So if you see here in this survey, it said that 65% of enterprise leaders strongly agree that APIs are part of their digital transformation strategy, 32% somewhat agree. So 97% of the people who responded to the survey said that APIs are an important part of their digital transformation strategy. Only a couple of percent actually didn’t think that they were important. And these are some of the reasons that they gave for why they’re important. So 49% said, we want to make the experience, the user experience better. And this is really important because all kinds of studies show that if people aren’t having a good experience through your website or through your API interface, they’ll leave and go somewhere else. They want to accelerate innovation. You can take advantage of emerging technology very quickly via APIs. In fact, if you’re interested in using some kind of technology, pretty likely that if you go and do a search on Google, you’ll find that there are APIs to access that technology. They want better collaboration among their internal teams. So they want to be able to share functions among the different teams. They don’t want to have a Windows group and a Unix group and an IBM i group and have them not talk to each other. They want to be able to make sure that everybody is collaborating and working together. And then they can also use third parties. So if they want to work with an Amazon or they want to work with a Shopify or they want to work with Magento or one of these outside organizations, they can work together and develop applications that talk to each other. And the developers, it makes it much easier for developers to do their work. Using APIs, they can access things like open source modules and add those to the applications. And I’ll talk a little bit more about that in just a couple of minutes.And what we’re also seeing is rapid growth in creating APIs between organizations. So if you look over here at this chart, you know, 74% of API communications were kind of on the Jeff Bezos line, that they’re internal kind of communications of the original idea that all of our applications will talk to each other. But more and more, the fastest-growing set of APIs are APIs that allow the companies to talk to their business partners and their customers, to make functions available so that there can be machine-to-machine communication across organizations, and then also to take advantage of these third parties that are creating APIs for performing different kinds of functions. And I’ll talk about some of those use cases as well.

These are some of the most popular use cases that we see in the IBM i world that people are using. And one of the first things we hear from people is, I want to build a new modern user interface for my application. You know, my users are tired of the green screen. They want a web interface. They want a mobile interface. They want something new. And what’s cool is that you can build these new user interfaces using open-source tooling or open-source languages like JavaScript React or Angular or Vue. And you can build these user interfaces very quickly by simply assembling pre-built components and then tying them into your back-end IBM i systems via APIs. So if you API-enable your IBM i functions and data, you can then use these tools to very quickly create these very modern user interfaces. And then the other thing that we’re seeing is people who are integrating internal applications. So they’ve got a Unix accounting system or a Windows system, and they need that to be able to interact with their IBM i. So they use APIs to allow the applications across those platforms to talk to each other. And what’s great about APIs is it’s a loosely coupled connection. So you can make changes on the Windows or Unix side. You can make changes on the IBM i side without breaking the connection between the two things. Because one of the fundamental principles of an API is there’s a contract between the consumer of the API and the provider of it that says, if you send me this data, I will send you back this other data, or I will run this function for you. So as long as you’re maintaining that contract, you can make whatever changes to your applications you want as long as they send you the data A, you give them data B back, or you execute function B for them. So as long as you’re maintaining the contract, you can make changes on either side of the API. And so people are then moving it out from, as we saw from the last chart, that people are moving out from just internal integration to saying, OK, I want to be able to communicate directly with my end user customers. So I want them to be able to electronically send me a PO and have that go right into my order entry system. Or, I want to be able to send out an acknowledgement to them to let them know that we got their order. And so we can have communication that goes throughout the entire process of doing business. And we’re seeing that across entire supply chains. We’re seeing people modernize the entire supply chain using APIs so that you can keep track of exactly where things are. So if you’re doing just-in-time manufacturing, or you’re a distributor and you need to fulfill orders, you can see exactly where your suppliers are sending things, exactly where it is at any moment in time. So all that information is being shared up and down the supply chain via APIs. The other thing we’re seeing is people finding new ways of generating revenue, finding new channels to market using APIs. So you can speak to Amazon via APIs. You can speak to payment processors. You can use things like Venmo with APIs. You can talk to transportation providers via APIs. So you can modernize your whole business process and take advantage of the functions that are being provided by these third-party providers.

The other thing that actually we’re seeing growing fairly rapidly is there are a lot of IBM i users who are concerned with, how am I going to recruit the next generation of developers to work on my IBM i applications? And one of the things that APIs allow you to do is they allow you to talk between languages on your IBM i. So if your core application is an RPG and you have thousands or millions of lines of RPG code that you don’t want to rewrite, that’s fine. You can continue to use that and maintain that. But you can also say, you know what, if I’m going to add a new capability, maybe I’ll build that new capability in Python or build that new capability in JavaScript, and I can communicate between the JavaScript module and the existing core application using APIs. So I can make changes where it makes sense in the RPG or COBOL, and I can make changes where it makes sense in the new languages and start to add these new languages to my application environment. And once I start doing that, I can start using open-source modules. So I can, instead of writing all the code, I can go out and say, well, maybe there’s an open-source module to do what I need that’s already been written. And I can go out and get that. And I’m going to give you a couple of examples of that in just a sec. And these are some other popular use cases that people are using APIs for. We’re seeing a lot of people adding text messaging to their business process, so you know, sending out order acknowledgments, things like that, or alerts or problem statements. You can do that all via text messaging, and you can integrate that right now, right into your RPG applications using APIs. We have other customers who want to generate PDFs or read PDFs, and they want to generate them using IBM data, or they want to be able to extract data from a PDF document and enter it into their IBM i. There are modules available to do that, so you don’t have to write the code to do any of that. You can simply grab the modules, and then using APIs, you can speak to those modules right from your RPG program. We have customers who are doing label printing, creating barcodes and QR codes using APIs. Address verification, you know, some of the shipping providers charge penalties if you give them bad addresses, so it’s useful to do an address verification. And actually, if I click on this, I’ve got a link here, you can see that when I clicked on that, it took me directly to the node repository of modules, where you can download these modules. And here, I see this one called SmartyStreets, that’s an address validation module, and you can see it’s being downloaded 50,000 times a week. So every week, 50,000 organizations are downloading this module, so it’s a very popular module that’s being used. So it’s something that you might want to use, say, look, I don’t want to have to write that. I’m just going to go grab this module and use it. So you can go get these modules very, very easily and integrate them with your applications using APIs. So the APIs allow you to take advantage of lots and lots of different kinds of code that you can add into your IBM i application environment. We have customers using weather information, tax information, government information, so lots and lots of different use cases for calling out with APIs. So when you’re thinking about how do you set up the infrastructure for your application, you’re no longer limited to just CL, RPG, COBOL, DB2, just the IBM i traditional code. You can add to that all of this new stuff, so you can take advantage of the significant investment you’ve already gotten in these RPG code, these RPG applications that work very, very well for your business. But you can then add to that these new kinds of application modules. So whenever we talk to people about APIs, we say, OK, take a look at, well, what is the business case? The APIs only make sense if they’re adding value to the business. So what are you trying to do? Are you trying to increase revenue and find new channels to market? Are you trying to give your customers a better experience? Or are you trying to automate business processes? And those are kind of some of the main areas where you can find ROI from using APIs. OK, so that’s a little bit about the state of APIs and why people use APIs and how they use them.

Let’s talk a little bit about the architecture of setting up an API environment. So basically, what you want to do with an API is wrap your existing application. So one of the things APIs allow you to do is they allow you to take advantage of all the new technology and do all the new things without having to rewrite that core application code. And it’s really something that is highly risky and very scary to do. And why do it? You’ve got these applications that work really well for your business. They’re tailored for how your business operates. If what you need is to take advantage of new technology, APIs give you a way to say, I can continue to take advantage of this great application that I have running and yet still get all the advantages of the modern environment. And so that’s part of what we try to do with Eradani Connect, or Eradani Connect product is actually a wrapper that wraps around all of your native IBM codes, your RPG code, CL code, COBOL code, DB2 applications. It wraps around them to create that layer of APIs so that you can call in and run those functions. So you can cut from the outside. You can go in and run an RPG program, the CL command, a group of COBOL programs. You can access the DB2 database, the logical files, physical files, stored procedures, tables, views. So you can access all of that from the outside. And from your RPG, COBOL, DB2 applications, you can call out to the API. So if you want to call out to Amazon, you can call out directly from your RPG programs through Eradani Connect. So it’s designed to be that kind of layer that wraps around your IBM i applications. And what we’ve done is try to make that extremely, extremely fast. If you’re going to start going down this road of building APIs and putting in an API infrastructure, it’s really, really important that they’re very responsive. You don’t want users sitting on a screen waiting for six or seven seconds for the screen to come back. You want to be able to have that API call be very, very fast and very responsive. And you may be handling very large volumes of API calls. We had a trucking company that was getting a million rate requests a day. So they had a high volume of calls coming in. We have other customers whose call volume is in the tens or hundreds of millions a day. So you can end up with very, very high volumes of calls as people realize they can talk to your application machine to machine. So you want to plan for what kind of performance do you need? What kind of speed are you going to need out of your APIs? Do you need to handle 10 million calls a day? So maybe I need to handle 120 to 150 calls a second. What is the volume you’re expecting so you can ensure that you have an API connector that can handle the volume that you’re looking for? And then you also want to look at how much load is that going to put on your IBM i back end? Maybe there’s some processing you can push into the API layer so it’s not putting as much of a load on your IBM i. And so this is just some benchmarking we did with Eradani Connect where we could handle with a single server without any optimization about 120 to 150 calls a second. But we can tune that and we can actually horizontally scale to many more than that. And with our new Kafka link, we’ve actually benchmarked this at 12,000 calls a second. Now Kafka is a system designed to provide you with the ability to handle very, very high volumes of API calls. So if you need that really where you’re getting the billions of calls, you can handle that with the Kafka link and it will handle the really, really high volumes of calls. And then when deciding how to set up your architect, you want to say, OK, so where should my APIs live? Should they be right on the IBM i? If they’re right on the IBM i, you get the advantage that they have access to your IBM i resources directly. So that’s going to make them very, very fast as you operate through that API server. So that’s a choice. It does mean, though, that you’re now connecting your IBM i to the outside world. So the outside world is coming into your IBM i and accessing the API layer directly there on the IBM i. So you could instead choose to say, no, you know what, I’d rather have my API layer be external to the IBM i. So I could say, I’m going to put my API servers on Windows machines or Unix machines or Linux machines. And maybe I’m going to have those machines running outside the firewall or in the DMZ or maybe up in the cloud so that I can have a layer where, first, I’m going to check all those APIs that are coming in before I actually go in and get access to the IBM i. And you can configure the IBM i to only accept connections from those API servers. So you can have that extra layer of protection where the IBM i is being protected by the systems that are filtering out any potential bad requests before they ever get to your IBM i. So something to think about is, how do you want to actually structure your environment? You could even have those API servers running up in the Amazon cloud or the IBM cloud if you want to do that. The advantage of having them running on Windows and Linux servers is you can scale them up. So the purple boxes here represent instances of an API server. If you’re running on the IBM i, you actually can do the same thing. You could scale up and have multiple API servers. But unless you’re actually expanding the size of the IBM i, you’re not really getting any additional processing power. Whereas if you’re doing it by putting it on a bunch of external servers, you can add servers and add servers where you’re actually getting additional processing power every time you do that. So again, these are some things to think about as you’re implementing your API strategies. What is the volume I’m going to expect? What are my security requirements? How do I want to make sure that I set this up for success? When you’re implementing APIs, one of the things that we’ve gotten from listening to IBM about this is your successful API strategy means using the right tools for the job as you create this API environment.

This is a slide that I took from Steve Will’s presentation. Steve Will does a presentation. For those who don’t know, Steve Will is the Chief Architect of the IBM i at the Rochester IBM i Lab. And this is from his presentation on the future of application development for the IBM i. And so what he says is the future is going to be a blended environment where you’re blending technology. We’re certainly going to continue to have our COBOL and RPG applications that run our core business again because they’re proven, they work, they do what we need them to do. But then we’re going to add new technologies around that. And one of the areas he has over here on the open source side are microservices and APIs. So building the API layer in new technologies that talk to the IBM i because the open source microservices and API technology really grew up in recent years. It’s all stuff that’s been developed over the last few years, long after RPG and COBOL came out. So they’re newer technologies. They’re built to take advantage of the modern computing environment. And so typically what that means is you’ve got your RPG, COBOL, CL stuff doing all your core business logic. It’s what they’re really good at. They’re proven. They do that well. And then using something like JavaScript for actually doing your API layer. So JavaScript is purpose built for doing API. So some of the reasons why you’d want to use JavaScript for the API layer itself is it’s designed to do APIs. The Lingua Franca of APIs, the format that data is sent in, is typically in JSON format today for REST APIs. JSON is JavaScript object notation. So basically the way data is being shared via APIs is in this format that’s really a JavaScript object. So JavaScript knows what’s in that JavaScript object out of the box. It doesn’t have to parse it. If you send in JSON data to the IBM i, you’re going to have to go through a process of examining the data, finding the fields that you need, matching those fields with the fields you have on the IBM i. So you have a whole parsing process that you don’t have to do if you’re doing that in JSON. In JavaScript. So JavaScript is much, much faster at pulling data out. And it’s simple. It’s a simple operation to do in JavaScript. And JavaScript is really easy to learn and use. I’ve talked to a lot of IBM i users who get a little bit nervous about, gee, I’ve got to learn this new thing. So if you can learn RPG, you can learn JavaScript. JavaScript is so much easier than learning RPG. And you don’t need to become an expert in JavaScript. There’s just specific things that you should know if you’re going to really do APIs in the right way. There’s also a huge active community developing things in JavaScript. So if you start to adopt it, then you can really take advantage of all those open source modules and all the free code that’s out there to help you build your applications. And if you want to talk to vendors like Amazon, like Shopify, like the payment processors, almost all of them provide what’s called an SDK in JavaScript. An SDK is a software development kit. Basically, it’s code that they have written for you to use their APIs. And this can be thousands of lines of code that they’ve built that you now don’t have to build if you want to use their APIs. So you can just download the SDK. It’s got all the code you need. You drop it into your application, and you’ve just saved yourself writing thousands of lines of code to talk to their APIs. There are over 2 million open source modules available on the Node Package Manager, which is the repository for these JavaScript modules, that you can download and use. So instead of asking yourself the next time you need a new feature, who’s going to write this and how long is it going to take, you can say, well, maybe somebody has already written this, and all I need to do is download it and add it into my application. It’s the largest developer community in the world.

So on the subject of what’s going to happen in the future as you want to continue to move your applications forward, getting plugged into the JavaScript world means you have access to a huge number of developers who understand how to build things in that environment. And you can deploy JavaScript in containers, meaning you can create an application. And if you need more processing power, you can simply take that container and drop it on additional servers, and you immediately get additional processing power. And this is just a quote from one of our customers who is an RPG developer, a long time, decades of RPG experience, and got into doing a little bit of JavaScript, and after a couple of months, this is what he said. He said, now that I understand the power of JavaScript, it’s like somebody gave me a set of power tools to replace my hand tools. So it’s something that can really transform the speed at which you can build things for your IBM i. And this just gives you a sense that JavaScript is by far the most popular language out there. And if you look at this line for TypeScript, this steeply rising line, TypeScript is actually just a version of JavaScript. So it’s also JavaScript. So you could add that and see JavaScript is even more popular than everything else. And this is actually a chart of the popularity of languages for building web services and APIs. And you can see JavaScript is really the very top, the most popular language. And again, the reason why that’s important is it has a whole lot of functions built in that you can just use so you don’t have to build it. And I’m going to give you some examples of that in just a second. But you don’t have to build those things. You can just use them. And it’s growing in popularity. You can see it’s growing in popularity on the IBM i as well. So rapidly, we’re seeing adoption of JavaScript and other languages like Python, PHP on the IBM i. This is, by the way, from the Help Systems IBM i marketplace survey. And with JavaScript, it’s really easy. There’s a bunch of different places you can go to download modules. And IBM is very committed to this new way of doing things. And so they’re providing modules as well in JavaScript for working with your IBM i. Now when you’re using an API strategy, one of the things you really want to take advantage of are these SDKs, the Software Development Kit. So if you’re planning your architecture for your APIs and deciding, OK, so how are we going to implement this? You want to say, OK, can we use an SDK? And if you look at almost all the major providers, they almost all have the SDKs. You can just do a search on whoever it is you’re interested in, and API, and SDK, and you’ll probably find a list of what they provide. If you try to talk to Amazon to their APIs directly using RPG, you have to write the authentication. You have to write the message formatting. You have to write all the error handling, all the logging. And you have to maintain it. So as they make changes, you have to keep it up to date. If you use their SDK, they do all that for you. They build the authentications built in. All the message formatting is built in, the logging, error handling, and all the ongoing maintenance is all built in. So when Amazon went from SOAP services to REST services, if you were using the SDK, you didn’t have to do anything. All the code was already built for you. So you really want to see if you can use those SDKs. So another reason why you want to look at using a language like JavaScript for doing web service work, because the vendors provide SDKs in JavaScript. They don’t provide SDKs in RPG. So you can always find that SDK to use. And again, it’s not a knock on RPG. RPG is a great language for doing all your core business processing, the kinds of things that it’s always done. JavaScript is just purpose-built for doing APIs. And this is, by the way, just from Amazon themselves. Using REST APIs calls directly from your code can be cumbersome. Unless you have a good reason, you should always use the Amazon SDKs. So you should always use their code. In fact, if I click on here, this takes you to tools for building on their Amazon APIs. And here you can see they’ve got here all the languages that they provide them in. And if I go in here to JavaScript, you can see in JavaScript they have all kinds of tools that they’ve built that you can just download the code for. They have SDKs that you can just download and use for connecting to IoT devices, for doing your DevOps, for managing your services development, all the communication. They’ve already built the code, and you can just grab the code and use it so you don’t have to build that yourself.

OK, so we’ve talked a little bit about setting up your API architecture, some of the tools to use. Let’s talk a little bit about security and securing those APIs. So one of the reasons you really want to think about this, by 2022, this year, APIs will become the most frequent attack vector, according to Gartner. API attacks are way up. 91% of enterprises have had an API security incident. So you can see that this stuff is happening a lot. And one of the things that’s very scary about it is some of those attacks, not just API attacks, but attacks on infrastructure, are coming from inside. So even if you’ve protected your system from the outside, if you’ve got somebody running a Windows machine, or a Mac, or something, or a machine on your network that’s been compromised, somebody clicked on a bad link, now the hacker can get to your system from inside using that user’s valid credentials. And so another thing APIs can do is creating an API layer around your system can actually help protect you even from insider attacks. And I’ll talk about that in just a second. There’s just some statistics about the number of attacks that have been occurring. And these are some of the reasons why people think they have the API issues. One is they’re not logging. They’re not keeping track of who’s accessing  their APIs, what kind of volume they’re getting, and where they’re coming from. They’re not authenticating properly. Misconfiguration. So the API is giving people access to things they shouldn’t have access to. So a lot of times, we see IBM i users who basically open an ODBC connection to the database, and now that user has basically access to the entire database.

What you really want to do is ensure that your API is only giving people the least amount of access necessary. They should only get access to the minimum amount they need in order to do whatever it is they’re trying to do. And then monitoring. The inability to monitor the APIs. So to see that suddenly we’re getting a spike in attacks, maybe it’s a distributed denial of service attack. So the inability to monitor them. And then to limit the API traffic to say, well, suddenly we’ve gotten this big spike in traffic. Let’s slow it down. Let’s block some users. Let’s make sure that we’re only letting in really valid requests into our system. So in securing your API environment, you really want to implement a zero trust environment. That is, I don’t trust anybody. Everybody has to authenticate. I need to know who everybody is, and I need to know it every time they try to do something. So I want to make sure that no one is reading the messages we’re sending. I want to make sure that the messages that are going back and forth between the APIs are not tampered with, that nobody’s changing the messages. And I want to make sure that the people who are accessing our system are who they say they are. So one of the first steps in doing this in the IBM i world is eliminating basic authentication. This is something we see a lot in the IBM i world, and that is you’re using IBM i user IDs and passwords as the credentials. So people are actually sending in valid IBM i user IDs and passwords in order to access an API or to get into the system. The problem with that is that every time you send a user ID and password up and down the line, it’s a potential exposure to being discovered. So somebody could be listening on the line to discover those credentials. If you don’t want to make the end user keep re-signing on, you have to store those credentials somewhere. So you store them in the browser. That becomes another place where they can be discovered. So typically, you want to get away from basic authentication and move instead to encrypted token authentication, which I’ll talk about in just a sec. And if you just hear just some notes, you can see almost every one of the major vendors are getting rid of all basic authentication. They’re not letting you authenticate this way anymore because it’s just too insecure. So basically, you want to eliminate that basic authentication and use this encrypted token-based security so that instead of sending user IDs and passwords, you’re sending these encrypted tokens up and down the line. And in fact, you’re never actually having somebody sign on using that IBM i user ID and password. They may be signing on with an email address and a password, and in exchange, they get a token back. And from then on, all your communication is being done via these encrypted tokens. And basically, this is how that works. So you send in your email address and password, again, not your IBM i native credentials, username and password. You get back a JSON WebToken as a kind of an encrypted token. And then you send back the encrypted token. Each time you make a call, the system checks to say, OK, is this a valid token? Yes. OK, now I know who this user is. Now they can have the data back. I will give them the response. So what you’re sending up and down are those JWTs, not the actual credentials. And if you want to add what’s called OAuth, OAuth says, I’m going to have a third party actually verify that you are who you say you are. So I’m going to go to a trusted third party. So this is like you see websites where they ask you, do you want to sign on as Google? Do you want to sign on as Facebook? So you actually go out to them. They actually verify that the user is who they say they are. They give them an access token, which that user then sends to you. You then go check with Google and say, is this a valid access token? If Google says yes, then again, you let them in and allow them to perform the operation. So you’re using a third party to help verify that this user is who they say they are. And there are a lot of people who there are a lot of options you have out there if you want to do this kind of third party authentication to make sure that the user is truly who they say they are. Then you can also add multi-factor authentications. You can say, you know what, in addition to that user ID and password, I want to add something else. So basically multi-factor authentications is I’m going to use at least two of the three items on the left. Something the user knows, like their password or secret question answers. Something the user has, like their phone or a dongle. And something that is the user, that is their fingerprint or their retinal scan. So I need to use at least two of those three things, or maybe all three, to identify that this is the user who they say they are. And we actually have customers who are doing this even with 5250 sign-ons. Because of the issue of internal attacks on compromised machines, when a user puts in their user ID and password on a 5250 session, they don’t get right into the system. What happens is that there’s an API call to their multi-factor authentication system. It sends out a text message to that user’s phone. The user has to respond to the text message before they actually can get onto the system. And what’s really great, getting back to the JavaScript idea, if you want to do all those things, you want to do OAuth, you want to do Kerberos or SAML or single sign-on kinds of technologies, if you want to do multi-factor authentication with JavaScript, all the code’s already built for you. So this has happened to be a JavaScript module called Passport. It already has the code for over 500 different methods of authentication. And you can just download it and use it. You can see it’s highly trusted. It’s being downloaded almost 500,000 times a week. And so it’s used in enterprises all around the world, enterprises of all sizes. And it’s licensed under the MIT license, which is basically a free license. You can do with it whatever you want. So again, one of the advantages is I don’t have to write all that code. I can just download it and use it. And because I’m not writing it, I don’t have to maintain it. One of the things about security in particular is these modules are being updated every day. There are vulnerabilities being found constantly. And so these modules are constantly being updated to make sure that they have protection against the latest vulnerabilities that have been identified. If you’re writing this stuff yourself in RPG, you’ve got to do all that maintenance yourself.

OK, so a little bit about security and securing the environment. Let’s talk about managing and monitoring the APIs. So you want to be able to make sure that you’re keeping track of. Remember, one of the security issues was inadequate managing and monitoring the APIs. So you want to be able to make sure that you know what API calls are coming in, how they’re being routed, who is the person that’s calling in. I want to be able to make sure I understand what data they’re sending me and what data I’m giving them back. So all that information, you want to make sure and you want to be able to do that whether somebody is calling into your IBM i to access one of your resources or you’re calling from the IBM i out to something else. You want to make sure that you’re monitoring all of those calls and you’re making sure that they’re all being done in accordance with whatever policies you set up. And not all APIs are a simple call and response, right? Not all APIs are I’m going to send you some data, I’m going to get some data back. They can have many, many steps, and so it becomes difficult to debug if there’s a problem. It becomes difficult to understand what’s happening. This is just a sample of a customer of ours that had a very complex API workflow where they wanted to give their customers the ability to look at their orders and then find out exactly where their order was at any moment in time. So first, from a mobile device, they would go in and say, you know, I’m customer X, show me my orders, so that would get authenticated in the API layer. Then they’d go to the IBM i, it would extract the list of their orders, send them back their orders. Then they would select from their orders the order they were interested in, so it would go back to the IBM i, get more data about that order and details about the order. Then they’d hit the track shipment button, which would then go back to the IBM i, which would then send a message out to their freight provider to find out where the truck was, and then it would generate a map and send back a map to the end user. So there are a bunch of steps in making that API work, and so you want to make sure that you’re tracking everything that happens, and that’s one of the things that Eradani Connect does. So Eradani Connect actually does all that authentication. It does all the routing. It does all the data transformations from place to place, so from JSON to RPG data structures and back. So it does all those transformations for you, and it ensures that all the communications are secure. So in that particular case, we had a bunch of different API types in one use case. So the modernization case, the integration of internal systems, the integration with outside systems to public APIs, using modern language. We had integrated open-source components, so lots and lots of things going on inside that one API use case, and we were able to implement that and create the whole thing, the user interface and all the other code and all the API connections in just a couple of months. So a little bit about the actual monitoring. So I talked about this. You can throttle API communication. So if you’re suddenly getting overwhelmed with APIs, you can slow down the API calls, and you can slow them down by user, by IP address. You can shut somebody off completely if you want to, and you can do that in both directions. We have customers that use APIs that they get charged for, and so they want to make sure that their users aren’t making too much use of those APIs. So they’ll limit how many API calls can go out from their system. And so with Eradani Connect, we give you the ability to limit those API calls by the endpoint, the API endpoint, by the application it’s accessing, by groups of endpoints, by IP address, by the user, so we can protect you from the different kinds of things that could overwhelm your system. And it also gives you the ability to monetize your API. So you could actually be in the position of saying, we’re going to provide an API to our system, but we’re going to charge people for it. So you can actually track that and charge people based on their API usage. And then you can also have the system go out and do health checks to say, is my API running? The last thing you really want is to find out that your API is broken when somebody calls you and says, hey, your API is broken. So you want to be able to get that notification proactively. So you can have the API management system actually going out and hitting your APIs and saying, are you up and running? Are you performing properly? So you don’t have to wait to get that kind of response. And so let’s take a look at actual monitoring here.

Hey, Dan, just before you start that next slide, I wanted to point out just 15 more minutes left just to keep you on track. Great. Thank you. I appreciate it, Chelsea. Absolutely. So this is just an example of a monitoring dashboard where you can actually monitor the information coming in, the API call, so you can see here, what’s the API response time I’m getting? This is actually live right now, how much CPU is being used, how many requests have come in, errors, if there have been any errors, how many errors are out there. So you get a lot of information about what’s happening with your API calls. And you can look at every single API endpoint and see for every one of your endpoints what’s happening with those API calls. And if there have been errors, you can go in and see, you can actually look at the list of errors, and you can open up each error, and you can see what data did we send out, what data did we get back, what were the errors that happened. Now if you notice here, you can see also here’s the rate limiting code that’s saying, I’ve got rate limits here that are limiting how much stuff from this particular source, how many API calls are they allowed to call within a particular period of time. So you can actually set that up within your APIs, and you can monitor all of that. So if I wanted to, I could go in and also go in and actually try out my API. So from my monitoring dashboard, I can go in and say, how is this API running? Is it running well? So I can go into this API, and I can say, OK, let’s run, let’s try it out. And I can run the API. And that actually just did a live call out to our IBM i. So you can see we got some JSON data back from running that API. So from my monitoring dashboard, I can actually go out and test the API and see how it’s working. So we’ve got a variety of APIs here that I can run. We’ll go out and run this one a couple of times here. One of the things here, if I run this one, I’m going to just hit this a few more times. You see, we’ve got the input and output down here. If I keep running that, now I’ve got the message, too many requests. So it hit the rate limit, and it came back and it said, you’ve had too many requests. And actually, I don’t know if you can, let me just turn off my background for one second here. If I turn off my background here, I don’t know if you can see here, but I actually got a text message on my phone saying, hey, the rate limit has been hit for that API. So you can get that, you can have the system send you back those kinds of messages to let you know if something is not working the way it should be or something has happened within your APIs that you want to know about. So you can get that information back. The API system is also logging everything, so everything that’s occurring. So one of the things we ran into with the customers is they had a complaint from their end users that said, hey, your IBM i is slow, it’s slowing down our APIs. We’re constantly waiting for the IBM i. And they had no way to defend themselves because they had no visibility into the API process. They couldn’t say, well, no, it’s not the IBM i, it’s something else. Well, once they implemented the API monitoring system, they actually could monitor that. And so, they actually then had logging information. This is actually a snapshot of the log, and you can see here in the log, here’s where they received the API request, and then they executed a bunch of RPG program calls. They then went out and went out to execute an external API, so an API that’s not an IBM i call, so it’s something going outside the IBM i. And if you look over here at the timings, you can see the timings for everything that’s running. They’re all running in all the calls to the RPG programs. They’re happening within milliseconds, right? It’s one millisecond, two milliseconds. They’re happening very, very fast. Actually, it’s not down here, so you get from 29.54 to 30 minutes, or 30 hours, or 30 minutes. You see that there was a six-second delay. So this is where the big delay occurs. I have this six-second delay, and that’s on the external call. So it wasn’t the IBM i at all. What was slowing them down was this external call to another API outside of the IBM i. So it gives you a really quick way to say, here’s where we’re having the issue. This is where the slowdown is occurring, or if it broke for some reason, you’d be able to see exactly where the failure was in your API process. So the last thing I want to cover is a little bit about managing the actual API environment. So when you’re working in an API environment, almost by definition, you’re working with a variety of technologies. So you’ve got your core IBM i applications that are running. So you’re running the core code in your RPG. But you’ve also then got your JavaScript code, or your Python code, or whatever else you might be using in building that application. So you might have the user interface code, whatever different things you have. And you want to be able to manage those things together. So in this API world, you want to be able to use the same set of tools for managing all your developments. So part of what you want to do is set up an environment where you can track all your changes in one system, where you’re keeping track of all the things you’re doing. That could be a JIRA, or a GitHub, or a ServiceNow, or any one of a number of systems for doing backlog tracking. You can edit using whatever editor you want to use, so RDI, or VS Code, or SEU, and PDM, however you want. And you can manage all of the code in one version control repository. So if you want to, you can actually have your RPG code, and your CL commands, and all of your IBM i native stuff using Git, which is the most popular version control tool in the world. That’s like 100 million users of Git. So you can use that very powerful version control, and yet still automate the build process of moving things through the lifecycle. So you can create this integrated environment where you can work in whatever tools you want. You can use these very, very popular open source tools, and still move things through your development lifecycle, and still do the things you’re used to of building the applications, managing all the dependencies, ensuring the right create commands are being used as you move things from development, to test, to QA, to production. It’s really important in this environment where you’re working with these APIs that you keep things in sync. So if you’re making changes, you want to be sure that the changes on both sides of the house are staying in sync. So that allows you to manage all the DevOps in one environment. Now you can also then take advantage, if you’re doing that, you can take advantage of the power of tools like Git, where you can see detailed information of everything that you’re doing. So if you look right here, I actually have, this is actually a live view of GitHub. You can see I’ve got a bunch of stuff, looks a lot like IBM i code sitting here in my repository. So I’ve got IBM i code. But I also can have in the same repository, I can have non-IBM i code. So if I want to, I can go in and say, show me all my code, and here I’ve got the IBM i code. And if I open up here, I’ve got JavaScript code, and I’ve got Java code, and I’ve got lots and lots of other kinds of files that I’m all managing in one place. And I can see the history of changes to all of those things in one place. So it becomes very, very easy to audit your environment for somebody to come in and see all your changes, because they don’t have to look at a Windows system for some stuff, and a Unix system for other stuff, and the IBM i for other stuff. It’s all managed in one place. So basically, you can automate the whole change management process as part of managing your API environment.

So we’ve covered a whole bunch of things here in API. So we talked about trends in APIs and what people are doing with APIs. We talked about setting up the appropriate architecture for high-performance secure APIs. We talked about security and how do you ensure that the APIs that you’re setting up are secure. We’ve talked about how to manage and monitor your APIs. And we talked a little bit about DevOps and how to manage the development of. Now, we actually have webinars on a lot of other topics that go into a lot more detail in each one. So we have a security webinar. We have a DevOps webinar, and you can find those on our website. So with that, I will just check in with Chelsea. Chelsea, do we have any questions? We have one. How does JSON work with Node.js? So in working with JavaScript, you have what’s called client-side JavaScript, and you have server-side JavaScript. So client-side JavaScript is JavaScript that’s used in building the user interface, and you have frameworks for that. And you may have heard of things like Angular and React and Vue. Those are client-side JavaScript frameworks for building client-side user interfaces, and they have lots and lots of tools and components to make that easy. Node.js is server-side JavaScript, so it’s actually built for building applications in JavaScript, so actually doing the business logic and building the application. So Node.js is a framework that has a lot of tools for building server-side applications, for building the code. JSON is actually just a format for sharing data, and it works in what are labeled value pairs, where you have a label that says, this is what this field is, and then you have the value for it. And so JSON is a standard format that is used pretty much for REST services, pretty universal for REST services today. And so you can communicate between the user interface and the server-side, so the Node and the React, you can use JSON messages to communicate between those. But you can also communicate from Node to your IBM i. You can have Node sending JSON messages to your IBM i, and Eradani Connect will translate that JSON into RPG data structures, into parameter data for you, and then get the results and turn them back into JSON. So you can talk from Node with JSON, and you can accept JSON in Node. Thank you, Dan. We had one more come through while you were giving the answer to that. Can we integrate Git for RPG, or do we need to transfer the code into IFS? So here you can see, if I go back here to my repository, this is my IBM i code here. And we’ve actually created a command for you that automatically loads the Git repository. This happens to be a GitHub repository, but this could be a Bitbucket. This could be on GitLab. This could be a Git repository on your IBM i. But we have a command called git init that will actually take code from your library source files and source members and load them into a Git repository for you so that you can start working with Git with your IBM i code. And then it will actually keep the Git repository in sync. Now, the Git repository itself is going to be in the IFS, because Git only understands directories. But you can work directly through the library source members. You can go right into PDM, go work member PDM in your development library in a particular source file. And you can edit the member right there in SEU. And we have something that will actually keep the Git repository in sync with what you’re doing on the IBM i. Thank you, Dan. 

And another one, when you have competing third-party APIs, different APIs that do the same thing like geocoding, how can you compare APIs to identify which API is more accurate, really that’s accurate, or provides more accurate data? Great. So if I’m understanding, let me just bring up another window here real quick. So I’ve got this up and running here. What I’m doing here is signing on to Eradani Connect. So one of the things we do in Eradani Connect is we allow you to create what we call applications. Applications are basically business area functions that you create. You can create as many of these as you want. You can call them whatever you want. And they’re really used for organizing your APIs. So you can have all your JD Edwards APIs in one place, all your warehousing APIs in one place, transportation APIs, payroll app, whatever you want. You can create whatever you want for these organizational structures. And then you can go in and you can see what’s the list of APIs that are actually associated with this. So now you can actually have us, if we’re generating APIs for you, you can actually have us put those APIs, those generated APIs, into a Git repository. If you do that, it becomes very, very easy to compare versions of APIs or different APIs to each other. So you can actually compare them and see what’s different about them. So if you want to see, gee, how are we handling the API call in this version versus how are we handling it in this other version, you can actually see what’s different and decide which one is the most appropriate. So you have a way of organizing the APIs. And then with Git integration, you can then actually see the differences between the APIs.

Fantastic. We do have one more, if we have time for it. Yeah, go ahead.mPerfect. Can API development be performed in the cloud, like with Azure or AWS? Sure. Yeah. And in fact, that’s one of the options for implementing, if you’re implementing Eradani Connect. And here, let me just bring up another slide here. Here we go. So we actually have a bunch of customers that are doing things this way, where they actually have their API servers running up in the cloud. So they’re running their API servers in IBM Cloud, in the AWS Cloud, the Azure Cloud. So you can deploy your APIs there. Now, typically, you would develop your API on your development machine. So you’re going to develop the API there, but then you can have it deployed and running wherever it is you want it to run. Now, you could remotely access a development box in AWS, or Azure, or IBM, and then develop it there if you wanted to. So it’s kind of up to you, but you can have those API servers running wherever you want them to run. Fantastic. Thank you so much, Dan. That was the last question, unless we have any more. We’ll input in the Q&A box. I don’t see any coming through.

So thank you so much for everyone joining us today. It was a great presentation, Dan. Thank you. We will, again, send you a recording of this webinar to your email address that you gave us. If you have any questions, please do let us know. I appreciate it. Have a great day. Thanks, Dan. Anything else from you? Nope. Just thank you, everybody, for attending. And if you have additional questions, please feel free to send it to me. My email address is just dan@eradani.com. And thanks for coming.