LawsonGuru Blog

At CUE in April, I got to meet with some folks from Lawson’s technology group who are working on adding web services capabilities to Lawson.  I truly believe this will change the way you work with Lawson some time in the not-so-distant future. Think I’m nuts? 

Well, first you’re probably asking "what exactly is a web service?"

Briefly, a web service is simply a computer-to-computer data exchange, using XML to package and describe the data. From a non-technical perspective, it’s a programmatic way for one application to interact with another application. Instead of a user keying data into a form on a website, think of a computer filling out the form, and submitting it to the web server.

A good Lawson example is entering a requisition. You can do this manually by entering all of the data on the RQ10 form. But, what if you had a way for outside applications to feed requisitions into Lawson? How about if it used a mechanism that populated an RQ10 form and submitted the requisition? And, by doing so, it inherently applied all of the business rules?

How is this different from the current Lawson web technologies?

The core of Lawson’s web programs are built around the DME (Data Mining Engine) and AGS (Application Gateway Service). Every Lawson program, such as the XML UI, the OLEDB connector (the basis for Enterprise Reporting), the Excel Add-Ins, etc. uses DME and AGS to accomplish their tasks. The Lawson Portal uses Java servlet versions of these programs, but it’s still the same technique.

The problem with the Lawson DME and AGS web programs is that they are very proprietary. In particular, creating a program around AGS and DME requires knowing a lot about Lawson, and it is a very labor-intensive to program.

The Lawson technology layer has been producing XML for a couple of years now, but it’s still delivered in a very proprietary, hard-to-use, format. My biggest complaint about Lawson’s web products has been that they’re so darn proprietary. That’s all about to change.

Understanding the technology of web services is not that hard. Just think of it as new set of buzzwords and acronyms, layered on top of XML. In particular, data exchange is done via a protocol called SOAP (Simple Object Access Protocol), and since it runs over the standard HTTP transport, it’s "firewall-friendly". For the non-technical readers, that simply means that diverse applications can use a standard method of communicating, using a web-based protocol to handle the conversation. If you’ve ever dealt with EDI, it’s the same concept, just a whole lot simpler to communicate. No more proprietary data exchanges, no more VANs, etc. And, unlike EDI, you’re not locked into standard transaction sets.

To make it all happen, web services need to know "who, what and where" to be able to communicate with each other. This is accomplished via two other web services concepts that you need to be aware of:

• UDDI (Universal Description Discovery and Integration) is a search service that is used find a particular service, be it within your own enterprise, or on the internet as a whole.
• WSDL (Web Services Description Language) is a protocol used to describe the details of a service, how it is used, and how to connect to it.

Think of UDDI as a "Yellow Pages" of services, while WSDL is more like the company operator, who can connect you with a particular party. In a Lawson-only context, UDDI within a particular enterprise may not be that important, since the services are all being offered by the Lawson server, or other services that are well-known to the enterprise.

How do I benefit?

A few months ago, the LawsonGuru Letter featured an article about using the Lawson Excel Add-In for conversion tasks (see: http://www.danalytics.com/guru/letter/archive/2003-03.htm). The popularity of the Lawson Excel Add-Ins has been fueled by the "power user", who can now use Excel to populate Lawson data, utilizing Lawson’s forms behind the scenes.  What if a developer could also get data in and out of Lawson, using standard off-the-shelf programming tools?

By wrapping up the form definitions in WSDL, Lawson can offer their forms as industry-standard web services. Think about it this way. Using the earlier example about requisitions, what if you have an external application that needs to interface requisitions into Lawson–what are your options? I can think of about half a dozen ways to do it, using a flat file into RQ500, EDI into RQ512, perhaps BCI into RQ10, etc. The problem with each of these is that it is either very proprietary or just plan hard to use, or both. What if I could fire up my Visual Studio, which knows all about web services, and code up a Visual Basic program that shoots them into the RQ10 web service?

Back in the pre-Logan days, I wrote a bunch of ActiveX/COM+ components that I used to write interface for clients who needed to integrate their applications with Lawson. These operated at the database layer, rather than the application layer, but they accomplished the same objective. Of course, I did have to replicate a lot of the business logic into my components, and make sure they didn’t invalidate any of Lawson’s data. But, these components provided me with a way to meld applications with Lawson with a minimal amount of interface coding.

Now, by employing a web service, we can interoperate at the application layer, and inherently apply the business logic, using standard development tools.

And, I’ve only touched on some of the benefits of web services, particularly as a new way of developing interfaces. There are a number of other benefits as well, including the use of web services to combine multiple data sources into a comprehensive web-based application.  That is one of the promises of Microsoft’s forthcoming InfoPath product, which I’ll probably write more about in an upcoming issue.