enting everywhere is:
Input Port [Failed Flowfile] --> PutS3 deadletter///${uuid} --> PutSlack
ListS3 deadletter/// --> FetchS3 -> Output
Port [Fixed]
This gives me storage of failed messages logically grouped and in a place that
wont block up my flow since s3 never goes down, err..
No confusion, Nick. I hear you. In our case...
We attempt to reroute flowfile back through processors that, for
whatever reason, might bring them to a state in which they can be
successful (much to explain there, but...) and others we route to a
similar, "deadletter" s
and fix them
> manually.
>
> This leads me to https://issues.apache.org/jira/browse/NIFI-3351. I think
> I need a way to store failed flowfiles, fix them and reprocess them. The
> process group I am currently considering implementing everywhere is:
>
> Input Port [Failed Flowfile] -
need a way to store failed flowfiles, fix them and reprocess them. The process
group I am currently considering implementing everywhere is:
Input Port [Failed Flowfile] --> PutS3 deadletter///${uuid} --> PutSlack
ListS3 deadletter/// --> FetchS3 -> Output
Port [Fixed]
This gives me st
failed flowfiles, fix them and reprocess them. The
process group I am currently considering implementing everywhere is:
Input Port [Failed Flowfile] --> PutS3 deadletter///${uuid} --> PutSlack
ListS3 deadletter/// --> FetchS3 ->
Output Port [Fixed]
This gives me storage of failed messag
