General requirements and considerations

Data generation

Flows with activity nodes that produce or create output data must ensure that the same data is always accepted by the consumer of that data. For example:
  • The destination (FileStorage, FTP site, etc.) should always allow the same file (with same content) to be created or overwritten.
  • The target of the WebService, WebCall, etc., should always accept the same data being sent, possibly multiple times.
If the above requirements cannot be met, the flow will do one of these prior to re-running the activity node:
  • Undo approach
    Undo the previous node execution:
    • Delete or remove the file created by the previous workunit execution.
    • Delete or cancel the transaction created by the previous execution.
  • Bypass approach

    Flow logic can be put in place to bypass the activity node that already generated data in the previous workunit execution.

Data consumption

Flows with activity nodes that consume, read, or get input data must ensure that the same data can always be generated by the producer of that data. For example:
  • Source file (FileStorage, FTP site, etc.) should be persistent and unmodified. If the workunit is restarted, the file must still be available, and have the same content.
  • Source data (result of Landmark query, WebService call, etc.) must be the same for every call - given the same query parameter or filter, the same data must be returned.

If the above requirements cannot be met, the flow will do this after the activity node finishes:

Save data approach: If the data volume is small, save a copy of the data that was retrieved in PfiWorkunitVariable as needed. Upon workunit restart, flow logic can be put in place to use the saved data and bypass the activity node.

Otherwise, if the incoming data is too much to save and the query could not be re-run (to get the same data), the flow becomes not restartable (too much data and not restartable).

Miscellaneous

  • Capture restart number attempts (0 == first run, anything greater indicates it is in a restart run). Doing this would allow logic in branch nodes to check to see if there are existing records.
  • Create PfiWorkunitVariable variables for anything that needs to be persisted related to what the flow is doing (for example, request IDs made to third party vendor for background check data).

Situation that causes a flow to not be restartable

  • ION Inbound BOD processing
    • For example, processing message 1 fails due to a ZDT update. When the system comes back up, message 2 is processed successfully because it is next in queue, then IPA processes message 1, possibly overwriting subsequent changes from message 2.