Stefán, It sounds like you figured it out and understand the port strategy now. If you are still interested in communicating between distinct nodes without running a full NiFi installation on each, you should take a look at the subproject MiNiFi [1] which provides both Java and C++ “agents” — lightweight footprint “guest” processes which can run on limited hardware and perform a subset of the full NiFi behavior (no UI, etc.) and connect back over the Site to Site protocol to a full NiFi instance. Your original question may no longer apply given your new understanding, but if it does, this may be the solution you’re looking for.
[1] https://nifi.apache.org/minifi/index.html <https://nifi.apache.org/minifi/index.html> Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Dec 2, 2016, at 2:31 AM, Stefán Baxter <[email protected]> wrote: > > Hi again, > > This was indeed silly. When asking I was assuming that Processes were > available remotely, not "just" the IN/OUT ports. > > I can see how the port-only strategy is a good thing. > > All the best, > -Stefán > > On Thu, Dec 1, 2016 at 9:03 PM, Stefán Baxter <[email protected]> > wrote: > >> Hi, >> >> This may be a silly question, please forgive me. >> >> We are trying integrating our platform with Nifi in an as efficient way as >> possible and we have been implementing the same "port based" integrations >> as used for stream processing solutions. >> >> The nifi-site-to-site-client library makes this very easy but the IN or >> OUT port approach seems slightly "disjoint", at least in comparison with >> remote process groups which support both IN and OUT >> >> And here is the question. Is there a library available which would allow a >> solution to provide a Nifi compatable "Remote Process Group" service >> without being a complete Nifi server? >> >> All the best, >> -Stefán >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
