Testing processor from UI

[Pierre Villard <pi...@gmail.com>]

Hi team,

Matt has just proposed a great tool helping users in testing scripts into
ExecuteScript processor. And I thought that allowing users to test
processors directly from the UI would be great and save time (when creating
a flow I personally spend time to route my flow files into various
processors to check that I configured the processor correctly to do the
job, or to test some failure cases).

What do you think about the following proposition:

On UI side, there would be a "Testing" tab (see picture, credits Paint),
allowing user (if the processor accepts inputs) to manually enter
attributes (a little bit like ambari with configuration properties : one by
one or in batch mode) and content (with a textarea input like in the
Comments tab), and a button "Test" (enabled only if required processor
properties are set).

When clicking on the button "Test" it would kind of execute the onTrigger
method of the processor and would (for example) open a pop-up with the
generated flow file(s) (the pop-up could have one tab by outgoing
relationship to display attributes/content of every flow file). I think the
best would probably be to execute the method without generating provenance
events, and the generated flow file(s) would be auto-terminated (not really
sent to outgoing relationships).

Obviously, I don't know well enough the whole framework to foresee all the
changes/complications it could introduce. I guess that we would need to
update the ProcessSession to change the behavior in case of a "test
execution".

What do you think? Does it sound like something interesting?

Note: on UI side, I wouldn't be able to help much (as you can judge by
yourself with my Paint skills) but if needed I could help on server side.

Pierre

Re: Testing processor from UI

[Joe Witt <jo...@gmail.com>]

Absolutely a great idea.

With the feature proposal for interactive queue management which has
some parts done one of the things desired was the ability to upload
flowfiles directly to a given queue.  It would be helpful then too to
make it really easy to author/paste in attributes/content as you
mention.  I think whether a processor is in test mode or not is just a
function of what it is connected to but we should absolutely make it
easy for the user to do the type of validation you describe.

Thanks
Joe

On Fri, Apr 29, 2016 at 4:26 AM, Pierre Villard
<pi...@gmail.com> wrote:
> Hi team,
>
> Matt has just proposed a great tool helping users in testing scripts into
> ExecuteScript processor. And I thought that allowing users to test
> processors directly from the UI would be great and save time (when creating
> a flow I personally spend time to route my flow files into various
> processors to check that I configured the processor correctly to do the job,
> or to test some failure cases).
>
> What do you think about the following proposition:
>
> On UI side, there would be a "Testing" tab (see picture, credits Paint),
> allowing user (if the processor accepts inputs) to manually enter attributes
> (a little bit like ambari with configuration properties : one by one or in
> batch mode) and content (with a textarea input like in the Comments tab),
> and a button "Test" (enabled only if required processor properties are set).
>
> When clicking on the button "Test" it would kind of execute the onTrigger
> method of the processor and would (for example) open a pop-up with the
> generated flow file(s) (the pop-up could have one tab by outgoing
> relationship to display attributes/content of every flow file). I think the
> best would probably be to execute the method without generating provenance
> events, and the generated flow file(s) would be auto-terminated (not really
> sent to outgoing relationships).
>
> Obviously, I don't know well enough the whole framework to foresee all the
> changes/complications it could introduce. I guess that we would need to
> update the ProcessSession to change the behavior in case of a "test
> execution".
>
> What do you think? Does it sound like something interesting?
>
> Note: on UI side, I wouldn't be able to help much (as you can judge by
> yourself with my Paint skills) but if needed I could help on server side.
>
> Pierre
>
>