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_mis...@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. >