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. For subscription information, see the bottom of this message. 

Lawson® is a registered trademark of Lawson Software, Inc.  The LawsonGuru Letter is neither affiliated with nor sponsored by Lawson Software, Inc.  Lawson Software, Inc. is not responsible for the content of this information.

One of the highly touted new LSF9 features is Lawson Single-Sign-On (SSO).

In LSF9, each user is assigned a resource record, which stores basic user information, such as first and last name, default product line, whether the new LS (Lawson Security) is enabled or not, whether a user is a Portal Administrator, etc. Each resource record is also associated with one or more identities. Identities store user-specific information--used by Lawson SSO--to interact with a particular service.

Identity records minimally include the SSO Primary (SSOP) for your Lawson Portal username, and possibly your (encrypted) password. Identity records are also used for the OS/Lawson Environment as well as additional products such as LBI, PSA, etc. Finally, identity records store Lawson self-service information, such as Company number and employee ID associated with Employee/Manager Self-Service:



Single Sign On Primary (SSOP) acts as the "master" password for a user, and is used to "unlock" the other passwords for the given user, which are all stored in the LDAP repository. When you sign onto Portal, you are using the SSOP password. From there, Lawson SSO takes care of signing you into other modules.

The SSOP password for the lawson installation user (i.e. 'lawson') is set when you install LSF9, and can either be changed via ssoconfig or from Lawson Security Administrator.

If you decide to bind Lawson Portal to another LDAP (for example, Active Directory), the password for each user's SSOP is the one which is verified via ldapbind. This means that--for Portal users--their password is the same as the one from Active Directory.

Now for the Tricky Part

For batch/LID users, there is an additional required identity—which can be an Active Directory user if you’re running LSF9 on Windows—for the OS/environment. The password for this identity is stored in Lawson's LDAP—but cannot be bound to Active Directory. That is because, in order to perform LDAP binding, Lawson needs to know the actual value of the password so it can login that user “behind the scenes” into Windows. During batch job submission, a user does not specify his/her password anywhere; hence, Lawson needs to get it from somewhere.

The 8.x Environment handled this problem in a rather elegant way—by capturing your password when you logged in via LID and storing it—encrypted, of course—in the registry. Which explains why you would always have to login via LID before running a batch job. In addition, the 8.x Environment also provided an override for Portal-only users who needed to run batch jobs: the RUNALL/RUNUSER/RUNPWD feature in lajs.cfg. The administrator used this feature to specify a default username/password to be used for running batch jobs if the user’s login failed when submitting the batch job.

Now, fast-forward to LSF9, where this feature does not exist, and for a Windows environment it is a step backwards. Since the usernames/passwords for the Environment/OS service (required for LID users and batch jobs to run) are stored in Lawson's LDAP, they somehow need to be maintained and synchronized.

Although the SSOP service can be bound to Active Directory for authentication, there is a SIGNIFICANT maintenance (and of course, security) issue for updating the Environment/OS service usernames/passwords in Lawson's LDAP, particularly if your organization uses stringent Windows-based password expiration.

Some Workarounds

• The users themselves can update the passwords, using the Lawson-provided SSO ‘User Attributes’ pages:
  
  
  
  
• One solution Lawson recommended is to use ProcessFlow to synchronize the passwords. It simply doesn’t work. I’ve tried it, and when I opened a case with Lawson, the response was “Password is not an available attribute for a Resource Query. Remove the password from your Resource Query and try it again.”  Uh, thanks.
  
  
• Another Lawson-provided alternative include perhaps loading .xml files (via ssoconfig) or .ldif files (via ldapmodify) from a client's AD—not a solution for Active Directory, because you can’t extract passwords. For other LDAPs, perhaps it’s still a solution--but it’s still high maintenance.
  
  
• You could set up user accounts—to be used only for batch jobs—on the local machine (or Active Directory) with non-expiring passwords. Only the Lawson administrator(s) would know about the accounts and manage the passwords, and it would require no involvement on the part of the users. Still doesn’t solve the problem for LID users.

A Plea for a Solution

To borrow one of my pet phrases: "The world does NOT revolve around Lawson".  Active Directory is the industry standard, and for Lawson to "force" the clients to use Lawson's LDAP for anything other than LAWSON resources is a recipe for failure.  Try telling any IT professional that they have to store their users’ OS passwords in Lawson's LDAP, and it's a serious "showstopper".

I realize that this is a tough problem.  I had originally hoped that Lawson could somehow solve this by allowing you to use 'ldapbind' for services beyond SSOP (e.g. so that you can bind the Environment service to AD for authentication), but I don’t think that’s possible.  Maybe they could prompt for a password when you submit a batch job and store it in the registry.  Maybe the answer is to bring back the RUNALL/RUNUSER parameters.

All I know is that this is a serious issue and it needs a solution.

by David Williams, Paradigm ERP

By using Design Studio we were able to automate this process; however we did face some interesting challenges during our design.

Conditional event based “trigger”

The triggering of our JavaScript function would be conditional upon the “Add” or “Change” buttons being pressed.  We elected to use the Form object OnBeforeTransaction event available in the Script section of Design Studio.  Our trigger was based upon the function code (fc) being either “C” (Change) or “A” (Add) – meaning the Change or Add button had been pressed.

 The next conditions to check were whether the applicant Type was “Internal” and whether the Offer Type was “Accept.”

The Type field is named “select1” and the Offer Type field is named “select2.”

We got the values of these fields and assigned them to variables (which we also named select1 and select2).   We then checked these variables to make sure the required conditions are met.  [JavaScript uses the double equal sign = = when comparing values and the single equal sign = when assigning values.]

Note that unlike the value of fc, which could be either “C” or “A”, both values for select1 and select2 had to be met.  [In JavaScript, the double ampersand && equals “and” and the double pipe || equals “or.”]

Since we’ve now validated that our form and field value conditions have been met, we’re ready to move forward.

Calling functions to perform tasks

Since we’re going to perform several different tasks we decided to keep them separate and built a different function for each.  The code below demonstrates how we’re calling each function in the order we want them processed.

Variables

My JavaScript for Dummies book tells me that you can’t define a variable within a function and have it available outside of that function.  I found this to be true when I defined my variables within my inquirePA42() function but couldn’t use them in later functions.

I remembered seeing within Lawson’s ProcessFlow requisition approval JavaScript sample (recsum.htm) that they defined their variables using a loadvariables() function so copied that methodology.

Gathering required information

In order to eventually add the Transfer action on PA52, we need a lot more data than is available on our PA45 form.  This requires that we get information from the job Requisition (PA42), the Position (PA02) and the employee’s current values from PA52.

We decided to inquire on the actual forms (AGS) rather than the data tables (DME) because it was easier to reference the data we needed and because we only needed one record instead of multiple records. 

The first form we needed additional data from was the PA42 – Requisition form.  We needed to pass selection criteria in order to inquire on the correct record.  We were able to hard code the company but needed to use the Requisition number (stored in the “text2” form field).

We defined the “s” variable with the AGS call and then submitted the AGS call through the sAGSInfo variable definition.  We could now reference the AGS object and get the field values to assign to our variables.  (Be sure to include the _RTN=DATA portion in the AGS call or you won’t be able to reference the values you need to assign to your variables.) 

In order to perform the AGS call on the Position (PA02) we needed the Position value assigned to the variable newPosition but we also needed the position’s effective date.  To get this date, we did perform a DME call against the data table but then used the inquire AGS call against PA02 (again, because it was easier to reference the data values).

The last inquire AGS call we performed was against the PA52 form and this was done in order to quickly access the employee’s current values.  When you add the information to PA52 you can’t key the same data into the Selected Items “Change To” field if it is equal to the “Current Value.”

Since we had all of the data values we need to “change to” from the PA45, PA42 and PA02 forms and have them assigned to specific variables, we needed to compare them to their current values on PA52.  If the “change to” value was equal to the “current value” we updated the variable to a null value.

[Note the inquire AGS call being set to _OUT=XML you need reference the fields as they are returned in XML.  We used the API Builder to get the correct formatting.] 

Adding the PA52 Transfer Action

Having the data (and updating it as needed) we were ready to perform our last function - we were ready to add the transfer action via an AGS call to PA52.

We were actually told we couldn’t add the transaction on PA52 because of the form’s functionality.  This form requires you to add the Company, Employee, and Action and then Inquire before you can fill in the remaining fields and add the transaction.

We got around this by using _EVT=CHG within the AGS call instead of _EVT=ADD as you would normally expect.  Since FC=Add was set in the AGS call the system added the transaction.

In some cases, the add function to PA52 would fail – this occurred during our testing when the supervisor data was missing on PA02 or when the new pay was outside of the position’s range.  In order to let the user know that the PA52 was added correctly we included the system message in an alert box.

Share your Tips & Tricks. Send them to mailto:letter-tips@lawsonguru.com.
You can view other Tips & Tricks on LawsonGuru.com.

Including common JavaScript routines into Multiple Forms

As you increasingly use JavaScript in Design Studio, you’ll notice that you’re repeating the same or similar code for various functions, and pasting them into multiple forms. For example, you’ll probably find that you end up with various routines that get used across multiple forms, performing functions such as:

• AGS, DME Calls
• Common Lookups
• Date logic
• String functions

There’s no need to keep copying/pasting the same code into each form. You can use a Design Studio feature for including the common JavaScript code into multiple forms. Think of it as a “poor man’s repository”.

What you do is save all of your common Javascript routines (debugged and tested of course!) into one or more .js files into a specific folder on the web server:

/lawson/portal/content/scripts

Then, when you need to include a routine that is stored in one of those files, you specify an “include” file, to referenced by your form-specific JavaScript: