IPA: Landmark is still referencing old java location after update

, ,

After a Java update in Landmark, there are typical steps to follow to reset the java location.  Firstly, change the JAVA_HOME and LAW_JAVA_HOME environment variables.  Verify that the new path is also stored in the Path environment variable.

 

Next, run the change-jdk.jar command in the grid home/tools folder.

Finally, validate the LAW_JAVA_HOME setting in the config.bat file.

After those steps are completed, reboot the server and make sure the application starts.  If it doesn’t, it’s time to get into the nitty gritty.

Open up the Grid Manager.  Click on Configuration > Grid Configuration.

Select Grid Properties.

Under Node Properties, select Java Executable.

It is most likely pointing to the old location for Java.  Fix that, then reboot and you should be good to go.

Lawson Security – loadResource returned identity already exists

, ,

When we try to update some user records on the Infor Security Services (ISS) webpage, it gives an error stating: “loadResource(): returned identity [User:] already exists”

This error is due to missing extended attributes in LDAP. The extended attributes are what allow ISS to know that the user exists in LMK and are created when a user is added via ISS or the user is included in a sync.

To create the extended attributes for the user, you have two options (we recommend step 1):

  1. Run a list-based sync for the user who you are getting the error on.
  2. Run a full sync via the ISS webpage.

 

See LSSCG_11.0.0.0_UWA.pdf via Infor Concierge for example on list-based sync.

 

This is typically done by a Lawson technical resource. Organizations often hire a Lawson consultant team who offer managed services at a fixed monthly rate. These Lawson teams have a wider range of expertise and knowledge and are ideal for larger organizations but also are great for smaller ones that don’t need a dedicated Lawson employee on-site. Nogalis does offer this as a service so feel free to reach out to us via our contact page.

LASE Fails to Start After Java Update

, ,

There is a known issue after some Java updates where lase won’t start, and attempting to run the bcinstall.jar throws the exception “JCE cannot authenticate the provider BC” in the lase_server logs.  When the LASE fails to start after a Java update, this issue can only be resolved by installing a compatible Lawson CU.

When this happens, you will either need to revert to the previous version of Java, or update LSFCT to the minimally compatible CU (or later).

For Lawson version 10.0.9, the minimum CU is 4.

For Lawson version 10.0.10, the minimum CU is 5.

For Lawson version 10.0.11, the minimum CU is 6.

 

AS400 Debug Online Programs

, ,

To debug online programs through command-line entry, follow these steps:

  1. If LAWENV is not called as part of your user profile’s sign-on program, you must call the LAWENV program to set the environment variables correctly.
      1. At the IBM i command line, type
        CALL LAWENV
      2. Type the name of an Environment and press Enter.
  1. Compile the program you want to debug. At the Qshell command line, typeqcompile -D productline systemcode programcode

Note: If you need to include modules in the compile, use qcompile -Dm productline systemcode programcode .

  1. End any jobs using the previously compiled version of the program. At the IBM i command line, type:CALL TMCONTROL PARM(’-rp’ Productline Program)

Example (IBM i command line):

CALL TMCONTROL PARM(’-rp’ LAWAPP9 PR14)

  1. Access the online form either through Lawson Interface Desktop (LID) or Lawson for Infor Ming.le, and perform a transaction.
  2. Start a service job for the program.
    1. Get the job information by typing at the IBM i command line:WRKACTJOB SBS(Subsystem)

      Find the appropriate LATMProgramName job in the appropriate subsystem, and then select option 5 (Work with). Select option 1 to confirm that it is the correct job. If it is correct, return to the previous screen and note the job number, user name, and job name (which will be LATMProgramName).

      Note: You can also use the WRKSBS command to find the appropriate subsystem and then LATMProgramName job.

    2. At the IBM i command line, type:

      STRSRVJOB JobNumber/UserName/JobName
  1. Start debug. At the IBM i command line, type STRDBGand prompt it (F4). Make sure the library is the one where you compiled the source. If the information is correct, press Enter.
  2. When source listing appears, set break points (F6), then press F12.
  3. Perform another transaction with the online program.
  4. After finished with debugging, end debug and the service job. At the IBM i command line, type

ENDDBG

then

ENDSRVJOB

IPA Variable Assignments Lost After Wait Node

, ,

There exists a scenario in IPA where variable values are lost after a wait node, if the variable is set using javascript as opposed to the straight assignment feature.  This article will describe the workaround for this scenario.

In this sample, the first assign node uses javascript to set the variable apples.  The 2nd assign node (after the wait node) sets the debug string variable to the value of the apples variable.

This excerpt from the work unit log shows that the variable debug is set to a blank value.  This is because the value of the variable apples is lost after the wait.

To ensure that the variable value is not lost after a wait node, simply set the value of the variable to itself using the traditional variable assignment.  This can be done any time after the javascript setting, and before the wait node.

As you can see, the debug variable is now successfully set to the value of the apples variable.

How to setup Lawson Security to give user different security access in 2 different productlines in same environment at the same time

, ,

You might be wondering if it is possible in LSF to a give a person access to 2 different data areas (productlines) with 2 different roles at the same time.

 

So let’s say if user1 is in data area 1 and has the security access associated with the role that has access to data area (1) and then again user1 also is in data area 2 they have the security access associated with the role that has access data area (2).

More discreet way of putting it:

User1 >> DataArea1 >> ReadOnlyRole access in DataArea1.

User1 >> DataArea2 >> ChangeAccessRole access in DataArea2.

 

The best way to set this up is to separate the two DataSources so they each have their own Productline and their own separate security profiles. That’s it!

 

User1 >> DataArea1 >> ReadOnlyRole is in SecurityProfile1 which is set to DataArea1.

User1 >> DataArea2 >> ChangeAccessRole is in SecurityProfile2 which is set to DataArea 2.

 

Good luck!

Copying Portal Bookmarks

, ,

Procedure to Copy Lawson Portal Bookmarks from/to Different Servers or Environments

 

Bookmark data is stored in three places:

-Database tables in the LOGAN product line (listed below)

-LAWDIR/persistdata/lawson/portal/data/users/<user>.xml files

-LAWDIR/persistdata/lawson/portal/data/roles/<role>.xml files

 

Reminder that the <user>.xml files in LAWDIR/persistdata/lawson/portal/data/users contain references (bookmark subscriptions and/or locks) to the bookmark IDs in the original bookmark data. You must EITHER delete the “to” environment or copy from the “from” environment to the “to” environment, before you begin. Skipping this step will lead to orphaned references within the .xml files, errors in the Preferences > Content screen.

 

Also, the Portal role files in the “Manage Roles” screen under Portal Administration in Portal/Ming.le must EITHER have all bookmark locks removed in the “to” environment, or the files should be copied from the “from” environment to the “to” environment, because they contain references to the bookmark IDs in the original bookmark data.

 

PROCEDURES

 

Update the <user>.xml files in the “to” environment:

 

Copy the <user>.xml files from LAWDIR/persistdata/lawson/portal/data/users directory to the “to” environment. Or you can remove all of the <user>.xml files in the “to” environment; they will be recreated when the user logs in and receives or assigns content. DO NOT DELETE THE default.xml file in LAWDIR/persistdata/lawson/portal/data/users.

 

Update the <portalrole>.xml files in the “to” environment:

 

Copy the <portalrole>.xml files from LAWDIR/persistdata/lawson/portal/data/roles directory to the “to” environment. Or you can remove all of the bookmark locks in the “to” environment’s <portalrole>.xml files and reapply the locks later.

 

Backup and delete existing data in the “to” environment:

 

Perform the following tasks in the “to” environment, where the bookmark data will be copied to.

 

Back up and delete the LOBKMARK records (in the LOGAN product line/data area).

Back up and delete the LOGRPBKMRK records (in the LOGAN product line/data area).

Back up and delete the LOUSRBKOPT records (in the LOGAN product line/data area).

Back up and delete the LOUSRBKMRK records (in the LOGAN product line/data area).

Back up and delete the LOBKCONFIG records (in the LOGAN product line/data area).

Back up and delete the SISETUP records (in the LOGAN product line/data area).

 

Create dump files of the existing data in the “from” environment:

 

Perform the following tasks in the “from” environment, where the bookmark data will be copied from.

 

dbdump -d logan lobkmark > lobkmark.dmp

dbdump -d logan lobkconfig > lobkconfig.dmp

dbdump -d logan sisetup > sisetup.dmp

dbdump -d logan logrpbkmrk > logrpbkmrk.dmp

dbdump -d logan lousrbkmrk > lousrbkmrk.dmp

dbdump -d logan lousrbkopt > lousrbkopt.dmp

 

If the “from” and “to” environments are on separate servers, copy the .dmp files to the “to” server.

 

Load the data from the dump files in the “to” environment:

 

Perform the following tasks in the “to” environment, where the bookmark data will be copied to.

 

dbload logan lobkmark lobkmark.dmp

dbload logan lobkconfig lobkconfig.dmp

dbload logan sisetup sisetup.dmp

dbload logan logrpbkmrk logrpbkmrk.dmp

dbload logan lousrbkmrk lousrbkmrk.dmp

dbload logan lousrbkopt lousrbkopt.dmp

 

Update the <portalrole>.xml files in the “to” environment:

 

Reapply bookmark locks if you removed them previously. If you copied the files over, you can skip this step.

 

Refresh the IOS cache:

 

Run IOSCacheRefresh (“Refresh IOS Cache” admin task).

 

Verify bookmark data is not corrupt:

 

Log into Portal and go to Bookmark Manager (“Manage Bookmarks” admin task). Add a new Top-Level bookmark. Then verify that you can see it at the top of the list of bookmarks in the Bookmark Manager. This is confirmation that the bookmarks are loaded properly and the data is not corrupted. If you don’t see it at all or it was added under another bookmark, then your bookmark data is corrupt and Support should be engaged.

 

Test the data from a user perspective:

 

Log into Portal as a user (or have a user test) and verify that the bookmarks in the “to” environment look the same as the “from” environment. If you copied the <user>.xml files over, the user shouldn’t notice any differences.