Energize Your Enterprise - Centralized Connectivity with the Business Connector Suite
Ignition Community Live58 min video / 60 minute read
Data isn't meant to shelter in place; come see practical examples of how Ignition and the Sepasoft Business Connector Suite can break down data silos across the enterprise and supercharge your business.
Travis: Hello, everybody and welcome to today's Ignition Community Live. My name is Travis Cox, and I'm with Inductive Automation. We're really excited here about today's Community Live. We have a really great topic and a great speaker. So today, we're talking about how to energize your enterprise, looking at centralizing connectivity with the Business Connector suites. And these are modules that plug in right into the Ignition platform, that allow you to do so much with connecting the enterprise together. We're really excited here to have Joe Dolivo with us. So Joe Dolivo is the Principal of Digital Transformation at 4IR Solutions. He has been doing enterprise integration for the last 10 years, and has a lot of experience solving customer pain points using Ignition. And we're excited for him to present on today's subject.
So my name is Travis Cox. I'm the Co-Director of Sales Engineering for Inductive Automation. I'll be serving as the moderator here, and kinda just interjecting some comments here and there. And as well as if there's any questions I'll be interjecting those questions. So again, without any further ado, I'm gonna let Joe here take over. And welcome everybody to today's session.
Joe: Excellent. Well, thanks a lot, Travis, for the introduction. As Travis said, I'm really excited to be meeting with you all today, and I think we have a topic that is really exciting. I'm gonna try to make it interesting for a wide variety of people. And so I've kind of broken this down into three different sections. First of all, I wanted to really highlight the Business Connector Suite that Travis alluded to, and the power that it really brings to the Ignition platform and some of the new solutions it enables that have been previously either impossible or difficult to do in requiring things like scripting or other middleware.
I wanna walk you through a simple process for making enterprise integration projects successful. This is really a way of encapsulating a lot of the lessons learned that I've had, having done this for a very long time using Ignition, and just some things, more on the business side as well as the technical side, to think about when you're doing one of these projects. And then finally, I actually want to get into the weeds a little bit and show you an actual demonstration of a scenario that you may have in your own company, where you've got a whole bunch of different systems that you want to connect together with a business goal in mind. So in this case, I'll be connecting Ignition with an actual SAP instance. And then some web services that are basically emulating which you might have from a computerized maintenance management system or a human resources management system. So I think it's a pretty cool demo, so definitely stick around for that. I'm happy to share with you some of the resources that I've built for this demo with you after the call.
So without further ado I'll kind of dive in. For those of you who may not have heard of the Business Connector before, it's a module from Sepasoft and the goal is pretty simple. It's connecting Ignition to business systems. It plugs right into the Ignition platform just like all the other modules that you're used to. And particularly if you're using some of the other MES functions, it actually integrates very, very nicely with those, but they're not a requirement. It works in a standalone way unless you connect the core Ignition platform to other systems. The core of the interface is really this drag-and-drop mapping tool which lets you develop your business logic. You can transform data from one form to another, you can map data between Ignition and other systems. You can do straight-across mapping, you can do things like use a little bit of scripting in kind of an expression language to maybe do some transformations. Maybe you wanna do some padding to fields or you wanna do data-type conversions. But it's a very intuitive drag-and-drop notion that's really meant to be like what the rest of the Ignition platform enables as far as kind of a visual tool.
And then, instead of doing all of the scripting that you might have done in the past for these kind of things, you're basically building your business logic in an intuitive flowchart, which might be something that you've seen if you're putting together documentation or you're whiteboarding or you're doing a PowerPoint presentation or something like that. And the nice thing about this is that it tends to be self-documenting. So once you understand what the actual blocks are doing, you can basically look at one of these charts and have a pretty good idea of the intent of what it is. So it makes it a lot easier for somebody who may not be a programmer or who may not want to actually go through and remember their program from three months ago, to figure out what exactly is going on.
And then on top of that there's kind of an add-on module for the Business Connector, which is called the Interface for SAP ERP. And this one sits on top of the Business Connector and it provides native connectivity to the SAP family of ERP systems. Specifically, it provides a number of templates that basically account for common data exchange scenarios that again, we've seen in having done this for a very long time. These are the examples right now that are included with the products. We're working on a couple of more based on some early feedback that we've had from some customers. But things like doing your production orders and your process orders, communicating inventory movements across your facility, downloading materials and then being able to display those on tables and such, which I'll show you in a little bit.
And the nice thing about it is that it really exposes to you all the functionality that SAP makes available to you. So we have the templates that basically account for a lot of these common scenarios. But SAP systems come with tens of thousands of functions, and we wanna expose all those to you. And that's really what the module enables you to do. And because it's built on the Business Connector, the Business Connector is required to use the Interface for SAP ERP Module. But it's also not the only connector that you can use with the Business Connector. Just highlighting some of the benefits here. You do your initial account setup and then otherwise all the configuration, all the charts, all the business logic, all the mapping, all happens within the Ignition ecosystem. So you're not having to involve your SAP team. All you need is a user account that is properly licensed and authorized to access the system. Everything else happens within the Ignition system.
We also went through the certification process by SAP's Integration and Certification Center. This is very important. This is basically us going through a process to make sure that the system is reliable, that it can scale up with your future connectivity requirements. It accounts for things like handling international characters or having to have... I think our test was 50 simultaneous connections to SAP and making sure that we're not bringing down the system by doing that, that we're doing it in a best practices way. So we have the certification. And that's a big value-add for the module and for the platform.
And then I already talked about some of these ways but it really is integrated into Ignition. So the goal is to not have you have to learn a whole set of other skills to do these types of things. So drag and drop is a core principle of the UI. You have tag binding so you can access the entire tech model from within the tool. And then there is scripting available if you wanna do something a little bit outside of the box of what's included in the core functionality. But that scripting is able to be kind of scoped to just where you need it. You do have the full Ignition API to do that. So for example, there's not a block right now, natively, for supporting named queries. That's something we're working on. But in the meantime you can do it via scripting very, very easily just like you would within any of your Vision or your Perspective windows. And then this is an optional highlight but it is nice if you're using some of the other MES modules from Sepasoft, as part of Platform 3, which is, it's been released in some form right now and there's other modules that are kind of coming very soon. You get automatic synchronization of MES objects across your enterprise.
So if you have multiple Ignition systems, they're set up as a part of an enterprise and the Gateway Network, you can basically pull down production schedules, you can pull down materials and then automatically the platform will synchronize those across your multiple servers, and only to the systems that require it. So previously, you would have to do some difficult scripting, you might have to use some message passing. If you're doing it at the database level, you might have to do some database replication or some other kind of synchronization strategy, that's all handled for you automatically by the platform. So, especially with some of the projects I've done in the past where we're having multiple systems, talking to maybe one SAP system through a common gateway, it really, really nicely simplifies the architecture. And then, as I mentioned there's not only the SAP Connector to work with the Business Connector, you can also use the Web Services Module which is a really nice tool for exposing connectivity to any system that has either a REST or a SOAP endpoint.
And a lot of systems, especially a lot of the newer systems, the more cloud-based systems, they all tend to provide these. And the example I'll show you today actually works through connecting to a couple of these. So that's kind of the first step. I wanted to talk you through what does this actually look like? And I wanna, again kind of speak to some of the practical things that I've done in the past, and there's really a five-step process to doing this successfully. And I'll highlight these and show you some of the questions that we tend to ask with this. But at a high level, it's identifying your business goals. You're not gonna be connecting systems and trying to get permission from your IT team without having some kind of a goal in mind. So you wanna identify those business goals; what are you really trying to achieve? Then you wanna make sure that it's actually feasible before you invest a whole lot of time into it. So in some cases that's gonna be making sure: Does my system have a way of me getting data out of it? Or do I have to go ahead and build something and is that gonna be cost-prohibitive to do? Then you wanna map out your data flows. So figuring out where is your data, where is it coming from, what does it need to look like? And then you map your specific inputs and outputs within a data flow.
So that's considering more of the details of what that integration looks like. And then of course you wanna do testing, not everything's gonna work the first time out of the box. You might be working with data from a system that you're not familiar with and there might be some special considerations for that data so there has to be a lot of testing, especially when you're talking about something that interfaces with an enterprise system or production system that's really critical to keeping you up and running. So, let's dive into a couple of these. So, business goals; what are you trying to achieve? And not only what are you trying to achieve but do you have the right level of sponsorship from your organization for this? A lot of these different projects, especially if you're having to talk to a system like SAP, you're gonna need somebody from IT. You're gonna need somebody from operations, maybe an executive to basically approve you getting access to maybe financial data that you can correlate with your production KPIs. Maybe you wanna be able to get some of the human resources data to understand your employee shifts and you wanna incorporate that to some of the reports that you're showing, certification levels. That's part of what I'll show you in the example today.
Those are things where you wanna make sure that the people in your organization who have to approve these kinds of things are aware of these and will sponsor you to get the access that you need. And then feasibility, this is again figuring out where does the data reside? Do I have a way of getting that data? Does the system expose it through maybe some kind of a web service, maybe through a database that I can access, maybe through OPC-UA, maybe through some other protocol that I can use a device driver for? Who needs to be involved to provide this access? Is it a simple matter of somebody needs to open a couple of ports in a firewall or do we actually have to have some other middleware involved to get that? Do I have this maybe five-step approval process where I have to have a business justification and talk about ROI before somebody's gonna open up one of these ports, what does that process look like? And then of course, especially this is true, certainly on the production floor and it's definitely true at the enterprise level, is being aware of any risks that may happen.
So any time I open up a port, any time I expose access to a system, there's always risks with doing that. Maybe you're allowing access to a system to an individual who previously wouldn't have had that level of access. Maybe you're worried about having too many systems hitting the same points, and you're worried about creating downtime or creating bottlenecks in your network, those are things to be aware of and making sure that you're considering and that your whole sponsoring parties are aware of when you're actually going through one of these projects. Then you wanna define the data flows. So for everything that you wanna do, you wanna map out the process from beginning to end. The Business Connector actually is a really nice way of doing this and we've started out some projects including the demo that I'll show you, where I basically just put blocks down on a chart to show you what that process looks like before we get into the details. And it's a nice way of documenting what that looks like. And normally, when we're thinking about something we wanna do, we're always thinking about the happy path, we're thinking about, in a best case scenario, what is this gonna look like? How is this gonna work? But it's also important to think about error cases. What if I don't have connectivity to the system I'm trying to talk to? Or what if I get data back and it's a format that I don't expect?
What if I lose connectivity to a system on my production floor that is a critical interlocks part of my process, what happens then? Or what happens if there's a mistake in my chart or the user does something I'm not expecting? How do I handle those kind of cases? And then if I'm aggregating data together from multiple systems, there has to be a common link to that data, a common identifier, like a foreign key in a database, for example. How do I make sure that when a certain piece of equipment is called at one system is the same thing that's called in another system? Or if I'm accessing user data, do I have a single source of truth for identity provider or authentication, like an LDAP server Windows Active Directory, or do I have a username, or do I have some other kind of name that I have to kinda link between these different fields? And then what's the trigger event for this data? Is it a tag in a PLC? Is it another system that wants to be able to trigger something in my system? Is it some kind of a condition or an event or an alarm that I'm gonna be monitoring? So these are all things to think about when you're defining your data flows. Then the most detailed step here is really where you're mapping the inputs and outputs.
So we've kind of been looking at a high level, okay, am I able to connect to the system? What does that flow, that functional flow need to look like? Now we have to get specific. What is the format, the nature of the data that my system is expecting me to pass in? How is it going to be returned to me? Is the format of that data going to differ depending on if my case was successful or if my case was an error?
Thinking about: Is my data being passed as a string? SAP, for example, tends to like working with strings. Ignition has a very robust set of data types that it exposes. So do I have to do conversions between dates, for example from a date time to a string? What does that need to look like from a formatting perspective? Do I have to have a certain number of characters? SAP again likes to be zero padded or space padded, depending on some of the configurations. So what does that all need to look like? The Business Connector, in particular, has a nice tool with the expression function to let you do some of these conversions right within the mappings, which I'll be able to show you. But what are the other things you have to think about when you're doing these mappings? And then finally, testing. So you're gonna get data that you expect that's especially following that happy path case, and then you're also gonna get data that you don't expect. So how do you handle that?
And especially when a user is involved, you've got a screen that an operator's using or you have a screen that a manager is using to pull down some reports, how do you make sure that you're handling errors gracefully? Are you showing an error message on the screen? Are you logging something to do with the database? Are you tying in with an existing notification system, like email or SMS notifications, maybe alarming? How do you make that look not too scary to the user, and also help them figure out what needs to be either fixed or to report it to somebody else who can take a look at that? So I wanted to talk you through a scenario of what this might look like in the real world, and I'm gonna go through an example. I'm gonna show you the actual configuration within Ignition. These are the only screens, I promise you that are basically all text, but I wanted to highlight a couple of things in here to set up a scenario. It's a bit contrived but it's also very realistic and it's very representative of the types of things that I've been doing in my career using Ignition and other systems, and also that a lot of customers that we have are also looking to do.
So I'll talk you through this at a high level. We have a manufacturer who is using a PLC with an Ignition front end for controlling their production process. And they've been running production for a very long time and they have a quality team who does inspections. And during a routine inspection, they discovered a problem with a batch of product. They reported that issue to their operations team, who was then tasked with doing a detailed investigation to figure out what went wrong. Now we have to do a recall of this product. What was the actual problem? And in doing this, they found two problems. One of those was that a major piece of equipment within a work center where they do their work, was overdue for scheduled maintenance, and it was used improperly in production, which especially in certain industries, that's a very big no, no. And they also noticed that the operator who was running the process had not been trained to use the equipment, and they probably weren't aware of some of the restrictions on scheduled maintenance, for example.
So these were two issues that they brought up and then the next question was, okay, how can we go and fix this? What can I do from an operations standpoint to go in and actually correct this? So a little bit of background about what this company has. They have an on-premise corporate network, and I'll show you an architecture diagram to visualize this in a little bit. They have an SAP system, and that's where they manage their production schedules, and then also within this network, they have a Human Resources Management System or an HRM System, and that's where they maintain all the training records of staff, especially ones that can operate equipment, so that includes their operations folks.
Then in addition to that, they have this other system, it's hosted in the cloud and it's a CMMS System. And this is where they manage their maintenance work orders, they manage the status of their production equipment. So that's this other system, it's not part of their network, it's out there in the cloud, and this is some of the data that they'd wanna pull together. And so, ultimately, their goal is to add interlocks to the process to make sure that the operator, A, has up-to-date certification before they're allowed to work on equipment; and B, that the work center itself is actually in service before it's allowed to be used. And then if neither of those is the case, they wanna essentially log the attempt and make note of it so that they have a record when they go back to look at what happens, "Oh, okay, I see the operator shouldn't have been using this." Or, "The equipment shouldn't have been in service," to kind of troubleshoot some of these and also prevent them from happening in the future.
So this is kind of what this looks like. They have this SAP version of, note, it's SAP ECC 6.0 or maybe you've heard it described as SAP ERP. I did wanna highlight that the Business Connector and the Interface for SAP ERP natively support connectivity to SAP ECC 6.0, which is the most ubiquitous platform. The newer one is SAP S/4HANA and it is also compatible with. There's also a cloud hosted version of SAP which is a little bit different, it has a different API. We can also connect to that. That's just done through web services. In any case, this customer is using SAP 6.0. Their HRM Software we did it. This is kind of the initial feasibility study that we did. They have a RESTful endpoint, and they return XML documents and then the CMMS System, the cloud hosted one, has RESTful endpoints that return JSON, which a lot of the more modern platforms work with.
So we have all these different systems, we got our Ignition server sitting in the middle, the next step is to figure out: How can we actually do this connectivity, and Ignition is a really, really good platform for doing this? So the PLC, we can talk to via OPC UA and the driver modules. The database, we can use SQL Bridge for doing that, and then the core business logic for actually executing these flows, can be executed using the Business Connector. And then to talk to SAP, we have the Interface for SAP ERP Module, and then for the Enterprise Connectivity for the HRM and CMMS Systems, we can use the Web Services Module for both of those. So this is our High-Level Dataflow, what is it that we're trying to do? We wanna get a list of production orders from SAP. Then when an operator selects that order, we wanna have them get a list of the operations, the individual operations that have to be executed as a part of that production order, including the assigned work center.
So a production order isn't typically made at a single station, that's gonna be made at a number of stations, and that at each station, there's a different operation that you have to execute to build that. Then we wanna talk to the CMMS System and figure out, okay, for the work center for the operation, I'll show you what this looks like visually in a little bit, but for that work center what's the status of it, is it actually in service? It's not we wanna log that it's not and we wanna make sure that production is not allowed. Next we wanna actually look at the logged in user from Ignition. So who's the operator that's trying to actually execute an operation at this station? We're gonna query the HRM tool to get all the certifications for the user who's currently logged in. And then we're going to check if they have an active certification for the work center that we're trying to execute on, and if not, we're gonna log it again and we're gonna disallow production.
So that's the overall process. We can break this down into a couple of individual transactions for talking to these different systems, and I'll show you those. Here's the first one, this is for getting the production orders. So this is mapping the individual data flow, and this is again where it's important to figure out what's the trigger event for this flow, what are the inputs that are expected, what are the outputs that are expected? And if I were to tell you that the E-block stands for exception and the angle bracket block right next to it stands for script, at a high level, I could actually walk you through what this does without even showing you the mappings, which we'll get to in a little bit. But essentially, I am making a call to SAP, to get a list of orders, and then if there's an exception, I'm catching that exception and I'm logging it. If there's not exception, then I'm done and I have the information that I'm looking for. So the trigger event for this is going to be an operator button press. So we wanna have a screen, we want the operator to basically hit a button, and that's gonna get a list of all the orders that meet some criteria.
The trigger event in your case might be, "You know what, every 24 hours at 2:00 AM, local time, we're gonna pull down a list of all the orders for the next day," that's something that you might see. In this case, we wanna make it manual so we can actually show you that transaction happening. You're gonna have a number of inputs. So what are the production orders that I actually wanna get? Do I wanna limit that based on maybe the plants that I'm at, or limited based on only orders that are scheduled for the next week, so I can only work ahead as far as a week? And then the output of this is going to be my list of production orders. The next one looks very similar, but it's a little bit more detailed. Now, when we select one of those orders, we basically want to pull down a list of operations that are associated with that order. So here the input is only a single production order, and the output is a list of operations. And then the air condition here is the same. So if there's an exception, we wanna be able to catch that and log that, if not, we're gonna continue on our merry way. And then there's a third one, so this is the most detailed one. But it's really not all that more complicated, and I'll talk through some of what these other blocks do.
But this is where we're doing our production checks, so we're going to get the status of the work center, we're gonna get the certifications for the user who's logged in. And I'll walk you what this looks like. And when I started to build this, I actually just started dragging these blocks onto the chart and mapping them together, and then before I had to worry about any of the specific mapping, I was able to walk through what is this actually gonna look like? Before I start to do all my detailed mapping and figure out my data types, what does this process actually need to look like from top to bottom? And so I'll talk you through this at the same high level that I went through in deciding this. So first we've got a REST ... Let me get my mouse over here. So we've got a REST call to get the work center status. So we're gonna be talking to the CMMS system. If there's an exception, we wanna capture that, we wanna log it. If there's no exception, this D here is basically a decision block, so this is like the Diamond you would see in a regular flow chart. And we're going to check the status of the work center.
And if it is in-service, then we're gonna follow our true path, so we're gonna continue on. If it's not, then again, we're gonna be able to log in air and we're gonna exit. So if it is the case that the work center is in status, then we're in-service, then we wanna get the certifications for the user who's currently logged in. And again if there's an exception, we wanna log that, we wanna end the chart. If there's not an exception, this I here is an iterated block, and this basically lets me do loops. So I'm gonna get a list of all these different certifications for the currently logged in user, I'm gonna iterate through those one by one, and then each time I have this decision block, and I'm gonna check is the certification that I found the active certification for the work so that I'm looking for. And if it is, I'm going to log that and allow production and end my chart. And if I've gone through all of these and at no point did I ever find one that matches, then I'm gonna log that, I don't have an active certification, and I'm not gonna allow production to continue.
So that's a lot of information. I think this will make sense when I show you some of the visualizations, but I just wanted to show you at a very high level, I was able to map out this somewhat complex business logic that's talking to multiple different systems and they're facing with a PLC and a database without having to go through the details of how that actually works. The last thing on this slide I'll just highlight what are the actual events in here? We've got the trigger event that's gonna be the operator pressing a button to say, "Hey, I wanna start my production run." The inputs are gonna be the work center ID. This is gonna come from SAP, within a table that we populated, and I'm gonna get the login user from Ignition. And then my output is gonna be as production allowed. And then there's gonna be some side effects of log into a database, but that's really what this chart is doing. Enough talk. Let me actually show you this. I've got a system up here and running, and this is where I have my actual charts in place. If you haven't seen much about Ignition or maybe you haven't seen the business connection before, what you get is this new node here within your project browser for the business connector.
And then in here I could basically have a folder structure for mapping my different business logic and I have these three different charts. And these three different charts are exactly what I showed you within the presentation. I'm gonna walk you through a simple one of this, and then I'll actually show you the UI that we built to let you go ahead and execute this. So here within my chart, you see I've got this pallet, this is very similar to the component pallet that you might have in a Vision or Perspective window, and I can basically click-and-drag these blocks on to here. I can rearrange these. I have this night's grid layout. And right off the bat, I have a start block. And the start block is how you manage data that's going to be exchanged into and out of your business logic chart. So these are basically my parameters, and you can see here I can denote these as an input or an output.
So in this case, I basically have ... This is an array of orders that I wanna get back, and there's certain information that I care about for that order. I have an ID, I have the product that we're actually gonna be creating, I have the quantity and then I have the unit of measurement for that. And then I have a starting order. So what I'm actually gonna query SAP for my list of orders, again, what's the range of orders that I wanna get, what are the criteria that I wanna pull down. Then I have this block that actually is going to go out there and talk to SAP. And what the Interface for SAP ERP provides is this list of remote enabled function modules and BAPIs, and these are all organized based on the type of object that I want to interact with. So for example, if I say I want a material then I get this nice list of BAPIs, which are just like function calls into SAP of everything I can do that's associated with a BAPI, like getting details about one deleting one, editing one. And then when I select one, all the metadata from how I actually call that function is pulled into the system, and I'm able to map into and out of it.
So for orders for example, we already know what my input parameter is. I can drag down here and show you my... Let me do it from this way. My starting order, and basically what I'm doing here is very simple, I am mapping in the order that I'm passing in, as a parameter to the chart, and I'm mapping it into this low value, within this table for order number range, so this is giving me the range of parameters that I wanna set. And that's on the input side, but on the output side, I basically have this orders parameter that I showed you, and now I'm mapping into this parameter. So I'm looking at all the header information that comes back from SAP, this is letting me basically map quantities from a source to a destination. So what I'm saying is, for every item that comes in, and so for every order that I'm getting, I wanna instantiate a new array elements of orders, and then I'm gonna map my individual fields. So in this case, I care about order number, which is I'm calling order ID, a products, a quantity, a unit of measurement.
And that's how I'm getting data into and out of SAP. And then I've got this block for capturing an exception. If there is an exception, this is just a simple example where I'm essentially logging what happens. I said I have an exception when calling a BAPI, and then otherwise, I'm just gonna end my chart. And that's all that's there.
Let me go ahead and show you what this actually looks like. So this is a UI, and this is something that you might have within your system, and this is built within Perspective, so I can shrink this down like a mobile device. This works very, very well. All the components resize, and this is where I'm able to go get a list of my production orders. So if I click get production orders, this button is going to clear my list, I'm going out to an actual SAP system, and I'm pulling down a whole bunch of production orders that meet some criteria. And you can see here these are the fields that I was describing. So we've got my order ID, we've got the products, we've got the quantity, you got the unit of measurement. What's really nice about Ignition is that it provides this really nice table component where I can go in here and I can choose how many of these do I wanna display on a single page? I could navigate through these very quickly. If I wanna go to a particular page, I can go ahead and do that.
There we go, and then I can navigate forward and backward through my entire list. So that's the first chart that I showed you. The next chart is where I'm actually gonna click on one of these orders, and then I'm going to go out and query the individual work centers that are associated with operations that I might execute when trying to run that order.
Travis: We have a couple of questions that have come in for the settings relevant, if you go back to that particular chart in the designer, the original one you were just on. One of the questions was in terms of the BAPIs to SAP. Does every SAP instance have those kind of BAPIs or is that to be custom? What kind of work is there if you will, on the SAP side, to be able to use this?
Joe: Yeah, that's a great question. So SAP, ECC systems, all going all the way back to R-3 including SAPS for Ohana are especially pre-populated with a list of BAPIs and remote enabled function modules. So, every system comes with them. A lot of customers will actually tweak those, or have custom versions of those where they wanna maybe change the functionality a little bit, but essentially, you get all of those out-of-the-box. And the list that you saw there, if I go back to navigate to this, this list is not hard coded, this is actually us querying your particular SAP system, and pulling down all the available functionality that's exposed. So, whatever your system provides, we're essentially able to make available to you. The other thing that I think is worth highlighting is that you can also go ahead and instantiate these templates, which I did show you as an example. So for purposes of this, to simplify these, I basically built these from scratch. However, you're also able to go in and leverage some of these existing chart templates, and then you get a lot of this best practice functionality that's already built in.
So in theory, I can instantiate one of these, if my system is pretty close to an out-of-the-box SAP installation or I haven't changed anything specifically related to, in this case, stock movements, for goods movements, I could basically use this as is and get up and running very, very, very quickly. But the flexibility and the availability functions available to you is essentially what your SAP system provides.
Travis: Perfect, that's a great question. The second one that came in was in terms of mapping that to, from SAP to the object. The question is: Can you create any kind of object? And are there some standard ones that we could use as starting points, if we don't have a good idea?
Joe: Yeah, so a great question. So here basically the information that you pass into and out of SAP, is exposed in what we call parameters. And so, in some cases, we have something like an order ID which is an out-of-the-box simple parameter. This one is pretty self-explanatory. You also have these other types of parameters. The example I showed you, with operations, is fully custom. So here, I wanted to define what this looks like. This is a complex objects with an array of other complex objects that have integers and strings, but we also have this B2MML category, and this one is particularly relevant if you are doing interactions with MES, but this is standard, this is nothing proprietary from Ignition or Sepasoft, but these are typical. Forms of data that you may wanna exchange between business systems, so it's things like production capabilities, work alerts, physical assets, equipment itself, operation schedules.
And so you basically get this predefined schema that you can map into and out of without you having to create that yourself. So those are kind of the ones that are bundled with it. And then if you are doing MES integration, there's also a schema for Work Order, so some of them were MES specific things. So you can either build something yourself, you can either use a simple type, so String, Integer, Double, Date, or you can leverage some of these objects that are based on ISA-95 object models to map to MES specific objects. So also a great question.
Travis: Perfect, alright. Thanks Joe.
Joe: Thanks Travis. So jumping back here, the first flow I showed you, is when you click this button to get the production orders. The next flow that I showed you is executed when you click on one of these different operations. So in this case, there's no work center, so that's not very interesting. I'll see if I can find another interesting one in here, otherwise, the example I'm gonna show you for pulling down the operations is just essentially gonna be the one at the end. Looks like these are all the same products, so maybe that's why we're not getting anything more interesting.
Okay. So in any case, the one that we're gonna be showing you is essentially this first one, this is all sample data, by the way, from our sample SAP system. Oh, there you go, here's an example where we have... These are all the same work center, but there's a number of different operations, and then this is the description. I'm gonna go back to our first order, where I have these four different operations. So if I wanna make this product, I've got 10, 20, 30, 40, I have a pre-assembly stage, an assembly stage, an operation test and then a packaging stage. And each of these occurs at a different work center. I have SH01, 02, 03 and 04. And I'll show you because I'm behind the scenes, but essentially, when I click on one of these operations and I'm an operator, I'm going to click this start production button. And I'm gonna get the message back here that is also being logged. So in this case it says, "Error. Work center SH01 is not in service." So that was, again, one of our requirements to starting. Now, I'm gonna try the second operation, and this one says, "User Joe," Who I'm logged in as, "Does not have an access certification for work center SH02." If I try operation 3, I get an okay. If I try operation 4, I get an okay as well.
So that's what the application looks like from the user perspective. Now, I wanna go in and show you some of the actual mappings that make all of this stuff happen. So I showed you the first chart already, that was the production orders chart. The operations chart works very, very simple or very, very similarly, where the input is this order ID. So I'm passing in a single order that I wanna get details about. And then on the output, I am basically getting a list of all my operations, and just like you saw on the table, I have my operation number, I have my description and I have my work center. So the most interesting one is this execute production checks, and this one is really showing the power of the business connector. Because again, I'm talking to multiple different systems within the same chart. And if I wanted to, if it made sense for my business logic, I could actually also use these SAP blocks in the exact same chart as well, so I can have all my logic encapsulated in the same place.
I also get some other nice tools here on the side that let me better organize my system. So let's say that I'm building something complex, and I actually have some reusable logic that I wanna build and use in multiple places. I actually had this enclosed chart function, where I can actually call a different chart that's been defined elsewhere. And using the parameters, I can map data into and out of that chart, just like I would if I were calling any other function. So it's a really nice way of kind of composing your code and keeping it maintainable and reusable throughout your entire enterprise system.
So to get the status, here's my input side, I have a work center, so the actual work center itself, I'm just pulling from the table, so I'm basically looking at the selected row in the table, I'm getting the work center ID, and I'm passing this into the query string for my CMMS web service. And if we got some time I can show you what this looks like. But basically, I've created a web service within Ignition. I pointed it at the CMMS system that I wanna talk to, and then I've mapped my parameters. And one of the things you might notice is that, in general with REST systems, there isn't really a well-defined standard for passing data, for structuring data that gets passed into and out of a web service. There's things like OData which try to provide some structure to what that interface might look like, but it's different than SOAP, which has WSDLs, which basically tell you, "These are the specific types, these are the specific web service operations that I can access." So it's a little bit more free-form.
So one of the nice things about what the Web Service Module provides for you is what I'm defining a configuration, like here's a CMMS system, I can actually paste in data that I'm getting from calling the web service, and then I will build up this structure of data. So this is what I was just mapping into. I have my work center with my status ID and last updated fields, and let me actually go ahead and call this. When I call this, you can see this is basically the result of calling that web service directly. And then, when I hit okay, it actually will populate this field right here. And what's notable about that is that once I have this structure basically figured out from kind of reverse engineering the data, then I can actually use it within the business connector as a mapping target.
So if you've done web service scripting before, that's actually a pretty neat thing that we no longer have to manually figure out, "Okay, what is this structure?" And I have to parse it out of this JSON object or in this case an XML object that's returned. I'm actually able to just map to it like I would any step redefined structure. So pretty cool. This looks pretty simple, I'm passing in an ID. And then the output side, I am basically returning this work center status, and I'm using this underscore here to just... It's kind of a convention to say that this is an internal parameter, I don't need to pass anything into this from the chart or press anything out of it. If you look at where I've defined these, I essentially have my user which is my input, I have my work center which is my input, and then I have a return value. And then I had these two intermediate values that I'm using to keep track of data within the context of a chart, and then I'm able to pass from one call to another. So I've got a work center status and then I've got my complex certifications. And in this case, I'll show you the mapping for this, but basically I have this array of certifications, this certification has an equipment that it's associated with and that it has an active status.
So that was this. I talked through, again, ‘what does this exception look like?’ This is a very simple way that I can use scripts to basically set particular parameter values. So in this case, I'm saying if I get an exception, I want to return a status of error and then I have a message with a little bit more detail, so it's basically telling me that, "Hey, this chart errored out. The reason for it was because my CMMS system caused an exception." If there's no exception, but in this case, we actually wanna do some kind of a check. And so, this is my decision block. I'm able to reference other parameters that I've defined in the chart. I'm able to directly map to fields within some of the BAPI blocks, so in this case, I could directly reference anything else return from network center call. In this case, I'm just checking if the parameter that I set, that I mapped from making this call is equal to in service. And if it's not, I know that my work center is not in service and I'm gonna return that as an error message and end my chart. If it is, next, I'm gonna actually go get the certifications for the user and I'll kind of continue my logic.
So here, this was very similar. Now I'm talking to my HRM system, and I wanna get information about a particular user, so I'm gonna pass in my user parameter, but I pass into the chart. On the output side, I'm gonna get that list of certifications that I showed you. We're here, I've got my equipment that I'm mapping over. Now, this one's interesting. As we mentioned, the format of data in different systems is not always gonna be the same. So in this case, my HRM system actually shows for each certification that's gonna say, "When was that user last certified?" And my company has a policy that you have to be re-certified every single year. So the check that we're doing here, you could see this little Fx. This is basically a function. So I'm mapping in this field, but I'm not using the field just as is, like I am for equipment. I'm actually doing a little bit of a transformation on that data, that's encapsulated here in this mapping. So if I go to the edit function, I'm basically doing something very simple. This is just using the standard Ignition API. I'm returning active if the years between the parameter that I pass in, this last certified parameter, and the time right now is less than one.
So if it's less than a year, I'm considered my certification is active. If it's more than a year, then it's considered inactive. So that's a really nice way to encapsulate that transformation right here within the chart. They'll do the same thing where I'm capturing an exception. If my system was down, I wasn't able to connect to it, something went wrong, I'm gonna basically log that HRM caused an exception. If not, well, now I've got this complex array of all these different certifications, and I'm gonna go through and check one by one what is the actual status of this. So one thing I jumped over here, this is the iteration block, so this is where I'm basically looking at an array. In this case, I have this array of certifications, I'm gonna take out one of those certifications, and I'm gonna pass it to this next block. So here, I'm checking if the equipment that's associated with the certification for that user equals the work center that I care about, and I'm gonna check if the status of that certification is set to active.
So I have this nice little way of not only visually choosing some of these parameters and some of these action values from the blocks, but I have these operators I can select. And then I have these conditional expressions I can build up with parentheses, kind of like I'm using the Ignition expression language, so I'm checking two conditions within a single block. And if both these conditions are true, then I'm gonna exit through my true block. And in this case, I'm going to set the parameters. So I'm gonna return a status of okay, and I'm gonna say that the user has an active certification for that work center and my chart is gonna end. Otherwise, if I've looped through all these and I get back to the beginning, well, then I'm just gonna log that there was an error and the user does not have an active certification. So that's basically the core of the logic, and that's how I was able to encapsulate all of this into a single chart. The last thing I wanted to highlight here is to show you, well, how does this actually get called? And to do that, I'll go back to my window here, and I'll show you the configuration for this view.
Here we go. So this is my production order view that is loading right now, and these are all the different components that I was looking at. If I go ahead and make sure I'm in design view, and I go to the button, Ignition lets me add events to essentially event handlers for things that might do that interact with one of these visual objects. So in this case, I have a script that I'm calling. And the actual interface into the business connector chart is actually very simple. There's a single call here, which is a system.mes.bc.executechart.synchronize. And I'm passing in the path to a chart. So in this case it's just webinars/ in this case I'm doing the get production orders one. Then I have an object of input parameters. So here I'm passing in the starting order, and then what do I care about from that chart, what do I wanna return? Which in this case is that list of orders. And I'm saving that to this results array.
And then all I'm doing here for this particular example, if you remember, I was clicking on this button, and then I was populating this table. I'm just setting the data elements of this orders table to be the order element that I've kind of indexed out of this service full result set, but really, this is kind of doing some preparation of the data and clearing it out, but it's really a single call to execute that chart. And what's really nice about this is that I have ultimate flexibility as to how I trigger these charts. So like I said, I could have it as simple as a button press on a screen, I can use gateway scripts, timer script, so I can have it run at the same time every single day. I can set up a web service endpoint, so that another system can basically trigger me, and when that happens, I can go and execute a chart that way. So basically I could also do it as a tag change event. So I could have a tag within my system, and when that tag as high, I treat that as a trigger to executing this chart.
So, as opposed to some other tools that have standalone scheduling components that are somewhat limited, we essentially have all the power of Ignition to be able to trigger these. And the only thing I realized I didn't actually show you is when I was clicking this start production, I do have this trigger value, which is basically my permissive for starting production. And I'll just go ahead and show you that, if I try to choose one of these options, actually I have to be using my logged in window here. But if I try to choose one of these options, and I'm not allowed to, you'll notice that my trigger just went to zero. So basically, it's disallowing production. And if I go ahead and click one, that's okay, my trigger goes back to one.
So that's especially what I wanted to show you. If I jump back here quickly to my slides, I just wanted to go through kind of a quick summary of some of the things that we talked about. Business Connector itself is a really powerful tool set, it's visual, it's used for mapping data in a very intuitive way between Ignition and business systems. Again, the suite itself is comprised of the core Business Connector, there's the Interface for SAP ERP add-on module, as well as the Web Services add-on module. When you're doing these projects, make sure that you identify business goals and determine feasibility upfront. You don't wanna start down this path of developing something and then you realize, "Oh, I can't actually talk to the system, 'cause it doesn't expose its endpoint." Or, "There's no way that my IT admin is gonna let me talk to the system because it's out in the cloud and they don't wanna set up firewall rules to do it."
And make sure that you test it as well. And also test for cases that aren't the happy path but things that you might anticipate to go wrong. I just want to show you how, with proper planning these charts really could help you simplify these multi-system workflows that could be complex, and get actionable data that you can actually use to make key decisions to improve your business in a very intuitive visual and quick to put together way. So that's it from me, I'm Joe from Fora Solutions, please feel free to reach out with any questions. And I'm happy to send over some of the example material here that I showed you, if you wanna use it in your own projects or just wanna talk about enterprise integration in general, I'm happy to help. And happy to answer any questions that may have come in Travis.
Travis: Alright, yeah, so there's a couple of questions. Thank you Joe so much for all of that, those are some awesome demos of the possibilities with these modules. So, one question that came in is about the amount of work that this could save, versus a traditional way of going about setting up scripting and the mappings and all that. So, I know Joe, you've had a lot of experience with that kinda thing. So do you have any sort of statistics or numbers that show how much time savings and what kinda ROI can get out of using something like this?
Joe: Yeah. So I actually have a couple of examples I can speak to and some are just from me personally, what I've kind of developed over the years, and some have come from actual customers who have been using this. So in doing this on top of Ignition for a very long time, before we had these modules available, I was basically developing scripting libraries that would handle some of this stuff for you. So we had scripting libraries for talking to SAP, we had scripting libraries for talking to other web services. And what this ended up amounting to was basically a couple of thousand lines of script for doing the communication, doing all these transformations, and then mapping it into a format that I could use within my Ignition windows. When the Business Connector came out, we threw all that out, because literally the feature set of the connector improves upon, and it's just a lot easier to manage than having this scripting libraries that you're having to go through. So thousands of lines of code from my own experience. We've also worked with a couple of customers who have said very similar, they've had very similar results, where they were doing a lot of this in script and they had... I think one customer said they had 3000 lines of script that they were able to throw out and just move that all into Business Connector charts.
In some cases, well, there's one customer particularly who had a very specific workflow that they wanted, and they still had to do some scripting in those scripting blocks, but they said that when I show this to anybody else in my team, it's so much easier for them to understand because all the script is just in this little block and the rest of the workflow is all much more intuitive. They can look at the block, it's self-documenting and they can understand what's going on. So, even if there still is scripting that you're using, it's all encapsulated into a much smaller part of your system. So that's been a really, really powerful message, and I think if you actually factor in the time savings from not having to not only develop but also maintain those scripts, the training involved with having somebody to have a deep knowledge of the scripting language, the training time to get set up with something like this is much, much, shorter.
Travis: Yeah, absolutely. Another question here is; you showed the connectivity SAP, you showed some web services there. Are there plans for additional direct connectors to other ERP systems, for example, JD Edwards?
Joe: Yes. So we are basically documenting right now requests from customers who have other systems that they wanna connect to. The one we've actually heard the most of is Microsoft Dynamics, Dynamics NAV, which has actually been rebranded now, but they still have the same interface. So we're basically looking for input from you guys to understand what are the connectors that you're looking for, and we have a list that Sepasoft and myself are maintaining of those requests. We do wanna build more and it will just tie into the Business Connector the same way that the SAP module does. So definitely reach out, let us know what you're interested in and we'll factor that into the plans for sure.
Travis: Okay. So another question here is. He says I'm pretty savvy with the Module SDK, is there any ability to extend the Business Connector myself with any custom nodes that I can stick in there or blocks? Excuse me.
Joe: Yeah, that's a good question, I'll actually have to get to talk to Sepasoft about the logistics of that. I don't know that those hooks have been made publicly accessible, so to speak. I do know that we're interested in talking with other companies who might have some expertise in a particular ERP system that they maybe wanna build a connector for, so I don't know that that's been publicly documented, but it's an interesting idea and definitely something we could talk about.
Travis: Okay, perfect, perfect. The other question here is, I saw you had a couple of templates specifically for SAP, are there any templates that are available for other systems that have REST or SOAP interfaces that are gonna be bundled with the system?
Joe: Great question. So right now the Business Connector itself doesn't come with any templates that basically provides those different blocks, unless you create anything that you want to. One of the value adds of the SAP Interface for SAP ERP specifically is that it is bundled with those templates, and so our plan is when we do talk to other systems, and it might be something like Microsoft Dynamics which actually uses REST under the hood for doing the communication, but it has a lot of specific workflows to do that. Those are things we'd be looking to bundle in with another connector. So if we did Microsoft Dynamics, it might be using REST under the hood, but she'll get all those templates as a part of that module. The problem is is there's a huge wide variety of those systems for us to develop against.
So we figured, "Well, we'll give you the tools and the building blocks, we'll build a specific module for a system that... " SAP ERP is the most ubiquitous ERP system in the world. So we'll start with that one and then based on requests we can build other modules. And part of the process of building those modules is actually, probably, one of the more important parts of building those modules is building out those template use cases. So again I'd love to hear any feedback you have on systems and as well as specific use cases within those systems. We focused on a lot of the production module and the material stuff within SAP, but you might wanna do preventative maintenance you might wanna do deeper warehouse management integration, you might wanna do some of that HR management that I showcased. 'Cause SAP also has those functions. So let us know what you're interested in for sure.
Travis: Good, good, good, perfect. So the question here is, I assume that you can import/export these charts from one system to another?
Joe: Yeah, absolutely. You can export and import charts and as well as the actual connector, the set up for web services or for the SAP system, you can export and import them. And they're included when you do a gateway back up and all of that.
Travis: Well, perfect, so I'll put a plug in there. We're talking about these templates with SAP, you have bundled in with there, but there are probably lots of others that will come about. And we do have a beautiful resource called Ignition Exchange. And I would encourage all of you guys, if you haven't seen that resource, go take a look at it. We're really putting a lot of work and effort into getting the community at large, to create resources and publish things that they've built. Of course, you don't wanna give away any secret sauce. There's a lot of little things, like a template for how to connect to this system or that system, that would be really useful to export and to put up in the Exchange and share publicly, so that we can all benefit from that and potentially add on to it, make it better as you go forward. It's one of those things where it'd be really nice if you could just go to a resource and start with an abundant amount of things that you can then bring in and customize to fit your needs. So I'll put that plug in there. I think it's really gonna be powerful. And hopefully Joe, we'll see a lot of stuff up there.
Joe: Absolutely, it's a really good point, Travis. And yeah, if you guys are making your own things or there's a system that you have that you wanna be able to share with others, then the Ignition Exchange is a great resource for doing that, absolutely.
Travis: There was one I think that's a pretty good question here. We focus a lot on ERP and with this or there's a least a lot of focus for ERP with Business Connector. But he says, "I have a CMMS system, and I believe that there's a REST interface with that, and I don't have any MES. Would it be possible for me to use this connector to connect it to the CMMS, and just to bring data in and show it on screens at Ignition, get information about machines and their maintenance and all that's coming up?"
Joe: Absolutely, yeah. So the example that I showed, even though I spoke about some of the MES modules that are available, the stuff that I showed in the demo actually did not use any of the MES modules. So that was talking to a CMMS system, we were just pulling it down into parameters and showing it out at just core standard Ignition tables. And what's it's in a table or a data set you can do whatever you want with it. So, absolutely. We tend to talk about ERP systems, but there's a lot of other systems out there. We've done integrations with LIM systems, with BAS systems. There's really no limits on the type of system you can connect, as long as you can get the data into Ignition, then you can work with it.
Travis: And so there was a comment here. So it's the comment I think it's pretty relevant, it's pretty good, I think we'll close on this point: “Joe, is (the) ETL tool on steroids?” I think that's a pretty cool comment.
Joe: That is a great way to phrase it. And I'll just highlight that I've been using other middleware to do this kind of thing, and it's always this other tool you have to maintain, it's typically very complex. So, when Sepasoft developed these modules, it was like a breath of fresh air for us. So totally agreed, if you're used to the more traditional XML-based expat ETL tools, this is a much nicer way of working. So, thanks for the comment.
Travis: Alright. Well, that'll be it for the questions here. So thank you guys very much for joining us here today on the Ignition Community Live. We're doing these very frequently, and so, stay soon for more updates on the content there. But thank you so much Joe for attending here and giving us that amazing demos and content here on the value of these modules, I really appreciate. Any final remarks on your side?
Joe: Just wanted to thank you, Travis, and the whole Ignition community. You guys are great, it's been really great being a part of this. Please reach out with any questions, comments, if you'd like some of the sample code, I look forward to talking with you about enterprise connectivity and hopefully more to come in the future.
Travis: Alright, well, beautiful, thank you very much everybody. Please stay connected to us on social media, subscribe to our newsfeed and our podcast. And again, you'll see a lot more of the Community Live sessions coming up. And have a great rest of the day, and we will see you next time. Thank you.
Joe: Thanks, everybody.