Bryan’s comments are definitely helpful around the additional work separation, but revisiting your initial question, did you try using Site To Site through the proxy? Koji Kawamura has done a lot of work on this [1][2] and I believe it’s pretty successful. There are example configurations and diagrams in the Admin Guide [3][4][5].
[1] https://cwiki.apache.org/confluence/display/NIFI/Support+HTTP%28S%29+as+a+transport+mechanism+for+Site-to-Site#SupportHTTP(S)asatransportmechanismforSite-to-Site-ToStandaloneNiFi:HTTPusingProxy <https://cwiki.apache.org/confluence/display/NIFI/Support+HTTP(S)+as+a+transport+mechanism+for+Site-to-Site#SupportHTTP(S)asatransportmechanismforSite-to-Site-ToStandaloneNiFi:HTTPusingProxy> [2] https://issues.apache.org/jira/browse/NIFI-1857 <https://issues.apache.org/jira/browse/NIFI-1857> [3] https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#proxy_configuration <https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#proxy_configuration> [4] https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#site_to_site_reverse_proxy_properties <https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#site_to_site_reverse_proxy_properties> [5] https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#site-to-site-and-reverse-proxy-examples <https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#site-to-site-and-reverse-proxy-examples> Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On May 16, 2019, at 8:31 AM, Bryan Bende <[email protected]> wrote: > > I think it might be simpler to implement it as a separate > PackageContent processor that you would use right before InvokeHttp. > Only because InvokeHttp is already quite complex, and really the > packaging is a separate function from the http interaction. > > PackageContent would be the reverse of UnpackContent. > > On Thu, May 16, 2019 at 11:26 AM Michael Di Domenico > <[email protected]> wrote: >> >> On Thu, May 16, 2019 at 11:20 AM Bryan Bende <[email protected]> wrote: >>> >>> Well MergeContent in general is meant to take many flow files and >>> merge them together, so typically if you were using the flow file >>> format, the idea would be to create a single flow file where the >>> content contained (flow1 attrs, content)(flow 2 attrs, content) etc, >>> but what I was suggesting was to try to configure the processor in a >>> way that it never actually merges multiple flow files and just acts on >>> 1 flow file. Essentially trying to use the packaging functionality of >>> MergeContent without the merging, since there is no corresponding >>> PackageContent processor to go with the UnpackContent processor. >> >> Oh, i see. I'll give it a try and see. >> >> Do you know how hard it would be to get the "Send flow" added into >> invokehttp?
