Problem Description

WorkUnits are not moving forward after a user takes an approve action in the inbasketRoot

 

Cause

The Lawson user was set to have “Run as” disabled. This prevents WorkUnits from successfully updating their PfiQueueTask records to move forward. This occurred as part of a sync that was executed a week before. The ISS SCWebAppAdmin had the Lawson user flagged as run as “No“, when the sync occurred the Landmark Lawson actor was updated. This did not impact the system until a week later when the Landmark system was restarted after applying windows patches.

 

 Solution

Change the Lawson user to “run as enabled”

and push that new setting and do a rolling restart on LPA/LmrkAll node to restore functionality.

 

 

 

This problem can occur after updating Lawson and Landmark from an older version and or when organizations update previous users to a newer naming convention.

 

Problem: A user is trying to access their Inbasket to approve orders but receive the error below:

 

  1. Validate the user is setup correctly in Lawson Security
  2. Validate the user is setup correctly in Landmark via Rich Client or Process Server Admin
  3. The RMID in Lawson Security must match the Landmark Actor ID.
  4. If Step 3 does not resolve the error, look into the IOS.log and see how the users RMID is appearing there and make sure the Actor ID matches the casing there.

This can be a tricky issue to resolve, especially for organizations with a single Lawson professional to debug while they are swarmed in daily tickets and also tasked with maintaining recurring process flows.

Alternatively, organizations will hire a Lawson consultant team that have a wider range of expertise who offer managed services at a fixed monthly rate. This would be more ideal for larger organizations with many daily tickets or workflows to maintain or even smaller ones who don’t need a single dedicated Lawson professional but still need weekly maintenance/support.

 

Searching for user properties in LDAP may not be as straightforward to do or you may not have had formal instructions in past to do this task. Below is a step-by-step guide to easily search for user properties in the LDAP application.

 

D:\LSF > ldifde -f cli.ldif -r “samAccountName=Cli”

Connecting to “cust.private”

Logging in as current user using SSPI

Exporting directory to file cli.ldif

Searching for entries…

Writing out entries1 entries exported

 

The command has completed successfully

D:\LSF > ls cli*

cli.ldif

D:\LSF > lashow cli.ldif

 

dn: CN=Li\, Catol,OU=Users,OU=Accounting,OU=Finance,DC=cust,DC=private

changetype: add

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: user

cn: Li, Catol

sn: Li

title: Accountant I

description: Finance – Accounting

physicalDeliveryOfficeName: Halo

telephoneNumber: (713) 644-3333

givenName: Catol

distinguishedName:

CN=Li\, Catol,OU=Users,OU=Accounting,OU=Finance,DC=cust,DC=private

instanceType: 4

whenCreated: 20210218225523.0Z

whenChanged: 20220224165103.0Z

displayName: Li, Catol CatolCat

uSNCreated: 293302835

memberOf: CN=!AP_Invoice_Process,OU=Distribution Lists,DC=cust,DC=private

memberOf:

CN=FortiGateWebFilter_Finance,OU=Web Groups,OU=Information Technology,DC=cust,

DC=private

 

If you receive a “socket” error when saving data in Infor Security Administrator, it is probable that your Federated Server Certificate is corrupt or out of sync and needs to be recreated.  Note that this is NOT the WS Federation Certificate.

To recreate the Federated Server Certificate, open a command line window on the LSF server and set the environment variables.  Log into ssoconfig -c.

First, get the Federated Server Certificate name.  “Manage Federation” > “Manage Federated Server Certificates” > “List Federated Server Certificates”.  Make note of the name.

Select “Manage Federation” > “Manage Federated Server Certificates” > “Delete Federated Server Certificate”.  Type in the name that you saved above.

After a successful confirmation, restart the servers and try again.  A new Federated Server Certificate will be generated upon recycle.

 

After making changes to Landmark application configuration or security configuration, it is not always necessary to restart Landmark.  You can force configuration changes via command line, or in Rich Client.

To force changes via command line, open a Landmark command with environment variables set.  Run the command clearconfigs -s <data area> to clear the security caches.  Other options are -a for authendat, or blank for all (clearconfigs gen).

To perform this task in Rich Client, Go to “Start > Configure > Manage Cache”.  Then select “Actions > <the cache you wish to clear>”

 

The listprod -d command shows information about the product line’s status.  The -a option shows information about all product lines.

For Example:

D:\\>listprod -ad
prodline data area Status

gen gen active
prod prod active
test test active
dev dev active

 

Here are descriptions of the statuses:

Active

The data area has an active dictionary

Pending

The data area has a pending dictionary

Upgrading

The data area is being upgraded

Out-of-date

The framework version used to build the most recent dictionary for the data area does not match the framework version used to build the most recent “GEN” dictionary

Active-out-of-date

The framework version used to build the active dictionary for the data area does not match the framework version used to build the active “GEN” dictionary

Config-missing

There is no data area configuration file

Config-changed

The data area configuration file is newer than the newest dictionary for the data area

Source-missing

There is no source for the product line

Source-changed

The source for the product line has changed since the newest dictionary for the product line’s data area was built

 

 

 

 

 

After configuring ADFS, if you attempt to launch LBI and receive the message “(security:3042) Unable to authenticate user”, go to the SystemOut.log to gather more information.  If the error is displayed there with a reference to the username, this is a known issue with LBI and ADFS.  Navigate to the SystemOut.log on the LBI server to gather more information.

 

7/2/19 11:58:30:986 EDT] 00000069 webapp        E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[GenericServletWrapper]: com.lawson.efs.security.GeneralAuthenticationException: (security:3042) Unable to authenticate user.

 

com.lawson.security.interfaces.GeneralLawsonSecurityException: Event request failed: Could not get identity for user – lawson

 

Stack Trace :

 

com.lawson.lawsec.authen.LSFSecurityAuthenException:Could not get identity for user – lawson

 

If your stack trace looks similar to the above, you will need to create a user in Lawson security where SSOP matches RMID.  This means, that you need a user whose RMID is formatted as their userPrincipalName.  To do this, you must have a service account that can be used for the purpose.  Also, you must load the user details with the loadusers command, as the characters “@” and “.” are not allowed when adding users in LSA.

 

First, have your networking team create a service account for this purpose.  Then, create a loadusers.xml file like this:

<?xml version=”1.0″ encoding=”ISO-8859-1″ ?>

<XML>

<ROLEDATA>

</ROLEDATA>

<USERDATA ProductLine=”LSAPPS”>

<USER ID=”[email protected]” RMID=”[email protected]” Name=”lbirmadmin” FirstName=”lbirmadmin” LastName=”lbirmadmin” Email=”[email protected]” CheckLS=”YES” Role=”SuperAdminRole”/>

</USERDATA>

</XML>

 

Next, on the Lawson server, run the command loadusers -f <full path to your loadusers file>.  In LSA, assign the LBI admins and LBI users groups that your organization uses to this account, and verify that the user has the SuperAdminRole.  In the Framework Services Configuration assistant in LBI, change the RM user to [email protected] and set the password.  This can also be done in the SYSCONFIG table of the EFS database.

 

Restart LBI WebSphere and try the connection again.