Click here to forward to a colleague
August 2004
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: Moving Lawson applications
2. Reporting, Part 5: Using Crystal with Lawson's OLE DB Provider
3. Is Absence Management the 8.1 "Killer App"?
4. Worthwhile Reading
5. Lawson Tips & Tricks
This month we welcome Alex Tsekhansky from Analysts International (AIC)
for the first of two (and hopefully, more!) guest articles. Alex has a
very deep understanding of the Lawson architecture, and has recently been
knee-deep in Lawson upgrades. He's probably encountered and resolved
more Lawson installation issues than he'd care to admit. Next month,
Alex will share some Tomcat troubleshooting techniques.
Do you have an idea for a Guest Spot article? Ready to write your own? Send me an email at
letter-editor@lawsonguru.com.
1. Guest Spot: Moving Lawson Applications
(by Alex Tsekhansky, Analysts International)
Most teams involved in Lawson upgrades need a copy of their Lawson
installation, so all upgrade testing can be done on it. Others need a copy
of Lawson for patch testing, code development, reporting etc. Some are
satisfied with having a separate product line, but most want a copy of the
whole Lawson Environment instance.
There is a difference between those approaches. Using a copy of the product
line in the same instance as current production creates a dependence on
other instance restrictions such as security classes, job scheduler and
print manager configurations. It also prevents to the testing of environment
patches before putting them in the live production environment. So, most
companies prefer to have an exact copy of the whole Lawson installation for
testing or upgrade purposes.
Cross-platform migration (e.g. migrating from Windows to UNIX or vice versa)
may include one or more fundamental tasks:
- Copy or move Lawson into the same directory structure on a different
server running the same or similar OS version (e.g. moving Lawson from
HP9000 K-class server running HPUX 11.0 to HP9000 L-class server running
HPUX 11.11)
- Copy or move Lawson to a different directory on the same server (i.e.
creating a copy of Lawson with a different $LAWDIR, $GENDIR, $LADBDIR)
- Copy or move Lawson to different hardware/software platform
This article provides a high-level overview of the first task on UNIX and
Windows platforms. AS/400 users may apply similar ideas, using different
commands. This is by far the easiest task of the three listed above. Note,
however, that even in a simple installation, these tasks may take a few
days, so plan accordingly.
First, you need to satisfy the prerequisites, such as the installation of
Java, Perl, COBOL, C-compiler, MKS toolkit (for the Lawson Environment on
Windows). You should also migrate your users, so that they retain the same
IDs on a new server as on the old one.
On most UNIX installations it's simple - a copy of /etc/passwd file as well
as accompanying files (e.g. /etc/shadow) to the new server will do the
trick, or ask your system administrator to do it. Some UNIXes may have
distributed users (e.g. NIS+ database) that may make it even easier. Others
may have advanced security (e.g. TCB) that make it more complicated.
On the Windows platform, Lawson tracks users by two parameters - SID
(internal ID that exists within Windows) and the Lawson-generated NTnnnnnnnn
id that can be obtained by running "listusermap" on the original instance in
LID. You need to copy pieces of the registry to a new server, and if your
users are not domain users, do some registry modifications, so that the NTnnnnnnnn ids will match to the right user names. This requires a good
understanding of Lawson, Windows and its registry, so I advise you to seek
assistance for this task. Incorrect registry modifications may cause
irreparable damage to your server. I, as well as my fellow consultants, have
successfully accomplished this task on many occasions, and if done
correctly, it will not adversely affect your installation.
Next, you'll need to create an RDBMS instance for use on your new
installation, and possibly populate it with a copy of the data. Don't forget
about copying other RDBMS databases/instances related to Lawson, such as BSI
TaxFactory.
The next task is to shut down Lawson Environment you will be copying from,
and perform the actual file/directory copy. On UNIX, I recommend a "tar"
archive of the Lawson directories, which can be FTP'd to the new server, or
an SSH copy (via SCP or via SSH directly) if SSH is installed on both
servers. SSH has the advantage of not requiring the temporary space on the
source server to during the creation of the "tar" archive of the Lawson
directories. "tar" will also preserve permissions and ownership of the files
- important if you want your copy to be identical to the source.
On Windows, an xcopy or even a copy via Windows Explorer to a mapped drive
on a destination server is usually sufficient.
You then need to perform several configuration steps. On UNIX, it's a matter
of copying the /etc/lawson.env file and running the Lawson Environment
"install/install" command from $GENDIR. On Windows, it's running "laconfig"
and filling in the user group, as well as running "installlaw" to create the
Environment service.
You will also need to modify your database configuration files to point to
the new RDBMS server and/or database (e.g. $LAWDIR/productline/ORACLE file).
If your RDBMS configuration is different, you may need to modify location
information in DBDEF and perform "dbreorg -d .." so Lawson will "learn"
about new data locations. If you used Taxfactory in the original copy, you
may want to recopy Taxfactory library.
Since your new operating system may be slightly different, on UNIX I highly
recommend recompiling the "lacobrts' module (by running 'cmprts'), the
database Lawson drivers (e.g. cmpora9 for Oracle 9.x) and the Taxfactory
interface (e.g. cmptfxora if Taxfactory database is in Oracle).
Finally, do not forget about your web applications. There is a variety of
configurations, and it's hard to provide specific instructions for all of
them in a single document. You will need to create another instance of a web
server, or modify your existing configuration, so that a new web server is
created which points to your new Lawson copy. Accompanying Lawson and
third-party products such as Tomcat, CCS, and ProcessFlow also need to be
installed and/or configured.
Congratulations! The copy is done! Now you can start all components and
perform basic testing.
2. Reporting, Part 5: Using Crystal with Lawson's OLE DB Provider
In last month's installment in our series on reporting options for
Lawson, we looked at Crystal Reports (see
http://www.danalytics.com/guru/letter/archive/2004-07.htm).
I told you that the question I get the most about reporting is: "What's
the difference between Crystal and Lawson Enterprise Reporting?"
To understand the answer, you have to realize that Crystal is divided
into two major components: the report designer, and report deployment. Part
of designing a report involves selecting your data source(s). Before the
Lawson OLE DB Provider arrived on the scene, there were a number ways to get
data from Lawson into Crystal Reports. In particular, the most popular, and
easiest way, was to use the native OLE DB provider or ODBC driver provided
by the vendor of the backend database you are using for storing your Lawson
data, which can be Oracle, or SQL Server, or DB2, etc.
The Lawson OLE DB Provider
Or your data source can be the Lawson OLE DB Provider, which is bundled
with Lawson Enterprise Reporting (or can be purchased separately). Using the
Lawson OLE DB Provider, your data is available regardless of which database
is used to store the Lawson data. However, since most organizations stick to
a standard across the enterprise, this is typically not an issue.
In a nutshell, Crystal calls the Lawson OLE DB Provider which calls upon
various LOGAN/IOS services to return the data to Crystal:

Regardless of which data source you choose-Lawson OLE DB, or your native
provider-the report design and deployment process is still mostly the same
in Crystal Reports and Crystal Enterprise.
Pros & Cons
The key advantages to using the Lawson OLE DB Provider instead of the
database vendor's OLEDB provider are:
1) Lawson's OLE DB Provider applies Lawson security to your report data
2) Lawson's OLE DB Provider understands more about how Lawson stores its
data, in particular the relationships between Lawson tables.
If you use the native database provider, you have to build the security
and table relationships into the report yourself. Let's look at the pros and
cons in a little more detail:
| |
|
|
Lawson OLE DB |
Native RDMBS OLE DB Provider |
|
Security |
-
Uses the built-in application security classes to limit data access,
which probably the #1 reason for using this tool
-
Usually "foolproof"
-
Works with variety of external systems, regardless of database/storage
-
Operates through the firewall via HTTP |
-
Uses database-based security, which is typically "wide-open" in Lawson
environments, since most organizations use Lawson's
application security to manage data access
-
However, you can use Lawson's database security tools (e.g., bldorasec
for Oracle) to implement your Lawson security classes in the
database, and use those to implement reporting security
-
May require maintenance when updating Lawson versions, as queries
against updated tables may fail if table/column names are
revised
-
Vendor-specific firewall ports may be blocked |
|
Table
Relationships |
-
The architecture of OLE DB depends on the application metadata stored
in the Lawson Environment., and the Lawson OLE DB provider
is very "application-savvy" and understands the business
rules and table relationships that make Lawson such a
powerful ERP application.
-
You can only relate ("JOIN") tables that have a relationship defined in
the Lawson application metadata repository.
-
However (and this is A HUGE HOWEVER), the relationships can only be one
layer deep. In other words, you can't link from ACTRANS to
PRTIME to EMPLOYEE. |
-
Lawson stores nothing about the application table relationships in the
database, but rather, stores all of that knowledge in the
GEN repository.
-
This means that a user must understand the table relationships
(including contextual relationships).
-
However, a Lawson-savvy technology consultant should be able to provide
robust, meaningful, and user-friendly views of the Lawson
data. |
|
Limited
Index Usage |
-
Index filtering applies only to the base table, not to related tables.
This requires applying additional selection criteria in
Crystal |
-
Any table indexes can be used, regardless of whether it's on the base
table, or a JOINed table. |
|
Performance
Since the Lawson OLE DB Provider operates over the HTTP (or HTTPS, if you
desire) web protocol, and Lawson itself sits on top of a database, there are
a number of layers that it must transcend. For that reason, you would expect
it to be slower than the database native drivers. Informal benchmarks show
it to be about 10 times slower. For small reports this may be acceptable,
and the benefits of having built-in Lawson security may prevail over the
need for speed.
Deployment with Lawson Enterprise Reporting
The other significant component of Lawson Enterprise Reporting that adds
some value to the Crystal solution is called the "Crystal Integration Pack"
(formerly "Enterprise Reporting Integration Pack"). Remember that Lawson
Enterprise Reporting does not include its own report designer-Lawson uses
Crystal for that.
So, once you've designed a report, you have to decide how you're going to
deploy it. One of Crystal's big advantages is its various deployment
options. For a report that only a couple of people are going to run, you
might choose to simply run it from the Crystal developer. But you'll
probably want to deploy it to a number of users, and that requires some sort
of web-based intranet/internet application.
You can go with the standard Crystal Enterprise, which is a web-based
framework for deploying reports. You can choose from several other options
that Crystal provides (more about that later). Or, you can go with Lawson
Enterprise Reporting, which is a bundled version of Crystal Enterprise,
combined with a little bit of Lawson Portal integration (notably, single
sign-on and support for DrillAround).
The Lawson Reporting Suite (which replaces Lawson Enterprise) replaces
Crystal Enterprise with Lawson's own report management framework.
Summary
While utilizing Lawson's OLE DB Provider in combination with Crystal
Reports has significant advantages, there are some serious issues you should
consider before choosing it for serious use, and there are some report
requirements that may require you to stick with your native database
drivers. That being said, built-in security makes Lawson's OLE DB Provider a
compelling choice for simple reports.
The bottom line is that Lawson Enterprise Reporting can add some
significant value to Crystal for your reporting needs; however, there's
still a lot you can do with Crystal's products alone, including adding
Lawson DrillAround to your reports.
What Else?
Like they say on those Ginsu TV ads: "Wait, there's more!" Well, there's
one more reason to use the Lawson OLE DB Provider. And it does something you
simply can't do with any of the other data sources. Tune in next month.
3. Is Absence Management the 8.1 "Killer App"?
As you may know, Lawson has recently released Absence
Management as part of the new 8.1 Applications. Absence Management is the long-awaited
replacement for Time Accrual, and it may behoove you to upgrade to 8.1 in order to
take advantage of these beneficial new features:
Streamlined Plan Set Up
Currently, limitations in varying accrual rates by employee group, position
and special cases mean that users must often create multiple versions of the
same leave plan, for example, "Vacation," to cover the various scenarios
that commonly occur in an organization. This can lead to cumbersome plan
maintenance. Rather than setting up multiple vacation plans, with the new
Absence Management users can vary accrual rates within a single "umbrella"
plan by defining however many accrual rules are required to accommodate the
specific positions and groupings of each organization. Clients can even use
FTE as a variable for accrual calculations.
Current Time Records Not Required
In Time Accrual, if no time record exists, accruals are not processed.
However, in Absence Management, accrual calculations can occur, even if
there is no current time record present for the individual. When accruals
are based on user-defined accrual rules and are independent of time record
presence, an employee on leave of absence will be able to accrue vacation.
If an employee receives hours-based accruals, then time records will be
required. User rules, rather than system restrictions, determine how and
when accruals should be calculated.
Date Restrictions Removed
The current "period end date restriction" has been a significant hindrance
for users of Time Accrual, because once a pay period is "processed" by the
TA cycle programs, it can no longer perform further processing in that pay
period. When lagged time records come through payroll, if any usage of
vacation or other accrued time is present, it is NOT picked up by TA.
Clients are forced to check for late time records to determine if there is
any impact on plan balances. With the new Absence Management, the date
restrictions are not an issue, since there are virtually limitless dates and
rules that define when accruals should occur. In addition, adjustments and
late time records can be processes in the time period in which they
occurred, providing superior reporting accuracy.
Managing Enrollments
Clients struggle with updating Time Accrual enrollments because there is no
automation for situations when eligibility changes or is ended. This leads
to frequent manual processes aimed at preventing unwanted accruals that
occur when an employee is not terminated from a plan in a timely fashion.
Manual stops are also risky and tedious to maintain. The new Absence
Management includes automation programs to enroll, change and terminate
employees from plans based on position and employee group membership
changes. The system does the work for you, ensuring compliance and accurate
plan balances.
Leave of Absence Tracking - Emergency and FMLA
Currently, no processing, and limited date tracking are available to users
of Time Accrual. The new Absence Management introduces several features to
help keep organizations in compliance with leave of absence tracking,
especially related to FMLA-type leaves. A new type of plan for up front
allotments, 12-month rolling calendars, in addition to a new leave tracking
record, which permits the tracking of multiple dates, and eligibility
calculation reporting make Absence Management a critical tool for Human
Resources Professionals.
Processing Options - Dependency on Payroll and Order of Processing
The current Time Accrual system is tightly linked to Lawson Payroll for
processing order and accrual calculations, making it impossible for users to
allow employees to accrue and immediately decrement usage balances from the
accrued amount in the same pay period, without creating negative balance
edits at time record entry. Absence Management includes the ability to
process and calculate accruals and eligibility transfers independently so
that usage can be processed within the same period. This allows clients to
accrue and update balances, with the newly accrued amounts, if employees can
accrue and use accruals in the same pay period. In addition, real-time
Payroll integration remains an option for Lawson Payroll users, although it
is not required with the new Absence Management system.
Negative Balance Edits
Time Accrual provided users with a "soft" warning when a balance was
negative at the point of time record entry or interface. In Absence
Management, clients can choose to display no warning, issue a warning, or
create an error and prevent the time record from being entered, if the
employee's absence plan balance will go negative as a result of the hours or
earnings on the record being entered. This allows users to fine tune
processing to suit their organizational leave policies.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- QUOTE OF THE ISSUE -
"You can't build a reputation on what you are going to do."
- Henry Ford
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4. Worthwhile Reading
Stanford University: Hard Lesson
When the prestigious institution installed new Oracle and PeopleSoft
systems, it nearly flunked out of the project. Can tighter controls earn it
a passing grade?
Baseline Magazine, June 2004
http://www.baselinemag.com/article2/0,1397,1609128,00.asp
Casting Stones
The software vendor may not be the reason why your enterprise software
project is failing.
Intelligent Enterprise, May 2004
http://www.intelligententerprise.com/showArticle.jhtml?articleID=19502441
Off Shore
Shipping jobs overseas may save money, but it's a public-relations nightmare
-- and that's the least of the risks.
CFO Magazine, June 2004
http://www.cfo.com/article/1,5309,14008,00.html
Billion-Dollar Bet
Inspired by a relative newcomer, SAP is banking on its
Web-services-based NetWeaver to become an IT-platform vendor.
Information Week, June 28, 2004
http://www.informationweek.com/story/showArticle.jhtml?articleID=22102067
5. Lawson Tips & Tricks
Share your tips. Send them to
mailto:letter-tips@lawsonguru.com.
Blanking out zero-filled dates in CSV Files
Recently, one of my clients asked me how to blank out zero-filled dates in
Lawson-generated CSV files. For example, when loading a CSV file into
Microsoft Excel, they wanted termination dates for non-terminated employees
to show as an empty cell rather than "00/00/0000".
When defining a Lawson CSV file, there is no option to control this, so the
easiest alternative is to perform a search-and-replace on the file
after it is generated. The tool of choice for something like this is
the Unix-based SED editor (and yes, you can use it with Lawson's Windows
Environment, because it's part of the MKS Toolkit).Specifically, you'd
use the global search-and-replace command in SED:
$ sed 's/00\/00\/0000//g' /tmp/emps.csv
> tmp.$$
$ mv tmp.$$ /tmp/emps.csv
To learn more about the power (and arcane syntax!) of the SED editor, I
recommend visiting
http://sed.sourceforge.net/grabbag/tutorials/.
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.
To subscribe, visit
http://www.danalytics.com/guru/letter/
© Copyright 2004, Decision Analytics. All rights reserved.
Please share The LawsonGuru Letter in whole or in part as long as copyright and attribution are always included.
Decision Analytics is an independent consultancy, focusing on Lawson
technical projects, and specializing in customization/modification, data
conversion, and integration/interfaces.
Please visit http://www.danalytics.com for more
information.
Decision Analytics. Integrating Lawson with the Real World.
|
|