Setting Up LSF Java User Permissions for IPA

When working with Infor Process Automation (IPA), code or programs can be executed remotely on the Lawson System Foundation Server through these four nodes:

  1. System Command Node
  2. File Access Node
  3. Resource Query Node
  4. Resource Update Node

These nodes work by making a connection (via RMI call) to a java.exe process running on the Lawson System Foundation Server. Therefore, it is vital that the process owner has the proper access to run these commands.

Follow the instructions below to configure your LSF system so these processes will be owned by a user that has the necessary access:

  1. Create two files (pfrmi.cfg and pfem.cfg) in %LAWDIR%/system directory. The next time the process flow is restarted, the java.exe process will refer to these files to specify which user will start the java.
  2. Both files should be identical and have just two lines each:
    line 1: LAWSONUID DOMAIN\accountname
    line 2: 

LAWSONUID DOMAIN should be replaced with your own domain and accountname should be replaced with your own account name. This is the user you are designating to run the java command. This user needs to have the proper access to run those commands. This domain/accountname combo needs to be a valid user defined in the LSF Environment Service Identity.

The second line needs to be a blank line. (Only if LSF system is running on Windows. No blank second line needed for UNIX)

line 1/line 2 are there to show you the line numbers. The actual words “line 1” and “line 2” should not be in the files.

Top Takeaways from “Process Automation – Performance Considerations and Best Practices” Infor Webinar

This 1 hour, interactive briefing from Infor provides an overview of the best practices for performance tuning your IPA process flows, grid tuning considerations, and tips to leverage the most from your system.

The full webinar can be accessed through a link on this page: (

Here are some notable takeaways from the video:

  1. IPA Settings Tuning
    Basic tips for improving performance:

    • Ensure you are on the latest release of Landmark Environment.
    • Upgrading your system to a newer release of Java will often result in performance improvements.
    • Core Pool Size: pfi.dispatcher.CorePoolSize setting within Grid determines how many simultaneous workunits can process at a time. Rule of thumb is to start by setting this value to the number of CPU Cores in your Landmark Server. (8 core CPU = 8 max workunits) In order to fully optimize, you can start simultaneous flows equal to your server’s cores and check Task Manager’s Performance tab. For example, if only 50% of your CPU is being used with 8 simultaneous flows in progress, you can probably safetly increase the maximum workunits to 12 or even 16 for improved performance.
    • Max Heap: grid.jvm.maxHeapMB setting within Grid sets the max amount of server RAM a particular Grid Node can use for processing. When setting this value, be aware of how much total RAM is available to use on the server. All the Max Heap sizes for all Grid Nodes, Operating System Memory, and Memory Footprint of other programs needs to be less than the total RAM of the server. The Max Heap should be set as high as possible with these considerations in mind.
    • LmrkDeferred Node: When installing Landmark, some grid deployments create this LmrkDeferred grid gode which combines the functionality of Async and IPA into one node. You should not be running Process Automation with this grid node. Infor recommends that the Async node and IPA node be broken out into their own grid nodes.
    • Configure the system so that there is only one IPA Grid node per Data Area that processes workunits.
  2. Process Tuning
    Basic tips for improving processes/flows:

    • Most important factor is the number of nodes. Try to minimize the number of nodes in your flow as flows take approximately 5-20ms time between nodes and 2-5ms time per variable assignment. An important tip when trying to reduce nodes is to remember that values returned from a query or processing node will automatically be assigned an internal variable name that we can refer to. There is no need for an additional assignment.
    • When using a query to cycle through records and write to a file, using a MsgBuilder versus a FileAccess or Assign node is more efficient as it is keeping the records in memory to write all at once at a later time. FileAccess in between a query is the most inefficient as it requires opening and appending onto a file once for every record encountered.
    • Turning on logging will decrease flow performance so it should only be turned on when troubleshooting flow failure or performance issues. When a flow is failing, turn on Workunit and Activity Logging and turn this off when done troubleshooting. For performance issues, run the flow with Workunit only logging turned on.
    • When creating a large csv file, consider using SysCommand node instead of writing to a file by looping through records.

For more details and the most recently updated KB articles, refer/subscribe to:
KB 1671693 – IPA Support Best Practices

Infor Process Automation (IPA) Best Practices and Performance Improvement Tips

Since Infor Process Designer is an open-ended visual design tool, different users can achieve the same end goal but in many different ways. While the flow might technically “work”, this level of design freedom usually leads to processes that are not as efficient as they could potentially be.

Here are some tips to keep in mind as you design your next flow:

  1. Use a MsgBuilder node instead of writing to file for each record


    By using a MsgBuilder node, we can append all found records to a String in memory. We can then call the string when we need to write the records. This is much faster than individually writing each line, each time through the FileAccess node.

  2. Merge Assign Nodes

    This is a common mistake in many processes. There is no reason two Assign nodes would have to line up one after another in a flow. You can simply use one Assign node for all your variables/javascript. More nodes in your flow results in slower speeds so you should always try to use as few nodes as possible.
  3. Remove Unnecessary Assign Nodes

    When a value is returned from a query or processing node, it is automatically assigned an internal variable name.

    In the screenshot above, we see the values pulled from my SQL query have already been automatically assigned a variable. Therefore, there would be no point in having an Assign node to set SQL ADDRESS to my custom variable <!ADDRESS>. It would be better to simply call <!SQLQuery1080_ADDRESS> when needed as the variable has already been created for me.

  4. Remote File Access
    When the Infor Lawson business applications and ProcessFlow are on the same server, file access is blazing fast since all the files are local. However, when IPA is on a separate server, the process slows down since the flow must now access the file across the network and not locally.

    To mitigate this issue, make sure file access is done as efficiently as possible. Perhaps reach out to those in charge of network IT to see about reducing network lag.

  5. Upload the Process with Logging Off
    Process logging can negatively affect performance. Unless you are troubleshooting a problem, processes should be uploaded with Log Level: No debug

IP Designer Email Node – Using HTML and Inserting Images

Using HTML or inserting images via the IP Designer Email node seems to be a common problem based on the number of forum posts on this topic.

Here are some of the solutions that have been proposed.


Based on the responses of senior IP Designer users, the gold standard for using HTML in your email is to write the HTML directly into a MsgBuilder node ( so that we can call the MsgBuilder variable name in the email body of the Email node.


  1. A simple way to insert images in emails sent by IP Designer Email node would be to compose HTML as shown above and bring in images from web servers.
  2. Another way would be to store the image in the Lawson emailattachments directory in order to attach it in the Email node.In Windows the directory to store the images is: lawsondirectory/bpm/emailattachments
    In Unix: lawsondirectory/LPS/emailattachments/

Troubleshooting IPA Schedules

Sometimes you may find that your scheduled flows have not run, seemingly with no explanation.  When this happens, there is a good possibility that there was an error in the scheduler that needs to be resolved.  To check the scheduler, log into Rich Client or your IPA Web Administrator as the user who owns the schedule.  Search for “My Scheduled Actions”.

Find the schedule of the flow that didn’t run, and verify if there is an error.  Double-click on the failed instance at the bottom of the screen to get more detail on the error.

Once you have resolved the issue that caused the error, right-click on the instance and select “Requeue”.  Note that this will cause your schedule to run immediately.

After the schedule has run successfully, there will not be any more items in the “Action Instances” tab.

IP Designer Series – JSON Builder Node

The JSON Builder node can be used to build a JSON object, which you can use later in your flow for reading or sending out to a server using a web call.

Under the input tab on the Properties, the input could be output from some other node, a variable, or a text string.

The output of a JSON builder can be used to send a JSON web call, or it can be read similarly to the JSON parser output.

IP Designer Series – JSON Parser Node

The JSON Parser node can be used to parse JSON data, either from a local file or from a response from a Web API.  The steps are very similar to getting XML data from a web API.

Under the input tab on the Properties, the input could be output from some other node, such as a file access node or Web Run result.

For the output, if you provide a sample file with a JSON response, that is an easy way to get the syntax for the variables coming across in the JSON response.  You can click “Set Variable” to see the syntax, and you can select “Export Variables” to get a file with the syntax for all variables in the sample file.

Use this output syntax to set variable values to use later in your flow.

Security Violation – Using Environment Utilities in IPA

Many times, you will have a need to run environment utilities (such as importdb) using a system command node, or a batch job such as IMDBB.  If you are getting security violations when you attempt to use these tools, you will need to elevate the Lawson Security privileges of the user running IPA.  The reason for this is that the system user running the IPA service is who actually is running those system commands.  Windows took away the ability to do a “run as”, so there is no way to bypass that user.

If you don’t know which user is running IPA, you can find out by executing a “whoami” command in a system command node on your IPA server.

Next you need to find this user in Lawson Security so you can elevate his privileges.  Open up Lawson Security and go to Manage Identities.  Search for the service account that you discovered in your “whoami” command.

Make not of the RMID and use that to search for the user under User Management.  Set that user’s “CheckLS” to “YES” and give him the roles required to allow access to the necessary environment utilities.

How to test your SOAP Web Service calls using Postman

If you have worked with Web Services you can appreciate the ability to test your web service calls quickly and efficiently without a lot of programming. This is exactly what Postman was meant for. When you’re building SOAP service calls with IPA it can really make your life a lot easier if you have this particular skill and tool.
The secret sauce here is how you form the actual request. Just follow these steps:
  1. Set the method to POST
  2. Paste your URL in the “Enter request URL” field.
  3. Click the “Params” button and enter any parameters you may have. If you’re using IPA you probably don’t have any parameters to enter here and they’re all included in the body of your request.
  4. Click the Authorization tab and enter your authorization information. If you have user / password this is likely “Basic Authentication”
  5. Click the “Body” tab.
    • Select “raw”
    • From the drop-down on the right select “XML (text/xml)”
    • Paste your entire soap envelope into the body text area
  6. Click Send
That should do it. You’l be able to see the status code (200 OK as shown below) and the time it takes to make the call (570 ms below)
Then in the body of your response you can see what the request returns which is pretty great to see if you’re trying to get a feel for what you’re dealing with.

How to make an HTTP request from command line

There are many instances where you are making HTTP(s) requests from within your code or IPA flow to a Web Service or alike but you cannot RDP to the server to make sure HTTP requests will actually work once they run there. It would also be really nice to see the response code and return message in case you’re doing something wrong. This is of course almost always the case with the Infor Cloud as you are not able to remote to the server and test your request on a browser. But luckily you still have access to LID or IPA. Turns out there is a clean and easy way to run a command from LID that will simulate the HTTP request and bring back the header and body information. One such way is by using PowerShell. The following powershell command retrieves the content of the Infor website for example:
powershell -c “Invoke-WebRequest -UseBasicParsing -Uri” | lashow
You can type that command on your LID command prompt  and you should see the response from as shown below:
Notice: In the command below I have piped the output to lashow for easier viewing
Alternative, if you do not have access to LID, you can use and IPA flow System node to run the command, and subsequently write the output of the command to a file that you can then view.
This is how we determined an issue we were having with making calls to the ExpenseWire web service from Infor Cloud. The server could not create SSL/TLS secure channel to ExpenseWire via https and resulted in this error in LID:
This was especially useful because the IPA flow that was making the Web Service call was simply returning the message:
“Received fatal alert: handshake_failure Message=Could not send Message.”