The LawsonGuru Letter is a free periodic newsletter containing provocative commentary about 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 https://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 email@example.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 https://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
- 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
- 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.
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.
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.
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.
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
The software vendor may not be the reason why your enterprise software project is failing.
Intelligent Enterprise, May 2004
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
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
5. Lawson Tips & Tricks
Share your tips. Send them to mailto:firstname.lastname@example.org.
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 https://www.danalytics.com.
To subscribe, visit https://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 https://www.danalytics.com for more information.
Decision Analytics. Integrating Lawson with the Real World.