Top Posts & Pages
- An error has occurred; the feed is probably down. Try again later.
Thought-Provoking Commentary for the Lawson Software Community
It’s a question I hear quite a bit. For years now, Lawson has been telling us that LID will be going away. Now with the just-released 8.1 Technology, this may indeed be getting closer to reality. All application forms can be accessed from the Lawson Portal. In fact, Lawson’s developers have been given free rein to create forms and portlets that run ONLY in Lawson Portal, and Lawson will not guarantee them to work in LID.
That being said, I think Lawson will have to support LID for the foreseeable future, since there are a number of features that still require it (ever tried to add a recurring job in Portal? How about accessing a “user form”?) But for that, Lawson wants us to use the browser-enabled “Lawson Terminal”.
By the way, a lot of users don’t know about “user forms”. User forms are environment (not application) screens that serve as front-ends to environment utilities and custom shell scripts. For example:
$ lapm importdb
will load $GENDIR/menus/dbadmin/importdb as a front-end “user form” for importdb.
User forms are defined in tokendef. A lot of clients use them as an easy way to front-end scripts for post-job processing, etc. And you HAVE to use LID (or Lawson Terminal) to access them–no Portal.
The other reason Lawson can’t get rid of LID is another dilemma–of its own making–Design Studio. When you customize a form using Design Studio, you are adding a level of complexity to the system–as well as to your support infrastructure–and Lawson’s support as well. What happens when Lawson changes the form on which your customized form is based? Your Design Studio form breaks. So, when you call Lawson for support, what’s their first question? “Have you tried it in LID?”
(Minor digression: What’s even worse for Lawson? The ugly fact about Design Studio is that Lawson now potentially has a custom version for each and every form-for each and every client! Lawson’s “Process Level” may be called “Operating Unit” in your organization, so you have to decode that nomenclature each time you open a support case. And Lawson-by giving you the ability to customize your screens-now has to deal with that as a support issue.)
OK, so there are a number of technical and administrative tasks which still require LID. My guess is that Lawson will make a big push for client adoption of the browser-based Lawson Terminal product to fill these holes.
What about the “try and pry it from my cold dead hands” power users who will never want to abandon LID? Well, get ready. To take advantage of the new security model in 8.1 Technology–you can’t use LID–it’s that simple. Sure you can use LID with 8.1 Technology, but you can’t use the new security-you’d have to stick with LAUA security. It’s great for clients that Lawson built in that backward compatibility, but I think it decreases their ability to get rid of LID.
I’ve seen the 8.1 Technology security enhancements (and I don’t even think to call them enhancements does them enough justice). If you haven’t started your 8.1 Technology upgrade planning, you should. Which means, for end users, the end of LID, and therefore you should plan on LID going away when you implement 8.1 Environment / Portal 4.0.
And, LID will certainly go away once we start seeing Landmark-based applications, sometime around 8.2 Environment.
But, one last thought. Lawson’s been done this path before, and may have to bow to the pressure from the market-you the clients. I remember the release of Lawson 7.1 on the AS/400, which came out with only LID and NED/JED-but no “green-screen”. Try taking “green-screen” away from the AS/400 crowd! Well, Lawson had to do a quick retrofit in order to appease those customers. Will they have to do something similar with LID? We’ll see.
But for now, I would plan for LID to be gone. Rest in Peace.