Advanced ImageNow to Lawson Integration with Yoga Connect™

Britney:
I’m Mrs Britney Zegler, I work for RPI. For any of you that might not be familiar with us, we are a Perceptive Software business partner that has been working within this now for over 10 years. I want to thank you again for taking the time to attend this seminar today.

With us this afternoon we have Richard Stout, a senior systems integration expert at RPI, he does a fantastic job covering this topic, and with that I’ll hand it over to Richard.

Richard:
I’m Richard Stout from RPI Consultants. Today we’re gonna be talking about advanced integration techniques between Lawson, ImageNow. For now, I’m gonna start with a bit of background information about our company. We are an Infor Lawson partner, we’re also a Perceptive Software partner, and as a company we have over 10 years’ experience integrating Lawson and ImageNow.

We have 32 at least, certified Lawson resources on our team. We have our headquarters in beautiful Baltimore Maryland, but we operate in Nashville. Our ImageNow services cover the full gamut, everything from implementation to day-to-day system maintenance, bringing on new lines of business, supporting upgrades, reporting and advanced workload metrics, and obviously the company’s web development and WebNow development which mostly I will talk about that.

So let’s get into our first topic here, and this is an inbound interface to Lawson, we invoice data from ImageNow, and talk about how to bring that in to each one. Well the traditional model, the way they’re most commonly used to bring invoice data into Lawson is to use the AP520 or the MA540 but that’s broken. These run in batch, meaning you’ve got a collection invoices, you schedule this program to run, pick up the invoices and bring it into the system. And they usually operate with exports.

So there’s a number of steps in the traditional invoice interface. And this is perhaps one of the drawbacks, is there’s just so many steps, there’s multiple places where things could go wrong, and multiple places where you need to resolve it. We start with an iScript that is exporting out data from eform, and building a CSV file. The CSV file that needs to be moved from the ImageNow server to the Lawson server. At that point we run the MA540 job which will reboot the CSV file, and that loads records into the conversion table, that is the invoice table, where they automatically sort things. And then invoices are actually created from that.

So, some of the pain points with that model is first off, it’s not real time. You’re not getting it immediate & fast, you have to wait before your invoices get uploaded to Lawson. Exception processing is the thing that’s really difficult, because there’s just so many opportunities for something to break in that <inaudible>. And we’re not able to offer any feedback or to say as to whether or not the script was successful.

Let me focus on the exception handling for a second. There’s a couple of stages that can go wrong here, that you might need to address when interfacing or uploading to Lawson. If you have some data in a field that just doesn’t even have space on it. For example, if you know anything about a company, number, or you’ve got an error sent in a column or you’ve got a character, a field that’s too wide, too many characters in the field. Some of that can cause the MA540 not to be able to load the record, even for the conversion field. The only way to know about that is to review the MA540 report, and then at that point you’ll have to try and correct the record, find the record in ImageNow, correct it, try to re-interface it.

The other possibility is everything came in to the conversion field okay, but for one reason or another it won’t be able to create that much. For example, maybe the vendor’s inaccurate, at that point you have another place to go look, and try to resolve the error and this can be frustrating, or it can be frustrating with the AP520, and you’ll need to resolve the error there again, possibly try to find the image in ImageNow, and then rerun your batch job again. This time running the batch job through the different set of parameters, to try and pick up your error records, and now do a fresh new batch conversion.

So, I have an alternative possibility to try and address the issues, and that’s to do the live AGS call to AP20. The AGS call, that’s the Application Gateway Service, is a proprietary web-based interface that’s built into Lawson. And, it’s actually the interface that’s used by the Excel Upload Wizard, it’s used by ProcessFlow, every transaction note, and it’s really what drives Portal. Portal itself is making these AGS call to the screen, whenever you key something into, for example, AP20 it adds, behind the scenes, Portal, during that AP20 call.

Benefits of AGS call is it’s a real-time transaction. You can really get instant gratification whether or not the transaction is successful. And you’re able to see your record and log the transaction. Also immediate, we get feedback with the transaction. We know whether or not it’s successful, and we can go ahead and update the record in ImageNow.

So the benefits of AGS call, the record is either in Lawson or it isn’t, there’s no conversion table to worry about, there’s no CSV file on the LSF server, that may or may not have corrupted CVS, so there’s just a lot less working parts that can fail during that transaction. And also we’re able to actually route based on success and failure. So, if the record is not in Lawson, at that point they reach out to the leaders with the record, we can maintain that record in ImageNow.

Specifically, talking about the AP20 here, some additional benefits we have are we get a voucher number back. If you’re using voucher numbers you get that number back when you add it on the AP20. So that’s it, so you get them available to add to a custom property on your interface. Also, one possibility you can do is online match of PO invoices. It’s when you’re prepping the match files on the AP20, there’s a variety of matches that can come back that you might want to make the routing choices from.

We can take the message that comes back from Lawson and record that into ImageNow, so you have that there as a reference if you’re working exceptions in ImageNow, you know exactly why the invoice did not load. You get the same messages that the AP Processor would have gotten. Here’s an example of putting the methods into the eForm, also we can use notes on a document.

Okay, let’s talk about how this AGS call might be implemented in your system. eForm data is stored in XML. In fact, the form that’s attached to a document actually is a separate page within that document. An XML document is stored in the same way a .tif file would be stored in ImageNow. The Lawson application gateway service also works with XML. You can pull an XML document to that interface, it will act on that [inaudible 00:08:07] and then will turn back and resolve it. Because we’re doing an XML to XML interface, I won’t use XSLT for that, XSLT is a technology that you can use that easily transforms XML forms to another.

So let’s talk about how our iScript might look.

The next step we’re gonna do an XSL transformation, so we’ll convert that document that’s in key form format, and convert it into the format that Lawson uses. We’re gonna need to log in to Lawson in order to do this transaction. So once you start you’re gonna need to configure with the Lawson application. Finally we will post that to the AGS servlet. You’re actually gonna copy the several transactions in a row to get a full set. There’s one transaction, again it’s the AP20, to add a header. Next you need to add your lines you’ve got. And you’re gonna do one transaction for each line. Maybe that’s the AP20, if we’re talking about the invoice for this region, maybe that’s the purchase order. And then we’ll get back our result, we’ll see what were the results into the transaction, if you like that result, if it’s a success, we’ll write a document that’s complete to you, if you’re not able to add the header, maybe we need to route the document back, okay we have more work to do on the damage before we can bring it into Lawson.

I’m gonna talk about a lot of the accounts payable scenarios today, of course there are a lot of other scenarios where these techniques are useful. In these invoices, you might think about a vendor request form and try and hit that AP10 so you know how to vendor, you might want to think about working with the employee to change position or change of status for them, and having them come in as a personal action so they can see it. And the finance module, we can work with journal entries maybe understanding and making backup documentation for a journal entry, entering the details on an eForm or even in subsequent properties and use that one for every transaction to GL40. Really, anytime a live update is desired is a good time to look at possibly using AGS calls as opposed to your batch interface program. And of course there’s not a batch interface program for every possible Lawson transaction, so at some point, depending on the transaction, AGS call might be the only way to get your transaction logged.

Next example I’d like to talk about is GL coding validation and how we might do live coding validation in Lawson. So here’s an example of an AP eForm and we’ve got our accounting unit account, and we want to give live feedback to the invoice approver, and let them know whether the accounting is valid or not.

There’s a couple ways that this can be done, traditionally one possibility is to use a nightly extract for Lawson to build up some CSV files that’ll list all the possible valid accounting combinations. Of course, the obvious drawback to that, the nightly extract, if you’re activating an account on GL20 during the middle of the day, ImageNow doesn’t know about it until the next day when the extract is run.

Of course another possibility is to use database files, so that resolves your issue with the live updates. But really, you can’t replicate 20 or 30 years of Cobalt code with a simple SQL statement. Generally, if you’re gonna do coding validation with ODBC you’re talking about using GL master cable, but there’s just a little bit more to it than whether or not a row exists in GL master, which we’ll take a look at an example next, when you would find a row in GL master but AP20 is gonna kick it out if you try to enter it.

So here’s an example where we have an accounting account that exists in GL master, but we have system control to find on that account, and it’s not valid from AP. Maybe this particular account string is only to be used internally within GL, and it’s restricted from account payable in Lawson. Here you can see I’ve done a SQL query against the GL master table, unpacking in my company, accounting unit, account and sub-account, and I am getting back a record. And it doesn’t look like that record is active in GL Master. Why? Because it turns out the logic for the system control is fairly complex. There’s a variety of different places that the 4GL code is looking over in the system, determining whether or not this account really is active.

So what’s our alternative? There is an invoke screen in Lawson called IFAC.1 and that is the screen that is internally used by the AP20 program, to determine whether or not an account is valid. We can do an AGS call to this invoke screen, to really bring in the same lines that the AP20 is gonna use, when the invoice gets interfaced in. Let’s take a look at our IFAC.1 screen, you can see the screens here are pretty smart layout because it’s design is used by a program, it’s not really an user page. I’m also showing you some of the XML that’s going on behind the screen, in my Lawson portal traits window, which I’ll talk a little bit about more in a minute.

So the benefits of getting this IFAC.1 screen for your coding validation as opposed to database query, as opposed to nightly extract, first off it’s a live call, so, if the coding is invalid, if your approver is getting background that the coding is invalid, a receiver picks up the phone, calls client, I know this is the right account, client says, ‘I’ll take care of that right away, I’ll make that account active, I’ll make the changes in the GL module that you need, right away. At that point your finance person is still on the line, you can click validate again, in WebNow or ImageNow, and see that that side transaction now works. That’s the benefit of a live call, is everything happens in the call.

In addition, we have a more of a robust validation than we could ever hope to achieve with Sequel queries because we’re using the same 4GL code that Lawson uses internally, when you go to add that invoice on the code.

Okay let’s talk about how our implementation might work if we were to try and do this. Basically, your eForm is gonna call a server-side iScript, that’s how coding validation works, you have some properties that you can set on a button or on a text CL’s in an eForm which will generate a call back to the ImageNow server, to execute the server-side iScript. On the server-side, we do the same posts to the AGS servlet that I talked about in the AP20 example. We get results back as an XML document that’s first on the server-side iScript, which will then return a thumbs up or thumbs down result back to the eForm. At that point our client-side JavaScript kicks in on the eForm to update the display, notifying you if you were valid, or ‘no it’s not valid and here’s the map that shows why it’s not valid’.

How do we make these calls into the I server from iScript? It’s a web-based interface, which means that we need to open an http, or an https to access it using Excel, to your Portal server. You have to do that from the server-side iScript. iScript doesn’t have an immediate web-client built in, so we need to use a COM object to make that call.

There are a few different Lawson API’s that you’re gonna need to hit. First is you need to authenticate to the server. So you’re gonna use the SSO servlet to do that. Second, you’re gonna need to execute your AGS call by using the transaction server, which I have up here.

In order to make an http connection in iScript, we have a couple of options. Every Windows server comes with a built in MSXML http implementation from Microsoft, and you can use the code that I’ve shown here to create that COM object and use the AMI script. Or, you can actually build your own COM object and roll a custom COM object that you call right from iScript, that can be a little bit more advanced with the logic than just the basic plumbing that’s provided by Microsoft sometimes.

The custom COM object route is definitely the way that I have found the most valuable, definitely a lot of personal advantages. Number one, performance. If you’re writing all the code yourself, the log in to Lawson, it does all the communication, it’s gonna happen a lot faster if you’re writing in a compiled language as opposed to an interpretative language like JavaScript. You can develop in a real integrated development environment where you have debugging available, debugging iScripts, if you’ve tried developing iScripts in the past, sometimes the more complicated they are it just becomes really difficult to debug, because the only way to try them is to run [inaudible]. Where if you’re working in a commercial programming language, I can personally type, I can just hit debug and then get feedback right for that line I developed.

Testing outside of ImageNow I think is really helpful, it allows you to get it past your opponent and really hit it up with a lot of different scenarios that might be difficult to reproduce with ImageNow. The final big advantage is you can use COM+ to post your COM object. COM+ is part of the Windows operating system, it allows you to take a COM object and run it in a separate thread on your server, and that thread will stay alive, and you can follow into it from Excel.

So the advantage of keeping your COM object alive with COM+ is it’s just going to be so much more responsive back to iScript, it sees resident in memory, which means it can stay logged into Lawson, you don’t have to re-log into Lawson every time an iScript runs, especially if you’re using your script as an in-script, if you’re validating 10 documents in queue, that’s 10 different iScripts and that’s 10 different log-in’s to Lawson you have to do. Also, COM+ objects, you can call to them asynchronously, meaning I can handle a set of commands and then return back to my iScript, route my item forward and then let my COM object handle communication. And if I take one, two, three seconds, if it has to do a lot of calls against Lawson, we’re not folding up the process of our iScript while that’s going on. I found that particularly useful for adding URL attachments, because URL attachments can be a little slow up.

Let’s talk about the URL attachments, this is a great compliment to what you might do in Design Studio, you know on AP20 or AP90, AP30, you might use Design Studio to add the links where you would bring up WebNow, and bring up the current record that you’re looking at in Lawson, it’ll bring you right to that image in WebNow. We can use URL attachments to sort of compliment that ability. The great benefit is that almost anywhere that you can go into an invoice. Where it’s designed studio modification, you have to go and modify a specific set of screens and then you only have those screens available. But we don’t need to get into it.

Here’s an example of the AP I had drilled in from AP90 to this invoice, and right in the top of the drill, we have our options in the URL attachment and so I click this blue ‘open’ link right here, it’s going to open this link, which of course is pathing in my company under an invoice, and they direct us to this image that we’ve got here.

URL attachments are added with the writeattach.exe PGI application, basically you’re gonna path in the keys of the Lawson record that had the attachment in it. So for invoices that is, company, vendor, invoice, something. You also have to tell the name of your attachment and of course the actual link. You’re gonna build your WebNow link using the documents, so whatever your document scheme is for invoices, you’ll put that together so that way WebNow can bring up the right – I’m basically posting an XML document to my writeattach PGI and that includes some information about not only the keys in Lawson, but it also includes my whole URL attachments in Lawson, in WebNow.

How can you learn more about these Lawson web API’s? I have a couple of resources to share, so you can get more comfortable with what it is that you can do with AGS, and what it is you can do with writeattach, and what it is you can do with [inaudible]. First off is a document out there, published by Lawson, it’s called the Doc for Developers: IOS Application Program Interfaces, and you can find that on their [inaudible] site. This [inaudible] communication in what’s going on. For http, so you can…Portal has a tracing feature to it, so even without a program like Fiddler, it’s possible to see all the communication going on between Portal and the server, and you can see…to bring that up, all you need to do is at the end of your Portal URL, [inaudible], and you put DEBUG in all capital letters = true. When you go to that, that’s actually going to bring up two windows. One is your regular Portal window, and the other is the tracing window. And, you’ll see the tracing window keeps a rolling log of all communications to and from, between Internet Explorer and the Lawson server.

Finally another great tool to use is the ProcessFlow IOS API Builder, this is the tool that comes up when you’re working your process well, and you drag your transaction note on your palette, and you click build from that transaction node, it’s gonna bring up this builder, and this will help you assemble a call and basically anything you want, it shows you all the fields available on that screen, it shows you all the actions available on that screen. This is similar to the Excel upload wizard, but where the Excel upload wizard had a good notation of it can add, it can change, it can delete and that’s about it, this IOS API Builder gives you every possible method on the screen. On AP20, we’re talking match, we’ve got the release action, we’ve got all sorts of actions that aren’t traditionally available in Excel Upload Wizard.

So how can that RPI help you in your quest to improve your interfaces, from ImageNow to Lawson? We have a lot of experience doing this type of work, we build interfaces for invoices, coding validation, URL attachments like we’ve covered today. We’ve also done this requisitions and post orders type, we’ve done journal entries, personnel actions, and that’s just personally what I’ve been involved in, I’m sure that my team members have an even greater breadth of experience there.

Our services include script development, as I’ve mentioned I’m a big fan of using COM objects for some of these types of communication, and we’ve actually put together a fairly reasonable set of code so we can pull up these scripts relatively quickly, as opposed to starting from scratch and having to figure all this stuff out. We can assist your in-house development keys, let us know what we can do to support your own efforts. Of course we offer training, really anything we can do to help get you and your team up on the technology front.

We want to hear from you. So tell us about the integration projects that you have on your plate. Tell us what’s on your wishlist. Things that you thought might not even be possible, we’d be happy to just talk it through and see what the possibilities are. Please send me your questions, I’d be happy to help. And with that, I will ask our members of the audience, have we received any questions?

Hit me up at rstout@rpic.com, I’d be happy to talk to you about our work.

Britney:
All right well we don’t have too many questions, or rather any at all. So that’s the webinar for today, just a reminder, we will be sending out the link with the copy of this webinar to everyone so you have that on hand, and I hope you enjoyed it and have a good afternoon. Thank you.