Tom,
Acknowledged a bit of pain here. This was recently discussed in the Dev
mailing list about this functionality going away, and yes, it's definitely
going away. So you're aware, this deprecation will be locked in when NiFi
2.0 is released (in the near future). That being said, there are a few
solutions for you...
1. You can bundle up your flowfiles using the MergeContent processor. You
will generally want to choose the "FlowFile Stream v3" format. With this
configuration, MergeContent will grab a batch of flowfiles and serialize
them into a format that captures all of the flowfile attributes and
payload. It's a very simple protocol underneath the hood, basically just a
binary concatenation style of format. It does capture all of the
attributes, which can then be extracted on the receiving side.
On the receiving side, you will want to configure the UnpackContent
processor, again with the "FlowFile Stream v3" configuration. This will
effectively unwind the bundle and recreate all of your original flowfiles.
Note that there are a couple of attributes that will be completely lost in
this process. Specifically, the flowfile uuid will not be updated to the
original value. So if you need to maintain the original flowfile id, you
will need to copy it (using UpdateAttribute) before running through
MergeContent on the sender.
You would use InvokeHTTP and ListenHTTP as your transport for this option.
The complete workflow would look something like:
[Sender] ... -> MergeContent -> InvokeHTTP (using POST) -> { ... } ->
[Receiver] ListenHTTP -> UnpackContent -> ...
2. You can also configure NiFi to talk to another NiFi using the "site to
site" capability. The setup for this is a bit more complicated and may not
necessarily work for your network topology. But it's there as an option and
used by many people successfully. And it's pretty cool, because it's
configured more like a processor group rather than a processor chain (as in
#1 above). Site-to-site supports both "raw" (raw socket) and "http"
transport protocols. There's plenty of good documentation about this, but
here's the user manual entry for it:
https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#site-to-site
I think in general, the second approach (site-to-site) would be preferred.
But after experimenting with it or based on some characteristics of your
network, you might find favor with the first method. Additionally, the
first approach is probably closer to your existing dataflow configuration
today, if you're just simply trying to model the behavior you had with
deprecated PostHTTP.
Hope this helps.
/Adam
On Wed, Feb 8, 2023 at 11:23 AM Tom Horvath via users <[email protected]>
wrote:
> Hello,
>
> I’d like to use the InvokeHTTP processor instead of the PostHTTP processor
> because the PostHTTP processor is deprecated but I cannot figure out how to
> configure it to send the flow file attributes along with the content
> similar to how the PostHTTP processor does, when the send as flow file
> option is set to true. I want to maintain the attributes across the sites.
> Can someone assist?
>
> Regards,
> Tom
>
