Disabling a user in ISS vs LSA is pretty straight forward, however there are differences explained below.
When disabling a user in Lawson ISS, there is no “IsDisabled” field under the LSF tab as seen below:
So when disabling a user in ISS, you simply go to the top left and click on “Disable Actor”:
Once the page loads, search for the user again and you’ll notice the Disable Actor button is now called “Enabled Resource” (this is how you re-enable a user in ISS):
In LSA, you simply query the user >> Edit RM Information and set the “is disabled?” field to YES or NO:
The one advantage of disabling a user in LSA over ISS is that when you run certain user reports (custom or native), the disabled field actually shows YES or NO. This can be helpful to know when reviewing user security or running audits. (This can change in the future so please note this may not be the case anymore after this articles date).
You’re running an audit for Lawson security and are generating user, object, profile, security class/role reports left and right. It can be tiresome to review each individual one. With a simple batch command, you can save lots of time combining multiple Lawson reports that are in CSV format.
- Place all similarly generated reports into the same directory
- Open windows command line and change directory where Lawson CSV reports exist
- Type command: copy *.csv Lawson_reports_combined.csv
- Open your newly combined report and send away!
TIP: Reports may contain header info that will have to be removed via excel or text editor
Between batch job files, temporary files, and core dumps, file storage can quickly get out of hand on your LSF server. Here are some recommendations for cleaning up your server:
- Download a tool like windirstat to scan your directories and quickly find “problem” areas.
- Run a perl script to list out all the files recursively in a directory, and save to CSV. Here is a sample script that traverses the print directory and gets all the file stats within. This will help you make a more informed decision on what to delete.
- Run the deljobhst command with the “r” and “c” parameters to delete completed jobs up to a specific date, including the print files. Make sure you supply a date that meets your company’s archive policy, and/or back up the directory to a separate location. For more on the deljobhst command, click here.
The jobinteg command identifies orphaned jobs and allows you to delete them to clean up your job server.
The parameters for jobinteg are
- v (Verbose) – prints the bad records
- t (Terse) – prints totals only
- P – validate parameters
- U – print usage/syntax
- d – deletes bad records
It is recommended that you run a jobinteg -v first to see how many (if any) jobs are orphaned or missing. Then, run a jobinteg -d to delete the orphaned jobs. Here is an example of the output:
The Lawson Transaction Node can be used to add/edit/delete records in Lawson forms using AGS calls.
After you drag the node to your process, you can enter the AGS call manually, import it, or select “Build” in the properties to open a wizard. In the Wizard, select all your system values. When you are selecting the fields to update, also be sure to include all the key fields so that Lawson can find your record. The field values can be hard-coded, or you can use variables. Once you’re done building your call, click Finish, and the AGS call will be displayed in the properties window.
The Resource Update node is used to add/edit/delete resources in Lawson Security (Resource Manager). This node is extremely useful for automating onboarding and offboarding.
In the properties of the node, click “Build” to build your resource update action.
Select your action and the type of object you are updating (People or Thing). The selection criteria and the updated values can be IPA variables.
After you click “OK” on the build, you will be able to see what is being updated in the properties window.
If your LBI instance is installed with Crystal Report Application Server 2011, you may see a recurring error in your LBI WebSphere logs, referencing “JSONOBject[“ancestors”] is not a JSONArray”.
This is a known defect in CRAS 2011, and will be resolved with an update to CRAS 2011 SP4. You can safely ignore this error, or you can configure the logger to ignore it. To configure the logger to ignore the error, add the following to the LBI_HOME\Reporting Services….\erswar-x.x.war\WEB-INF\classes\log4j.xml:
<!– Workaround to supress com.businessobjects.report.web.json.JSONException: JSONObject [“ancestors”] is not a JSONArray. error–>
<logger name=”com.businessobjects.report.web”>
<level value=”FATAL”/>
</logger>
Then, restart WebSphere and verify that the errors are no longer being logged.
If you are logging into Rich Client and getting a “login failed error”, check the security_authen.log file located on the Landmark server at LASYSDIR/security_authen.log. If this file contains the error “ADFS login failed. The call to ADFS Login page was not successful”, you can configure your Rich Client installation to use an ADFS login.
These steps can be performed in the LPA Web App, or you can get to Rich Client using the command line utility. To do this, log into the Landmark server as the Lawson user. Open a Landmark command window, and type the command “canvas64 gen”. This task is performed in the GEN data area.
In the search window, type “IRC” and select “IRC Install Specifications.”
The default specifications for Rich Client 64 should look something like this:
Modify the specifications to:
- -s
- $specfile.href.url$:$specfile.version$
- -iw
- -m
- $com.lawson.url.protocol$://$com.lawson.url.host$:$com.lawson.url.port$
- <your data area>
- -q
- $com.lawson.url.protocol$://$com.lawson.url.host$:$com.lawson.url.port$
Download Rich Client again, and you will be presented with a new style of login page:
You may be running Document Express with Lawson and Citrix Storefront and encountering this error. Before you jump to conclusions that this issue is related to Lawson or Citrix security, check these steps below.
The user is likely experiencing this error when trying to import invoices into Document express.
- Make sure that all application related access is set in MHC.
- Verify the user has Active Directory access to the import routine folder on the server where the invoices are loaded in from Lawson.
- Lastly, verify the user has access to the import routine directly from Windows folder explorer. This path can be found in the import routine itself in document express.
- Copy the import routine path, paste it into Windows folder explorer to verify access.
Conclusion: When the user imports the invoice in doc express, it downloads the file locally and opens it. Verify both channels are open for the user.