Click here to forward to a colleague

December 2005

The LawsonGuru Letter is a free periodic newsletter providing provocative commentary on issues important to the Lawson Software community.  The LawsonGuru Letter is published by—and is solely the opinion of—John Henley of Decision Analytics. Visit Decision Analytics at http://www.danalytics.com. For subscription information, see the bottom of this message.

The LawsonGuru Letter is not affiliated with Lawson Software.

---

In this issue:
1. Guest Spot: Create Lawson PDFs from PERL
2. Does Landmark Change Lawson’s Offshore Strategy?
3. Upload to HR11 User Fields with Excel Add-In
4. Worthwhile Reading
5. Lawson Tips & Tricks

The LawsonGuru Letter has joined the DigitalConcourse.com vendor sponsor community.  If you've registered for Lawson CUE, or one of the regional Lawson user groups, you know that DigitalConcourse.com has become an integral part of the Lawson community.  I will be sharing more about DigitalConcourse.com in the future.  In the meantime, you can read more at http://www.digitalconcourse.com/GetDigi/GD_News_10122005.asp.

---

1. Guest Spot: Create Lawson PDFs from PERL
(by Aleksei Wolff)

Recently I received a request from a high level Manager that at first thought seemed impossible. But seeing that I had just taken a PERL scripting class I decided to tackle the request hoping that PERL might provide an easy solution. The request is paraphrased below:

“Tax season is coming up and we need to do our yearly run of Asset Management jobs to send to the tax folks. The tax folks do not have access to Lawson so we need to provide the reports to them as PDF files. By the way I calculated the number of jobs we need to run and it amounts to about 4000, so manually going into Lawson Portal’s Print Files screen to save each report as a PDF is not an option. Oh yeah I almost forgot I need this done by the end of this week”

Day 1:
With my task clearly defined I set out to solve it. Examining the Print Files screen I noticed that Lawson provided an option to view print files either as text or in PDF format. That explained the statement provided by the Manager “so manually going into Lawson Portal’s Print Files screen to save each report as a PDF is not an option...”.


Figure 1. Manually viewing the print file and saving it as PDF is not an option.

My job got a lot easier when I realized Lawson already provided the functionality I was looking for. All I had to do was figure out how it was doing it and make it work for my purposes. It eliminated having to purchase a 3rd party product which would save the company a whopping $100-$150.


Figure 2. Lawson provides a mechanism for viewing PRT files as PDF.

Day 2:
Sometime mid-morning I ran over to the local web administrator and asked. “I am hoping you can tell me what the what the web-server is logging as a call every time I go and view some Lawson print files as PDF files?”.

After a few minutes of grep’ing at log files and me going back and forth to mimic the actions via my web browser the web administrator was able to provide several log file lines which showed that every time I view the print files as PDF Lawson would make a call to a cgi-program called WEBRPT.EXE:


Figure 3. Access logs showing calls to webrpt.exe on Unix/SunOne server.

Day 3:
So now I was really on to something. I had the exact command that Lawson was using to convert print files to PDF. I just had to do a little more digging into how to use the command. At this point I figured that I could possibly write a PERL script that would make the same call to this WEBRPT.EXE program that Lawson was using and take the converted PDF file and save it someplace on the server. I was not sure if this was possible, but seemed a reasonable path to continue pursuing.

After looking at the various calls, I deciphered a general format for the WEBRPT.EXE call:

URL: http://<server-name>/cgi-lawson/webrpt.exe?
PARAMETERS:_DMD=PDF&LAYOUT=LANDSCAPE&_FN=<full-path-to-print-file>

One drawback is that the full path to the print file must be a valid record in the USERRPT GEN file.

Day 4:
I got down to business on the PERL side of things. I had to come up with a script that could make an HTTP call to the web-server and using WEBRPT.EXE pass it all the parameters required. I had already automated the portion that would execute each Asset Management job via a 4GL/Lawson batch program. At the completion of each Asset Management job I would kick off the PERL script pass it all the parameters and let it do its thing. I also wanted to create the script so it could be invoked at the command line to be used on a one-by-one basis. Feel free to enhance this script or make it more user-friendly. Use this script on at your own risk there is no guarantee that it will work at your specific locale (i.e. OS, PERL version, Lawson Environment, etc.). Enjoy.

#!/opt/perl/bin/perl   # THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS # OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A # PARTICULAR PURPOSE. # # Use of this software in any way or in any form, source or binary, # is not allowed in any country which prohibits disclaimers of any # implied warranties of merchantability or fitness for a particular # purpose or any disclaimers of a similar nature. # # IN NO EVENT SHALL I BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, # SPECIAL, INCIDENTAL,  OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE # USE OF THIS SOFTWARE AND ITS DOCUMENTATION (INCLUDING, BUT NOT # LIMITED TO, LOST PROFITS) EVEN IF I HAVE BEEN ADVISED OF THE # POSSIBILITY OF SUCH DAMAGE # # Copyright September 2005, Aleksei S. Wolff # # This software may be freely copied, changed or redistributed under # the same terms and conditions as Perl itself as long this disclaimer and copy # right statement stays intact.   ## Import Packages use LWP::UserAgent;               use strict; use warnings;   ## Check all arguments have been provided if (scalar(@ARGV) < 7) {    print 'Usage: prt2pdf.pl pl user step jobname prtfile path+dest rlog'."\n";    print '              pl        - product line (i.e qas, prod)       '."\n";    print '              user      - username of printfile              '."\n";    print '              step      - job step                           '."\n";    print '              jobname   - lawson user job name (lowercase)   '."\n";    print '              prtfile   - print file name (i.e. AM190.prt)   '."\n";    print '              path+dest - full path and file name of PDF     '."\n";    print '              rlog      - full path to *.rlog                '."\n";    exit 12; }   ## Parse Arguments my $pl   =       $ARGV[0]; my $user =       $ARGV[1]; my $step =       $ARGV[2]; my $jobname =    $ARGV[3]; my $prtfile =    $ARGV[4]; my $dest =       $ARGV[5]; my $rlog = '>> '.$ARGV[6];   my $curtime = localtime(time); my $server = ''; my $file = '';   ## Open RLOG open(RLOG, $rlog) or die "Error opening RLOG for Append\n";   print RLOG "Starting script $0 at $curtime\n";   ##Client Specific determination of productline/server if ($pl =~ m/qas|integ/) {     $server = 'slbsqas';                 $file = '/lawq/lawqas/print/'.$user.'/'.$jobname.'/'.$step.'/'.$prtfile; } elsif ($pl =~ m/prod/) {     $server = 'slbsprod';                 $file = '/lawp/lawprod/print/'.$user.'/'.$jobname.'/'.$step.'/'.$prtfile; } elsif ($pl =~ m/dev|test/) {                 $server = 'slbstest';                 $file = '/law/lawson/print/'.$user.'/'.$jobname.'/'.$step.'/'.$prtfile; } else {                 print RLOG "A valid productline was not supplied\n";                 close(RLOG);                 exit 10; }   ## Check status of printfile if (( -e $file) && ( -r $file)) {     print RLOG "\n file $file exist and is available for read\n"; } else {     print RLOG "\n there was a problem with accessing $file\n"; } print RLOG "Server ======> $server\n"; print RLOG "File Path ===> $file\n";   ##Initialize HTTP Object/Web Call...Make sure to provide correct webuser/passwd from RD30   my $webrpturl = "http://<username>:<passwd>\$\@$server/cgi-lawson/webrpt.exe?"; my $browser = LWP::UserAgent->new; my $param = join "",'_DMD=PDF', '&_DTGT=', '&_FN=', $file; my $fullurl = $webrpturl . $param; print RLOG "Request URL => $fullurl\n";   my $request = HTTP::Request->new( GET => $fullurl ); my $response = $browser->request($request); my $content = $response->content."\n";   ##Save binary response to file   open FILE, '> '.$dest or die "Can't create file...hmmm\n";   binmode FILE;   if ($response->is_success) {       print FILE $content;                   print RLOG "\n                         File downloaded and saved!!!\n";   }   else {                   print RLOG "No response from the site!!!\n";                        print RLOG "\n                         Check the file..Something went wrong!!\n";   } close FILE; $curtime = localtime(time); print RLOG "Script $0 completed at $curtime\.\.\.\.exiting\n"; close RLOG; exit 0;

---

Is Lawson about to reinvent itself? Remember a couple of years ago, how everyone was trying to be part of the offshore phenomenon? Lawson, not wanting to miss the party nor the potential savings, hooked up with offshore services provider Xansa (see http://www.danalytics.com/guru/letter/archive/2004-03.htm). The plan was that Xansa would be utilized, “...to manage Lawson’s product maintenance services...” and to “...increase Lawson’s development capacity, to focus on new product development.” (see http://www.xansa.com/shared/pressreleases/192037).

See, Lawson’s primary competitors have been using offshore resources for some time now. Lawson now has a new CEO, who came from such a competitor, and who is a big believer in using offshore resources for cost containment. Even some of Lawson’s biggest customers are demanding it, and expect Lawson to pass along the cost savings (while this might be true, perhaps, for services, I doubt that Lawson plans to reduce its maintenance fees!) Like it or not, offshoring is here to stay, and Lawson has to play along.

Lawson’s dilemma is now what—exactly—they should be sending offshore. A software company is essentially composed of four functions: development, support, services, and sales & marketing. Of those four pieces, we know one that certainly won’t be sent offshore: sales & marketing. (Wait a minute...that’s an interesting strategy—Lawson as a telemarketing company. Oh, never mind).

Lawson also announced at CUE 2005 that it was putting together a "blended professional services" offering in partnership with Xansa (see http://phx.corporate-ir.net/phoenix.zhtml?c=129966&p=irol-newsArticle&ID=707047). This would allow Lawson to offer cheaper services to its clients, by leveraging Xansa’s offshore resources for consulting services.

Which leaves support and development. I do not think, in Lawson’s case, that these can effectively be broken up—there is a significant amount of interaction between GSC and development. While I may be the atypical example, the majority of my calls end up being resolved by a developer not a support consultant. Nevertheless, let us make the somewhat safe assumption that 30-40% of Lawson’s support calls require some interaction between GSC and development. In addition, remember that Lawson still manages the case workload with their own homegrown application (yes, it is a LID application written in 4GL!). Add to that the time zones and the cultural/language differences, and you will soon understand why having development and support separated across the hemispheres is a disaster in the making!

Therefore, since you cannot effectively offshore one without the other, it means that they both have to go. However, something has to stay in MN to appease the locals, right? Or does it? Perhaps Lawson can split things up by product line or platform? Technology (Environment and IOS) support and development stays in MN and COBOL application development goes offshore? On the other hand, perhaps iSeries and RPG stays and 4GL/COBOL goes?

Then, along comes Landmark.

Landmark changes Lawson’s application development approach. To use an analogy, think about how Visual Basic changed development for Windows applications. Before VB, you needed to know an unapproachable lower-level language (usually C++). You had to write bazillions of lines of code to create a window, put buttons on it, etc. Then along came VB, which is an order of magnitude easier to develop with—you paint your window, call form.show() and you’re done.

Based on what I’ve seen thus far, I’d expect a similar experience with Landmark. You write “design instructions” in Lawson’s pattern language and Landmark spits out a finished Java application. You don’t need to know Java. You just need to know the pattern language, which is far simpler than COBOL. So, while Lawson still needs to maintain and enhance Landmark itself (much like supporting and enhancing the Lawson environment), they simply don’t need all those COBOL programmers anymore—they need analysts (or more formally, subject matter experts) who can write the specifications and the Landmark design instructions. And those RPG programmers? Lawson won’t need them anymore either.

Which highlights the dilemma: Should Lawson send the remaining “legacy” COBOL/RPG development and support offshore, and keep Landmark in MN? This means a huge ramp-up for Xansa on the old-style Lawson applications (and judging from some of the questions I get from India, they still haven’t even figured out the basics of Lawson). By the time the Xansa folks learned Lawson well enough to be effective, the clients would all be migrated to Landmark.

Or, should Lawson keep the COBOL/RPG stuff in MN and offshore development of Landmark applications? Well, that will alienate Lawson’s own developers, who can’t wait to get their hands on Landmark. And many of those developer positions can be eliminated. No longer do you theoretically need 40 COBOL programmers to maintain AP. Now you just need a handful of analysts.

This brings me back to where I think this will ultimately lead. I would expect—and it’s pure speculation on my part—that Lawson will keep the COBOL/RPG development in MN, and as that development dries up, turn some of their better developers into Landmark analysts, but ultimately eliminate a lot of those positions. And, I’d expect that, for the foreseeable future, the bulk of Landmark-based development will be done offshore.

What I see is that they are about to structure themselves into two parts: an “application enablement” organization (based in MN) which builds the tools (IOS, Landmark, etc.) and the traditional “business application development” organization (based in India, with direction and specifications coming from St. Paul), which does the application development (i.e. the old COBOL work, which will now be done in Landmark). Think of the Microsoft model--operating system, tools (SQL Server, Visual Studio, etc.), Office, and business applications. Lawson will keep Landmark and what remains of the Lawson “technology stack”—Lawson’s crown jewels—in St. Paul. The rest will go offshore—development and support of the business applications. And, remember that assuming the Intentia merger comes to fruition, Sweden is closer to India than St. Paul!

How do you think this will play out?  Send me your thoughts at mailto:letter-comments@lawsonguru.com.