Stop Believing the Real‑Time JDE Myth – Session Limits, Timeouts & Stale Data
November 17th, 2025
27 min read
Youtube:
Spotify:
This episode explores the often misunderstood world of real-time JD Edwards integrations, breaking down why modern JDE environments are finally capable of true real-time performance. Through a detailed discussion covering session management, stateful orchestrations, load balancing, architectural considerations, error-handling strategies, and data freshness, the conversation highlights both the technical challenges and the practical solutions teams need to build reliable, scalable integrations. Listeners learn how orchestrations revolutionize synchronous processing, how smart architecture prevents overload, why exception handling must be proactive, and how clean, real-time master data synchronization eliminates downstream issues. Ultimately, the episode makes the case that real-time integrations aren’t just possible, they’re essential, and with the right design, testing, and monitoring, they can be highly dependable.
Table of Contents
- How Real-Time JDE Integrations Evolved & Common Misconceptions
-
Session Management, Statefulness, and Integration Architecture
- Error Handling Challenges and JD Edwards vs Middleware
- Data Freshness, Master Data Sync, and Real-World Failures
- Balancing Freshness with Performance and Designing for Scale
- Orchestration Timeouts, Patterns, Best Practices, and Wrap-Up
- Best Practices for Reliable Real-Time JD Edwards Integrations
Transcript
Introduction
Your JD Edward system says it's integrated in real time, but is it really? What happens when session limits, orchestration timeouts, or stale data quietly break your business processes? In this episode, we're unpacking the hidden challenges of real time JDE integrations and how to solve them. Stick around. You'll learn how to avoid downtime, bad data, and missed opportunities in your integrations.
Welcome back. To Not Your Grandpa's JD Edwards. I'm your host Nate Bushfield. And today we're pulling back the curtain on the technical side of real time JD integrations. When AP is orchestrations and external systems all connect, things don't always run as smoothly as the demo promised. Issues like session management, slash statefulness, air handling, data freshness, and orchestration timeouts can cripple performance if you're not ready. But to help us break it down, I'm joined by Mo Shujaat, great friend of the pod. Obviously, Mo, I mean, you've been here a lot of times, even a few times in the past few weeks, but he is the VP for application advisory here at ERP Suites for listeners that are new and might not know that. Mo, how are you doing today?
I'm doing great. How are you? Having a great day so far. I finally hit a little bit of a heat wave, but I don't know, there's this whole like BLOB thing that everyone's talking about right now in terms of weather patterns. So it seems like it's going to be the coldest winter yet in Chicago. Great time to move here. I've heard I'm, I'm getting ready to pack for a trip to Cancun. So I'm just waiting to run away from the winter, and hopefully that's the week it'll snow the most here in Cincinnati. Yeah. Well, Cincinnati, they. That's the best thing about Cincinnati. It'll be snowing, freezing cold, and then they'll wake up the next morning. It'll be 65, and you can go golf. It doesn't make any sense. But I love that about Cincy. I really do. It's bright and sunny and shining outside today.
Are you invested in a Chady Edwards upgrade? So, weren't you seeing the ROI you expected? Could a few overlooked factors be quietly sabotaging your investment? In this episode, we break down the top reasons companies fail to realize their full return from their JDE upgrade. Stick around, you'll learn how to avoid these mistakes and turn your upgrade into a strategic advantage.How Real-Time JDE Integrations Evolved & Common Misconceptions
So. Yeah. Yeah. Well, I am excited to talk about one of my favorite topics, which is integrations. Yeah. And so when we actually talk about real time integrations and JD Edwards, what does that actually mean? So you know, it's, it's kind of funny how this world of innovations has changed and has changed so fast, right. So if you would have asked me the same question like 8 years ago, I would have told you, oh, it's, it's a huge pain in the **** to do real time integrations with JD Edwards, right? You ask this question now and I would say it is extremely easy, it's extremely efficient, and it is probably the best way for you to integrate right now, right? So in just like six to seven years, the entire landscape with integrations in JD Edwards has totally changed, completely changed, right. And it has been wrote like really cool for somebody like me who started their career in JD Edwards to see how it's changed and think about how I wrote integrations at the start of my career as a JD Edwards consultant and how it's so different the way I write them down. Yeah, it's it's one of those things that obviously like with everything in JD Edwards, who really has evolved and it's cool to see and it is cool to see. I like, I also like the how you threw in a nice little 6-7 joke. I'm sure that our kids at all will love that. That was unintentional. That was unintentional.
But what's like the, what's the biggest misconception that maybe you see companies today have with real time integrations? I think the misconception that companies still have to this day with JD Edwards is that it can't do real time integrations right? Like, and, and, and I don't blame them because for the longest time we, we in JD Edwards world, we lived in the world of flat file integrations. Like that was the way you integrated with JD. You dropped a flat file on a folder, you ran a table conversion program and then you imported data to AZ file and then you ran AZ file processor. Now doing all they're like, wow, you know, I don't even want to do it anymore, right? I basically want to be able to just host an API, have the API be standardized. I want to be able to hand out documentation to my partners to say, here's how you connect to my API and you only just send the data right in, right. So I mean, it's a totally different world of, of real time API based integrations, 100%. I mean, yeah, at at least to me, it always seemed like real time was more marketing than reality. You know, like is, is that something that's still true or there's some cases that real time is actually real time? You know, that I, I would say we now live in a world where real time is real time. Like we have customers that are receiving orders and from third party systems and those orders are getting entered into JD Edwards in, in literally seconds or fractions of seconds. And I'm not talking like 1-2 line orders. I'm talking of hundreds of live voters that, that are going through advanced pricing, that are going through Configurator that are going through any of the advanced functionality that you could do in, in JD Edwards, right. So really all of this wouldn't have been possible without the orchestration layer. But now we have the ability to really create actual true real time synchronization between your third party systems and JD Edwards, right? And really, there's no excuse now to not be synchronizing your data real time unless there's a real big need to not have to do things real.
Session Management, Statefulness, and Integration Architecture
Yeah, I mean, it's kind of impressive to even think that we can actually achieve a real time like that, especially obviously in the olden days of JD Edwards, like floppy disk with the idea of a floppy disk to me. By the way, just a little quick tangent, still can't wrap my head around that. I don't, I like what what was the process there? You got to have this giant machine to put in a floppy disk, whatever. But the obviously where we're going with JD Edwards and everything that has been evolving is it's obviously it doesn't surprise me that real time integrations are real now, this year, 2 ago even it really wasn't. Maybe that's just anyways, what role does session management slash the statefulness play in JD orchestrations? And how does it feel when like how does it trip up those real time integrations?
So I think, I think like up until probably like two major releases ago. So I mean, 9.2.7, you could do real time integrations, but there you would always hit the scenario of needing to maintain state or needing to manage sessions that you really couldn't do right. And then boom, I just don't know how. Shout out to AJ and Paul at the and, and John and, and the whole Oracle product team. I don't know how well they basically read the customer base's mind and we're like, hey, here's this great feature around statefulness and orchestrations.
So now you know, starting from like 9.2.7, we really have the ability to make almost any kind of real time API you need to. I would say probably the only area where we have some limitations is like web hooks. But you know, so you know, you know, shameless plug, AJ or Paul, if you listen to this, please give us web hooks. We really want it. But really now when we have this, we have the stateful orchestration capability, I think, you know, you now really have the ability to basically have systems connected to JD Edwards and not have to necessarily wait on JDE anymore, right?
Systems can connect to JDE, they can send things to JD Edwards. JD Edwards cannot maintain the orchestration, cannot maintain state. It can do the things that it needs to do. And then once it's done, it can return responses back to the system and, and, and, and the communicating system and, and you know, all is right with the world and all the data is synced right. You know, and as a, as, as a note, Onyx is a big fan of state full orchestrations. So please make sure you use state full orchestrations when you're building them.
They're not necessarily everywhere, right? But in the scenarios where maintaining state makes a lot of sense for the orchestration, like, so for example, you, you have a third party system that sends something to JD Edwards. Right now, JD Edwards is going to do something and it now needs to, you know, wait on some other processes. It needs to wait on some other things to finish. You can have a kind of wait and pause. You can have a pause. And after it's done doing all the other downstream stuff it needs to do, it can then resume the orchestration and communicate back to the third party system and say, hey, either asynchronously or synchronously depending on timeouts and sessions, right?
You know that hey, I, I got what you sent me and and whatever you sent me is done processing downstream, right? Prior to that, we would have to always do things these things asynchronously, right? So you have to send something to JD Edwards and basically you would, it would feel like sending it into the nebulous void and you don't know if it actually really did what you needed it to do. And then you just kind of create these two stage bi directional integrations.
But honestly, having the ability to maintain state with orchestrations is really nice because now we can create very synchronous, kind of more robust, complex processes, right? So I'm super excited to see how that evolves as customers start to connect more things to JD Edwards, because I really don't think it's something that a lot of the customer base has started using yet. But I think once they do it, it'll be tremendously beneficial, right?
So yeah, you talked about how complex some of these things can be. What happens if there's maybe too many orchestrations that hit JD Edwards at once? Yeah, you know, that's a real consideration. So you know, whatever I'm helping a customer way of kind of going through their integration journey or their API journey, they kind of go all go through similar like evolutionary stages, right? So when you're first starting to dip your toes into API, you're always talking about point to point kind of API like 1 to one API integrations, right?
As you mature and you evolve your API strategy and your integration strategy, you start to take into factors like heavy volume, stress, scalability, right? Those kinds of things all matter. So then you want to take into consideration things like load balancing, things like API gateways or API management, right? Because you know, you a, you don't want to explore, you don't want to expose JD Edwards to like an external system that's outside of your firewall, right?
So there's a lot of considerations that go into that and, and to be honest, that tends to become more of an architectural question than it does an integration question because it has less to do with like there's a factor of how you integrate that matters, but mostly it matters on how you architect the whole ecosystem of integrations you have in your IT tech stack, right? So this is where like middlewares and Esvs. So it's like service buses and, and, and I've passed tools and all those things start to get in API gateways, right?
So there's a whole architectural strategy that you want to talk about and you want to consider once you're starting to like really get serious about doing a lot of third party integrations with APIs and orchestrations, right? Because you know, you you have to worry about session management, you have to worry about load balancing, you have to worry about token refreshing, right? There's all these things that that kind of go into it and it starts to become a more of an architectural question, right?
Yeah. And specifically about those session pool, like managing the session pools and even the load balancing. Are there best practices that you would say that some of these companies shouldn't do? Or is it just figure it out yourself type situation? You know, you definitely don't have to figure it out. You know, and I, I'm not an architectural expert, right? So like my expertise is definitely in the building of the integration and stuff like that.
But you know, like we have amazing CNCS and amazing network admins on our team who who kind of help customers through that. And you know, from what I've learned from them and what they've always talked about is right, You want to have, you want to have very like, you know, you want to focus a lot on often authentication, you want to focus a lot on session management, you want to focus a lot on load balancing, right? Ideally the big thing is, is you there's this balance between security and load, right?
So, you know, so you want to make sure that everything's staying secure, you're managing load and none of its compromising performance, right? The last thing you want to do is have an integration that's basically taxing your system so much that it's taking down a production server, right? Nothing that that doesn't happen. It can happen, but typically we'll want to avoid those things from happening by architecting and designing these integrations in ways that, you know, they're not creating zombie kernels, they're not, you know, doing never ending processes or loops or not taxing system resources. They're well distributed. You know, they're, they're more they're performant and they have exception handling kind of built into it. So there's some best practices that you can do in all these just to make sure that like, you know, a like, like I said, you don't, you don't basically cause problems for users in production.
Error Handling Challenges and JD Edwards vs Middleware
Yeah. And it's, it's the little things in that, you know, like obviously we can sit here and say, oh, there's things that you can do in load balancing, session management and that type of stuff. But that's when you have like specific people for that's when you have these specialists for lean into it, ask them, 'cause they'll tell you what to do if you do not know. And that's the main every, every environment's different, right? Like, you know, so you really want to make sure that you're doing this for your environment, right? Like if you're a Azure shop that uses, you know, Delbuni as your middleware or or Informatica as your service bus or right, like your, and then you have AC, like AC. So that has these kind of architectural requirements or security requirements, right? All of those things are going to play a factor into this, right? If you have specific security requirements round certificates, if you have specific security requirements around kind of how long someone's allowed to authenticate for right? And there's, there's so many factors that go into this that honestly, even if, if, if this is like, you know, if a customer even asked me this, usually my next solution is like, hey, let's get you in front of an expert and let's get you talking to them. And let's have you describe how you run your, your infrastructure stack and, and then have them give you a recommendation on what really works. Right. So, yeah, every situation is a little bit unique here.
Yeah, of course. I mean, every environment's very different. And that's the main thing to understand in this situation where it will always change depending on the situation, depending on the environment. And as long as you know that and as long as you have the right people in the room that will figure out figure it out for you, it's going to be fun. Now to switch topics a little bit. What makes more of a air handling in real time JD Edwards integrations so tricky.
So I would say, you know, the the main thing that makes it air, you know, air handling in in real time integrations tricky is that there are just are so many scenarios sometimes, right? Like there's just so many errors and exceptions that can happen. So when you're going through it, you try to make sure that you program for and account for as many errors and, and, and exceptions as you possibly can. But inevitably you're going to come across a scenario that you miss like it's just bound to happen. Nobody, you know, no human being can can predict everything unless you're like the integration Nostradamus, right? You know, honestly, that's kind of a cool nickname. That's why I'm going to start referring to myself as the integration Nostradamus.
But, but like, you know, like, so you're not going to be able to predict everything, but you do want to try to predict for like the basic things like, OK, you know, if, hey, what if somebody forgets to pass a blank date and you know, somebody passes a blank value into this, right? So, and, and to be honest, like even we weren't super great about testing and, and for every exception scenario. But what we've done in the past year is start to build out a function where when we're building an integration, we kind of have our unit testing go through basically every crazy scenario you can imagine. Like what if an entire chunk of the Jason array just went missing? Like what would happen to the integration, right? Would it just blow up or would it fail in the middle and send an e-mail to somebody? Right. Like, you know, those are all valid questions.
So we try to do a lot of that stuff now as we're building things and, and you have to build that resiliency into the integrations, right? Like I said, you're always going to find something that you missed, which is OK, that happens, right? You know, but the, the real key is trying to make sure you account for as much as you possibly can beforehand and, and building the exception handling kind of loudly. Yeah, exactly. And that's also a way that you can prevent like silent errors, you know, is if you get in front of it and you attach alerts, I'm sure to that side of it. I mean, it's, it's those type of things that, yeah, the blanks that you have in there, yes, that's a simple example, but it is probably one of the biggest things that people have happened. So as long as you have the alerts that are attached to that or one of those things in JD Edwards that will actually show it to you should be fun.
But what's the difference between like the handling the errors inside JD Edwards versus maybe an external middleware type situation. So, you know, both are going to have some similar capabilities that like, hey, you know, they can both like e-mail you and and things like that. Where handling these inside of JD Edwards was really, you know, really neat prospect is that you can actually auto correct some data based on your exception handling, right. So I think a feature that's probably not used as much, but it could, it shouldn't be, right, is more is kind of what you do when you encounter an error that's a corrective action, right?
So a lot of times when you think about error handling and exception handling, we think a lot about notifying somebody, right? It's kind of like, hey, you know, you run, you get into trouble if something bad happens, you call an adult, right? You know, but as your systems are getting smarter, we need to kind of teach them how to fix things on their own, right? So for example, maybe if a system is getting sent in and you know the, the, the customer number is missing, right? Maybe rather than sending it the, the, the, you may be just stopping, right? Maybe you write that data somewhere, you still notify somebody. But then if there's any accompanying documents or any place else for the customer number, could be, you can teach the orchestration, go look up that customer number, right?
For example, a item number is nothing or an item number is, you know, like, like for example, your, your vendor sends you a dare item number or instead of yours or yours instead of theirs, whatever you need, right? You can go look up that data inside of JD Edwards and correct it. The score goes good. The other thing so, so I think one of those things is that's really the benefit of doing exception handling inside of JD Edwards is that you have the opportunity to reference JDE to like fix some of these things. But, you know, that's not to say you can't do exceptional handling in your middleware.
You may still need to because you might have exceptions that happen at the middleware layer that that, that, that occurred before they even get to JD Edwards. Right. But in general, when when we're talking about exceptional handling in U1, we, we want to focus on both notifying somebody, but also seeing if we can correct that in some way.
Data Freshness, Master Data Sync, and Real-World Failures
Yeah, yeah. Having those alerts, having a dashboard where you can see all these things. I mean, it's, it sounds simple, but sometimes it's just not something that a lot of customers even think about or you know, so like in programming, we have something called a try catch exception, right? So, you know, so like sometimes we just want to try and see if we can catch an exception and then if there is something, see if we can fix it and then try it again, right? And it may still be an error, right? It may still be an error. But at least if we know that, hey, our, our of all of our errors, this isn't the 40% most common, This isn't 30%, it's a 20%, right? Can I at least build some try catch logic to account for those 40 to 20% of exceptions and then see if I can fix correct something and reprocess it. And then maybe I'm not going to eliminate 100% of my errors, right. But at least I'm going to eliminate maybe 15 to 20 to 30% of my errors. And that's 30% less than you were dealing with yesterday. So, you know, it's I think it's a win.
Yeah, Honestly, when you said that you flashed me back to college. So I'd like to move on actually. So what is like the data freshness? Like why is that a, why is that a hidden challenge in integrations and what's the business impact of even like stale data from JD Edwards? So yeah, like that's a, that's a really good question and I think there's layers to it. So just to make sure I don't rant, I'm, I'm going to, you know, to, to think about it a little bit, 'cause like data freshness inside of JD Edwards is, is silly how important it is, right?
If your data is old. But JD Edwards is an interconnected system, right? Like everything, the left, what the left hand does impacts what the right hand does, right? You know, and if you have data that's still upstream, now everything downstream is stale, right? So one of the examples I love to use is if you have a planning parameter, an MRP wrong for one dependent of an item, that can actually throw off your planning for almost for, for for hundreds of other items depending on how it's used, right? So, so there the, the impacts of stale data are very pervasive inside of the system.
If you have inventory that's in the wrong location, right and you have sales orders and work orders and all the stuff that's committing to that location and you try to go pick that inventory and it's not there, well, you've just wasted tons of man hours. You've caused late customer orders, right? It's it's, you know, you want to make sure you have data that's as fresh as possible. And one of the areas specifically in terms of integrations where people just absolutely overlook how they can make data more fresh is integrating their data, their master data between their third party systems and JDMS, right?
So for example, if you have customers coming in from Salesforce, you can now real time sync them with JD Edwards. If you have Salesforce in JD Edwards and you're on 9 dot 2.7 plus, why are you not real time syncing customer information between JD Edwards and Salesforce? You update a customer in JD Edwards, it syncs to Salesforce right away. You update a customer in Salesforce, it syncs to JD Edwards right away. That's a reality in today's world and we don't have to live like this anymore. Like nobody's forcing us to live like this besides our own limitations.
So like I said, I'm going to rant about this because I think it's really important. But data freshness. So data synchronization between enterprise grade systems like ERPCRMSHRISS, all these different systems, you can make this all real time now. You don't have to make it so a flat file comes once a week and it gets dropped into a folder. And if Jeff from IT is not awake at 2:00 in the morning, that folder doesn't run that file into JD Edwards. And all of a sudden payroll is delayed tomorrow, Right. Like we don't have to live in this world anymore because now we can sync master data real time and keep our data fresh between our systems.
Yeah. And it's it's weird that you say specifically 2:00 AM and payroll there. Are there any specific examples where outdated data cause serious downstream issues? Oh yeah, yeah, yeah. I mean you talk about, I mean we've countless examples of customers where EDI data is, is set up incorrect. Or if you have customer cross reference data that's set up incorrect. Or if you have pricing data that's set up infractory, we have customer master data that's set up incorrect, where now all of a sudden all these prices are wrong, these orders are wrong, emails have been sent to the wrong place, right. You know, the the events are the impacts are pervasive, right. So we have, I have lots of examples in my career, those where every Judy Edwards practitioner does in their career of where steel outdated, not maintained master data has bit you in the bump.
Yeah, we love to we love to sit and have drinks and tell war stories about this stuff. You know, it's, it's fun, but it's probably every Judy Edwards consultant's favorite thing to do. Yeah, it's it's something we talked about on this podcast a lot, too. It's a lot of clean data, a lot of fresh data. Like, it's, it seems so simple. It truly does, especially in this day and age. Like fresh data is something that we all use. Like, oh, with your cell phone these days, you see fresh data every single time you open that it's.
Yeah, it's weird. It's weird. It's like, you know, it's like if I put a reel up on Instagram, you can see that same reel in Facebook real time. Like that's what I'm talking about. Like that's the world you can live in with JD Edwards where like you update a customer's credit, credit limit and now it's updated in Salesforce right away. Not an hour from now, not two hours from now, not at 2:00 AM tonight, right then, right, Nick, you update, you hit OK, it's already in Salesforce by the time you go log in and refresh your page in Salesforce. Like that's the golden standard and we should all be aiming for it.
Yeah, exactly. And hell, we're all used to it these days anyway. So why are we settling for anything less? Why are we doing it?
Balancing Freshness with Performance and Designing for Scale
Why are we doing it? But how do you balance that like freshness with maybe even performance or these like, like in the reporting world, so or even the in the integrations. You know, my DNCS would probably hate me for this answer, but I have to give it is buy get more resources. You know, I'm just kidding, don't you don't always have to do that is number one typing.
I think balancing performance first of all comes with is masterful design. That's really my philosophy, right? There's this, like, there's just a class of people who are like, oh, I'm going to write this really complicated, very bloated, big integration, so I can show off a screenshot with 45 steps, right? And, you know, and, and I feel really good about it and, and, and I just look at that and that freaks me out because I'm just like, wow, that thing is going to break at some point and I'm going to have no idea how to troubleshoot that, right?
So for me, I think, like for me, performance, the first step of performance comes from design, right? So your design has to be simple, it has to be elegant, and your design itself has to come with performance and scalability in mind. And what I just described is honestly super hard to do right. This is not easy, right? Like, you know, if you, if, if you really have mastered something, you, you know how to make it simple. And, and the thing with integrations is that you want to make them as simple as possible, especially if they're real time synchronization integrations, because you don't want to create a lot of load, right?
You could have things going back and forth. Like we have a customer that's thinking data between Salesforce and JD Edwards. And you could, you could have people, you could have 30 people updating customers kind of at the same time, really, right. So you think about it, that's a lot of load going back and forth between these AP is that are constantly talking back and forth to each other.
So you want to make sure that they're very, very simple, right? You don't need to put extra things in there. You don't need to put a lot of extra capabilities in there and where you can offload workload where you can kind of offload some some workloads onto other work streams inside of JD Edwards, right? So like if you can park some data and then run at UB asynchronously, because you don't really need to run it synchronously, go ahead and do that. If you can leverage a business function or an ER because you're going to get a little bit more performance out of it, do that.
If you can leverage a logic extension, logic extensions are amazing for performance. They've actually been very, very performant in my opinion. Leverage a lot of logic inside of your logic extension. You don't need to put like 17 if rules in your orchestration. You can just build a logic extension that kind of does that and then gets the data where it needs to be right.
So it's good the, the, the, the, the heavy lifting is contained in one step rather than many steps, right. There's, there's like these different tips and tricks that we learn and honestly, you know, a lot of consultants will say like, Oh yeah, it was, I've, I've always known this. And, and to be honest, we haven't, we learned a lot of that through getting our teeth kicked in, right?
Like we'll build an integration for a customer and be like, yeah, this is going to be great. And then we, we start the UAT and then we send 2000 orders in at the same time and we're like, Oh my God, that's going to break in that same spot we just realized, right? And then we'll go fix it.
So even us as integration developers, we get our, we get our stuff rocked all the time with integration. So we learned this from the school of Hard Knocks, right? Like we, we learned this by building integrations, not by talking about them only, right?
So what I'll say to you is the best thing to do is how to make an integration performance is build an iteration of it, has the ever living daylights out of it. Just slam it. Just slam every possible scenario. Thousands of orders, hundreds of people trying to use it at the same time, Just slam every scenario, See where it breaks and then make a second iteration of it. That's more that's that's more performant, right.
Orchestrations are meant to be iterative. There was a whole philosophy behind them. So iterate.
Yeah. And honestly, that sounded just like, just like a teacher of mine. Just test it, test it, test it. If it breaks, fix it. Like that's, that's how you can really do something and make it better for the next time. Yeah. Yeah, exactly. And that's, that's a real way to learn. I mean, that's the, and that's a real way of doing it, which is fantastic there.
Orchestration Timeouts, Why They Happen, and How to Avoid Them
But talking about orchestration timeouts, they're obviously one of the most frustrating integration issues. Why do they happen and how can teams really avoid them? You know, generally if an orchestration is timing out, something's gone wrong, right? So first of all, again, I would say it starts with design. We spend, when we're talking about orchestrations, we spend a lot of time in design. I think sometimes it may confuse customers a little bit of how much time we spend in design. But part of that, it's because of how we've learned how to build integrations, at least how I've learned how to build them, is that the design really matters, right?
Because you can build and iterate quickly, but the design, if you don't design something well, like it takes a lot, you know, you're, you're, it doesn't perform as you need to, right? So I think, I think, you know, time managing timeouts really starts with design. The second thing about managing timeouts is to make sure that you're not creating any sort of never ending loops inside your orchestration that like, hey, doesn't just hold like 3 orchestration layers deep. And then it's just kind of stuck somewhere, right? You know, sort of like server performance issues.
You're never, you're not going to have a timeout really. You know, you, you may have a timeout with the servers, like AIS is not responding or something like that. But you, you know, you want to make sure that now, now there are some realistic, there's some real timeout scenarios, right? So we don't talk about these as much, but sometimes JD Edwards takes a minute to do something, right? Like let's say you got to do you have to run the UBE and that UBE is going to take a while to run, right? That's where the statefulness of orchestration comes in, right?
So I can have an orchestration that's maintaining state and it's kind of hanging out while things are happening. That means that I'm my, my, my consuming system doesn't really have to hang out. It can just send us to Asian finished reply request. My orchestration can kick something off. It can maintain state, it can wait, it can wait until things are done. And then, you know, after a while it can then send a response back to the requesting system and saying, Hey, what you wanted is done, right?
It's still technically, you know, you know it, it's still technically a two stage connection, right? But the JD Edwards process is synchronous, right? And this is really helpful for things where it just takes a while and other systems really don't want to hog up their resources to really be waiting on JD Edwards, right? Like, like if you have something like a Salesforce or if you have a Shopify or something like that, they're not going to wait around like because they have their cloud based system.
So they have very strict governor limits on how long you can have a timeout because you know, you don't want you, you're in a cloud with lots of other customers. You don't want to be hanging up resources, right. So you know, for them, they're, they're going to have a native built in timeout, right? I think like 240 seconds sometimes, you know, it's like somewhere between 5 to 10 minutes, whatever their native timeout is.
So if, if you're, if you know that there's chances that you're going to go past their native timeout, make your work estration state full and therefore you can still kind of control how everything is working. Yeah, yeah. I mean, you always making a stateful is definitely the right way to go in this is is there any other way that you would say like here's a different fix, like maybe breaking them into smaller orchestrations or setting retry policies or even using queues for heavy workloads? Andrew Yeah.
Andrew Yeah. So I mean, all of those are great examples. Cues are another really great example, right, with orchestrations, because there are, you can do cues and orchestrations, you know, and run them on specific cues, right? You know, there's also other methods of, you know, sometimes breaking things up and sometimes there is these methods of this truly making things asynchronous, right? Like we'll just just really break it up into two steps, right? It doesn't always need to be in one step.
You know, I, I might contradict myself, but real time is amazing and I loved it. But sometimes it's OK to just have a bulkified or batch integration, right. So, you know, I, I think there's, there's lots of creative ways where you can design around it, but it's really going to depend on what ultimately the requirements of the customer are and what the requirements of, you know, you know, what the other systems can kind of accommodate, right? Yeah.
Best Practices for Reliable Real-Time JD Edwards Integrations
So let's put this episode all together. You know what, like if you had JD Edwards team out there right now, what were, what would be 3 best practices that would make the real time integrations reliable? You know, I would say #1 you know, try to make sure that you have good monitoring kind of built around everything, right? You know, like whether you're using the orchestrator monitor or if you're going through some sort of a, a, a middleware tool and you use their monitoring.
We have some customers that actually write JD Edwards AIS data to, you know, even like Power BI. If you use our scan ability tool or starting our scan ability tool, if you use our Clarity tool, you can get a lot of insights from that. So, you know, monitoring everything is really good, you know, trying to make sure you're building things with good retry and error handling capabilities, right? So we just built an integration for a customer where, you know, we have an order that doesn't sync with Salesforce.
So we, we retry it at least three times, right? So it'll, it'll kind of keep a counter, it'll try, try, try. And then if it still doesn't work, it'll, it'll, it'll let someone know that retry count is also a, a, a configurable feature, right? So you know, so you know, the other thing really is to know when to kind of use what. Don't try to fit a square peg into a round hole, right? Like if, if real time is amazing.
I love real time integrations. As you can tell, I'm very passionate about them. But sometimes if a batch integration is fine and it will get the job done, you can do a batch integration, right. Knowing when to use what is better than always doing one method or the other, because you know, that's how you, you kind of make sure that you're, you're using the right tool for the job, right?
And number, you know, the last one I would say is spend a good amount of time in designing them, right? Talk about design, build a couple iterations. And, and when I see design, I don't just mean like, do it only on paper, right? I mean, like build it like design A version, build a version, design a second version, build a second version. Like just get it out on paper, build it bare bones, build a skeleton of it, right?
Design as you like, build as you design too, because that itself will teach you how to make things a little bit better. And when honestly, like one of the things I love to do is phone a friend. So like if you've got a friend, a buddy or someone you know or someone a trusted advisor on, you know, orchestration building, call up and send the orchestration.
Like, so one of the things I love to do, even though I lead our, our consulting practice, is still building the orchestrations with my developers. And I. It's, it's one of my favorite things is when a developer on my team calls me and says, MO, can you take a look at my orchestration? And we're walking through it. And, you know, I think, I think just going through that process of talking through the orchestration with me helps them design it, you know, two or three times better than if they were just trying to do it on their own.
Right. So, yeah, someone, a friend if you need help, yeah, sometimes talking to even talking with people that don't know what's going on and trying to explain it to them like they're five years old. It makes it simple. It's it's weird like that. It really is. And I think one more that you might have forgotten here. Test the living **** out of it. Tell you straight, you know, test it, test it, test it, test it. Kick, kick it every which way you possibly can.
Yeah, kick the fast, but you know, if real time, if JDE real time integrations aren't as reliable as you like, ERP Suites can help. From orchestration design to integration health checks, we make sure your JDE environment runs smoothly. We were talking about phone a friend earlier, Phone Mo or visit erpsuites.com to learn more. And you can even find Mo and his team on there and you can connect with them.
It's the integration, Nostradamus style. Oh, the intro to the integration, That's Odomous. I forgot. My bad. We'll, we'll change that on our about us page so you guys aren't confused. But that's a wrap for today's episode of Not Your Grandpa's JD Edwards. Remember, real time integrations aren't just about speed. They're about reliability. Subscribe, leave a review, leave a like, share it with your team. But until next time, integrate smart, not just fast. Thank you.
Video Strategist at ERP Suites
Topics: