EDI Revolution: Overcoming Hidden Costs and Challenges

EDI Revolution: Overcomming Hidden Costs and Challenges

Mike Samboy

Well, hello, everyone, and thank you to coming to our session today. EDI revolution, overcoming hidden costs and challenges. I’m Mike Samboy, and I’m going to moderate this session for us. Is your company struggling with an outdated EDI system, and is it slowing you down, eating into profits? Well, you’re not alone. Whether you’re in trucking, retail, healthcare, manufacturing, it doesn’t matter. An outdated EDI platform could be holding you back. But what if you could transform EDi from a necessary evil into a strategic advantage? Dan and Erin are going to walk us through just that today, and they’re going to cover how to eliminate unpredictable fees, stabilize your EDI costs. Talk about some strategies for responding to customer needs in hours versus weeks. The secret to effortlessly onboarding new EDI partners without vendor delays, why deployment flexibility is crucial, how you can achieve it, and finally, how to break down EDi silos and integrate seamlessly with modern technologies. There’s two quick things before I hand it over to Dan and Erin. Number one, the session is being recorded today. We will send out an email with a link to the recording and to the slides. And then number two, please ask questions. And I know you guys have been through this a million times in webinars, but just to remind you, on the zoom toolbar, you’ll see a q and a button. Click that at any time. Type in your question, and some of us will be in the background making sure questions get routed and answered. And with that, I am going to hand it over to Dan.

Dan Magid

Great. Thank you, Mike. I realize that in the header you had talked to the EDI revolution, and I have an EDI in trucking, and I focused a little bit on transportation because so many people who are signed up for this webinar are in the transportation business. But all of this stuff that I’m going to be talking about is applicable to any kind of a business that’s using EDI. So whether you’re manufacturing and distribution or in transportation or retail or insurance, whatever kind of an environment you’re in, if you are doing EDI everything I’m going to be talking about here is applicable. A lot of the examples I’m going to be using are going to be transportation examples. But again, the concepts of how we work with EDI are the same. And I’m really excited about what we’re going to talk about today because we’ve really built some things now into aerodynamic connect for companies that are doing EDI based on a lot of the feedback we’ve gotten from customers. So everything we’ve done really has been based on things we’ve been hearing from our customers and feedback around EDI.

We’re going to talk a little bit about what are some of those challenges, what are some of the things that customers have told us that are a challenge around EDI? When you think about Edi, Edi is 60 year old technology. It’s been around for a very, very long time, and it was really way back early in the day before we were really using the Internet and the web, but it was a way for companies to share data in an automated, standard way. Now, over time, it has evolved a lot, so a lot of it isn’t so standard. But the idea was we need to be able to share data so that we can process business functions in some automated fashion. And that’s still what it’s meant to do and that’s what we want to support. And it’s become so deeply embedded in so many companies, it’s not something that would be easily replaced. So it’s going to be around for a while. So we want to talk a little bit about how you can overcome the challenges and continue to take advantage of the promise of EDI. So we’ll talk a little bit about what we’ve done, the things that we want to do to help you in managing an EDI and automating an EDI environment. And a lot of that has to do with adding in AI. AI is a great tool for EDI in that you can start to instruct it to how to deal with the data that’s in an EDI format and get it mapped into your IBM IB two format, or to JSON format or to other formats out of the EDI, and have that done automatically using machine learning and AI. Then we’ll talk a little bit about how you can automatically generate those EDI connections, a little bit about EDI security. A lot of times EDI has been done with just FTP, which is inherently an insecure way of file transfer. So how do you secure that? So you’re not putting your systems at risk. And then a little bit about licensing, because one of the big drivers from our customers that we’ve heard is the way that licensing is being done currently in the EDI environment. If we look at some of the challenges that people have talked to us about, things we’ve heard from our customers, one of the biggest things that comes up over and over again has been the amount of time that it takes to onboard new partners. If you’ve got a new company wants to do business with you and they’ve come to you and said, okay, we want to do this via EDI connections. But you find out that, of course, they’re not using the EDI document in the standard way. They have their own way of doing things with the EDI documents, and you have to put in specialized business rules. So if you’re working with the vendor, you have to go to the vendor and say, hey, I want to onboard this customer. And they typically have a backlog of people they’re working with. And our customers have told us it can take four to six weeks to get a new partner onboarded with the EDI software, which may mean you can’t do business with that company until that process is done, or at least you have to do business in an old way until that process is done. So it can cost your company real money because they are unable to do business with companies right away. They have to wait for this onboarding process. So that’s been one of the key things that people have identified to us as a problem. The other thing is this sort of idea that EDI is supposed to be a standard, but it’s not really in that a lot of people have tweaked the EDI documents and they use them in their own way. And maybe you use the EDI documents in your own way. And so how do I take the EDI document? I’m getting that may be tweaked and then tweak it to meet the way that I need to use it so that I can make sure that I can still share that data and I can do that in an automated way. And then I mentioned the lack of security of FTP. So in these batch file transfers, the way things have been done, they’ve been done using relatively insecure technology, because back in the day, when we first started doing a EDI, EDI was really doing point to point communications. Yet you set up a communication line directly with your partner, and you were transferring data back and forth across that direct connection. Of course, today, almost nobody does that. Now, almost all of the connections are going across the open Internet. And so we need to make sure that we’re encrypting, that we’re authenticating, that we’re making sure that we’re securing that environment as we move that EDI data back and forth. Then what a lot of our other customers have told us is that they’re concerned about getting locked into a proprietary technology. So they go with a vendor to do the EDI translations. And what they get then is a very, very proprietary, vendor based way of doing translations. And once they’ve sort of built up all their partners to get everything into the system, they’re now locked in. They cannot move to anything else. So they’re locked into that vendor’s way of doing things and they don’t have a lot of options moving forward. So we’ve had customers say, is it possible to make those EDI connections in some sort of standard, open way, that I have some options in the future, and we’ll talk a little bit about that. The other issue was that we have heard many times is from customers who say that the batch oriented nature of EDI means that I’m getting data slowly. So I’m, you know, I’m going out and pulling an FTP server. I’m looking for the documents, see has anything new arrived? And I’m getting batches of data that I then process. When a lot of times today, what people want is real time event processing. They want to know right the moment something happens. They want to get updated. They want to get that information. So they don’t necessarily want to have to go out and check to see has something arrived. They just want the moment the event happens to get updated with that information. And I talked a little bit about the licensing, the licensing models for many of these EDI vendors. It’s based on the volume of documents, the amount of data actually in the document accounting, characters of data, how many transactions, and every transaction can be a double cost because you’ve got the actual transaction itself and then an acknowledgment going back, and each one of those things get counted. You never really know what your bill is going to be because it’s based on whatever your volume was for that particular month or that particular quarter. So people have been looking for a way. Is there a way that we can get licensing that’s more predictable, that I know exactly what it’s going to cost me to use this software? And then the other thing is a lot of companies are now moving from EDI to standard APIs, and customers are saying, well, can’t I reuse some of this mapping code, some of the things that I’ve done and the EDI side with the APIs that I’m building or that I’m starting to connect to? And typically, since this stuff is done in a proprietary, vendor based EDI format, you can’t really move that stuff. You basically start over again when you start using APIs. So the question was, well, isn’t there a way to do this where I build the EDI connections in a way that I can use them if I move to a new way of doing things? So if I move to an API based way of doing things? So these are some of the challenges. I’m sure those of you on the call here can think of other things that have been challenges with working with your EDI environment. These are some of the ones. Actually, one of the things we hear a lot from customers is that they have one person in their organization who understands the EDI stuff, and if they lose that person, they’re in big trouble because they don’t know how to actually deal with onboarding new people, or how do you deal with new formats, or how do you deal with changes in how a customer or one of your partners is working with it. So another thing is to try to encapsulate that knowledge somewhere so that you’re not completely dependent on the only person who really understands the EDI environment in your organization. So those are some of the challenges that we’ve heard about from customers. And then there are some specific challenges of working with the IBM I itself. The IBM I has very specific ways of handling security. So if I’m going to connect to an IBM, I need to make sure that I’m supporting the way the IBM I wants to work with security. Then how do I process these customized EDI documents and extract the data and get it into my IBM IDB two database? So I have particular ways that my application works. I need to get it into my IBM I database. So how do I make that happen? And then another thing we are starting to see a lot of, especially in transportation, but in lots of industries, is people are moving to this modern messaging technology. So they’re working with things like Kafka, like Amazon’s SNS and sQs. These are event brokers that you use so that you can first of all process events in real time. So as things happen, you get that information and you can react immediately to it, but it also allows you to handle very, very large volumes of transactions. So for those of you who are in logistics and in transportation, you know that you can get very, very high volumes of transactions if you’re starting to use devices on board, on the trucks that are sending you data. And you can get, we have a customer who told us that they were getting data from every truck every 19 seconds and they had thousands of trucks in their fleet. So you can imagine the volume of transactions that they were getting. The great thing about these event brokers is they can handle very high volumes and they’re also set up to be resilient so that you don’t ever go out, so you’re never out of business. And I’ll talk a little bit about how that works. And by the way, this is specific things to the IBM I, but the EDI solution we’re going to be talking about and the things that aerodynamic connect is doing for EDI can work with Unix Linux with whatever platform you might be working with.

So let’s talk a little bit about some of the things that we’re doing that we in fact have done over the last couple of years to start providing support around the EDI environment. So the first thing and the most important thing is everything we’re doing for EDI is based on our Eridani connect framework. So I know that there were a lot of aerodany current customers actually signed up for the webinar. So for those of you who are already Aerodyni connect customers, you get to take advantage of all of the aerodany connect framework. So its ability to do authentication and authorizations, its ability to do data transformations, its ability to connect and route things to the IBM I to Windows platforms, to Unix platforms, to whichever systems you might be working with. So it’s built on that exact same framework. We’ve just added to it now the capability to do EDI integration. So we’ve added the EDI piece to that whole framework. So it’s just an addition to that. And you can see we’ve already done many, many many different integrations. But the lists here are things we’ve already done. So these are integrations we have already done for customers. So we’re building on existing proven technology for doing connections, but really specifically now to handle the EDI environment. So handling the EDI formats, the different document types, and then that data mapping from EDI formats into IBM I or Unix Linux Windows kinds of formats. And by the way, I talk about the IBM I a lot. For those of you who’ve been around a while, it’s the same thing as the AS 400. It’s the same thing as the I series. We’re talking about the same environment. So one of the things that’s fundamental all to this is that idea of security. And so again, we’re taking advantage of the fact that aerodynamic connect supports over 500 different methods of securing your environment. So you have the option to choose from many, many of the most modern ways of doing security for your environment. Again, whether it’s IBM I or other platforms, you can use the latest in security rather than doing things sort of the traditional way things were done. On the IBM I, where if you want to connect to the IBM I, you’ve got to have IBM I native credentials. We decided that that’s not really a great way to do it because you don’t want native IBM I credentials floating around and you don’t want to be passing them up and down the wire every time somebody wants to send you something. So rather than using those native IBM I ways of doing authentication, we allow you to use all of the modern ways. Now, we do actually support that basic authentication, but we don’t recommend it. So you can use, if you want to, JSON Web tokens, you can use oauth. We’re going to encrypt everything for TL’s communications. You can do multifactor authentication. All those things are built in and can be part of your EDI environment. And so you take advantage of all of that stuff that Airdani connect already does and add to it its ability to handle EDI documents. So again, we have all these different things that we already do. So we secure the environment. We do all the encryption for you, we do all the data transformations for you. We do data sanitization. Make sure nobody is sending in that payload of data that theyre not sending in any injection code that might compromise your system. Were doing all the logging and error handling. We allow you to do IP address whitelisting and blacklisting so you can set up a very secure environment for your IBM I and then use our EDI connector to get the data to your IBM I. And then I also talk a little bit about the event driven connector, and we’ll talk in some more detail about that in just a sec. But you can take advantage of all that stuff that’s built into the air Donny Connect framework and add to it now all of the EDI capabilities that we’ve created. And again, we do all these automated translations. So we’ve added now the ability to say, okay, I want to take an EDI document and turn it into JSON data. And so we can take any, we can take any of those EDI formats, any of the EDI documents, and take them and transform them into JSON data, XML data, or into IBM I db two data.

This is just a little bit of a picture of how this works for inbound EDI processing. So somebody is sending you an EDI document. So they send an EDI document. It can come in via FTP or SFTP or as two, or actually as an API call. So you’re getting sent that EDI document. The first thing that Eridani does is it breaks down that EDI document into its component field. So we get field data out of the EDI documents, so out of the EDI format and into a standard format like JSON or a standard format for handling the data. We then have a database of trading partner information that tells us the business rules for that particular trading partner, for that particular kind of an EDI document. And then we have a natural language based data mapper where you can say, I want to take field x and put it into field y. Or if field x equals one, then put the data field x equals two, then put it there so you can build up rules using natural language. And again, Aaron is going to show you an example of what that looks like, but you can create then the rules for how the data is going to be handled. Again, we’re going to do all the error logging for you, and then we’ll take that data and either pass it off to an RPG COBOL CL program on your IBM I or directly send it directly to the database. The document comes in. Eridani Connect will process that using all the EDI capabilities that we’ve created, and send it off to your IBM I. You’ll be able to take advantage of all the monitoring so you can monitor all of what’s happening with your EDI. And I’m not going to show you too much about that because Aaron is again going to show you a little bit of that live. He’ll show you some of what the monitoring looks like, and then the same thing for outbound. So if you want to create an EDI document to send out, so you’re running a program and you need to send out, maybe you send it, you’re sending out an acknowledgement. You got in a 204 tender and you now want to send out a 990. You want to send out an acknowledgement, you can tell the system to do that, send it some data, and same thing, it will go ahead and take that data, get the information, put it into the EDI document format and then send the EDI document out. So it can do both inbound EDI processing and it can do outbound EDI processing. And this is kind of what the generate sort of under the covers what’s happening. And again, Aaron will show you this, but it’s a natural language kind of way of setting up the rules, but under the covers this is all the stuff that it’s doing, and there’s a lot going on here, but it’s generating the code for you to do those translations. And the important thing here is it’s generating standard code. So when it generates the code to do the EDI translations, when it generates the code to do the data mapping, it’s generating that in standard RPG code or JavaScript code, depending on the use case, it’s creating it in a standard way so that later on, if you want to maintain it, you want to make changes to it, you can, so you can get into that code. It’s not a proprietary Erodani way of doing things. We’re using standard functions to do those things. And you can get in and you can make changes if you need to do that. But the idea here is that you can onboard your own partners and onboard new document types without having to go to come to a vendor. Now we have people who do this and we are happy to do it for you. If you want a contract with Eridani to do that, we will create these connections for you. But the idea here is to give you a way to generate them if you want to directly. So you can do it yourself. So you can go either way, you can either generate yourself or you can contact us and we can help you generate those, generate them for you. And this is a little bit, I know a little bit of an eye chart, but it’s really just a couple of different components. Basically you’ve got the publisher of the EDI documents, and in this case the system wants to do it in an event driven way. So you want to set up in an event driven environment where instead of going out to check to see do I have any new EDI documents to process, is there anything new out there for me to work with? You want the system to automatically react when something happens. So again, if I use the transportation example, every time a trailer is open, every time a trailer is closed, if a driver goes off route, I want to know about that. I want to know about it when it happens. And I want that to be an instantaneous update. I want those updates to happen. We were working with a customer that actually doing things with their current process had a two week delay between the time an event occurred and the time it was completely updated in their system. Now with this new way of doing things, it’s about a four second delay. So it happens very, very fast. The idea of this is the event happens. It could be a transportation device, onboarding of a new employee or new driver. You got in a PO, something has happened and immediately you want the system to react. Now, again, you get all the Airdani connect functions to make sure that this is an authentic request coming from an authentic person, that they’re only doing the things that they’re allowed to do. It then publishes to these different message brokers. And you can, these are just options of different ones. You can use, you can use Kafka, you can use Azure service bus or Amazon SQs or SNS. So you can use whatever broker you want. What we do, what aerodynamic connect is going to do is it’s going to take that EDI document and turn it into JSON, because that’s what these brokers want. So we’re going to turn it into a JSON message and then we’re going to post it to a topic. So what these event brokers do is they take those messages and they put them into what are called topics. Topics are just areas of interest. So it could be all the tenders, all the acknowledgments, all the POS that have come in, whatever it might be. You have different topics that you can publish to. So you send in the stuff to Airdani Connect, it will automatically then publish those to the appropriate topics in the event broker that you want to use. And then in order to get it to your back end system, now it’s going to take those and read those messages off and translate them back into things the IBM I can understand, so into the IBM I db two data. So it’s going to take the messages off of those topics. So again, the way the event broker works is the publisher publishes things to the topics and the using the applications here are subscribers to those topics. They can all use those same messages. You don’t have to write end to end, point to point integrations. For every one of these different kinds of EDI documents you might be getting, you can post them. And then the different applications that need the data that are in those documents can subscribe to them. And Airdani Connect will make sure that they’re getting the messages that they need and getting the data from those messages that they need. So basically, we have this environment where you can now process with your IBM I events. So even though the IBM I is not really built to be an event driven processor, you can use it that way. The other thing this gives you is resiliency, because what these event brokers do is they will make multiple copies of that repository of messages, so that if you lose one, the other ones are still up and running. And you don’t have to worry about your system being down because the event broker is broken. You’ll just move all the traffic to one of the ones that’s running and it’ll keep reading the messages. And the event brokers do all the housekeeping to make sure that these things don’t get out of sync. And it knows what’s the next message that the rating application needs or what’s the next message that dispatch needs. So it knows where each of the applications, each of the subscribers are in the message load and the message loads can go both directions. So the right side here could be also publishers where they could be publishing messages that are going to the brokers and then being read by the other side, the things on the left side here. So the messages can go either way. So in an EDI environment, I can take advantage of these event brokers to very, very rapidly process these documents.

Mike Samboy

Dan, just a quick question. In terms of the presentation, you’re going to go over logging and monitoring later. Okay, great. I’ve had a few questions filter in. I’ll save them till that time.

Dan Magid

Sure. Yeah, yeah, yeah, yeah. And Aaron’s actually going to show a lot of that, but yes. So here’s the workbench. So we’ve integrated directly into our versus code workbench. For you to create these things. You just fill in the form to say what is it that you want to do? And then you have, and again, Aaron’s going to show you this. You have this natural language interface for saying, what do you want to have happen with the data? How do you want it to be mapped? And so you fill in this natural language, this english language kind of form, and we will then generate, or airdany connect will then generate the code for doing those data transformations.

And then once you create those, you can manage them. So the air Donny connect workbench plugs directly into version control tools like Git. Or you can use them with your IBM I change management systems where it will generate the code, and then you can promote the code, build the code, move it through whatever lifecycle that you want to create. And you can, if you want to use the latest tools like Azure DevOps or Azure pipelines or Jenkins or other kinds of process automation tools. And so, yeah, a little bit, Mike, about monitoring. So basically, everything that’s happening, Airdani connect is tracking. So it’s tracking every transaction that comes in, and it allows you to feed that data. So we feed the data we’re gathering out in logs that are in Prometheus format. For those of you who aren’t familiar with, Prometheus is the standard for feeding data, for feeding log data, or data coming out of your application into dashboarding systems like splunk, like new relic, like Grafani, these different kinds of dashboarding systems. So we actually take all of that log data. You can actually tell Eridani Connect how detailed you want those logs to be. It goes anywhere from simple logs, where it’s just keeping the most basic information, to what’s called silly logs, which is keeping every single thing the system does. And it can build up very large logs very quickly. But any of that, all the information, you know, who, where did you get the transaction from? What happened when it got to your system? How long did it take to get from the Airdani connect into your IBM? I. What was the end to end process? It’s tracking all of that information. So you can go in and you can look at that information, and we can display that information through any of these dashboards. And one of the things that Eridani will do is we’ll help you set up these custom dashboards. But I’m going to leave a little bit of this to Aaron because he’s going to actually show you some of these live dashboards.

Mike Samboy

That actually covered one of the questions.

Dan Magid

Great.

Mike Samboy

Yep.

Dan Magid

Okay, thanks.

Aaron Magid

Alright, so I’m going to share my screen and we’re going to get started here. Just 1 second here, of course, right as I started sharing my 5250 session time. That. So

that’s better.

Dan Magid

Okay.

Aaron Magid

All right, let’s let that load. Okay. Nobody else can respond to me but Dan, can you see my screen?

Yes.

Aaron Magid

Okay, great. I always like the verbal confirmation. Okay, so you can see my logs here actually, from running this earlier. But. So let’s say and this is probably a common situation for a lot of people on this call. Let’s say that I’ve got a 204 coming in. I need to process this, and I need to get it into my database. The most common architecture that I see for EDI integrations, that’s what I’m going to show here for inbound EDI documents is ingesting EDI documents, breaking them down, validating them, doing some form of transformation on them, and then placing them in appropriate database tables for later use. That’s the most common structure that I see, especially among IBM I shops. So that’s what I’m going to show here. But I do also want to just mention, in line with Kishore’s comment or question, that you can go to other places with this if that is something that you need to do. So what I have here, I just want to show here, I look at the shipment stops in here. I’ve got an empty table. I’ve got nothing in here. Um, and I can jump into some of the other ones. I got an address, I’ve got shipment stops.

Dan Magid

Right?

Aaron Magid

This is the information that I’ve gotten in a typical 204. And what I’m going to do here is I’m actually going to pull up a 204 that I have here. I’ve got a sample one here. And what I’m going to do is I’m going to grab this document and I’m going to send it in to an endpoint that I generated. And the cool thing about this endpoint I was going through working on this endpoint, actually generated this one yesterday. And I was sitting, actually, at my kitchen table eating my lunch, and I took this document in and I put it into the workbench and generated this integration. And the reason I mentioned I, where I was and what I was doing is to point out what is, and to focus on what Dan was saying earlier about onboarding, that we see a lot of companies who are seeing four to six week delays in onboarding. And I was actually done with this integration and processing 204 documents before I was done with my sandwich. So that’s just kind of the timeline that we’re talking about here when we work with this. And again, that I’ll show you in a minute. What I’m going to do here is I’m going to send this document once it comes back. You can see here a couple of stats about it. It took about 1300 milliseconds to do all the database interactions that I needed. Once I do that, what I want to do here,

I’m going to jump over to my database. You can see the same tables that I was looking at before. I’ve got the information from that document. You can see I got my stops and my weight numbers. And if you look at just a reference back to the document, I’ve got the same information in my document. For those of you who are familiar with these documents, you probably are very tired of seeing this format, but I’m not going to go into detail on the actual EDI document here just because I want to focus on with the time that we have on the technology that we’re talking about here. So I sent in my EDI document and it got broken down and ingested in my database. And I just want to point out that here I’ve got my shipment stops, I’ve got my header record, I’ve got my addresses. See, what else do I have? I’ve got a shipment date, and I’ve got a summary. I’ve got all of this information broken out into a database. It’s all been mapped and it’s available in my system. Again, the key point that I want to make, there are a lot of tools that will do that thing. This integration took me about 15 minutes to put up. That’s including some tweaks that I made to it after I generated the initial one and got, and needed to change the business logic a little bit to do something a little bit differently that I wanted in terms of how it processes the document. So I just want to pause there for a second. We’ve processed an EDI document. I know that was fast, and it’s a very high level view, but I wanted to do that to show that we can take these documents, we can break them down into an understandable format, and then place them where they need to go. And again, that’s the most common structure that I see in EDI integrations. The question then is, how did I get here? How did I actually get this integration done? That’s what I’m going to take everybody through next. When I want to generate an integration with an EDI document, the first thing that we’re going to run into when we get into that, when we try to do our own onboarding, and anyone who’s working in EDI has probably run into this many, many times. At Iridani, we like to call EDI the non standard standard. Dan mentioned that a bit, that it’s a standard, but it’s always a little bit different, which means that mapping it into your applications can be pretty difficult. You bring on a new trading partner. You need to skim through their documentation. Actually, you can’t really skim. You need to read very closely through their documentation and make sure that what they’re doing is going to work with your process. Because very frequently in my experience, in fact, almost every time there is something weird that a company is doing that’s a little bit outside the standard, just enough that you need some kind of customization to your mapping. That’s just generally been my experience with EDI. There are some big offenders out there, you know, some, some larger companies that just sort of make up their own formats and don’t even follow the spec at all. But most of the time we’re talking about some, some small changes, but it’s just enough to throw off a typical translator. So what I’m going to do here is I’m going to do this process of onboarding a new integration based on the real data. I don’t want to read the documentation. I don’t want to go through all that stuff. What I’m going to do is I’m going to take samples of the actual data that is going to be sent and I’m going to feed that into my workbench and it’s going to create the integration for me. I just want to say that again. I’m going to take samples of data of EDI documents. I’m going to pass those in, and that’s how I’m going to generate this. That’s a key part of the Airdanti philosophy, actually, in a lot of different ways. We use this philosophy of dynamic analysis in a lot of different places where we want to look at the real data that’s going to be transferred. Not often what somebody says is going to be transferred because oftentimes the real data doesn’t match what someone says they’re going to send. What I’m going to do here. So I’m going to jump over to my workbench and I’m going to start with something that should be familiar to.

Dan Magid

A lot of you.

Aaron Magid

I’m going to start with my command here, and I’m going to say, I want to generate an inbound API here. The first thing that I’m going to do here when I generate my inbound API is I want to say, what do I want the system to do? Now, a lot of you are familiar with some of these options, but I’m going to go over here to my EDI Mapper, which is an additional module that I have installed.

What I’m going to do is I’m going to give this an endpoint where I’m going to say I’m ingesting a 204. Here, make a post. I’m going to say ingest 204. Now, I could do this with a different type of trigger. I could do this with an outbound call. I could do this with an SFTP read. I could do this with an as two server. There are a lot of different ways of receiving an EDI document. Rest assured, aired on Connect will handle them. But in this case, I’m going to do an inbound API. It’s the easiest one for me to demonstrate, so that’s why I’m choosing that one. Just a quick q and a question that came in. How does translation happen? Is it automatic? So the translation, yes, the translation. So I want to break down the process between translation and mapping. What we’re going to do, we’re going to take the EDI documents and we’re going to translate them into a more readable format, what we refer to as our x twelve JSON format, which is going to represent all the data that was in the EDI document in a way that’s easier to process, and especially it’s easier to write business logic around. From there, we then go into a mapping stage where we say, okay, from our standard format. Now, because it’s a more readable, more processable format, it’s going to be a lot easier to tie things together. So that’s how that’s going to work. So yes, the translation is automatic. What I’m going to do here is I’m going to generate a base integration. Again, nothing really new here so far in what I’m doing. I’m letting my generator go through and do its thing. For those of you who have used air dynamic connect before, you know that the next thing you’re going to get is one of these controller functions, which is just going to be a starter for now. This is where it’ll depart a little bit from what you may be familiar with, with Airnani connect, if you’ve been using it for a while. I’ve got a starter function in here. I’ve got code that I can use that will process an EDI document, but it doesn’t really know what I want it to do yet. It’s sort of a blank slate, sort of a container for what I want to do. It will be able to break down the document, it will be able to validate, it will be able to authenticate. It’s got all that base stuff, but it doesn’t really know what to do with it once it has it. So that’s what I need to tell it next. So what I’m going to do is I’m going to go over here, I’m going to take my EDI document. I’m just copying it out of my interface. If you look on this right side here, you can see it says your new integration has been generated. Should any changes be made. That’s our standard introduction to when we bring our generator in. What it’s going to say here is it says, generate a business process that will handle EDI documents like this sample. What I’m doing is now I’m talking to the Aerodyni generator services, and I’m sending in my sample, and I’m saying this part of the prompt is hard coded, this is saying, but it’s there to give me an idea of what the system’s going to do. I’m telling it, I want you to generate a whole business process to handle this type of document. I mentioned earlier that the translation is going to happen automatically. That is true. The translation of the document into our format, into our internal format, will happen automatically within the system. But then from there we need to be able to map it to the database. That’s really where EDI processes become very complex. For anyone who’s worked in EDI before, what you’ve probably seen is getting the document. That’s not that hard, right? You talk to your van or you set up SFTP, fine, we’ve got the document. But once we actually have it, picking out all those little data elements and understanding the hierarchy of the document and making sure that we get everything to the right places, that’s where all the work goes. Right. And if you have a tool right now that you’re using for this is probably where the vast majority of your configuration work has gone to date, is going through all those screens and saying, this segment’s going to go here, and if this segment is there, then you’re going to do this, and then you’re going to accumulate these values and you’re going to count this up there, here, here. Right. That whole process is what we’re trying to simplify here by sending it up to our AI services, right. That’s something that we found is a very good application of this LLM technology that’s been exploding out onto the scene recently. So you can see here my generator came back, and what it’s done here is it’s updated all of my code so that I have an application here that will process my EDI document. Now I’ve said code a couple times, so I want to make a point here. I don’t have to be looking at the code. This code will compile, run, and process my EDI documents, no problem. But true to the Eridani philosophy, we never want to lock you in to a box that you can’t get out of. We’ve seen many, many times drag and drop tools, low code platforms, things like that. Get to a place where you need a button for something, the button’s not there, and they just sort of say, I’m sorry, guess you can’t do what you want to do, right? We never want to be there. So airborne connect, as you’ll hear in most of our presentations, will generate code, industry standard, readable, clean, well documented code that will run your process and get it done. But also, if I want to get in there and I want to look at it, or if I have developers who want to take a look, we can also do that. And we’re just going to take a quick look at some of these things now, and then we’ll put it away and move on. What I want to mention here is the integration type that I selected is generating a new integration from an EDI document without an existing database. What the system did here is it actually went in and it designed a database and generated the create table statements for me. So it didn’t just do the mapping code. This system is generating a full business process, including a database. You may notice I didn’t tell it anything about how to organize the database. It generated for me a set of valid IBM IDB two SQL statements because it knows that I’m using db two. And if I was using another database, it would generate appropriately for that database. It’s generating my database definitions here that give me everything I need to store the data it generated. This way, it generated the SQL queries that I need to insert the data in. And it generated all of the mapping logic that I need to grab things out of the different segments. For example, if we just peek in at this, you can see when I look at this in here, you’ll see things referenced like the s five segment. You’ll see things referenced like the g 62. I’ve got the different fields in here, and this is all, again, this code will work out of the box, but I can also get in here and I can see exactly what it’s doing. If I need it to, if I need to get in there, I need to see it, or if I need to tweak it. So that’s my process for generating these integrations. And again, that’ll work for whatever document I want to run, right? I don’t know if I have time here, but if I have another, I think I don’t, but if I have another transaction type, I throw that in there and I’ll get another integration there that will do exactly what I need for processing that particular data. So that’s what the process looks like. Now we’re not actually done until we decide that we’re done. And so there’s one other thing that I just wanted to mention, which is that if you notice, my generator interface is still here, but it says something different now. Now what it says is update my integration. So what it’s saying now is it’s coming back to me and it’s saying, hey, okay, so I generated a base integration for you that’s going to take that EDI document, break it down, put it in your database. But do you need anything else? Maybe you need something more sophisticated. For example, what if I want to say if there is an error processing the EDI document, send a text message to me using Twilio with the account information in my configuration saying error processing EDI, let’s say 204 document, and we’re going to bring in the current timestamp. So I’m going to say send me a text message. If you get an error, I want you to send me a text message and I want you to tell me, I got an error processing this 204 document. And this is when it happened. That’s a critical thing when we’re trying to troubleshoot an issue with an integration, because we have to be able to look at our logs and our observation systems, our monitoring systems, looking for the specific time when the error occurred. So we can see what’s going on in the system. If we look at the code that got updated. This brought in Twilio, which is a service that does text messaging from JavaScript code. It’s got my message here to send the text message. It pulled in my message, it’s got my phone number. It knows exactly from the configuration. It knows exactly how to do this. This is where the process then becomes much more sophisticated. We do this in a loop when we’re building the real integrations. Another example that I wanted to bring up, because it was an issue we saw with a real company. We worked with a company once they were facing an issue where they were getting a lot of requests for shipments to destinations that they didn’t serve and that was costing them a lot of cpu cycles on their IBM I and in their core systems for no reason when they could have, you know, just to figure out it wasn’t something that they served. So another thing that I might do here is say reject the EDI document with an error. If the, if the address, and I happen to know because this is in my sample, the address is in Ohio and I’m picking on Ohio because I went to college there. So I can pick on Ohio. And so again, I can come in here and I can say, okay, here’s what I need you to do. Go in and update my controller so that it does that and it’s going to keep on building up this code. Again, if you look in here, if we scroll down here, you can see, nope, it’s got an error there. If I’ve got a problem and it’s processing our format to get that data out, figure out where that is, because it knows exactly what’s in my document, knows what it’s going to have access to, and just to bring it around for the q and a earlier, I wanted to just mention there are also capabilities in here to say convert the document to xml. There are also capabilities in here to say call this salesforce endpoint, call this mulesoft endpoint, or retrieve from those endpoints and use that to get the document out. Those are the kinds of things that we would do in this step. I know I held you guys to the last minute to say that, but that’s, this is where we would do that type of thing. So, Mike, Cobra, I know you got a question there. If a trading partner uses a segment differently than another, how do I handle that? It’s a great question. That’s why we take the sample and you can actually pass in additional documentation if you’re interested, if you need context for it. But that’s why we do the sample. So if I have this integration that I generated is specific to this trading part, it is this trading partner and this document type. So if I have a sample that has a totally random segment in there that’s not even part of the EDI spec, or if it’s just used differently, the system is going to process that, it’s going to bring it in. And again in the comments I could also, if it’s something that’s a little bit more subtle, I could put in some information like the trading partners documentation to assist the generator in interpreting the data properly.