Maia Samboy

Okay, I think it’s about that time to get started. I see some lovely familiar names and also some great new ones. So hello and welcome everybody. This is our third and final session of our EDI series. Keep an eye out. We do have some other exciting things coming up in the next couple months, but today we will be focusing on EDI modernization and building a modern integration strategy. We have our CEO Dan and our chief architect, Aaron, and they will walk you through creating a practical EDI modernization roadmap that positions your company for long term success. I’m Maia in marketing and pretty much my job today is to just introduce our lovely speakers. So I will pass it on over to Dan.

Dan Magid

Great. Thanks Maia. And by the way, if you have questions during the webinar, please put them into the Q and A section and we’ll either try to answer them as we go or we’ll have some time for Q and A at the end. So please, any questions that come up, let us know. This session is really kind of a synthesis of what we’ve talked about so far with some new information about planning for the future. So if you’ve been in the other two webinars, the one about rapid onboarding of partners and the one about monitoring, we’re going to cover some of that same material. But as part of how do you plan for the strategy for the future? So if you haven’t been in those sessions, this should catch you up a little bit. And if you have been, there should be some good review information as well as some new content. So we’re going to talk a little bit about, so where do we go now? Now with the whole EDI process, Where are we going for the future? So we’ll talk a little bit about why are people looking at this now? EDI has been around for 60 years. So it’s a technology that’s been proven, it’s used. There are literally trillions of dollars of transactions flowing through EDI connections. So what are the reasons that people are looking at modernizing and then what does a modern strategy look like? What does it mean to be modernizing your EDI connections? And then how can we take advantage of some of the latest technology like AI? How can we use that in our modern strategy? How can we ensure that everything remains secure? So we’re securing those connections, since EDI connections as well as all the other connections we might be doing, or adding these gateways into our systems, how do we make sure that those are secure? How do we monitor them to make sure that we’re tracking what’s happening with it. And then Aaron is going to, as usual, give you a demonstration of some of these technologies so you can see how you can actually use in your environment. So just a quick review of where we’re coming from. So this is basically kind of how EDI currently works. And again, it’s been around for a while. Most of the people, I’m sure, were not around at the early days of EDI when it was the only way really to share information. This came from a time when all computer systems were really standalone and so you weren’t really sharing information. And companies found that, well, it would really be helpful if we could electronically ship information from one system to another. So they came up with this idea of electronic document interchange change. And it was really based on the idea that you were sending documents like POS that you wanted to send out to a business partner. So you wanted to take a document and send it out and then have that, that other company be able to read that document electronically. So that’s kind of the original thing was how do we take these paper processes and turn them into some kind of electronic processing? So, you know, you’d have the EDI documents, you’d batch them up, you’d have a whole set of EDI documents, you’d send them out, the partner would receive those documents, it would in a batch process, again read the documents and then put that data into their database or run some programs on it and then send documents back. So send acknowledgments back or other kinds of documents back to the partner. So it was basically this idea of simply automating the document process. There are several issues that have arisen over time with that way of doing things. One of the things is the current solutions can be very, very expensive. There are transactions, there are per character charges, there are transaction per transaction charges, there are per partner charges, there are onboarding charges, there are lots of things that can make this process very, very, very expensive. So one of the things we look at in modernizing are there ways that we can reduce the cost and make the cost of doing this more predictable. The certificate. In key management, we have lots of customers using our software for doing EDI processing. And we get called all the time about, oh, my partner’s changed their certificate, we have a new certificate, how do we, how do we manage that? And then EDI traditionally has been very slow. It’s all been batch oriented. So you batch up transactions and we have customers that they receive batches once or twice a day. It’s not real time. So we’re getting things that are old that other people may have already gotten. So if somebody’s sending out shipping tenders or some kind of thing where they’re looking for at different vendors, I may not be getting them in a timely fashion. And then everybody has customized their EDI documents. What we have found is that the EDI is the non standard standard, and that everybody seems to be using it in their own way and they tweak it in their own way. And so that leads to the painful onboarding process of trying to figure out, okay, so how do I deal with this particular partner? And the data is very, very fixed according to the standards. And, and often we find that, that there’s one person or a couple of people in the organization who understand the EDI and nobody else does. And it’s kind of this black box in the organization that’s hard to manage.

Aaron Magid

Right. Dan? I just jump in there a couple of things here because, you know, I work with a lot of, we work with a lot of companies that are doing this kind of thing. And, you know, the number of times that I’ve gotten on a call with a company that’s getting, you know, that’s working on their EDI and you know, we get 10 minutes into the call and then, you know, very quickly it becomes clear that, oh, shoot, we need Tim, the EDI guy. You know, we got, we got to get this out. You know, there’s, there’s some guy, you know, who’s off in the corner who, you know, wasn’t on the meeting, you know, who is like the one person in the entire organization who understands the edi. You know, we got to get that person on there. And it’s, it’s, it’s often a challenge, you know, and I also work with a lot of groups. I’ve seen a lot of companies where that person, that one person who understands the EDI is nearing retirement or is actively trying to retire, but can’t because the company can’t, you know, can’t find anybody to actually take over that system. So, you know, these are just some of the things that, that we get with legacy technologies. The other thing, Dan, that I wanted to jump in just because I always think it’s a, it’s a fun thing. Whenever I talk to somebody about, about EDI communication, you know, really in traditional systems, your options come down to either FTP or SFTP, hopefully SFTP or AS2. And, you know, in either way, you know, the security of those systems, they can be secure, but the management is so much higher than a lot of other technologies. You know, you look at like what it takes to add a user to an OAuth 2 system, right? You log into your dashboard, you add the user, boom, done, right? Everybody’s happy. You know, when I talk to people about as to almost every single time, you know, it’s, there’s this process that we go through in the conversation. It’s like when I say as to, you say certificate management, right? Like every single time I talk to people, it’s, you know, what, what, what comes to mind when you think of this and they go, you know, this nightmare that I have around, around making sure the certificates, you know, it seems like every day somebody’s expiring and I got to go fix that anyway. There’s a lot of pieces here that I think come from the technology having evolved over a long period of time

Aaron Magid

and the original designs have aged along with it. And I think that’s where we’re seeing new technologies making a lot of headway here. So I just wanted to add that.

Dan Magid

Great. No, thanks. And those leads to the why modernization? Why do you want to do this? Well, you want to have real time data rather than batch data. So you want to be able to process things as they’re happening and so you want to update the technology. And it doesn’t mean you have to go away from edi, but we want to be able to handle those documents in real time. So we want to be able to make sure that we’re getting things as quickly as possible and responding as quickly as possible so that we don’t have to wait to get the information we need. We’re also seeing an explosion of standards, of things that you have to track. So you’ve got lots and lots of different formats that you might have to deal with, including the new messaging technologies like REST and SOAP and event brokers. So there are lots and lots of different things that you have to manage. How do I make it so that not every one of those is a one off, that I can manage them all in some consistent way, that I don’t have a lot of extra duplicate effort happening? Because managing different standards and obviously security requirements keep growing. The need to keep up with the latest security technologies is critical for every kind of connection, including the edi. And we already talked about the EDI expertise is concentrated in a few individuals and not typically shared across the entire organization. So what are your options, what you can do? Well, you could abandon edi, but that’s probably not realistic. Again, because There are trillions of dollars of transactions still flowing through edi and most of the big major players out there are going to expect you to be able to support their EDI for, for, for the foreseeable future. So you probably can’t abandon it. You could say, well, we’re just going to stay on EDI forever. But because of the pain associated with edi, many, many companies are looking to, to see can we get off it, can we do something different? In fact, a lot of those big companies that are so committed to EDI are still now offering alternatives to EDI processing as they move forward. You could try to rewrite everything in some new technology using rest APIs for everything. But again, you still have to deal with your partners who aren’t ready to do that yet. And so what we’re seeing is most companies are doing progressive modernization. That is, they’re attempting to do things in either, do things in a new way with their edi. So update their EDI so their EDI processing is more real time, is more automated, it supports more standard ways of doing things and then adding the additional technologies like REST APIs like soap, APIs like different kinds of communication methods to their environments. Rather than doing a big rip and replacement, they’re simply adding new things, new ways of doing things. And these are just some of the real world projects we’re currently working on with customers. So you know, we have people who are, we have, we have several customers who are working with Amazon and using Amazon strategy. And Amazon still supports edi, but they are really trying to move people to their, their API technologies. So they’ve got, you know, literally thousands of APIs that you can use to work with the different parts of Amazon. So we’re working with customers who are using both the EDI side and the API side. Walmart also is offering both API communications and they’re offering the EDI communications and I love their thing here. This is this, I pulled this directly from their website. It says Walmart’s EDI mapping requirements are very detailed, often including custom fields. Even a minor error can lead to document rejection. Accurate mapping is crucial. So when you’re working with these partners, you actually have to be very, very disciplined in how you communicate with their EDI technologies. We’re working with some customers who are working with Ford and their strategy and they’ve started to introduce APIs as part of their communication strategy. So they still have edi, but they’re also now doing API. And oftentimes they will mandate that if you want to continue to Work with us. You, you have to adopt our new API strategy in the healthcare environment. We have several healthcare customers who have requirements around the edi, have HIPAA requirements around their EDI processing because they’re dealing with personal data, they’re doing with confidential data and they need to make sure that all their EDI communications are HIPAA compliant. And then we have banking and insurance customers who are using EDI for processing onboarding of clients and for managing client policies and for managing banking transactions. So obviously they have very, very, very big security concerns in the finance world. So there are lots and lots of projects going around around this modernizing of the EDI environment.

Dan Magid

So what we’re working with customers and doing is creating a, a combined gateway for all integration for all communication. So whether it’s APIs, whether it’s EDI, what we want to do is leverage the parts of the technology that are shared so that we don’t have to rewrite all of the technology for each kind of connection we’re doing. So the security technology, the routing technology, the data translation technology, all of those things can be shared. They’re amongst the different communication technology. So I’m not rewriting them. So I’ve got a central gateway where I can develop these, these integrations and I can manage these integrations. And so you have the kinds of shared things. Like I’ve got the same kind I need, I have the same security requirements for my EDI transactions as my API transactions. I, I need to do the same kinds of data transformations. I want to get stuff from a, some one fixed format into another format. I’ve got to make sure that the data that’s coming in is accurate or the data that’s going out is accurate. As Walmart said, if you don’t get your document exactly right, we’re going to reject it and we’re going to charge you for that. So I want to make sure it’s exactly right. All of the logging information that’s common among EDI processing and API processing, all of the monitoring technology can be common across the two things. So I can share all of that technology rather than having an EDI process and then an API process and then other communication processes that are separate, I can share all of that technology and use them for talking to my systems or to talking to my business partners. And one of the things we’re seeing, one of the projects we’re working on with a few customers is now introducing event brokers for EDI processing. So that rather than me having to manage all the EDI Transactions, I can have them all going to an event broker. So every time a new tender arrives, every time a new client onboarding document arrives, every time a new financial transaction arrives, it just goes into the broker and the event broker actually tracks all of those events. And I can read those events as I’m ready to and process those events. So the event broker is actually handling everything. And these can be very, very, very high performance. These can handle literally tens of thousands of transactions a section or even more. I think that LinkedIn is using these event brokers and they’re using it to manage like 7 trillion messages a day. So you can actually manage very, very, very high volumes. And what’s great about this is it keeps them ordered so you know exactly what order the documents are coming in in them in the appropriate order. And they’re also very resilient. If you lose an event broker, it’s replicated to multiple event brokers and all of the transactions are still there. So I can continue to process that. So you can actually turn your IBMI into an event driven system, which is very different from how the IBMI typically works as a very procedural process oriented system. So the modern EDI flows. The way we work with our customers is you, you. As the documents come in and they can come in in whatever technology you want, they can come in and they can come in in real time. The, the, the document gets translated when we translate the document into JSON, JSON becomes then the lingua franca of all my communication. I get everything into JSON. Now I have a common format for all my data and I can feed it into programs, I can put it into the database, I can create new do. Once I have it in that standard self described form, I can do lots and lots of things with that data and then I can validate the data again, whatever source it may be coming through. And then I map it into whatever my internal process might be and I can use AI to generate those mappings. And Aaron’s going to show you a little of this so that I don’t have to write those mappings manually and then I can monitor all of it. So this is just an example of taking a, this would be a EDI 204 document and then mapping it into JSON and creating a JSON document from that. So now I have it in a standard self described form, right?

Aaron Magid

And the critical point here, right, is that when, with all this architecture that Dan is talking about, and again I’m going to show you this in a minute, you’re Building a loosely coupled integration layer around your core business processing, right? And we’re basically doing that, we’re sticking that in with the edi, right? That’s the core of the philosophy that we’re talking about here. That’s the core of the strategy. Because if you get a secure, performant, modern layer in between your EDI documents coming in and your core processing, that then allows us to translate internally to whatever you need on the back end. That’s what Dan’s showing right here, where we can take an EDI document and translate that to a canonical JSON format or whatever else you need in your systems. And then what Dan’s next slide is about is saying, okay, then on the front end we can also change what’s going on at the partner level, right? The partner can be talking over EDI to our existing system and that’s great, but then tomorrow or a different partner can be using a completely different technology to talk with our, with our systems, right? That might be rest APIs, it might be SOAP integrations, that might be Kafka, that might be solus, that might be, what are some other technologies, right? There might be file transfers, it might.

Dan Magid

Amazon sqs and sns, right?

Aaron Magid

Whatever else they want to be using, you can then have that on the front end. And it all starts with creating that loosely coupled layer. One of the big problems that I see with legacy EDI solutions is actually, interestingly also their greatest strength. Meaning the legacy EDI platforms were designed to make EDI in their way as easy as they could. So they built a complete end to end black box that does all of your processing. The problem is when you got this big thing in there that takes in the EDI document and then is all coded around EDI and then builds to your database all built around edi. You can’t change any part of that system, right? It’s all one unit. You put in the loosely coupled layer there and at that point you can then modernize each side independently. You can modernize each trading partner independently. You no longer have this giant lift to make a change. And I’ll give you an example. We actually have an EDI integration going live this week actually with one of our customers, where one of the components of that EDI integration is an EDI2 API integration. Meaning what’s happening here is they’re actually mixing technologies where one partner, one side of this transaction is going to send an EDI document, a214 actually for a, for a load update, and that’s then going to get mapped into their standard formats and then communicated to an external system that uses a REST API. Right. So in transit, this is flipping technologies. It is flipping through decades of technology in transit, basically as the request is being processed. And again, what that’s allowing is the reason they have to do the EDI on one end is that they have a tool on one end that can only do edi. That’s the only thing it supports. So they have to do the EDI there, but the other side doesn’t want to do EDI, they only want to do APIs. Right. And if they didn’t have that loosely coupled layer, what they would have to do is, is rip up the entire system or try to get one of their trading partners to agree to implement an entirely new way of doing things. Right. Just to do business with them. Right. So what this does is it dramatically eases the process of actually doing this modernization by focusing on what actually needs to change in order to make this happen. Not just, you know, not, not what’s going to get dragged along with it. What’s all the baggage that we have to pull along with it. So what, what do we actually need to do? And then we can build out from there.

Dan Magid

Right? And I think that that’s the critical piece is we’re creating a basically universal gateway that allows you to talk to your backend systems or from your backend systems to your trading partners via a variety of technologies. And yet you’re sharing much of the infrastructure. So you don’t have to create separate infrastructures for each of these different ways of communicating. And it makes it really easy if you’re, if your, your partner decides to switch from EDI to API, it makes it easy to do that because most of the code is already there

Dan Magid

and you can take advantage of the latest security. So again, the security has to be deeply embedded in the architecture to make sure that you know who’s coming in, who’s, what it is that they’re allowed to do, what it is that they’re allowed to send you what’s valid data, what’s not valid data. You want to make sure that you can support the latest technologies, both on the inbound side for people who are talking to you, but also if you’re calling out to somebody else. Your partners are going to have different technologies they’re going to require. You want to make sure you can support those different technologies,

Dan Magid

and you want to be able to work from a modern workbench. So our approach has been to say, if everybody seems to be moving to Visual Studio, code let’s do everything in Visual Studio code. So whether you’re doing here what this is, sample API or EDI integration, where I’m dropping in a sample EDI document and I give it samples of what that data then looks like in my tables and the system will automatically create that integration for you. Or I’m doing APIs, I can do it all from a common workbench, so I can work from the same place for all the things that I’m doing.

Aaron Magid

Right, right. And again, that, that whole process, if you want to be able to employ this type of strategy, right, where I’ve got multiple technologies in place, right. We obviously we’re going to need a workbench that can actually, that can actually handle all of them. And again, that’s, that’s what we’ll, we’ll go through when we get to our scenario.

Dan Magid

Right. And you can manage, obviously then you can manage it all in common tools like Git, and then monitor it with whatever monitoring dashboard you want. Because all of the logging data, when we create logging data out of any kind of connection, whether it’s EDI, whether it’s APIs, we’re going to stream it out in standard, industry, standard open metrics, Prometheus format that can be read by any dashboarding system. With that, I’m going to go ahead and turn things over to Aaron and let him actually show you some of this stuff.

Aaron Magid

All right, well, thank you, Dan, for that great introduction as always. I’m just going to share my screen. We’re going to jump in. So this strategy to me is something that’s very exciting. I always get very energetic, as you may be able to tell, when we get to talk about these kinds of future strategies, because this is where the technology gets really cool. We’ve done in our prior webinars. Okay. I can onboard a trading partner much faster. I can generate an edi integration in 90 seconds. Gone through that. If you’ve been at our sessions, you’ve seen that. Right. But this is the part where we really start talking about the future. Right. What is it that we want to do with these technologies to support the future of our platforms and of our systems? We’ve talked about what some of the options aren’t right, like trying to get totally off of one technology or staying on a legacy system forever. Right. We’ve talked about the hybrid method. So what I want to do here is I’m going to actually go through it with you and hopefully that’ll illustrate what we’ve been talking about here. So to Set our scenario here. What we’re going to be doing is modernizing A, an EDI 204 integration for a logistics company. Right. So for anyone who’s not in logistics at 204 is a load tender. You got a shipper that wants to work with a carrier. They’re going to send that document over with an offer and. And then we’re going to reply based on that. Right? So that’s how we’re communicating. All you need to know is that’s how we’re communicating between our, between our, our shipper and our carrier. So in here, first of all, let’s say I’ve got a new trading partner, right? I need to get them onboarded. Well, if I’m going down this hybrid strategy, I’m going to need to be able to maintain my EDI integrations. I’m going to need to be able to do that quickly. Right. What you don’t want to do is build up two completely separate systems where you have independent maintenance and they’re all taking full effort, right? Because then you’re just doubling the amount of work you’re doing. So the first thing we need is we need to ease the process of our EDI integrations so that we actually have some capacity to move on to the, onto the newer technologies. So what I’m going to do here is I’m going to do that very quickly. I’m going to take my EDI integration. So I’m going to go over here and I’m going to say, okay, I need an EDI integration. Let’s say that this is going to be EFGH2 is gonna be my trading partner. You may recognize this from, from our first webinar. EFGH was the trading partner we used. It’ gave me a 204inbound. I’m receiving it. I’m gonna say, okay, go ahead and generate my integration. I need this for my new trading partner.

Aaron Magid

Okay. And now that I have that, it’s going to come back and it’s going to ask me. Okay. I need to map the data for you. Great. Thank you for doing that for me. This is awesome. Here’s my document that I got from the trading partner that I don’t want to have to think about. And here’s what my data looks like in my database that I need to be processing. Let’s go into database table DMO204.

Dan Magid

And.

Aaron Magid

Oh, right, I’ve got one other database table. Okay, perfect. So I’m going to take this guy and I’m going to Dump this sample into my system. DMO2.04D was the other table. So I got a header table and I got a details table. And I’m going to say, go ahead and generate that for me. Right? The key point here is that because I can generate this mapping very quickly because I can build an integration without having to invest a huge amount of time from my people or from an EDI expert. Because the AI assistant here is my EDI expert. That means that I can focus on the business rules, which is what we need to be focused on if we want to actually engage in modernization projects. So I’m giving this a minute to go through my EDI document, read through the spec, make sure it understands everything that needs to happen, go through my database and understand what all the mappings are, and then set up all the configurations for that. It just came back. So now I have at this point an EDI integration, right? So I can go over here now and I can say with my process EDI document, I’ve got an EDI document here. And I can go ahead and I can say, okay, process that. It’s going to say, status success. Great, it processed it. I’m going to take a look at my database and say, you see, I got this DMO204 table on here and it’s a little small. And I’m going to say, open up that table for me. And in here, zoom in because that’s tiny. In here you can see I’ve got some data down there from my EDI document, right? So I’m done. I’ve got my EDI integration. I can now go back to my trading partner. I can take a test document, I can make sure it’s good. If there’s anything else I need to tweak, I can go back to here and say, hey, here’s a business problem, not a technical problem. Here’s a business level issue like, oh, I need you to also handle Hazmat data. Okay, fine, throw that in there. It’ll go in and update my integration, right? That’s taking my core people off of all of the work that has to happen to get the EDI done so that we can focus on the new technologies. So now I’ve got my trading partner up and running. They can send me documents, right? I just send a document to this system. It processed it, right? So I can send a document here. I can handle that. Now let’s say that I get a new trading partner and the new trading partner is going to come to me and they’re going to say, you know what, we lost our EDI person, or we decided we don’t want to be on EDI anymore. So we want to do a rest integration with you. And by the way, we’re really big customers, so your boss is going to force you to do it. Right? We have to get this business, we have to get this integration up and running. So now we have, we have what traditionally would be a problem, right? I’ve invested a lot in my EDI system. I’ve got this system set up. It’s all working. I’ve got all the mappings, everything’s good. I know how to do the business process for a load tender request through edi. Now I need to be able to do it through an API because I’ve got a new trading partner that wants that. Well, one of the core points of the hybrid strategy is I want to take advantage of what I already have, right? I don’t want to have to go back and rebuild the entire system. So what I’m going to do is I’m going to say, all right, I’m done with this EDI integration. What I’m going to do is generate an API. Same workbench, right? I need an API. I’m going to give it some basic information. Let me just get my URL here that I wanted to use for that.

Dan Magid

Here we go.

Aaron Magid

So I’m going to name this API. Instead of being a 204, it’s going to be at this/API,/demo,/ logistics, slash load tender. So I’m making a, an HTTPs and making an API, a rest API here that I can call and make it a post. Just jump through that and say, post load tender. Give it a name. And I’m going to say, go ahead and generate my API. All right, now that’s going to go through my application. It’s going to create the API for me. Now here’s where it gets very powerful. I have an API of a base API. Now, it doesn’t really process my load tenders yet. And I have an EDI system that’s in the same project that knows all the business rules for processing the load tender. So what am I going to do? I’m going to come over here to my assistant here and I’m going to grab all this and then I’ll talk through it while it’s working, because it’s going to take it a minute and I’ll take you through what I just, what I just said I want it to do. So what I just gave this System is. I said, I just generated an EDI integration at this src routes, EDI transactions EDI EFGH2204 inbound. And if you pick this apart, you’ll see the identifier here is, it’s EDI and The trading partner ID is EFGH2. The transaction ID is 204 and it’s an inbound document. That’s basically how it’s keyed in here. So basically told it, I’ve got this integration here. I also generated an API at SRC routes and this is called. I have a route here. It’s called API Demo Logistics Load Tender. Right. Remember that? That’s what I told the API generator. This is what I want my URL to be. Can you read, can you go look at the EDI integration? It’s not scrolling. Well, can you go look at the EDI integration and update my API so that it takes a reasonable JSON structure that is equivalent to what the EDI integration is, is doing. And then I want you to update my API so that it will interact with the same core database utility that the EDI integration is interacting with. By the way, I’d like you to use this JSON structure. And I gave it a sample that says if we look at this, it’s got a load tender up in the top left. Sender id, shipment id, purpose shipper. I’ve got this name. We’re going to note this. ABC Manufacturing Company. Right, I’ve got that on there. Right. So I’ve gone through and basically just said, okay, this is what I want my new structure to look like. Now this may have come from my trading partner, right. It might not be something I designed, it might be that my trading partner who wants to do the API said, look, here’s what we send all of our partners who do this through APIs. Here’s what I want to send you. So what the system is going through and doing for me now is it’s updating my API to work with that. And there’s a critical point here, which is the final API that it gives me will take in the message that I asked it to take in using modern authentication, and then it’s going to turn around and put it through the exact same business rules that the EDI data went through. Right? So it’s going to take my data, it’s going to translate it so that it can be compatible with those rules, and then it’s going to put it through the same business process, same database entries, same result, same tables. Right. I Haven’t changed anything on the back end here. Right. And this is what I was talking about earlier about I don’t want to force changes in any other parts of my system as sort of collateral damage to modern, to modernization. Right. I just want my trading partner to be able to do APIs. I’m not focused on my back end system right now. I might be focused on it tomorrow, but I’m not focused on it right now. So the end API is going to take that data and it’s going to go into the same database resources. Right? And the result of that is that the previous trading partner will be able to send their 204 to me just as they always have, no problems. The new trading partner is going to send their API call to me the way they want to and my back end system is going to process through the same rules that it was already using. Meaning there’s no double maintenance here. I didn’t rewrite all the business rules. I didn’t have to go back and rebuild all my data pipelines and all my, you know, all my ingestion pipelines and all that stuff. I didn’t have to redo all of my business rules. I didn’t have to change my database. Right. So I’ve got my endpoint. Now what I’m going to do. Let me take this sample that I gave it. Let me just put this together. Let’s see. I need a new request here in my Postman. See, I did a post and I’m going to pull this out of the prompt. One second. I said this is going to be at API Demo Logistics Load Tender. Jump over here. It’s going to be localhome host 3002 is where this is running, the extra slash. API Demo Logistics Load Tender. This for anyone who’s not familiar, this is Postman. It’s an API test client. So I’m just using this to be able to call the API. Go over to Body Raw JSON because I’m sending that data in and let me go grab the JSON that I gave it because I asked it to use this structure.

Aaron Magid

And we’re going to take that over here and I’m going to paste that in there and I’m going to go ahead and send that and it comes back and it says load tender process successfully. I’m going to go back over to here to my database that I was looking at before. Remember I had this guy down here that said it had that record from the EDI document. Go ahead and run this again. Run the statement Now I got two. And if you notice I said earlier, let’s pay attention to that ABC Manufacturing Company, right? Which was up here in my data that I gave it. I’ve got ABC. Let’s see if I can find that right there. ABC Manufacturing Company, 123 Industrial Boulevard.

Dan Magid

Right?

Aaron Magid

This is right here in my document, right? So again, same core business processes, right? It’s going into the same database. I didn’t have to change anything else in order to get this up and running. And from here, because it’s going through the same system, I already have it monitored, meaning here’s my dashboard. If you were here at our second session, you’ve seen this before, right? This is my EDI dashboard that’s showing me. Here’s. Here are the transactions that I’ve been processing, right? I’ve got. What is that, 8,980 EDI documents. Since I started this up, I’ve got all my information about my EDI documents. And then in the same place, I can come over here and I can look at my API calls, right? 2,819 API calls, right? And I can see everything going through my system, whether it’s the 204 from the EDI documents or if it’s my new load tender API, right? Everything is going through the same visibility, the same dashboards, the same processes. I didn’t have to rip up and redo anything to get this live. I mean, case in point, I’ve generated this entire thing in like 10 minutes, right? There’s no, there’s there. I don’t have to do those giant rip and replace projects that modernization used to require because I’ve got that loosely coupled layer in the middle. That’s what allows me to do this. Now I mentioned before, after that tomorrow we focus on the backend system, right? So if we fast forward to that, the next thing I might want to do is I might want to come back to my assistant and I might want to say, okay, well now I’ve got this EDI integration here and I’m going to give it to it because it’s going to work for a little while. I have this EDI integration over here. It says EDI EFGH2204 inbound. And what it does is it processes EDI documents for incoming 204s into my database. I’m retiring that database. We’re done with it. That legacy system’s going away. I’m changing that and we’re moving to a microservice architecture instead. Okay, so instead I want that data to be sent as is to my new API, which is over here at this URL. HTTPs services aerodynamic.com API logistics load tender. That’s where I wanted to go. This is a different API, not the one I generated. Got a core system that I want to send this data to. And by the way, my old database had the header and the detail record separated from the document. I want you to combine that in the payload so that it looks like this. That’s what my API wants. So now what this is going to do is it’s going to go update that core business logic so that it’s able to run with this backend microservices architecture. Now here’s the critical piece. Before I ran this step, I had EDI going into my CoreLogic which was going into my database. Then I had EDI and an API going into that core logic, which was going into the database, right? So I modernized my trading partners first. I allowed them the option of moving to new technologies. This step is totally unknown to my trading partners. They have absolutely no idea that this is happening. They don’t need to know, they don’t want to know, they don’t care. It has no impact on them. They’re sending their EDI documents to that same loosely coupled layer that they were sending it before. The API clients are sending their API calls to the same API endpoint that they were sending it before. And I’m modernizing now the back end logic that both of them are going through so that it works with my organization’s future plans, which I’ve said are a microservice architecture instead of all going to the database, right? So now the end structure here is going to take a little while. So I’m going to let it work for a while. We’re probably not going to see it finish here. It usually takes it a couple minutes. But what it’s going to do at the end of this is it will have modernized the whole system because at that point I will have EDI and API calls coming into my system and going to my new logic. And I progressively modernized it in a way that never required any collateral damage, as I like to call it on modernization never required any additional changes beyond the particular system I was looking at. And critically, the system was live the entire time, right? At no point in this process did I have an outage. Right? And that’s another key, key point. My trading partners can now modernize at their own pace. I can modernize at my own pace for my systems. And there was Zero downtime in this entire process for anybody. Right? So that’s the critical philosophy here. That’s the target of our modernization path. This is what we are out there doing with our customers when we work with them on EDI modernization. Right? This is how you can actually in real life get and EDI integration through a step by step process modernized into not only APIs on the front end, modern stuff on the front end, but also modernize the backend process so that it’ll handle the new technologies that our organization says we want to work with. So I hope that’s helpful. That’s what I got to show you here. You can see my assistant’s still working, so we’ll let it keep working, but I hope that was useful. I’m a turn it back to Maia and Dan to close us out.

Maia Samboy

Hi, I just want to check in. I saw an unanswered question in the Q. Yeah.

Aaron Magid

Oh, yeah, yeah, good question. Yeah. Can it convert the JSON directly to 204? Yes. Yep. So this process, you know, at the end of the day, EDI is just data, right? It’s just another data format. So the aerodynamic connect EDI parser understands the EDI data. It understands it at a conceptual level and as a result, yes. You want to go JSON to edi. You want to go EDI to edi, EDI to xml, XML to JSON. You’re good. Whatever you’re trying to do, it’s, it’ll take care of it.

Dan Magid

Awesome.

Maia Samboy

Okay. And if anyone has any follow up questions, feel free to email me. I dropped my email in the chat and you’ve probably heard from me before. Thank you so much for joining us again. This is our last EDI webinar of the series, but we are cooking up another one for later this year. So keep your eyes out for that invite and thanks again for coming. I will send out that recording tomorrow.

Dan Magid

Great. Thanks everybody.

Aaron Magid

Thank you all.

Maia Samboy

Thank you so much. We’ll see you soon.

Aaron Magid

Bye.

Dan Magid

Bye.