Calling an API from IPA

Calling an API from IPA

APIs provide a secure way for unrelated applications to communicate with each other. Infor Process Automation offers tools that allow you to utilize third-party APIs to integrate applications with Lawson. IPA processes can gather data out of third-party systems via API for import into Lawson, or they can generate data out of Lawson and format it for an API request. These integrations can be real-time or near real-time, depending on the capability of the API.

Generally speaking, APIs will be called using a Web Service Node or a Web Run Node. These nodes can be found in the Web/XML/JSON category in IP Designer.

Web Service Node

The Web Service Node is used for SOAP API calls. The authentication information can be stored in a configuration set under the Web Service tab. It is recommended that you create a new configuration set for each interface, and there can only be one Web Service configuration per set. The authentication options are Basic or WS Security. Both accept a username and password.

When setting up a Web Service node in IP Designer, select the configuration set that contains the authentication data. Populate the WSDL tab with a schema file or URL. That way, you can use the “Build” button to generate the SOAP call. You can also type the SOAP call directly into the Activity window.

Web Run Node

The Web Run node is best for APIs that use advanced security, or that don’t require XML input (i.e. the call can be made via query string). Web Run offers authentication types of OAuth 1.0a or Basic. The connection information can be set up in a configuration set, and you also have the option to override the connection in the properties of the node. As mentioned above, it is always recommended that you have at least one configuration set per interface, and bear in mind that there can be only one Web Run configuration per set.

In IP Designer, the Web Program property would be whatever comes after the Web Run URL that you configured in the configuration set, or in the override. You can also pass header strings and POST strings when needed. The third-party vendor should be able to provide you with templates for making calls. It is best to test these calls using a third-party tool such as Postman before attempting them in IPA.


Reading Responses

Most APIs will send back a response in either JSON or XML. There are a few methods for reading these responses so that the data can be used later in your flow.


JSON Parser

If the response is in JSON, use a JSON Parser node to parse the output. In IP Designer, if you go to the Output tab on the JSON parser and upload a sample document, the “Set Variable” button will show the available variables in the response.

Then, each element can be accessed from in the JSONParser_jsonvar. Each element is represented by name using the syntax [“name”]. If an element can have multiple instances, each instance should be referenced by an index (0-based). For instance, this assignment accesses the first result in the list, element “u_requested_for”, and element “value” of the u_requested_for block:



XML Node

If the response is in XML format, it can be accessed similarly to JSON, by calling each element by name. In the case of XML, it is important to include the Schema information to assist with calling each element. Once the Schema is populated (either by URL or by a xsd file), you can click the “Build” button to display each element and a sample of how it should be accessed. If you prefer working with JSON, another option for working with XML nodes is to use a JSON Converter to convert the XML to JSON. Then you can work with the output from the converter node.




Interfaces that send data out of Lawson to a 3rd party can be run real-time. There are multiple ways to trigger a process based on some activity in Lawson (see here and here for some examples). It would be tricker to send data from a third-part TO Lawson in real-time. Typically, it’s best to do batch processing, where you reach out to the 3rd party system at some defined interval and gather whatever records are available. If real-time processing is an absolute necessity, you will need to get a little creative since Landmark and Lawson don’t have their own APIs. Some ideas would be to have the third-party app drop a trigger file to be picked up by a file channel, or to have the third-party app trigger a work unit using BPM. In all cases, there will have to be some custom programming involved.


Use Cases

User Deprovisioning

We had a request to query the Service Now API for users that needed to be deprovisioned. The flow then removed roles and disabled the user accounts, as well as removing any tasks they had in IPA. Then, it would update the original ticket with a status. This type of interface has many, many applications. If your help desk ticketing system has an API, you can automate tickets for interface failures, user provisioning and deprovisioning, and much more. It is important to note that most ticketing systems are highly configurable, so there should be a lot of planning up front to make sure the interfaces are efficient and leave little room for “accidents”.

The key nodes for these flows are a Web Run node that makes the GET API call with a query string; a JSON parser node that accepts the response from the API call; assignment nodes to access the data in the JSON parser; and another Web Run node that updates the ticket with a POST API call.



Automating AP Tasks

We have written many flows that reach out to various third-party vendors, such as Guidewire or Expense Wire, over API. These interfaces do everything from adding/updating vendors to creating check requests. Whenever possible, we will gather the data from the API call and put it into a flat file format that can be brought in by a conversion job (such as AP510 or AP520). This assists with error handling, and helps to mitigate points of failure. It’s also more efficient than adding data one-by-one. If a conversion program isn’t an option, it is also possible to use Lawson Transaction nodes to add data to Lawson. We also have interfaces that send data back to the originating application to keep the systems in sync.

The key nodes for these flows are a Web Service node that makes the SOAP API call with an XML request; an XML node that accepts the response from the API call; a file access node that creates a perl script to read the XML response and generate a flat file for a Lawson conversion job; and a system command node that calls the perl script.



HR Automation

APIs have quite a few applications when it comes to HR Automation. They can be used to get time records from an external system, or benefits data, or they can be used to export such data. This particular use case was for importing employees from an HR system into Lawson as vendors in AP10 so that they can be part of an expense reimbursement program.

The key nodes in this interface are a Web Run node to get the list of new employees; a JSON parser node to read the response from the Web Run; and various assign nodes to access the variables from the JSON parser.



Bank Transactions

Banks tend to be (rightfully) extra secure, so there is a good chance that the authentication process when you are dealing with a bank’s API may be a bit too complex for the Web Run or Web Service nodes. We ran into this scenario with an interface meant to send out payments to a bank for a program allowing vendors to make their own payments to the client through the bank. To get around the complex authentication methods, we wrote a custom program to handle the API calls. It accepts any payload file and sends it to the bank. We opted to keep the process in IPA rather than going fully custom, because IPA offers quick and simple hooks into Lawson, as well as an easy scheduling interface. Also, it’s often ideal to keep all interfaces in one application for maintenance.

The key nodes for this process are the XML builder, where we build the API request in the required XML format, which is then saved to a payload file. Then, there is a system command node that calls the custom executable with the path to that file, and that is what actually makes the call.



Check out our webinar, “API Integration with Infor Process Automation” to learn how to use IPA to effectively communicate with third party applications in real or near-real time.

API Integration with Infor Process Automation

APIs provide a secure way for unrelated applications to communicate with each other. IPA allows you to utilize third-party APIs to integrate applications with Lawson. It is a way to export data such as employee records or purchase requests, as well as importing data such as time records or third-party billing & revenue.

Learn how to use IPA to effectively communicate with third party applications in real or near-real time.


Nogalis Webinar: API Integration with Infor Process Automation (September 23rd, 9 AM PST)

APIs provide a secure way for unrelated applications to communicate with each other.  IPA allows you to utilize third-party APIs to integrate applications with Lawson.  It is a way to export data such as employee records or purchase requests, as well as importing data such as time records or third-party billing & revenue.

Learn how to use IPA to effectively communicate with third party applications in real or near-real time.  We will cover examples such as:

  • Communicating with a ticketing system such as Service Now for user provisioning and deprovisioning.
  • Importing vendor data from third party billing systems such as Guidewire.
  • Exporting purchase requests to utilize payment agreements between your vendors and your bank.

We use anymeeting for our webinars. The application sometimes asks you to install a plugin. In order to be ready on time. Please give yourself an additional 10 minutes before the webinar begins.

When: Thursday September 23, 2021

9:00 AM to 10:00 AM PST

This webinar is free to attend. Register Now

How to Resolve Workunits Sitting in Ready Status

Problem: Workunits for Infor Process Automation are sitting in Ready Status and not processing.

1.  Via LmrkGrid (Grid Management), determine how many workunits may simultaneously process in your system. (see attached “DeterminingSimultaneous.docx”)

  1. Determine how many workunits are currently in a processing state.

NOTE:  Please refer to attachment “DeterminingSimultaneous.docx” for instructions on determining simultaneous processes.  In case you will need to engage support, you should screenshot this information to provide when you open the support incident.


– Command to count records in Ready Status:  dbcount <DATAAREA> -f Status=\”1\” PfiWorkunit

– Command to count records in Processing Status:  dbcount <DATAAREA> -f Status=\”2\” PfiWorkunit

– Command to count records in Completed Status:  dbcount <DATAAREA> -f Status=\”4\” PfiWorkunit


It is a good idea to monitor and take counts of these records periodically. Are the number of workunits in Ready status growing? Are the number of workunits in Completed status growing? Is the number of workunits in Processing status equal to the maximum number workunits that can simultaneously process?

NOTE: If the number of workunits in Ready Status is growing and the number of workunits in completed status is not, then either:

  1. You have workunits that processing for a very long time holding up the system; use the Grid Management UI to determine which workunits are processing so long and determine if those are stuck in a loop; or if they are just processing normally large jobs. Consider cancelling the long running workunits, and scheduling them to run in off business hours.
  2. If you are on Landmark 10.1.0.x, there was a bug in this version of Landmark that periodically caused Async to stop picking up new workunits. This issue was resolved by a re-write of Asnyc and LPA nodes in 10.1.1.x Landmark versions. If you are on Landmark 10.1.0.x you should restart the Async Node, and the IPA node.

NOTE: The workunits that were already queued to an LPA node will not automatically start back up;  the workunit polling frequency (default 30 minutes) will need to trigger before they are requeued to a new LPA node.

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.

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.

Listing IPA Scheduled Processes

If you are like me, you find it frustrating that you can only see the scheduled IPA processes that you created.  As an administrator, this can make tracking down process triggers quite difficult.  It is also difficult to determine which process is triggered by which schedule in the front-end Rich Client.  I have created a query that can show all schedules, and which process is triggered by the schedule.  Feel free to take this and make it useful to you!





INSTR(AAR.ACTIONPARAMETERS, ‘]]>’, INSTR(AAR.ACTIONPARAMETERS, ‘<field name=”FlowName” id=”FlowName”><![CDATA[‘)) –

            (INSTR(AAR.ACTIONPARAMETERS, ‘<field name=”FlowName” id=”FlowName”><![CDATA[‘)+46)) FLOW,




WHERE “GROUP” = ‘pfi’






(CHARINDEX(‘<field name=”FlowName” id=”FlowName”><![CDATA[‘, AAR.ACTIONPARAMETERS)+49)),




WHERE “GROUP” = ‘pfi’


IP Designer Series – User Action Node

The User Action Node is typically used for Approval Flows. It is uses with the IPA inbasket to allow users to take action on items as part of an automated process.

Select the task associated with the user action (this must be configured in IPA Rich Client prior to creating your user action node).

Configure actions associated with this task (such as “Approve” or “Reject”)

Decide when the action should proceed

Configure the timeout settings

Configure the notification settings

Configure the displays for various platforms

Decide if/how reminders will be handled

Triggering IPA Processes Using an HTTP(S) Call

There are several ways to trigger an IPA process, including 4GL triggers and scheduling. One simple and low-overhead method is to use a HTTP(S) call.

HTTP(S) calls can be used to trigger a Process or a Service. To begin, you should have the process uploaded into IPA. Then you should create the Process or the Service Trigger. These can be created in Rich Client or in the IPA Admin web tool, but note that the following instructions use the verbiage & menus in Rich Client.

Creating a Process Trigger

  1. In Rich Client, go to Start > Scheduling by Process Definition
  2. Create New
  3. Select the Process under Process Name
  4. Give the trigger a work title
  5. Add variables if your process accepts them

Creating a Service Trigger

  1. In Rich Client, first create the Service Definition by going to Start > Configuration > Service Definitions
  2. Create New
  3. Give the service a Name and Description
  4. Check the “Is Service Enabled” check box
  5. Click the Save button

  6. Under the Processes tab, add the process that you will be running with this service (click the add new button)
  7. Select the process to add
  8. Make sure the “Is Service Process Enabled checkbox is checked
  9. Click the save button
  10. Add variables if your process accepts them

URL syntax for calling Process & Service Triggers

  • Make sure you give your process a work title, in this case we are using Trigger Test
  • These examples assume two variables: TestVar1 and TestVar2 (variables use a zero-based array)
  • For a Service Call, triggerName is the service definition name
  • For a Process Call, triggerName is the process trigger name

Asynchronous Service Call – https://ipahost:port/bpm/trigger?triggerType=ServiceAsync&triggerName=DHTest&dataArea=prod&workTitle=Trigger%20Test&varName\[0\]=TestVar1&varValue\[0\]=xyz&varName\[1\]=TestVar2&varValue\[1\]=123

Synchronous Service Call – https://ipahost:port/bpm/trigger?triggerType=ServiceSync&triggerName=DHTest&dataArea=prod&workTitle=Trigger%20Test&varName\[0\]=TestVar1&varValue\[0\]=xyz&varName\[1\]=TestVar2&varValue\[1\]=123

Asynchronous Process Call – https://ipahost:port/bpm/trigger?triggerType=ProcessAsync&triggerName=FileAccess&dataArea=prod&workTitle=Trigger%20Test&varName\[0\]=TestVar1&varValue\[0\]=xyz&varName\[1\]=TestVar2&varValue\[1\]=123

Synchronous Process Call – https://ipahost:port/bpm/trigger?triggerType=ProcessSync&triggerName=FileAccess&dataArea=prod&workTitle=Trigger%20Test&varName\[0\]=TestVar1&varValue\[0\]=xyz&varName\[1\]=TestVar2&varValue\[1\]=123

IP Designer Series – The System Command Node

The Return Activity node in IP Designer is useful for running command line tools within a process.  You can run anything from the System Command node that could be ran in a Unix or DOS command prompt.

The first step to using a System Command Node is to configure the Sys Cmd tab in the appropriate configuration setting in Landmark.  In this case, we are using Rich Client to configure the setting.  This can also be configured via the Landmark administration web application.

To configure the System Command settings:

  1. From Rich Client, open your Configuration Sets
  2. Choose the Configuration Set for the server that you wish to run your commands
  3. Click the Sys Cmd tab, and click Actions > Create (or if one exists, select it and click Actions > Update)
  4. Fill in the parameters
    1. If the server you are accessing is remote (respective to the Landmark server), click the “Remote” checkbox
    2. The LSF Web/RMI root is the server web address
    3. The Web User is a user who has access to the Lawson Portal
    4. Password is the Web User’s password
    5. RMI timeout is the number of milliseconds to attempt the connection before timing out
    6. GENDIR and LAWDIR are the locations of those specified directories
    7. Run as user information is if you want to run your command as a different user from the user that runs the BPM process
      1. NOTE: Windows no longer allows a “Run As” user in command line activities. In typical installs, the local system user runs the BPM process on the LSF server, that is who will be running the commands in your System Command Node.  If you are using the System Command node to run Lawson tools such as importdb, you will need to make sure this local system user has access to the necessary roles in Lawson Security.

Now that your Sys Cmd settings are configured, you can use the System Command node in IPA.

  1. In the node properties, select your Configuration name.
  2. The default is the System (Landmark) configuration.
  3. For Execution mode, you can leave it as automatic and it will use the server’s inherent command mode. Or, you can specify the mode.  Options are:
    1. run directly -> {command}
    2. run shell -> sh –c {command}
    3. run Korn shell -> ksh –c {command}
    4. run shell as System Command User (Unix only) -> su –p {password} {username} –c {command}
    5. run cmd.exe (Windows only) -> cmd.exe /C {command}
  4. The Command property is the actual command script. Be sure to use the syntax appropriate for the Execution mode you chose.  You can use process variables in this window.
  5. Command input is text that is sent to the command’s input stream. This is typically left blank.

Results of this example: