Set Timeout Duration to Timeout After No Activity

, ,

Portal Timeout

To configure a timeout duration for users’ session to timeout after no activity

 

The Lawson delivered default value for session timeout is 60 minutes.  If you wish to change the timeout duration, you can use the ssoconfig utility to change it at any time.  The timeout value does not affect performance.

To change the SSO timeout parameter complete the following steps:

  • From a command type: ssoconfig -c
  • Enter the ssoconfig password.
  • Select “1” to Change Single Sign-on Server settings
  • At the prompt to “Choose the protocol for use to connect to the Lawson authentication service”, do NOT make any changes. Type the number that corresponds to your existing setting (either SSL or TCPIP).
  • At the prompt for “Enter the service to use to sign on (SSOP),” press Enter to bypass the prompt. You do not want to make any changes here.
  • At the next prompt, enter a timeout value in minutes.
  • Restart WebSphere Application Server (WAS).
  • To verify that your change worked, run http://hostname/ssoconfig/SSOCfgInfoServlet and look for the “sessionto” property, for example:
  • <PROPERTY name=”sessionto” value=”30″/>

 

Note:

The SAML Token Lifetime value is equal to the “sessionto” from SSOCfgInfoServlet.

Lawson Security Administrator Reports Stuck

, ,

If your Lawson Security Administrator (LSA) reports are getting stuck in the “processing” status, then there is a quick and simple solution for this.

All you need to do is open the path: LAWDIR/gen/java/comman/lsserver.properties.  Next, on the ljx.ext.dirs line, you will need to manually add the following command: “${GENDIR}/java/impl”.

Then you just have to bounce Lawson services, or simply reboot the server. Once booted up again you will see that the “processing” status should be gone and the status should change to “completed”. You can refer to the screenshots below for a visual guide. That’s all there is to it!

 

Lawson Batch Job Error message “Dictionary/program timestamp mismatch (43)”

, ,

When a dictionary is generated using the “blddbdict” command, it includes a timestamp within it. This timestamp serves as a marker for the state of the dictionary at the time of its creation. Similarly, when a program is compiled, this timestamp is embedded within the compiled object code. This synchronization between dictionary and program timestamps ensures consistency.

However, situations may arise where changes are made to a database table, such as the addition of an index. When such changes occur, running the “blddbdict” command again is necessary to update the dictionary with the new structure. However, until the program is recompiled, the timestamp in the newly generated dictionary will differ from the one in the compiled program. This disparity can trigger the error message you’ve encountered.

To resolve this issue, follow these steps:

  1. Recompile the Product Line: To align the program with the updated dictionary, you should recompile the entire product line. This can be accomplished by running either the “qcompile” or “lawcmp” command.
  2. Check for User Exit Programs: If recompiling the program and its invoked programs does not resolve the issue, it’s possible that the program relies on a User Exit program. In this case, you must also compile the User Exit program using the “qcompile” command.
  3. Locate User Exit Program Code: User Exit program code is typically stored in the “LAWDIR/productline/XXsrc” directory, where “XX” represents the system code of the program. The program names often include “B” for beginning, “M” for middle, and “E” for end. For example, “CU01BPD” and “CU01BWS” could be the names of beginning User Exit programs for “CU01.”
  4. Check for Compiled User Exit Objects: You can also verify the existence of compiled User Exit objects in the “LAWDIR/productline/usrobj” directory. For example, you might find “CU01B.gnt” as a compiled User Exit object.
  5. Verify OS File and Directory Permissions: Lastly, ensure that the file and directory permissions on “LABDIR/dict” are set correctly. Both the directory and all files within it should be readable by the “lawson” user group.

 

By following these steps, you should be able to resolve the timestamp mismatch error and ensure that your program functions correctly with the updated database structure.

 

How to restrict certain users’ ability to delete queued jobs in Lawson job scheduler

, ,

Follow the steps below to learn how to restrict certain users’ ability to delete queued jobs in Lawson job scheduler.

  1. Create a new role named ‘BatchRestrictedRole’ using the Lawson RM Administrator tool.
  2. Next, in the Lawson Security Administrator (LSA), generate a new Security Class for the GEN profile and name it ‘BatchRestricted.’
  3. Within LSA, associate the ‘BatchRestricted’ Security Class with the ‘BatchRestrictedRole.’
  1. Now, let’s establish the rules for the Batch Restricted security class:
    1. Online: CAT UN
      • Grant All Access
    2. Data sources: GEN
      • Grant All Access
    3. Files: JOB, JOBSTEP
      • Grant All Access
    4. Elements: UserName
      • Grant All Access
    5. Files: QUEUEDJOB
      • Unconditional Access for Action Add (A) and Action Inquiry (I)
    6. More Security context:
      • Action Add (A) enables ability to add batch jobs
      • Action Inquiry (I) enables ability to view and run queued jobs
      • Action Delete (D) enables ability to kill running jobs
      • Action Update (M) enables ability to remove completed jobs
  1. Assign the newly created ‘BatchRestrictedRole’ to users. Ensure that these users do not possess any existing roles that grant full access to QUEUEDJOB. You can verify this by running a user security report for the GEN profile and searching for QUEUEDJOB.
  1. Please take note that, depending on your specific security requirements, you may opt to impose further restrictions on other objects within the security class.
  1. Keep in mind that while users will still see the option to delete a job, they will receive messages such as ‘User does not have access to queued job’ or ‘User Does Not Have Security Access To Delete This Job Log’ when attempting to delete jobs.

LBI CRAS Error – The system cannot find the path specified

, ,

If you are getting the following CRAS error message “The system cannot find the path specified” on every single LBI report that you try to run, then it is likely that the issue is with the CRAS configuration. To validate the configuration, first open the CRAS configuration manager. Next, double-click on each of the CRAS servers. You will need to validate that the “Report Directory” under the “Parameters” tab is set to an asterisk (*).  If the parameter needs to be updated, you must first stop the CRAS server you are working with, make the change, and then restart it. (Refer to the screenshots below for reference).

Increase Landmark session timeout value

, ,

From the Landmark server admin command prompt, run the command and answer the questions:

 

secadm -m

  • Maintain Single Sign On Configuration (Option 14)
  • Configure Lawson Single Sign On (Option 2)
  • Select SSL or TCPIP (Option 1 or 2)
  • Enter the service to use to sign on (ex. SSOPV2)
  • Enter a time out value in minutes for sign on sessions (default is 60)
  • Enter a time out value in minutes for orphaned sessions (default is 360)
  • Type e to Exit

Note: You must perform a system restart for the changes you made here to take effect.

To verify the current WebUI session timeout value:

From a web browser, navigate to:

https://LandmarkWebServer:port/ssoconfig/SSOCfgInfoServlet

Look for the PROPERTY name=”sessionto” value

NOTE: Landmark and Ming.le / Lawson Portal session timeout should have the same value (default is 60 minutes)

 

How to delete unwanted Lawson AP Batches

, ,

So, you have some Lawson AP batches (AP25.1) that you can’t release or delete? We can fix that.

 

Resolution:

There’s a simple solution for this instance. You can easily delete these batches in AP25.2.

 

First, you will need to enter the company and batch number and then click Inquire:

 

After you successfully inquire, select the delete button (If it doesn’t appear it may be in a drop down on the top bar).

 

You will also need the proper change access to perform this so if you’re receiving a security violation or don’t see the delete button, you don’t have the proper access.

 

Good luck!