Archive for category: Articles

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

3. 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”)
4. Copy the output file to the destination system
5. In the destination environment, run the command

jobload –c –o job inputfile

More on jobdump/jobload

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.

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

While using Previous/Next on a record in Lawson portal, you may eventually stumble upon a pesky error message of:

“Security search limit of X employees exceeded” (X being anywhere from 1-100+)

 Commonly this could happen when restricting user access via process level, department, etc.

What happens when you click next or previous while inquiring on employees is that Lawson is searching in blocks of records based on your specified search limit.

For example:

If the Employee Security Search limit is set to 10 and we click next to inquire on the next employee record in HR11.

Lawson searches the next 10 employee records to see if the user has access to them.  If they do not, you will get the error message: “Security search limit of 10 employees exceeded”.

When we get the error, we should be on employee record number 10 – meaning if we click next again, we will be on employee number 20 if we do not have access the next 10 records again.

 

Ideally we’d like to reduce clicking next 10+ times by increasing the search limit.

Solution:

HR00.1

Don’t forget to click CHANGE after adjusting Employee Search Limit

As seen above, changing the search limit to something higher like 100 or more can dramatically reduce the amount of clicks to get to the next record that the user has access to.

If we change it to 100 and the next employee record is #200, it will only take 2 NEXT clicks to get to that record.