Still using RPG applications on your IBM i? You’re not alone. Many businesses depend on RPG for their daily business processes and report generation.
To be successful, RPG applications often need to create, update, and consume data from spool file reports or databases like SQL Server, Oracle, and MySQL—as well as Microsoft Excel. Too often, this means manual or redundant data entry or re-keying of information.
It doesn’t have to be that way any longer.
Wouldn’t it be nice if your online order database hosted on Windows or Linux could easily update information in your IBM i systems—without extra work from you? Or if you could create an interactive IBM i 5250 application that displays data from an SQL Server query on the same screen as info from your IBM i business database? Or if you could extract data from a report to Excel without re-keying the information?
Explore ways to make it easy to use real-time information from any database, Excel file, or IBM i report.
Watch this webinar to learn how to:
Read and write database records from a SQL Server table instantly
Create an interactive 5250 app that uses live SQL Server data
Use CL commands to import or export Excel data for processing faster
Read and write Excel rows and columns from an RPG program in real-time
Extract data from IBM i spool file reports to formats like Excel and Access
Plus, in a live demonstration, you’ll see just how easily you can enable your end users and RPG developers to incorporate live cross-platform data into their native IBM i applications in mere minutes.
All right. Hello everyone, and welcome to today's webinar. I'm Richard Schoen, coming to you from our worldwide headquarters in Eden Prairie, Minnesota. Today's webinar focus topic is “Stop Re-Keying Data Between IBM i and Other Applications”. Today's 30 minute session will be focused on a common problem, re-keying data between applications. End users spend lots of time keying data between one or more applications. We'll be introducing you to some of our IBMi automation technology to help you streamline your daily work and reduce the re-keying of data between IBM i and your other applications.
As mentioned, I'm Richard Schoen, Director of Document Management Technologies here at HelpSystems, part of the technical solutions group bringing topics like this to our customers and prospective customers. I have over 30 years of background with IBMi, Windows, and Linux platforms software development, system integration, managing and delivering forms and documents and helping customers with automation processes. Also, I have a heavy development background using NET and Java, RPG and just about any other language you can think of.
Our journey today will hopefully provide a good introduction to a couple of our IBMi automation technologies that can be used to prevent data re-keying between applications. First we'll talk about the data dilemma many IBMi users have when working with data from multiple platforms, and we'll talk about three ways to eliminate data entry ... Or data re-keying and how you might put that into practice. After that we'll provide a short technology demo, so you can see how you might improve some of your data entry and extraction processes and then we'll end with a few minutes of questions and answers. So feel free to enter your questions in the question window as we go, and I'll address them towards the end of the webinar today.
We'll also plan to complete our session in about 30 minutes so you'll have plenty of time to make your next important meeting and today's event is being recorded, so you will receive a link after the webinar to share with anyone in the organization who couldn't attend today's session.
All right. So before we continue, I'm going to put up a quick polling question, and we'll leave this up for about 30 seconds, but if you can give me an idea of where you're at in the spectrum of application re-keying and what sort of things you're looking at for automating data between multiple applications. Just check all that apply, and we'll take a few more seconds. There's generally a lot of ways to keep data in place these days and I do a lot of work with customers where they're double keying data or they have people hand keying where they could automate data entry and that sort of stuff as well. So definitely lots of things to think about.
All right. Let's close our poll and so far ... I'll share that. So it looks like the majority of you are looking for reformatting report data into Excel and other data formats so that's definitely something we'll be talking a little bit today so that's cool.
All right, so let's start with a little discussion about the data dilemma that your organizations might be facing. So, getting the right data to the right place at the right time is important and often that means re-keying of data from paper or across one or more business systems. It might also mean copying and pasting of information or performing file transfers or data replication, this usually means lots of time and lots of human intervention. So let's look at this a little more closely.
Data might often come in and arrive in format such as Excel, or CSV, maybe other PC data formats, files might arrive via email or FTP site or other method and then the data gets manually keyed or imported into one or more of your systems then the data might get updated or entered into one or more IBM i, SQL server, Oracle, MySQL or other databases. This type of work screams manual process and there's many opportunities to improve the incoming data processing.
Then we have the need to generate data for vendors and trading partners and customers and employees. So traditionally it's been hard to extract information quickly and easily from the IBMi database for dissemination. So creating spreadsheets from our IBMi database and report information has been difficult. Often data has to get transferred or replicated from the IBMi to another database for use, so what if there was a way to reduce or minimize the effort it takes to transform data from our IBMi to other formats and systems. Fortunately, there is, and you'll learn about that today.
So let's take a look at three ways of potentially streamlining your IBMi data transformation to various formats for meaningful use. In today's world, every company has information that lives on different platforms and in different databases whether it's IBMi, DB2, Oracle, MySQL, PostgREST, or even Excel. We constantly have the need to collect and distribute our information as efficiently as possible without re-keying.
Common problems for our RPG developers are, different platform databases don't talk easily to each other from RPG. There's not an easy way for RPG to talk to those databases in real time. Often data comes in from vendors in CSV and Excel and Microsoft Access and flat file formats, so in our case, RPG to SQL Integrator is our solution to bringing RPG and the other database platforms together to get things done. Think of it as making RPG a client to all these other databases. We'll be demoing some of that technology in a bit.
While data replication can be important for backup and recovery, it's not always a good method for handling real time transactions. So in this RPG to SQL sample scenario, the customer has an eCommerce system running on a Windows server that uses a MySQL database to hold their incoming web orders. Then as the order gets placed, the data needs to be moved to the ERP system for order fulfillment. So when a new order gets entered into the MySQL database a status flag gets set marking the order as new, and then over on the IBMi there's a process running to pick up the inbound orders as they come in and move the information into the IBMi order fulfillment system. Or the user could possibly interactively search the eCommerce database from an RPG application, or a web application as well. There's a few different ways of architecting immediate access to the order data using RPG to SQL without moving the file or the database. We'll be demonstrating some live SQL server data access examples as well.
When an order ships from the fulfillment system, order shipment status can then get updated back to the eCommerce system immediately by directly updating the MySQL database from an RPG application. By using real time data, the process of replicating large chucks of information is removed from the daily web order process, and those workflow processes are much simpler to accomplish.
So the IBMi system can natively query the PC or the server database and if needed update that information on that remote database. So using data in place is a good thing. By using real time data across multiple databases both the ERP system and the eCommerce systems can be updated at the time, which avoids all the cumbersome file transfers and replication or dual system data entry, which I've seen a lot of.
Lots of key business information lives in IBMi spool file reports or PC text files as well. Most IBMi shops that I talk to still generate a good number of spool file driven reports. Often, these reports can't be quickly rewritten to provide data output into a file because they might be vendor provided reports, and many business system vendors don't provide the source code to their programs or their reporting. Or, there's a lot of RPG business logic embedded in the programs that can't be easily turned into a query or an SQL statement. This is why allowing you to interactively log in, download and confer reports for data mining is a great way for them to start using the information in existing reports without waiting for the IT team to write new queries or generate a new RPG report. Being able to quickly download, convert, and then deliver reports as needed is a great way to streamline your users daily workload without re-keying data and performing a lot of copy and paste work. So our solution here is called Deliver Now. So we'll talk a little bit more about that in a moment.
Let's talk about some of the benefits of reporting data automation. When it comes to IBMi application integration to data and other platforms, RPG developers, IT and business teams have not always had it easy. Businesses are always looking for ways to maximize employee productivity, and we've been around for over 20 years helping customers to eliminate data redundancy and replication, reduce time spent massaging data and merging information with IBMi business applications. By allowing your ports and data to be used in real time, the time spent moving data between platforms is greatly reduced or eliminated because that data can be used in the place where it lives.
Stopping the re-keying of data, we already talked about that quite a bit, and reducing the risk of data validation mistakes. Often that data being re-keyed and validated and updated into multiple systems manually can cause errors. So by automating that, and the retrieval of data from one or more data sources using a single RPG application, or an existing report, data no longer needs to be keyed more than once if even at all.
Data can also be validated in one place to ensure information integrity as fields are updated across systems. So another example, an example of having one program update multiple data sources at the same time, might be a company where, let's say they have the poor business system on IBMi and a manufacturing process system on Windows that uses SQL server. So every time the customer record is changed on IBMi the corresponding fields on the Windows manufacturing system can be validated and updated immediately as well. So this keeps two customer master file systems in sync at all times, without having to do replication or dual data entry.
Think about that. We'll see an example, I'm going to show you an example of a sub file today, but it could be a green screen application, or a web based RPG application, but the idea that it can update an IBMi table and synchronize directly to a SQL server in real time with that customer information, that's huge.
Automating the manual processes used to redistribute information. If you're reporting processes live in IBMi or Windows and data needs to be aggregated in one database such as DB2 or SQL server. If you're on the PC each night for processing, your business can reduce the need for specialized business analysts to create PC formatted output in Excel and other formats. If your team has strong PC reporting skills already, you can utilize those skills for report writing. Maybe you have SSRS or you're using Crystal or something like that and you want to use those tool sets for generating reports. If your team writes reports in IBMi using tools like RPG or Query/400 or our SQL or showcase products, take advantage of those skill sets.
Your IBMi team can do your report writing as well. It really depends where you have those team skill sets. You can also eliminate time consuming and cumbersome manual processes for uploading and reformatting Excel data as well, lowering labor costs and streamlining data and reporting. So at the end of the day, products such as [RPG desk fell 00:10:51] and Deliver Now have been created to improve data accuracy while saving significant time for employees so they can focus their time better servicing vendors, customers and employees.
Let's take a short look at how you can use Deliver Now to automate distribution of your IBMi reports and other documents automatically. You might have the need to burst reports or split reports and extract information from those reports into various formats, then deliver them via email or fax. If you want to archive reports longterm to a network folder or our web docs report and document management system or SharePoint or another third party document management system, Deliver Now can be the front end process to that. It performs all that automatic report distribution and manipulation of data and then places them with where they need to go. Or maybe you create invoices and statements and other document based forms and you want to apply form templates to create high quality documents without pre-printed paper. Deliver Now, with the iForms add on component, can help with that as well.
Deliver now is our automated document delivery software used to perform automated delivery and distribution, as well as allow users to interactively pull and reformat reports from the I as well, which we'll take a look at. Deliver Now can deliver documents from any platform source. That includes IBMi spool files, PC files stored in the IFS, or on any network directory including Windows, Linux, or AIX, so it really is multi-platform document delivery. Documents can also be delivered already as formatted if they're already built with a process, or Deliver Now can turn them, if they're reports, into Excel or PDF or Word or HTML spreadsheet and database formats. Also, for delivering electronic reports, as we mentioned, Deliver Now can deliver documents generated by iForms or AFP or even another third party product as well. So we can tie into all kinds of other forms and reporting engines with this. We'll be doing a short demo of the report extraction component in just moment.
Before we do our technology demo, let's talk about a few other data use cases. Manufacturing businesses run many different systems to provide product manufacturing assistance, order tracking, shipment of product and more often the ERP systems for those companies are IBMi based and need to access data on other platforms. In this case, the customer needed a way to send shop floor orders to an AIX based system running an Oracle database from the IBMi and then return the information to the I via real time database interactions with RPG to SQL. By doing realtime data transactions between those systems, both the IBMi and Oracle Systems were kept up to date at all times.
This customer owns several properties and has to do monthly and annual tax reporting to the state of Michigan. The state mandated that they use a specific complex Excel workbook template that they supplied with multiple sheets. So this spreadsheet process typically took a few days at month's end to complete, and the chance for errors during the creation of this was high. So also data needed to be aggregated or added into that spreadsheet every month throughout the year, and they kept all the versions of that. By using RPG to SQL and the Excel functionality, they eliminated the manual data entry and automated the state reporting process. So this greatly improved their government reporting capability by automating Excel from their RPG applications. Then, they also saved several days per month of hand entering information.
All right, let's do some technology demo in here. We're going to take a quick look at it. So this is the RPG to SQL component. From a developer perspective, either there's a PC component you can have running on your desktop. Typically there's an instance that runs on a centralized server, most likely, but in this case you'll see we actually have a CL command that we have front ending our application code, which we'll look at. Basically this connects to our PC component, to our SQL server database, and then to the appropriate database within there, and then using the appropriate credentials. You'll see, when we hit enter on this guy, you'll actually see when you're in debug mode and testing this guy, you could actually see everything that just happened.
So, what this guy just did is, this program when opened a connection to my SQL server and then it deleted all the records from my temporary table ... Normally you probably wouldn't do that. Then it inserted 10 records into my SQL server database for me. So if we go over to the SQL server, we can prove that out and actually do it. So you'll see our table here and we'll do a refresh on it. And you'll see we just inserted data in real time, and pretty fast. As long as you've got decent connections, I think most companies have either a 100 megabit or gigabit connections between their servers nowadays, typically you're going to have sub second access to most of your data using that methodology.
Lets look at the alternative to that one. This one's now going to turn around and read data back. So let's take a quick look at that. So the same concept here, but we have a physical file to find that we're actually using on the IBMi to pull the data from the database and placing it into that file, and then we'll display it.
We'll run it again and as you can see it took about, maybe less than a second, and it brought all those records back and placed them into a IBMi table. In this case, you don't necessarily need a place in new a table, but we did for our demo. You could be using that data real time as you're clearing it off of your SQL server. So, and so in here you can see same concept, we connected to our server, we did our SQL select, and then we read back all the data. So very similar to reading an IBMi physical file, but you're actually reading data using SQL and in real time. So let's take a look at the RPG for that. Hopefully you all are using RDI nowadays. It's definitely makes RPG nicer to look at. Um, but in this case, so the pattern here for these programs, so if you're using RPGs cause y'all, it's, it binds in as a service program.
So in this case you'll see we pass a couple of parameters into our program for our PC component and for our database connection string, we use standard ODBC connection strings if you're creating a database connection. So typically this is boiler plate is at the top of every program. So the first thing it does is, if you pass the host name and gets the IP address where the PC component is at and then it connects to the RPG to SQL server component and then it opens your database connection. So in this case, this is just opening a standard, a ODBC connection out to a SQL server and now we're ready to actually access our data. So if everything came back correct, we can do that. And you'll see we talked about, this is where we issued our ... We did a delete all of our records and then in this example we're actually looping through a physical file.
So we do a read and then basically run till end of file. And basically we're building out insert statement and then inserting this data into our SQL server database. And then we're reading the next record. So, and these examples are meant to be purposely simple, because this is a good pattern for reading from a physical file or even using SQL in the IBMi to read data and then write it out to a SQL server table or maybe issue updates if you're updating records or something like that or, or deleting perhaps. And then at the end we close everything up. So it's always good housekeeping. Um, but that's, that's our good pattern. So you'll notice in our component where we read that data, it looks roughly the same. So we'll take a look.
So here you'll see we've got all the same information, all of our boiler plates, startup stuff that comes in here. And then you'll see we connect. And then in this case we're actually doing a SQL select. So what that does is it runs the query and then it opens a cursor. So much like opening a physical file, or if you're using embedded SQL, RPG opens that file and then you moved first just like you would in an RPG program. And then you can move through all the records. So in this case we're reading our SQL server data and then reading to end to file and then inserting it into a physical file. So you can see here we're basically redoing our read. We then move our fields into our DDS defined fields for our customer file, and then we actually write it using the standard write statement, and then we do a move next.
It's a very similar to standard RPG. If I was just using DB two tables, but we're actually reading data from SQL server or oracle or Microsoft access. And then we just close things up. So very straightforward if you're doing data imports and that sort of thing. So let's take a look at an interactive, we talked ... We mentioned earlier an interactive program, so we have to show our prerequisite sub file application. So same thing, we're passing settings into this and then we'll launch it up. There's a pubs database, so this is a titles table that's out on my SQL server and you'll notice I'm bringing it up in a standard sub file. Typically, if you're doing an RPG thing, you might do a set lower limits or something like that when you search. But in this case we're just going to type in, I want everything that has the word cook somewhere in the title.
So it found these three documents for me. And if I want I could go in and view them. I certainly could do maintenance if I wanted to, but this one's only an inquiry, but it's reading that data real time from our SQL servers. So much like position to, in this case it's doing a search or you can just starts with or a contained style search or an exact search rather than doing position to. So it makes it feel natural if you're doing, a standard green screen app, I talked to somebody yesterday it was ... Was deploying one of the modernization technologies on IBMi where they're going to actually build web based RPG and they can use the same concept in a web based RPG application where they're taking their existing RPG programs and web facing them and then reaching out and accessing data on other platforms from those same applications.
So that's pretty nice. All right, so we'll just show you the code on that. So very similar to our other one. We won't spend a ton of time on the startup piece, but it's a standard sub file, same boiler plate. And you'll notice in here we opened our connection and then it's got to run SQL statement, which we'll look at in a second. And then it's just the standard sub file clear and fill, if you've done those before. And here it basically waits for some data entry and then it goes to our run SQL, which does all the work of searching and retrieval and that sort of stuff. So let's go down and look at that. I think he's towards the bottom here. So in this case you'll see all we're doing is we're building out an SQL statement, and in this case I'm doing a bunch of like statements where I actually am doing wild carding on the SQL.
So it takes those data entry fields they've got entered when they press the enter key creates our SQL select statement. And then we always make sure to close and reopen our cursor so we don't leave something open and then it runs our SQL select and then it does a move first. And then we actually have a sub file fill routine that actually reads through the first x number of records. I think it's up here and there. Yeah, right there. It's about Phil. So all he's doing is basically just reading through x number of records to fill the page or if I'm filling multiple pages or something like that. And some looping through and getting the results and filling those up much like if you did a set lower limits and a read. All right, so let's look at one last RPG to SQL example and then we'll look at some report samples.
So this particular one is actually, oops, actually I think I want to test 29. So there's no parameters in this case. What this guy is actually going to do is it's just going to read an Excel file. So you'll probably see Excel flash down here at the bottom, but it's basically launching Excel, because we can automate Excel right from RPG. So it's launching Excel, it's going to open our Excel file for us and then it's going to read that data into a physical file. And there you can see it drop those two records in for us into a physical file right from Excel. And so how that works, very similar, almost ... Almost exact same logic. So always connect, always do this, but the difference is we have, we have functions in your procedures in here to launch Excel, make Excel visible. You can set cells or grab data from cells or insert rows and that sort of stuff.
In this case, all we're doing is we're opening this existing Excel file that's out of my drive and then I'm setting role in column positioning. And then again, I can just do rolling through the data within that spreadsheet. Much like us set lower limits, I could treat a spreadsheet just like a data table or I can affect the individual cells if I need to undo formatting. So in this case, we're basically rolling through, we're getting the current row, all the fields, and then pulling those in. And then we do field moves like we did it in our other example. These are just moving fields and then writing to a DDS. So very easy to write a RPG that imports documents into ... Or imports data into Excel or exports, who could work the same way where you're reading Excel off the IFS or somewhere and then outputting to a different data source as well.
And then we also have a couple of convenience commands that are built into the RPG, SQL for Excel. So this particular one, let's find him. There we go. We have one for importing data. So if you have a ... So this one's easy because we're exporting from a physical file directly to Excel. So it outputs all the columns and then the column headings with the first row. If you have a spreadsheet that's defined that way as well, whether it's got field names in the headers, and then it's got the data, we can actually read in a spreadsheet right into a predefined DDS member too, and use the same field names. So it's a great way to import data. I'd always think of like I'm forecasting applications, we used to do that where he sent out a bunch of parts in an Excel spreadsheet with information. People would enter that data and then import it back into [the eyes 00:23:57] to do some forecasting or something like that. But just an example. So we'll run this. So you'll see in this case it's going to export this guy to an Excel file for me.
You'll probably see Excel flash here for a second again. And then there's our data. So let's pull that up and here we go. And there you go. There's our ... There's our data that we pulled up. So definitely ... So importing and exporting and reading realtime of Excel and database information is pretty huge to be able to do that with this. So lets kind of change gears for a second. Let's take a quick look at some reporting. This component is part of our Deliver Now software and allows you to actually log in, if I remember my password and make sure I do. And you can actually do real time a school file access right from a web browser. So in this case you'll see I've got a couple of cues to find my reports is like work spot, school file. In this case we're going to select my output queue and you'll see I've got a list of reports available.
I can even filter that if I had a bunch of reports, I can do a wild card if I want to or a specific search. So in my case I filtered down to these sample reports and I can just click on them if I want to view them in PDF and it'll open that guy in PDF and convert it. So these are just standard reports. So in any standard IBMi report can be converted that way. Same thing with HTML. If you wanted a HTML format for whatever reason, there's that and Word format, and TXT format. We'll do the text one, there's ASCII text.
And then this is my favorite. We can export directly to Excel using what we call a mask. So we'll look export the sample first so you can see it. So we say open it and it says, what do you want to do? What do I want to create a mask or translate? We're going to translate this guy. And then it's using a mask I already created that extracts all the data from that ASCII report and then turns it into a spreadsheet for me. So we'll take a look at the spreadsheet here once it launches, it takes a few seconds on my demo VM here.
And so there you can see the data that got pulled from that particular school file report. So very straight forward to be able to pull data out and you'll see, we had some level breaks, which you'll see in a second, but Rep and Manager got placed into that report as well. So then I could slice and dice that data all that I want. So let's say I was just creating a report mask for this for the first time, I would just select this guy again. And what I can do is actually say create mask.
He's not always ... Not always friendly on that. Well we'll do it over here. So in this case, this is our Windows version of that where you can pull the document. So we'll actually select us. We've got, we've said our output format that you can pick all kinds of different formats, but we're going to go directly to a mask. Here we go. And so what you'll see is we can actually define areas, I'm going to pull up a predefined one since we don't have a ton of time left here in our session today. But as you can see it actually pulls up. So you, so what you ended up doing is there's a pattern here where we actually define how we're going to include lines. So in this case I included anything where there was five digit numeric number for the invoice in here. And you'll see it puts an I next to each of these lines.
And then I can just draw my column. So I drew my various columns and the document here, and then I also did level breaks. So on manager it pulls this value on sales rep, it pulls this value and it appends it to each column in the spreadsheet. So we have all of [rich 00:27:31] data and then you can even test the test right from here. If you've got an existing mask it will translate this one again, just so you can see at work. So you can interactively create these report masks and then use them at runtime or as part of your automated report delivery process. So, makes stuff really nice. And there's our same data. So very cool stuff. All right, so I think that's about all we have time to demo today. Let's go and answer a couple of questions here. So if you've got anything additional, let's go ahead and throw them up for me. Otherwise, I'm going to read a couple here, just give me a second.
Oh, this is interesting. So ... So this one says, "This may sound off track, but do you offer any tools to help my users enter data into one or more screens automatically?" So they might be thinking of, we have a ... what we call a robotic process automation tool called automate. So our automate software, which basically offers the ability to automate interaction with windows and web based and telnet terminal applications such as 5250 to automate data entry and extraction. So you could actually have it read a spreadsheet and then key data entry into a web browser or a screen like that too. So not part of today's session, but we do have some technology for that. And then also how fast can I expect my database access to be? I think we talked about that. If your network connectivity is good and your databases already tuned and indexed well, indexes are important, than database access will be sub second.
So RPG apps should see similar response time to their PC or their .net counterparts when accessing data, because RPG to SQL uses the same exact database drivers they would use. Does RPG to SQ have a limit to which databases it can access? As long as there's a ODBC or database driver available RPG, SQL can interact with it. So if there's a driver available for Windows, we can take advantage of it, which is nice. And then we'd already talked about this one a little bit. Is Excel required to integrate with Excel data? The answer there is yes. So we are actually automating the running of Excel, so there's all kinds of things. Any operation that's available in Excel pretty much can be automated. So think of all the fun formatting and extraction and pivot tables and things like that that you might want to do in your spreadsheets. You can automate that from your RPG applications.
Can I install the PC server component on my SQL server for Windows? So while the PC server component can be installed on the actual SQL server box, we generally recommend giving the PC component its own Windows VM or server box. So the component doesn't use a lot of storage. But depending on the data load and how much data you're pushing at one time, you're placing an extra load on your SQL server machines. So isolating this PC server by itself on its own VM minimizes the risk of actually messing with your SQL server performance. So we can talk more about that. If you decided to test the software, can I install a PC server component on PC desktops? Absolutely. We showed using it in development mode, which is awesome. So you can see everything that's happening while you're testing. Can I have a process update an IBMi table and then update the corresponding SQL server table right after?
Yup. So we talked about that and why are customer master example, where you can update two records across two different or even more databases if you wanted to. Why is RPG, I always liked this, or why is RPG to SQL different or better than other products I've seen? So number one reason is that we don't use Java at like a lot of the other application code that I've seen. So you're never launching Java. Basically we just have a service program that binds it and it's talking to our high speed lightweight socket server program to do all of its database connectivity so it keeps everything lightning fast.
All right, I think that's about all we have for questions today. Thanks for attending our webinar and we hope you learned some helpful information to allow your company to start thinking about real time integration of your important multi-platform data reports and spreadsheets with your IBMi applications, allowing your company to save time, money and eliminate data entry and re-keying of information.
If you have any additional questions on today's topics including RBG to SQL, Deliver Now or anything else that we might have. Doc ... Our document management components, feel free to reach out to our sales team, my counterpart, Greg Schmidt or me, and we'll be happy to schedule a free consultation to address any of your questions or provide a more in depth technical demo. So you'll also receive a link to the recording so you can share the webinar with those in your company who couldn't attend today's session. So thanks again for attending today's webinar. Have a great day and enjoy the rest of your week.
Find out how you'll benefit from data automation. In your free consultation, our experts will go over your processes and determine areas for improvement. Request yours today!