You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Brajendra Mishra <br...@persistent.com> on 2018/05/08 05:10:28 UTC

NiFi REST APIs : How to create flows through 'nifi-api'

Hi Mike and Sivaprasanna,

Could you please provide few examples where I can create Flows, process groups, processors, connector services and input and output port through 'nifi-api' REST APIs?

I need your suggestion on one approach, where I want to create one flow and create processors (through nifi-api) based on specific input requests (like if input is 'abc' then create getFile processor and if input is 'xyz' then create 'GetMongoDB' processor).

In above scenario which approach should be more feasible (with respect to NiFi performance). I have figured out following 2 approaches:


  1.  All inputs should be handled by one 'router' processor and based on input it redirects and create specific processor.
  2.  Input should be specific at time of given inputs and flow will be individual for each processor.

Please suggest.

Brajendra Mishra
Persistent Systems Ltd.

DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.

Re: NiFi REST APIs : How to create flows through 'nifi-api'

Posted by Mike Thomsen <mi...@gmail.com>.
Brajendra,

The NiFi API is typically called from external clients, not from within a
flow. With that said, as far as I understand your use case I don't think
it's going to work out that well for you. What you seem to want to do here
is programatically create new processors to handle new situations as they
come in, but you don't need to do that. For example, GetMongo is already
parameterized w/ expression language and can take input queries from
upstream processors in 1.6. So what you'd be better off doing is building a
flow with upstream processors that tell GetMongo where to go (db +
collection) and what query to use using that approach instead of using the
REST APIs to tweak GetMongo.

WRT GetFile, my best suggestion would be to put a min secs of 5-10 in the
minimum age field and then just build in one processor. You're going to
have to figure out how to get files to a path that NiFi can see anyway, so
that's where your focus should be on that.

For you, starting with a message queue processor would probably be a better
approach. You might also need to get your hands a little dirty there and
add ExecuteScript or EvaluateJSONPath to read the incoming message and pull
out some properties from the message.

On Tue, May 8, 2018 at 1:10 AM Brajendra Mishra <
brajendra_mishra@persistent.com> wrote:

> Hi Mike and Sivaprasanna,
>
> Could you please provide few examples where I can create Flows, process
> groups, processors, connector services and input and output port through
> 'nifi-api' REST APIs?
>
> I need your suggestion on one approach, where I want to create one flow
> and create processors (through nifi-api) based on specific input requests
> (like if input is 'abc' then create getFile processor and if input is 'xyz'
> then create 'GetMongoDB' processor).
>
> In above scenario which approach should be more feasible (with respect to
> NiFi performance). I have figured out following 2 approaches:
>
>
>   1.  All inputs should be handled by one 'router' processor and based on
> input it redirects and create specific processor.
>   2.  Input should be specific at time of given inputs and flow will be
> individual for each processor.
>
> Please suggest.
>
> Brajendra Mishra
> Persistent Systems Ltd.
>
> DISCLAIMER
> ==========
> This e-mail may contain privileged and confidential information which is
> the property of Persistent Systems Ltd. It is intended only for the use of
> the individual or entity to which it is addressed. If you are not the
> intended recipient, you are not authorized to read, retain, copy, print,
> distribute or use this message. If you have received this communication in
> error, please notify the sender and delete all copies of this message.
> Persistent Systems Ltd. does not accept any liability for virus infected
> mails.
>