Recommendation by category

Data generation

This table shows the node-specific best practices for data generation:

label.importantStarting with the 2024.10 release, these activity nodes will be deprecated and removed from the Infor Process Designer (IPD) tool, Infor Process Designer for the Web (IPD Web), and runtime server:

Custom
Data Transformation
JMS
Social
SQL Query
SQL Transaction
WebSphere MQ

Additionally, these nodes are no longer supported in multi-tenant environments and will be removed on a later date.

See KB3522595.


Activity node	Consideration or recommendation if node cannot be re-run
Data Exchange - Outbound	Use Undo approach if possible, otherwise use Bypass approach. See General requirements and considerations.
Email/Social/SMS	Use Bypass approach. See General requirements and considerations.
Event Hub Publisher	Use Bypass approach. See General requirements and considerations.
File Access - Write to file	Use Bypass approach. See General requirements and considerations.
File Access - Append to file	Use Undo approach if possible, otherwise use Bypass approach. See General requirements and considerations.
File Access - Delete file	Use Bypass approach. See General requirements and considerations.
FTP - put	Use Bypass approach. See General requirements and considerations.
IDM - Add	Use Undo approach if possible, otherwise use Bypass approach. See General requirements and considerations.
IDM - Delete	Use Bypass approach. See General requirements and considerations.
IDM - Update	Use Bypass approach. See General requirements and considerations. Redoing the update should only be performed if one can verify that the value has not changed since the previous update.
Infor Lawson Adapter	Use Undo approach if possible, otherwise use Bypass approach. See General requirements and considerations.
Infor Lawson Form Transaction	Use Undo approach if possible, otherwise use Bypass approach. See General requirements and considerations.
Infor Lawson Transaction	Use Bypass approach if possible, otherwise: Create action: Duplicate Error on Creates: add a clean-up node at the end to delete errors on duplicates as FHR may be doing this. See Duplicate error suspension in Patterns. Update action: See Query-Create and Query-Update in Patterns. Future or effective dated records: Ensure there is a query followed by an update. We do not want to create future or effective dated records twice. See Query-Create and Query-Update in Patterns. Date fields in the key should not be restartable without extensive testing.
ION Alert	Use Bypass approach. See General requirements and considerations.
Inbox update	Use Bypass approach. See General requirements and considerations. Redoing the update should only be performed if one can verify that the value has not changed since the previous update.
ION Notification	Use Bypass approach. See General requirements and considerations.
ION Outbox	Use Bypass approach. See General requirements and considerations. The ION BOD could have been picked up and processed by the consumer. Use a LmrkTxn to create a variable indicating we are sending a BOD, and another transaction afterward that indicates the BOD was sent. Use a branch node checking to see if this is a restart or not. Branch should have a User Action node to have someone manually check to see if the BOD was sent and received. Provide actions on the UserAction node to send again or do not send again.
Landmark Admin	Unless the command being executed can be safely restarted, use Bypass approach. See General requirements and considerations.
Landmark Transaction	Use Bypass approach if possible, otherwise: Create action: Duplicate Error on Creates: Add a clean-up node at the end to delete errors on duplicates as FHR may be doing this. See Duplicate error suspension in Patterns. Update action: See Query-Create and Query-Update in Patterns. Future or effective dated records: Ensure there is a query followed by an update. We do not want to create future or effective dated records twice. See Query-Create and Query-Update in Patterns. Date fields in the key should not be restartable without extensive testing.
M3 Transaction	Use Undo approach if possible, otherwise use Bypass approach. See General requirements and considerations.
MsgBuilder	Using Bypass approach will be cleaner. See General requirements and considerations. Otherwise, the MsgBuilder variable would need to be re-initialized before re-running.
Queue nodes (JMS/Cloverleaf/Websphere MQ)	Duplicate messages occur if re-run. If the consumer is unable to handle duplicates, then use Bypass approach. See General requirements and considerations.
Resource Update	Use Bypass approach. See General requirements and considerations. Redoing the update should only be performed if one can verify that the value has not changed since the previous update.
SubProcess	Use Bypass approach or re-run only if the sub-process is restartable. See General requirements and considerations.
Trigger	Use Bypass approach or re-run only if the triggered process is save to be run again. See General requirements and considerations.
WebRun send/post	Use Bypass approach or re-run if possible. See General requirements and considerations.
Web Service/SOAP	Use Bypass approach or re-run if possible. See General requirements and considerations.

For flows that write to files:

Use case example: sending data to a vendor
The last node before the flow ends is the one that should send the data: extract data, build in-memory, write to a file, send the file. Create a pseudo checkpoint by using a LmrkTxn to modify a PfiWorkunit variable indicating data completed.

For restart logic, build data into a specific location such as PfiFileStorage or one that is present on the SFTP server, configured as transfer and delete; if the file is still present then send to vendor, otherwise start at the beginning.

Data consumption

This table shows the node-specific best practices for data consumption:


Activity node	Consideration or recommendation if node cannot be re-run
Data Exchange - Inbound	Use Save data approach or re-run if possible. Otherwise, use the Too much data and not restartable approach. See General requirements and considerations.
Data Iterator	Use Save data approach or re-run if possible. Otherwise, use the Too much data and not restartable approach. See General requirements and considerations.
File Access - Read from file	Use Save data approach or re-run if possible. Otherwise, use the Too much data and not restartable approach. See General requirements and considerations.
File Access - Check file exists	Use Save data approach. Re-running might return a different result. See General requirements and considerations.
File Access - List files	Use Save data approach. Re-running might return a different result. See General requirements and considerations.
FTP - get	Use Save data approach or re-run if possible. Otherwise, use the Too much data and not restartable approach. See General requirements and considerations.
IDM - Retrieve	Use Save data approach or re-run if possible. Otherwise, use the Too much data and not restartable approach. See General requirements and considerations.
Infor Lawson Query	Use Save data approach or re-run if possible. Otherwise, use the Too much data and not restartable approach. See General requirements and considerations.
Inbox query	Use Save data approach or re-run if possible. Otherwise, use the Too much data and not restartable approach. See General requirements and considerations.
LDAP Query	Use Save data approach or re-run if possible. Otherwise, use the Too much data and not restartable approach. See General requirements and considerations.
Resource Query	Use Save data approach or re-run if possible. Otherwise, use the Too much data and not restartable approach. See General requirements and considerations.
Sub Process	Use Save data approach or re-run if possible. Otherwise, it is not restartable. See General requirements and considerations.
WebRun query/get	Use Save data approach or re-run if possible. Otherwise, use the Too much data and not restartable approach. See General requirements and considerations.
Web Service/SOAP	Use Save data approach or re-run if possible. Otherwise, use the Too much data and not restartable approach. See General requirements and considerations.

For inbound data:

File channel flows: data is processed in-memory, and file written to an archive directory; upon restart the flow would fail. Check the destination to see if the source file exists; do this with a check point record with a PfiWorkUnit variable. Branch around the file cleanup part of the flow in the case of a restart.
FTP is similar. Transfer-and-delete.

User action and approval

Most User Action flows today are written in a way that make them auto-restartable, but restartable from the last User Action node.
You can restart flows using IPA Approval business classes. For example, APIA approval tracks its data in their own application classes. Requisition Approvals, however, uses IPA Approval History stored in IPA Metrics. APIA flows then are not necessarily restartable and need to be reviewed.

Miscellaneous nodes

This table shows node-specific best practices for miscellaneous nodes:


Activity node	Consideration or recommendation
Branch	Branch node can simulate a ForLoop, and should be dealt with similar to Iteration nodes
Iteration nodes	Should be evaluated to see if it can be restarted

Patterns

Table 1. Duplicate error suspension
Description	Recommendation	Cases
Pertaining to processing an individual record at a time in a loop as defined in the flow, a duplicate error can occur upon attempting to create the record again after a restart has happened, and the record was already created prior to the restart by the flow. The duplicate error shows up as an error the work unit and requires someone with knowledge of the flow and the data to review and ensure that the reported duplicate error is in fact an artifact of a restart.	To avoid this, use a LmrkTxn before the flow end, to review PfiErrorMessage, and delete duplicate errors. Use error handling for duplicates on LmrkTxn nodes if there are legitimate reasons for duplicate errors.	LmrkTxn that processed a set of records: Use a PfiWorkunitVariable variable and a branch node to skip this LmrkTxn if already completed. Update action: If there is a possibility that a record was updated since last flow runtime, and re-running the flow during a restart would overwrite the already-changed values, there would need to be flow logic to check the values of the record or skip updating.

Table 2. Query-Create and Query-Update
Description	Recommendation
A duplicate error message is created if a Create happens after a restart, on a record that was already created. Besides cleaning up duplicate errors, they can be avoided by instead querying to see if the record exists first prior to a Create, or checking values of a record prior to an Update.	Query for a record, and check the values of the record to see if they matches, and skip if matching. Submit the Create or Update if not matching.