WebSphere Update Error

,

When updating a WebSphere fix pack, the following error can be seen from the IBM Installation Manager.

The update in this example is from WebSphere 8.5.5.0 to Fix Pack 10 – 8.5.5.10.

Looking at the error details shows that a dll file was unable to be deleted –

D:\IBM\WebSphere\AppServer\bin\WASServiceMsg.dll. This file can be locked by the Cell Manager when the server is started.

To resolve the issue, stop the WebSphere service in Computer Management and set it to manual start (not to start automatically).

Then find the file that was locked (WASServiceMsg.dll) and rename it to something like WASServiceMsg8550orig.dll.

Permissions may need to be added to the IBM directory to ensure Full Control is Allowed for your user id. Then restart the server and run the IBM Installation Manager again to apply the update.

Afterwards, you can see an updated version of the dll is available along with the original file that was renamed.

Be sure to change the service back to start automatically after the update is complete.

Configuring the Landmark Main Configuration Set

,

This article will demonstrate how to set up the most commonly-used Infor Lawson configurations in Landmark.

Infor delivers two configuration sets with Landmark: “main” and “system”.  “Main” refers to the LSF environment, and “system” refers to the Landmark environment.  It is best practices to use these configuration sets for the processes that access these systems.

Here are the most commonly used configurations for Lawson:

Infor Lawson

Used for web calls (DME/AGS) to Lawson, as well as Resource queries (Lawson Security)

  • Infor recommends using Connection Type “Web”
  • Retry Count – number of times IPA will retry the connection after a failed attempt
  • Pause Time – Amount of time in milliseconds between each attempt to reconnect when web call fails
  • User – the web user who has access to DME/AGS calls and/or Lawson Security
  • Password – the web user’s password
  • Data Area – the name of the data area being accessed in the LSF environment
  • Web Root – https://servername.company.com
  • Time Out – Number of seconds of attempting to connect after which a timeout occurs
  • Page Size – The number of records returned in a DME query (blank means no limit)

File Access

Used for file reads and manipulation on the LSF server

  • Click “Remote” if LSF resides on a different server from Landmark
  • LSF Web RMI Root – Same as Web Root in the Infor Lawson connection (https://server.company.com)
  • Web user – the user who has directory access on the Lawson server
  • Web password – the above user’s password
  • RMI timeout – Number of milliseconds of attempting to connect after which a timeout occurs
  • GENDIR – GENDIR environment variable value on the LSF server
  • LAWDIR – LAWDIR environment variable value on the LSF server

 

JDBC

Used for SQL Queries and transactions

  • JDBC Driver – the driver name used for JDBC
  • Database URL – build the URL for your db
    • Example: jdbc:sqlserver://servername\instancename:port;databasename=databasename
    • Instance Name is optional
    • Port is optional (default is 1433)

 

Web

Used for the Web Run process node (can be used to update and run batch jobs, etc.)

  • Data Area – the data area to which you are connecting on LSF
  • Web Root – https://servername.company.com
  • User – the user who has access to web run calls
  • Password – the above user’s password
  • Time Out – Number of seconds of attempting to connect after which a timeout occurs
  • Amount of time in milliseconds between each attempt to reconnect when web call fails

 

Sys Cmd

Used to run command line system commands, including Lawson commands such as importdb

  • Check “Remote” is LSF resides on a separate server from Landmark
  • LSF Web/RMI Root – https://server.company.com
  • Web User – the user who has access to the LSF system
  • Web password – Web User’s password
  • RMI timeout – Number of milliseconds of attempting to connect after which a timeout occurs
  • GENDIR – GENDIR on LSF system
  • LAWDIR – LAWDIR on LSF system
  • Run as user – the provide user credentials under which the command should run
    • NOTE: Windows no longer allows cmd to be run as a different user, so command line will always be run under the user running the bpm service. This is most likely the system user, and as a result, that user will have to be added to Lawson security and given access to run Lawson commands (if that is how this node is used)
  • Run as user password – above user’s password (see note above)
  • Command timeout – Number of milliseconds of attempting to connect after which a timeout occurs

Copy User Jobs Between Environments

,

These are instructions for copying user jobs (by user) between environments. This will NOT allow you to copy jobs between environments on different versions of LSF (i.e. you cannot use these commands to copy v901 jobs to v10x).

  1. Run listusermap in both environments and make note of the NTID for the user in each environment
  2. In the source environment, run the command

jobdump –d –o job –v UserName “DOMAIN\UserName” outputfile

  1. Open the output file created by the command in a text editor
    1. Update any references to the NTID from the source system with the NTID of the destination system
    2. Make any directory structure changes as needed (i.e. change “D:\lsfprod to D:\lsftest”)
  2. Copy the output file to the destination system
  3. In the destination environment, run the command

jobload –c –o job inputfile

More on jobdump/jobload

Exporting LAUA Security Classes

,

You may be upgrading a client from LAUA to 901+ and will need to view their existing security classes in LAUA.  Whatever the reason, this is how you dump LAUA security.

Login to your server through LID.

Type LAUA >> Press Enter and you’ll be in Lawson User Security screen.

Press F7 >> D (Form Security)

Follow these parameter settings:

Now press F8 and sent to A. File, B. Printer, C. Screen

Your output should look something similar to this:

 

That’s it!  Now you can maneuver through LAUA screens and view/dump other useful data such as security class assignments, etc.

 

Installing CTPs in Lawson

,

Here is a quick reference to Install CTPs in Lawson.

  1. Download and save CTP to LSF Server
  2. Extract .tar (unzip) on LSF server to folder (d:\patch\CTPXXXX)
  3. Log on LID as Lawson
  4. Change directory to extracted CTP location:
    cd d:\patch\CTPXXXXX)
  5. Run command: perl %gendir%/bin/lawappinstall preview <PRODLINE> (make sure it completes successfully)
  6. Rename/Save Preview.log
  7. Run command: perl %gendir%/bin/lawappinstall update <PRODLINE> (make sure it completes successfully)
  8. Run command: perl %gendir%/bin/lawappinstall activate <PRODLINE> (make sure it completes successfully)
  9. Go to the Lawson application and perform general testing to make sure everything is up and running.

DBREORG ISSUE(S):

During the ACTIVATE mode if it stops at dbreorg, this is likely do to activity in DB (“database in use”) or “No such file or directory” Perform the following:

On the LSF Server

Window Services:  Stop the IBMWASXXService – LSFAPP – This prevents users from accessing Portal

Window Services:  Stop Lawson.insightEnvironment “PRODLINE” –  stops LID to disconnect LID users

Task Manager:  End all java processes

Windows Services:  Start Lawson.insightEnvironment “PRODLINE” – starts LID

In LID, run the reorg manually:  dbreorg PRODLINE

Run the ACTIVATE step again

 

IP Designer Series – The Data Iterator Node

,

The Data Iterator node can be used to loop through records.  One way to use this node is to loop through the lines of a TXT or CSV file so that the data can be manipulated and stored somewhere else, or used in Lawson programs.  Here is an example of a process using data iterators.  The first node accesses a csv file and loops through each line.  The second iterator takes the line from the first node, and splits it on a delimiter.  From there, it loops through each field in the line and makes an assignment.

  1. The first node, which uses a file as the input
    1. Configuration name – select the configuration where the file resides (main is LSF, system is Landmark)
    2. Input file – the path to the file
    3. Parse by:
      1. Line – loop through each line
      2. Delimiter string – provide a character or string, the iterator will “split” on that string and loop through each item
      3. Length – use this for a fixed-length flat file
    4. Starting position – use this to determine which line the iterator should start on (so you could skip header rows if needed)
    5. Maximum read iterations – Use if you only want to read a certain number of lines/characters in a file
    6. Ignore trailing delimiter – will ignore the delimiter at the end of the line
    7. Accumulate output variables – Specifies whether records should be output into separate variables as they are parsed. If true (check box is selected), each record will be saved in the activity variable activityName_outputDataN, where activityName is the name of the activity and N is the record number.
  1. The second node, which uses a file as the input
    1. Configuration name – select the configuration where the file resides (main is LSF, system is Landmark)
    2. Input data – the data to read into the iterator
    3. Parse by:
      1. Line – loop through each line
      2. Delimiter string – provide a character or string, the iterator will “split” on that string and loop through each item
      3. Length – use this for a fixed-length flat file
    4. Starting position – use this to determine which character the iterator should start on
    5. Maximum read iterations – Use if you only want to read a certain number of lines/characters in a file
    6. Bytes to read – used for fixed width files
    7. Delimiter string – the string that splits each field of the record
    8. Ignore trailing delimiter – will ignore the delimiter at the end of the line
    9. Accumulate output variables – Specifies whether records should be output into separate variables as they are parsed. If true (check box is selected), each record will be saved in the activity variable activityName_outputDataN, where activityName is the name of the activity and N is the record number.

IP Designer Series – The Trigger Node

,

The IP Designer Trigger Node, located under the Control Menu Group, is used to trigger another IPA process or Service.  Once you drag the node to the design screen, the processes and services list will auto-populate in the node properties.  The configuration settings are just like setting up a trigger in Rich Client or the Infor Process Automation administrator web application.

  • Trigger Type, Process, and Work Title are required. The  indicates that a variable can be used for that value.

  • Use the Process Variables tab to pass variables from the current process into the one being triggered

 

 

 

 

IP Designer Series – The Wait Node

,

The IP Designer Wait Node, located under the Control Menu Group, inserts a specified wait time into your Process.  The wait times can be units of days, hours, minutes, or seconds.  This can be used for approval flows, if you want approval notifications to be sent after a certain number of days.  This can also be used in flows that run commands which need a “sleep” time between runs.  You also have the option of setting up “variable” wait times.  This could be useful if the wait time varies based on some other condition that is evaluated in the Process.

Here is a configuration for a wait time of 5 days

Here is a configuration for a wait time on a variable

Configure WebSphere profile to use a different version of Java

,

There may be a time where you need to update your WebSphere profile to use a later version of Java.  One indication of this would be if you are installing an app in WebSphere, and you come across the error “The major.minor version ‘51.0’ is too recent for this tool to understand.”  This means that your application expects a newer Java SDK.

To determine which SDK your application is currently using,

  1. Open <WAS_HOME>/profiles/<profile>/logs/startServer.log
  2. Find the last server start entry
  3. Make not of the Java version

To update the SDK used by your WebSphere profile,

  1. Open a command prompt as administrator
  2. Navigate to <WAS_HOME>/profiles/<profile>/bin
  3. Type bat –listAvailable (managesdk.sh for Unix) to list the Java SDKs that are available for this profile (note the name of the SDK that you want to use)
  4. Type bat –enableProfileAll –sdkname <the name you noted earlier> -enableServers
  5. Syncrhonize the WebSphere nodes
  6. Restart the WebSphere application server
  7. Check the startServer.log to see that the java version has changed

For example:

WebSphere Application Server, update java sdk version, The major.minor version ‘51.0’ is too recent for this tool to understand