Ignition to ERP: Best Practices and Lessons Learned

Speakers

Parker Jacobs

Director of Development - Enterprise Solutions

Flexware Innovation

Nicholas Miller

Sr. Systems Engineer

Flexware Innovation

Looking to leverage  Ignition to seamlessly connect with Microsoft Dynamics 365 Supply Chain (D365)? This session will cover best practices and lessons learned from two perspectives: an Ignition developer, and an enterprise solutions architect. Flexware Innovation’s Ignition Team and Enterprise Solutions Team work together to merge IT with OT for true digital transformation. From this collaboration emerged a set of best practices (and lessons learned) that will be shared with the Ignition community. Presentation examples will center on D365, but the foundational architecture principles can apply to your ERP system, too.

Transcript:

00:00
Kevin Collins: So, welcome to this session. My name's Kevin Collins. I'm a software engineer at Inductive Automation. I'm gonna be helping moderate this session today. This is "Ignition to ERP: Best Practices and Lessons Learned." So I've got two folks here. Parker Jacobs, he's Director of Development Enterprise Solutions for Flexware Innovation. He's got more than 12 years of experience doing software development, technical consulting, ERP, technical support, integrations, upgrades, the whole works management. He's been involved with many ERP implementations across AX 2009, 2012, and onto Dynamics 365 including upgrades across those systems. So in recent years, he's collaborated with customers, including internally with Flexware's Ignition team to integrate shop floor data with a variety of business systems and ERP systems.

01:00
Kevin Collins: As a technical consultant, Parker delivers solutions with an adherence to best practices and long-term sustainability to customers. But a big part of his team is Nick Miller here. He's Sr Systems Engineer, Flexware Innovation. He's spent the last five years working with Ignition customers on their Digital Transformation journey, a variety of industries: automotive, food & beverage, life science. So working as a systems engineer in Flexware's Ignition team, Nick stood up many world-class applications providing key functionality, SCADA, MES, track and trace, and OEE. He's been actively involved in supporting kind of the collaboration between the groups, the enterprise solutions, and the Ignition innovation team. So, welcome Parker and Nick, and looking forward to a great session.

01:56
Nick Miller: Alrighty. Thank you.

01:57
Kevin Collins: It's all yours.

01:58
Nick Miller: Sure. So again, thank you. So again, we're talking "Ignition to ERP: Best Practices and Lessons Learned." My name's Nick Miller, Sr Systems Engineer with Flexware Innovation and an Ignition developer on the Ignition team.

02:16
Parker Jacobs: And I'm Parker Jacobs. And yeah, I'm within our enterprise solutions team, which we're focused on Microsoft applications. And really my background is all things ERP. And today we're gonna start off with a short video showing a candy factory that we built in-house. We'll talk more about that in a moment. We're also gonna do a brief overview of the ERP and MES software applications. Then we're gonna get into talking about goals of integrating those two. We'll talk about designing those, and then we'll also discuss some scenarios and things that we've done in our implementations, and then we'll wrap it up at the end. So before I start the video, just wanna share, we've done these integrations for customers of ours, where we've built out, where we've integrated MES and ERP, but we also but wanted to put this into a spot where we can now demonstrate it and show it to prospects and others such as this conference. So we've built in-house, a candy factory that actually will go through the process of taking in production orders from an ERP system, putting it down to the MES, and then putting out boxes of candy that you can take with you and you can eat. And we're gonna show you just in this video coming up that process, and show you that seamless... From a user standpoint, it's a seamless process, but behind the scenes, there's many things actually ongoing.

03:40
Video Narrator: This video highlights an integration between ERP and Ignition. We'll demonstrate this top-floor-to-shop-floor integration between Microsoft Dynamics ERP and SparkMES, an Ignition-based solution. Here is our candy factory with a white and blue hopper filled with different types of candy. Our factory is automated with many components that you would recognize from most plant floors. Here we will place an order for candy, and in this case, utilizes a chatbot to capture order information. The customer is ordering half of one type of candy and half of another found in our blue and white hoppers. The order is sent to Microsoft Dynamics, and from there to SparkMES. Here we see the SparkMES interface, which shows the order arriving and tracks the progress in real time. Our candy factory begins to fill the order while SparkMES continues monitoring the status of the order. Here our order completes and SparkMES triggers the conveyor to move the order along the assembly line. A message of order completion is sent from SparkMES to Dynamics to close the loop. Easy integration between ERP and Ignition. Now that's sweet.

05:25
Parker Jacobs: So really what we're showing you in this video is if you do an integration between your MES and your ERP, you can, again, from a user standpoint, it seems like one simple application, but there's many things happening behind the scenes, and we're gonna talk a little bit more about that coming up here in a minute. So we'll go ahead and kick off a, give you a little overview of both MES and ERP.

05:48
Nick Miller: Sure. So we're gonna start the conversation. Just kinda a warm up just talking about the ISA-95 model. This is something that we refer to at Flexware as "Flexware 101." So starting at the supervisory level, Ignition, as we all know, is a SCADA platform. It's a system that's operating on the OT network, connecting to devices on the plant floor devices on the control level, the PLC layer. And generally the control level, we would think is anything in the control cabinet, devices on the OT network. And then that has connectivity to the field. So instrumentation, you know, scales, temperature data barcode reading, that sort of thing. So where our conversation is gonna lie mostly is the MES and ERP layer. So for those of you that don't know, MES system you can think of is any system that's involved in the conversion of raw materials into finished goods and the automation and documentation of that process. And then ERP we call enterprise resource planning. That's the SAPs, the QADs, the D365 of the world. And Parker will get into a little bit more detail about what ERP is all about.

07:10
Parker Jacobs: Yep. So companies that may or may not have an ERP, they, or let me start over. So, ERPs are applications that you'll use to manage different aspects of your business. We've listed off some examples like accounting, inventory, procurement, production, and sales. There's many aspects of a business that can be managed and logged inside of the ERP itself. It's a very useful tool from collecting data from other systems that your enterprise uses. Typically you'll have it integrated with warehouse management systems with, in our case, manufacturing execution systems. But it ends up being a nice central location for all of your organization's data that you can use to plan and report and do your day to day. If you don't have an ERP today and you're looking to get one, some of those reasons behind that could be around just simple resource management, bookkeeping data management and process automation.

08:08
Parker Jacobs: As I mentioned, the, from the data aspect, we can have all the data in one place, makes it simple for reporting, makes it simple to close your books at the end of the year. And then from a planning standpoint, you can use the data to automate your day-to-day processes and tie into these other different systems as well. So we did give some examples on the screen of ERP applications, but they come in many different sizes. There's ERPs out there that are for specific areas in the market. These are three examples of broader or like larger enterprise resource planning applications. And our expertise really is around Dynamics 365. So that's what our conversation today will be, for the main part, focusing on. And just a little bit more about D365. This is Microsoft's cloud-based enterprise resource planning application. It does perform a lot of those functions that we previously mentioned that your business might use from a day-to-day standpoint. One of the benefits of it, and this will be a little bit foreshadowing of our conversation today, it lives in the cloud and has many out-of-the-box connectors to different Azure services, which you can leverage to do integrations to tie into like we showed the bot service earlier. And for us, that's something that we have considered when we go through this journey of integrating ERP with MES. So I hand it to Nick.

09:38
Nick Miller: Sure. So Parker talks some about D365. The MES system that we'll be working with through these integrations is SparkMES. The demo gave a little bit of an introduction of it, but it's a MES system that we developed internally at Flexware. It's built entirely within Ignition. We deliver to the end user the ability to view, edit, and modify views, scripting, database objects, and best for customers that are looking for something flexible, something custom, and really catered to the the citizen developer. So we have a number of different packages for SparkMES, including OEE, track and trace, inventory management, and ERP integration. And then you can see some sample UI screenshots of our OEE module.

10:36
Nick Miller: So next we'll get into just talking through some of the design of our ERP integration. So first thing we wanna address is what might be your desired outcomes of a ERP integration? So the first thing is we want an ERP integration that's able to adapt to our process. So the factory floor is a very dynamic environment. Things don't always go according to plan. So we want an integration that's able to adapt to a changing plan. We also want something that helps us improve our data accuracy and consistency. Minimize the use of manual entry, Excel, user error. We want something that you know... We're maximizing the amount of automated data collection and that sort of thing. So the next thing is we wanna limit the impact of system downtime. So we don't want a system where, say, if there's downtime and ERP for maintenance or that sort of thing, we don't want that to affect our ability to produce product. We don't want that to stop our MES system from being able to function. We still wanna be able to operate as a business. And the last thing is, we want a system that we can continue to iterate upon, something that allows room for growth something that we can continuously improve and develop with our business.

12:00
Parker Jacobs: So let's talk about architecting your integration. One of the first considerations you might wanna think about is where do your ERP and MES applications live? And the example where we're talking about today, we have an on-prem MES application, and then we have a cloud-hosted ERP. And this certainly will factor into decisions around security and how the two systems will talk. We mentioned one of the goals that we have is to limit downtime between the two. So we want our integration to be decoupled, and not only do we want to prevent one system taking the other one offline, if the integration is not running, we also need a way to get back to where we were when the system that's off comes back up. So for us, we are looking to have a way to have maybe a middle layer to maintain the data and pick up the integration where things were previously before.

12:50
Parker Jacobs: Another thing is performance. If you're doing an integration, performance is usually one of the most critical things you're looking to focus in on. And it's true for us as well. We want an integration that is as near or close to real time as possible to not to create any lag or disruption in the user's experience. Another thing is data integrity. And going along that lines, we will have data flows going back and forth that must process in a certain order. And you need to make sure that the integration that you're building follows that sequence in the right steps to prevent any type of errors that might come up from it, any type of manual rework, or worst case scenario, something slips through the cracks and nobody catches it and now you have corrupted data in your production systems. And then lastly, when you're going through this, you need to determine which system will be the system of record for each of your different data flows.

13:47
Parker Jacobs: Another thing is, when you're doing your design, is how do the two systems talk? We've provided some examples of different ways that we've considered to communicate between ERP and MES, but I'll say this is not an exhaustive list. So these examples that we have, such as an external database, API, file transfer protocol, message-based protocol, and, we mentioned, a custom service. These are just some examples that we've thought through and considered for ours. Mainly when you're deciding on which way to do this, you need to be considering certain factors and cost is a very big one. And if you do something completely custom, you're likely to spend a lot of money on the front end, but you may have less costs supporting it and maintaining it long term. While if you do something like a database, there's a good chance that it might be cheaper and easier to implement, however, you're gonna be spending more money potentially every month on licensing and maintaining that database itself. So these are just some examples of factors that you need to be thinking through when you're going through your integration journey.

14:51
Parker Jacobs: So with those considerations in mind, we've come up with a, just a generic solution that's been working for us. And you can see on the right hand side of the screen, there's a process flow that does an outline of the MES and ERP talking to each other. So on the right hand side, you'll see at the very top of the screen it says Dynamics 365. So that's the ERP. We're actually using two different communication channels to communicate back and forth. And D365 is driving communication through what's called an Azure Service Bus queue to send notifications and initiate different integrations down to MES. And then the rest of the integration proceeds with the rest API calls. This accomplishes some of our goals that we mentioned, having a decoupled solution, having a queue-based architecture so that we're processing things in the order that they should be processed.

15:48
Parker Jacobs: I also wanna mention, so the Azure Service Bus queue, this is, again, something that we're leveraging out of the box, out-of-the-box functionality in D365. So there's already a connector in D365 to connect to the Azure Service Bus queue. It's a platform, it's a message-based protocol that we can send lightweight notifications to. So things that might just be simple little messages that provide just enough for the listener to pick up and process. It does use a publish/subscribe model. So you have a publishing application, in our case it's the ERP, and then you'll have listening applications or subscribers that can pick up those messages and do something with it. So we're using that to do the lightweight quick notifications and kicking off the integration. And then we're using rest API to pull down where we need to get more data downloaded and processed.

16:43
Nick Miller: Sure. So Parker talks them about Azure Service Bus queue. Currently Ignition doesn't have any native connectors or drivers for Service Bus queue, so we ended up building a module to handle this. So using the module, you can configure any number of listeners to topics in Service Bus queue. And you can define the top, the listener name, callback function. So the callback function will be a gateway-scoped event handler that you can configure in the designer. And then you process the payload in a Python script. So you'll define a callback function here, define the subscription topic, and then the next couple slides are just kinda showing some UI screenshots of that. So that's... This is a status page and then this here is the configuration page. Again, defining your callback, your connection string, and topic for your listener. So next we're gonna talk through some we kind of introduce to the integration and how we're doing things. So we're gonna take the integration through a few different scenarios and talk through a few integration topics.

18:01
Parker Jacobs: So let's talk about production orders first and just, let's start off what is a production order? And just to keep it very simple, it's something that you can use to track the creation of finished goods. And typically your ERP or MES will be creating and monitoring these production orders, but at a high level, you're just tracking the quantity of what you're producing and then a timeframe for completing the product. And then just to share with you, you'll hear us refer to it as a batch order or a work order, and those can be used interchangeably. So how are production orders handled inside of the ERP? One of the first things is it's going, they're gonna be created either through manual or automated processes. And these processes can stem from things like customer demand, inventory replenishment, tracking, or, sorry, production planning. And these can create production orders through automated processes. Or it could be... So if you have like an influx of customer orders this month, you need more finished goods, the enterprise resource planning application can create those production orders automatically for you and get you new product in the door. And then lastly, the production orders inside of the ERP are tracking things like costs, your inventory levels that are being created from an inventory management standpoint, and then obviously us tracking the completion of those production orders.

19:24
Parker Jacobs: Sure. So in, MES generally we're using the production order to provide a context for our data. So we may be using it for reporting, or using it for dashboarding purposes. And we're interested generally in the genealogy of how the product was produced. So we're wanting to capture what people were involved in the production of the work order, what equipment was the materials passing through, and then what materials were consumed in the production of the work order. So capturing lot codes, actual quantities, and tracing that information back to the suppliers. So, we're gonna go into, on the next slide, we're gonna talk through how we're integrating the work orders. So to help kind of ease and kind of understanding how we're doing that, we have our example scenario that we've received a work order for five dozen cookies. And we have a bill of materials here, and this is the Nestle Toll House cookie recipe, so if anyone's curious.

20:37
Parker Jacobs: All right, so on the screen you'll see a process flow that we've created for this production order process. And on the left hand side are the steps that are taking place inside of Dynamics or your ERP, and on the right hand side are the steps that are taking place in the MES. The production order process is initiating from the ERP. And I wanna point out, there will be some conditions and rules that your company has in place that must be validated or met before you start sending those production orders down. And that's true in our case as well. We're using a very simple status field as our means for determining whether or not a production order should be integrated. But this can change depending on, like I mentioned, your needs or any of our customer's needs that we've worked with.

21:25
Parker Jacobs: So, in Dynamics, there's a status field on the production order itself called, that's just the, tells you what stage that the production order is in. When it's first created, the status is set to "created." But when it's time to be produced and integrated down to the MES, there's a simple trigger that happens, or a button press that happens, to change the status to "released." And this is our mechanism for now sending the production order to the MES. So what happens is, once that status has changed, to release the production order is written out to the Service Bus queue. It's a very lightweight message that just has the production order number and some other very high-level details that the MES needs to then call back and query the rest of the data. And I'll hand it over to Nick to talk more about that.

22:14
Nick Miller: Sure. So, after we receive the order over the service bus queue, we will request from ERP the BOM and routing information. This will happen immediately after we receive the production order released event. And then, we, depending on the integration scenario, we may, immediately begin working on the production order or set the status to production order started. Or we may, depending on what the customer wants, we may, wait on like a user event to start the production order. After the production order started, we'll start working on the production order. And we'll be reporting material consumptions as we process the order. So material consumption would be reporting [that] we consume this quantity of this lot code at this time, and be reporting that to ERP so they can handle inventory and that sort of thing.

23:14
Nick Miller: The next endpoint that we, may hit is this time used endpoint. So, say in the example of batching cookies, at the end of each batch, we may report that the time it took to complete the batch and ERP may be using this information for costing or just as a matter of record. And then after that, we have the step six, we're showing the finished good produced endpoint. So, we would be telling ERP at the end of each batch, hey, we completed, a work order, or completed a batch of the cookies, right? And, ERP would keep record of that. And then finally, after we finish work, we'll report production order ended. And another aside, some customers may, for simplicity, not be reporting material consumptions through this process and instead choose to report at each finished good produced and do like a back flush and subtract ideal quantities instead of the actual quantities. And it could be a way to kind of ease into this order integration.

24:34
Nick Miller: So we talked some about order integration. The next topic we're gonna talk through is routing. So we're not gonna get into too much detail on routing. It can be a pretty big topic, as far as MES, but we're just going to touch on a few details and, and how it pertains to our ERP integration. So, on the previous slide, on step two, we receive BOM and routing information from ERP. This may be typical of what we might receive at that end point: sparse information, just a flat bill of materials, and a listing of what routes or what stations our work order will pass through. So, MES has a big mapping problem to solve here. There's a lot of information and details for MES to fill in. So if we get into the next slide, we can kind of talk through all the context that MES needs to provide to this.

25:33
Nick Miller: So we may have materials that are serialized, some materials that are not serialized. We may have materials that need to be scaled and measured. We're reading over OPC from our PLCs. We may have materials that are hand measures, so things that operators are weighing on a separate scale and then typing in information in the MES. And then on the routing, we may have, we may wanna put work instructions in front of the operators. We may want to fill in the details of what steps need to be completed at which station. And we may have maybe more complicated routing scenarios, alternate routes that we want to do. So there's a lot of detail that MES needs to fill in and gaps that MES needs to fill to perform this ERP integration. So if we look at the next slide, gonna get a sip of water here.

26:40
Nick Miller: So, this is the order execution screen of SparkMES. And this is kind of showing how that looks to the operator. So you can see we have the product code, what batch we're on. And then this is just to clarify, this is something that you'd see at the workstation. So the operator would be working at the workstation, they'd have this in front of them as they work. And they'll have work instructions in front of them. They'll see what step that they're at in the station, what work order they're working on, work instructions in front of them, walking them through how to complete the steps. And at the bottom right, you can see we have some materials that we're capturing serial scans for. We're capturing some data from OPC, some maybe coming from a user input, manual entry.

27:37
Nick Miller: And all along the way, we're gonna be reporting material consumptions to ERP and providing this kind of one user interface that the operator's working with and that's tying the integration back to our ERP system. So, the next topic that we're gonna talk through is inventory management. So the scenario that we talked through previously was somewhat simple. We're only doing writes to ERP. But if we're gonna shift the scenario a little bit and think of a more sophisticated process thinking maybe electronics manufacturing, something where we have large bills of materials with many small parts that are hard to source. We may have work orders that are really highly custom, they're planned on a short time scale. We may be checking what materials are on hand immediately before we start working on a work order, during the processing of the work order, having a lot more read writes happening with our MES.

28:41
Nick Miller: So all this is to say we just have a much larger volume of inventory transactions. And so what issues might we run into as we scale up the volume of inventory transactions that we're wanting to make with ERP? So, what the obvious thing we might run into is performance issues. So, ERP endpoints may hang and take long time to return inventory data to us. So clients hanging MES makes it harder to do our job. We might see accuracy issues related to this. So client A is requesting inventory data and takes time for that to return. And client B snags that before it returns to client A. And the other thing that we might run into is just too tight of coupling. So MES is very much dependent on ERP to be able to run. And as we've said before, that's not something we want. So on the next slide, park will talk through some of our responses to these issues.

29:45
Parker Jacobs: And so for us, one of the approaches that, or things that we see in this case, to resolve the issues is to set up inventory management in both your MES and your ERP. So previously we've really just been managing the inventory inside of our ERP. Now we're maintaining an instance of it in both sides. One of the benefits of this is you'll have the data cache locally inside the MES. It now can do the processing of it, track its own consumption of the data, and it's not necessarily having to make those calls back. We get an improved user experience and we're not waiting on the data, or there's not a lot of processing back and forth, as we're trying to just go through a work order. We have a copy at our disposal. And then there's more granularity of the data.

30:36
Parker Jacobs: So we can, we can, track the details such as, does the item live on a workbench versus is it just in the room? So like the, the, the ERP itself may not necessarily care about all the details of where that product lives and what's being done with it. It just might only care about that we have it in stock, and the MES can then use it and treat it however it wants to. But as you might gather, this still does pose a problem. So we've solved one, but now we created another. And that's creating or keeping the two systems synchronized. And when we have two inventory management systems operating, one of the things that we use to leverage... One of the ways we keep the two together is using what's called an inventory snapshot. And, this is a process that essentially takes a snapshot of the inventory data inside of the ERP at a point in time and syncs it down to the MES.

31:32
Parker Jacobs: So like we saw with the production order, we have a process flow here for inventory snapshots. And it starts on the left hand side inside of the ERP. You'll have a process that goes through and takes a snapshot of the data. Once that snapshot has been created, the ERP will send a notification to the Service Bus and it just contains, again, very simple details like what's the snapshot ID and some other details that might be needed to query back. And then the MES can read the notification, then proceed to pull down the data and process it in. So you might be wondering, "Well, this sounds like a pretty data intensive, could be a pretty heavy process on the system taking a snapshot of all of your inventory data." And in our case, we do have a way to kind of get around that.

32:23
Parker Jacobs: So you'll see in parentheses on step one it says Full / Delta. So one of the ways we've approached reducing that amount of processing time that's involved is to allow the process to create a full snapshot, maybe overnight, after hours, but then from that point forward through the rest of the day, only synchronized inventory that's changed since the previous run. And then you'll also be able to set this up in such a way that you're only sending certain things. You don't necessarily need to send all of your inventory out of the ERP to the MES. But this is the approach that we've taken to keeping the two synchronized and allowing the MES to still have control and be able to work with the data on its own. So we've covered some scenarios and we covered our design. We're gonna move into our wrap up.

33:17
Nick Miller: Sure. So just a quick recap. We walked through a candy factory demo, showing how the integration actually looks and performs, ERP and MES. We went over an overview of what MES and ERP are and how they fit into the factory ecosystem. We talked through some of our integration goals, what outcomes we want out of our ERP integration. We walked through our solution design and how we're integrating ERP and MES with our customers. And then we took that design through a few scenarios, some examples to show how that might work.

34:00
Parker Jacobs: And, just some final thoughts. So if you're looking to start your journey of integrating your ERP and your MES, we gave you some an outline of what we've done, but I'll say you'll still need to go through this process of creating your own goals and laying out what your company needs to accomplish doing an integration between the two. So the goals we've given you might be a good starting point, but that's not going to necessarily fit your needs overall. Another thing is you want to go through a process of mapping your inputs and outputs. So we did do this between or for our the integrations that we've worked with. We've integrated or we've created data maps in Excel showing where the data originates from and where it's going to end up in. This documentation can be done in other mapping tools that you might prefer.

34:49
Parker Jacobs: It's very useful for the implementation team to fall back to if there's issues. It's also something that will be very useful for the team supporting the integration long term. Another thing is communication. So this might seem like common sense, but if you don't have common or frequent communication between your two teams, your project will end up having issues long term. We recommend that you have your MES and your ERP implementation teams talking weekly, if not daily, and make sure they're not working in silos and getting off track. And then obviously you want to keep project team members like your project manager and other stakeholders well informed of the project itself. And, lastly, go through and do your documentation: document your design, document your process flows, document your configurations. We've given you some examples of process flows that we've created. These are good starting points and can help you convey your thoughts to a different audience.

35:50
Parker Jacobs: Configurations, that's another thing that gets people in trouble, but simply documenting how the two systems should talk to each other. You know, what configurations need to be in the ERP and what needs to be set up in the MES. Have these recorded somewhere outside of your system. You don't want a situation where you refresh one of your environments that you're testing in and you lost all of your configurations. And then you also don't want a situation where you are going live. And some ways, somehow, your production ERP system is talking to your non-production MES. So make sure you're capturing this information and, again, it'll be useful for the actual implementation and go live and also supporting the product long term. And, one final note. So we did bring some candy from our candy machine and there'll be some boxes available to you on the way out. And that's it. Any questions?

36:48
Kevin Collins: So we do have some mic runners, so...

36:50
Nick Miller: Oh, okay.

36:53
Kevin Collins: We'll get the mic to you. I do need to probably ask how to query that ERP for the location of the finished product. Those chocolate chip cookies.

37:03
Nick Miller: Oh, yeah.

37:04
Parker Jacobs: Yeah.

37:05
Kevin Collins: Might need to do a...

37:06
Nick Miller: Don't wanna lose track of those. No.

37:09
Parker Jacobs: These are at grandma's house. Yeah.

37:12
Audience Member 1: Where are the cookies? No, my question is, 'cause you've mentioned a few different ERP systems, and did you find that you could have a common interface, or generic interface, that would, actually, the same technique would work with multiple ERP systems?

37:31
Nick Miller: Sure. So We have integrated with, a number of different ERP systems. Yeah, it, we always are just adapting to what the customer's use case is. And if you do decide to go with D365, this is how we do it, but we can adapt to it to different environments.

37:47
Parker Jacobs: I'll say, too, this is our model for integrating, say, MES with Dynamics 365. And the goal is for it to be adaptable for others. But even on projects where we're doing a D365 implementation and an MES implementation, we may have to get away from our own model too, for certain cases. And that's typical of any integration you're building. It's, you're going to have to adapt to certain changes for your customers.

38:14
Kevin Collins: I think we had one back here.

38:15
Audience Member 2: One of the things I've always run into is a customer wants me to integrate the ERP and the MES, but they actually can't talk. Do you find that it's easier to say, "Okay, I need you just to fix your network, or this isn't gonna work," or do you go and you do that custom solution where a file gets transferred through like four different things to get from one to the other? Which route do you usually push your customers to go for.

38:41
Nick Miller: Sure. Yeah. I think it's probably best to just approach it looking for quick wins. So if the file transfer is the only thing that you can make work that's the only thing we can get working for now. But ultimately, yeah, it's I guess it's on the end user to fix their network and make it so we can make it more robust integration.

39:02
Audience Member 3: Quick question. So I see that you build a module, an Ignition module to communicate to Microsoft Dynamics SAP. If you had to talk to an ERP that is SAP, what differently would you have done?

39:17
Nick Miller: Sure. I mean, again, it kind of goes to adapting to different scenarios and what tools the customer's using. We've done integrations with Kafka and things like that. So yeah, just it depends on the scenario. Yep.

39:35
Audience Member 4: So, quick question on the Service Bus. Is that a MQTT protocol or is that a custom by D365? Or they... You said it was pub/sub. I was just kind of curious what their protocol was.

39:46
Parker Jacobs: Yeah, it's pub. So it's something that Microsoft has available as a offering in Azure. So if you can use it to your own, or you can use it for doing your integrations. In our case, we're using it for ours, but you might have other means that you might leverage using the Service Bus, but it's a, yeah, it's a pub/sub tool that Microsoft has made available to the public.

40:13
Audience Member 5: When you're doing the report, it's finished, posting it in AX, are you able to do the flushing principle and the co-products and getting them into relevant locations and all that fun stuff?

40:26
Parker Jacobs: Yeah, there's a lot of details that can go on that we didn't really get into, mainly because it's going to vary by customer. But yes, you can have all of that take place and we can, some of these steps that we outlined, we, Nick mentioned it, you, we can skip. So we gave you like a model, but we may not implement, say, all seven steps of that production process as far as the integration goes. We may just have some of these things happen behind the scenes in each system.

40:51
Audience Member 6: Yeah. How do you deal with phase in and phase out of bill of material products in your raw material tracking, for any of the processes that goes through the both the ERP and the MES side?

41:07
Nick Miller: I didn't catch that. Could you repeat that?

41:10
Parker Jacobs: Like an obsolete, like product miss gonna be.

41:13
Audience Member 6: Yeah. Like in the example of the... For the cookies that you're manufacturing, let's say you run out of your baking soda and you're looking for from company two, right? A second company which is giving you the supply, then how do you track and trace based on what you produced?

41:34
Parker Jacobs: So yeah, our, I don't have a good answer for you on this case as far as the integration goes. It's, I guess it's, this is one of those requirements that will come up we'd have to address during the project.

41:47
Kevin Collins: Are you gonna adapt that module to use Event Streams in [Ignition] 8.3?

41:50
Nick Miller: Yeah. I was hoping no one would ask questions about Event Streams, but yeah, I think it seems like that's, well.

42:00
Kevin Collins: Be a perfect fit. Almost.

42:00
Nick Miller: It would for sure. Yeah.

42:01
Kevin Collins: Any other questions? Everybody's thinking about the chocolate chip cookies. Good news is they got you covered in the back, on the way out. They've got some treats for you. So any final words before we?

42:18
Nick Miller: No, thanks for...

42:18
Parker Jacobs: Thanks for coming.

42:19
Kevin Collins: Yeah. Thank you.