Recommendation by category

Data generation

This table shows the node-specific best practices for data generation:
Note: Starting 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 for details.
Email/Social/SMS Use Bypass approach. See General requirements and considerations for details.
Event Hub Publisher Use Bypass approach. See General requirements and considerations for details.
File Access - Write to file Use Bypass approach. See General requirements and considerations for details.
File Access - Append to file Use Undo approach if possible, otherwise use Bypass approach. See General requirements and considerations for details.
File Access - Delete file Use Bypass approach. See General requirements and considerations for details.
FTP - put Use Bypass approach. See General requirements and considerations for details.
IDM - Add Use Undo approach if possible, otherwise use Bypass approach. See General requirements and considerations for details.
IDM - Delete Use Bypass approach. See General requirements and considerations for details.
IDM - Update Use Bypass approach. See General requirements and considerationsfor details. 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 for details.
Infor Lawson Form Transaction Use Undo approach if possible, otherwise use Bypass approach. See General requirements and considerations for details.
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 for details.
  • Update action:
    • See Query-Create and Query-Update in Patterns for details.
  • 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 for details.
    • Date fields in the key should not be restartable without extensive testing.
ION Alert Use Bypass approach. See General requirements and considerations for details.
Inbox update Use Bypass approach. See General requirements and considerations for details. 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 for details.
ION Outbox Use Bypass approach. See General requirements and considerations for details. 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 (similar to above). 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 for details.
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 for details.
  • Update action:
    • See Query-Create and Query-Update in Patterns for details.
  • 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 for details.
    • 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 for details.
MsgBuilder Using Bypass approach will be cleaner. See General requirements and considerations for details. Otherwise, the MsgBuilder variable would need to be re-initialized before re-running.
Queue nodes (JMS/Cloverleaf/Websphere MQ) Duplicate messages will occur if re-run. If the consumer is unable to handle duplicates, then use Bypass approach. See General requirements and considerations for details.
Resource Update Use Bypass approach. See General requirements and considerations for details. 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 for details.
Trigger Use Bypass approach or re-run only if the triggered process is save to be run again. See General requirements and considerations for details.
WebRun send/post Use Bypass approach or re-run if possible. See General requirements and considerations for details.
Web Service/SOAP Use Bypass approach or re-run if possible. See General requirements and considerations for details.
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 for details.
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 for details.
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 for details.
File Access - Check file exists Use Save data approach. Re-running might return a different result. See General requirements and considerations for details.
File Access - List files Use Save data approach. Re-running might return a different result. See General requirements and considerations for details.
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 for details.
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 for details.
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 for details.
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 for details.
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 for details.
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 for details.
Sub Process Use Save data approach or re-run if possible. See General requirements and considerations for details. Otherwise, it is not restartable.
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 for details.
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 details.
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 already written in a way that make them auto-restartable, but restartable from the last User Action node.
  • Flows using IPA Approval business classes can already be restarted. 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 will be 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.