Archive for category: Articles

From time to time you may get inquiries from a client’s audit team about Landmark Security Roles. This overview table helps explain their uses assuming no modifications were made to them by the organization or Infor. To see a more in-depth understanding of Landmark classes, see our article: “Infor Landmark Security Classes (ST) explained”

 

Delivered role	Intended for use by	Contains these security classes
InbasketUser_ST	Normal end-users who receive work items in the Inbasket	BasicProductLineAccess_ST ProductLineAccess_ST InbasketUser_ST Lpa_ST ProcessSchedulingAllAccess_ ST
JobQueueServer_ST	Users who must perform actions on the Landmark job queue.	BasicProductLineAccess_ST ProductLineAccess_ST JobQueueAccess_ST
ProcessDesigner_ST	Process developers	BasicProductLineAccess_ST ProductLineAccess_ST Lpa_ST ProcessDesigner_ST ProcessSchedulingAllAccess_ ST
ProcessServerAllAccess_ST	IPA system administrators	BasicProductLineAccess_ST ProductLineAccess_ST Lpa_ST LpaAdmin_ST ProcessServerAllAccess_ST ProcessSchedulingAllAccess_ ST ScheduledActionsAccess_ST
ProcessServerReadAccess_ST	IPA assistant administrators, power users, developers (depending on policies at your site)	ProductLineAccess_ST ProcessServerReadAccess_ST
Not delivered through a role. Assign the class to any role for users who need to assign proxies.	Users who need to assign Tasks to other users to cover for them.	ProcessAutomationProxy_ST
ConfigConsoleSecurityAdmin_ST	Users who need full access to the Configuration Console.	ConfigAdminAccess_ST SecurityConfigAccess_ST ConfigConsoleSecurityAdmin_ ST

 

Here are 5 things you can check for when seeing what is wrong with Lawson:

1. Contact the different departments within the organization to confirm this is a wide spread issue. Coordinated with them to report back issues they are seeing.
2. If users can’t access Lawson portal, check to see if websphere is running.
   1. If you have access to the LSF server, go into services and check if the IBM Websphere ServerApp service is running. Stopping and starting the ServerApp is typically safe as well if you’re trying to prevent users from logging in.
   2. If websphere is running, check for IOS log errors found in %LAWDIR%\system
      
3. If you’re able to access Lawson portal but users report intermittent issue, check the LADB and LATM log.
   1. On the LSF server, go to %LAWDIR%\system directory and open the ladb.log and latm.log and search for “Database error (94)” or “Connection Failure” errors. Make sure the time stamps lineup.
      
4. Check the Lawson job scheduler or reach out to your database team to check for any scripts running on the server.
   1. Its rarer but an update job or sql script could cause intermittent connection issues within Lawson if its hogging all the database or LSF server resources.
   2. Its also important to verify there is nothing important running if you’re thinking of rebooting the either servers.
5. After doing the above checks and coordinating with the organization, if Lawson is still exhibiting issues and you’re seeing errors, it’s always best to reboot both the Lawson database server along with the LSF server.
   1. A simple way to do this would be to open up a command prompt or powershell in administration mode and type: shutdown -r -t 0

The Lawson Form Transaction node is used to create AGS calls to make updates to Lawson Forms.  If you already have an AGS call built, you can simply put it in the property window of the node.  You can also build an AGS call from scratch by clicking the “Build” button and going through the Wizard.  The connection should already be using your Infor Lawson configuration set, but you can set that explicitly if desired.  For this node to work, it is important that you have the Infor Lawson tab configured in your “main” configuration set in Landmark/IPA.  You can get more information on how to do that here.

In the Build wizard, select your product line, the module, and the token where you are making updates.  The Method(s) available to that token will be all the methods available to the token in Lawson portal.

Move over the field(s) that you want to update.  Make sure you include the fields that are required on the form.  If you are making a change, make sure you include the key fields and their values for the item you are changing.  The Value can be a hard-coded value, or a variable available to the node.

Click finish when you have filled in all your desired fields.  The AGS call will now appear in the property window.

 

There are a couple of authentication options when it comes to your external Lawson website.  If you want to authenticate using AD FS, you will have to put an AD FS server on the DMZ and make it externally facing.  If that is not an option at your organization, another option is to authenticate using the LDAP Bind.  Even when you implement AD FS for Lawson authentication, some pieces of the application (such as Add-ins) still require LDAP Bind.  So, you can set up your external website to take advantage of that service instead of AD FS.

The first step is to create an SSO domain if you don’t already have one.

Next, you will need to create a new HTTP endpoint with the values:

FQDN – the fully-qualified domain name of your externally facing web server

HTTP Port – the HTTP port your Lawson site uses (can be -1 if you want to disable HTTP)

HTTPS Port – the HTTPS port your Lawson site uses

SSO Domain – the LDAP Bind domain from the step above

Next, assign your new endpoint to your LDAP Bind service.  If you are still using LS as STS (as opposed to AD FS) for authentication to Lawson, this service is probably “SSOP”.  Otherwise, it is the service that was set up for LDAP Bind in applications like MS Add-ins or Lawson Security Administrator.

Next, you need to create an endpoint Group.  Give it a meaningful name that will let you know this is the group for external Lawson.

Now, assign your new endpoint to the endpoint group you just created.

Recycle services (or reboot your server), and do your smoke test.  Check the SSOServlet URL to make sure you are presented with the Infor Lawson login screen:

If you did an upgrade-in-place of LBI and are experiencing issues with it, you can revert to the previous version.

Before you begin a task like this, always get snapshots of your sever!!!

****If you don’t have a backup of your pre-upgrade database, then you won’t be able to complete these steps.  You can’t revert the database changes.  Always start with a database backup!!!****

 

Revert CRAS

You don’t need to perform this step unless your previous version of LBI requires a different version of CRAS.  To revert Crystal Report Application Server, you need to uninstall the new version, and reinstall the old version.  CRAS does not uninstall cleanly, so once you step through the wizard, and reboot the server, you will need to clear out the components left behind in the registry.  Here are the registry keys you may need to delete (key names may differ based on your version):

• HKEY_LOCAL_MACHINE\SOFTWARE\SAP Business Objects\Suite XI 4.0\Crystal Reports\
• HKEY_CURRENT_USER\Software\ SAP Business Objects\Suite XI 4.0\Crystal Reports
• HKEY_USERS\S-#-#-##-…-####\Software\ SAP Business Objects\Suite XI 4.0\Crystal Reports

Reboot again.  Try reinstalling the older version.  If you get any errors during the reinstall, you may have left behind some keys in the registry.  You can search the registry for “Crystal”.

 

Uninstall LBI From WebSphere

In WebSphere Administration Console, navigate to Applications > Application Types > WebSphere enterprise applications.  Select all of your LBI applications (Framework Services, Reporting Services, Smart Notification), and Uninstall.

Reboot the server.

 

Rename the LBI Install Directory

Stop the IBM WebSphere Application server service, then rename your LBI install directory.  This way, you can install your previous version of LBI in the same directory.

 

Restore Data

Restore your pre-upgrade data to the RS, FS, and SN databases.

 

Reinstall LBI

Run the LBI install wizard for your previous version.  Verify that the applications were deployed to WebSphere and that they were started.  Perform smoke tests.

 

You should be ready to retry the upgrade!  LBI upgrades can be finicky with WebSphere and database updates.  I recommend rebooting between each component update.  So, reboot before you begin.  Then reboot after upgrading Framework Services.  Then reboot after upgrading Reporting Services.  And so on…