RE: About NIFI-3620: Multipart support in invokeHTTP.java

2017-12-12 Thread Damiano Giampaoli
Ciao Pierre,

I can spend some hours tomorrow looking deep in the invokeHTTP implementation 
and figure out a way to properly support Multipart messages, then write back in 
the ML asking for feedback before implementing it. 
@Andre in case you have already some code or ideas I'll be glad to follow it!


Best regards
Damiano

-Original Message-
From: Pierre Villard [mailto:pierre.villard...@gmail.com] 
Sent: Tuesday, December 12, 2017 11:25 AM
To: dev <dev@nifi.apache.org>
Subject: Re: About NIFI-3620: Multipart support in invokeHTTP.java

Hey Damiano,

Andre will correct me in case I'm wrong but he is not working on
https://issues.apache.org/jira/browse/NIFI-3620 at the moment. If you want to 
give it a try, that would be more than appreciated.

Pierre

2017-12-11 18:01 GMT+01:00 Joe Witt <joe.w...@gmail.com>:

> Hello
>
> Sounds great.  I think i might have dropped the ball on that review by 
> commenting on it and then it made others who might be able to help 
> avoid it.  Just commented on the PR again but we're of course happy to 
> work with you to improve as needed.
>
> Thanks
> Joe
>
> On Mon, Dec 11, 2017 at 11:10 AM, Damiano Giampaoli 
> <dami...@searchink.com> wrote:
> > Hi list,
> >
> >
> > We are planning to move from our in-house-built workflow engine to
> NiFi... needless to say, we love this project.
> >
> > We created a PoC of some our production workflows using NiFi but in
> order to move entirely to NiFi we need a full multipart support in 
> order to be able to invoke some of our internal microservices.
> >
> >
> > I saw there is already a pending PR for the ListenHTTP multipart 
> > support<
> https://github.com/apache/nifi/pull/1795> and an issue already opened 
> about the InvokeHTTP<https://issues.apache.org/jira/browse/NIFI-3620>
> which is marked as in progress.
> >
> >
> > We are willing to contribute to the developments starting from 
> > adding
> the multipart support but before we would like to ensure that there 
> are no other developers who are already working on this, in case we 
> can provide support in testing, complete or bugfix a work not ready 
> yet to be merged in the master branch.
> >
> >
> >
> > We are looking forward to hearing from you!
> >
> >
> > Best regards,
> >
> > Damiano
> >
> >
> >
> > SearchInk
> >
> >
> >
> > Damiano Giampaoli
> >
> > Software Engineer
> >
> >
> >
> > mobile:  +49 1719956912
> >
> > email:  <mailto:diah...@searchink.com> 
> > <mailto:dami...@searchink.com>
> dami...@searchink.com<mailto:dami...@searchink.com>
> >
> >
> >
> > #execcircle17<http://searchink.com/ecircle> event: Connecting
> Innovators & Insurers
> >
> > Join our team: searchink.com/careers<http://searchink.com/careers>
> >
> >
> >
> > Koppenplatz 10, D-10115 Berlin
> > +49 30 220 560 730
> >
> > www.searchink.com<http://www.searchink.com/>
> >
> >
> >
> > HRB 171236 B, Amtsgericht Charlottenburg, Berlin |  UID: DE302404693
> >
> > This e-mail and any attached files are confidential and may be 
> > legally
> privileged. If you are not the addressee, any disclosure, 
> reproduction, copying, distribution, or other dissemination or use of 
> this communication is strictly prohibited. If you have received this 
> transmission in error please notify the sender immediately and then delete 
> this mail.
> >
> > E-mail transmission cannot be guaranteed to be secure or error free 
> > as
> information could be intercepted, corrupted, lost, destroyed, arrive 
> late or incomplete, or contain viruses. The sender therefore does not 
> accept liability for any errors or omissions in the contents of this 
> message which arise as a result of e-mail transmission or changes to 
> transmitted date not specifically approved by the sender.
> >
> > If this e-mail or attached files contain information which do not 
> > relate
> to our professional activity we do not accept liability for such 
> information.
> >
>


About NIFI-3620: Multipart support in invokeHTTP.java

2017-12-11 Thread Damiano Giampaoli
Hi list,


We are planning to move from our in-house-built workflow engine to NiFi... 
needless to say, we love this project.

We created a PoC of some our production workflows using NiFi but in order to 
move entirely to NiFi we need a full multipart support in order to be able to 
invoke some of our internal microservices.


I saw there is already a pending PR for the ListenHTTP multipart 
support<https://github.com/apache/nifi/pull/1795> and an issue already opened 
about the InvokeHTTP<https://issues.apache.org/jira/browse/NIFI-3620> which is 
marked as in progress.


We are willing to contribute to the developments starting from adding the 
multipart support but before we would like to ensure that there are no other 
developers who are already working on this, in case we can provide support in 
testing, complete or bugfix a work not ready yet to be merged in the master 
branch.



We are looking forward to hearing from you!


Best regards,

Damiano



SearchInk



Damiano Giampaoli

Software Engineer



mobile:  +49 1719956912

email:  <mailto:diah...@searchink.com> <mailto:dami...@searchink.com> 
dami...@searchink.com<mailto:dami...@searchink.com>



#execcircle17<http://searchink.com/ecircle> event: Connecting Innovators & 
Insurers

Join our team: searchink.com/careers<http://searchink.com/careers>



Koppenplatz 10, D-10115 Berlin
+49 30 220 560 730

www.searchink.com<http://www.searchink.com/>



HRB 171236 B, Amtsgericht Charlottenburg, Berlin |  UID: DE302404693

This e-mail and any attached files are confidential and may be legally 
privileged. If you are not the addressee, any disclosure, reproduction, 
copying, distribution, or other dissemination or use of this communication is 
strictly prohibited. If you have received this transmission in error please 
notify the sender immediately and then delete this mail.

E-mail transmission cannot be guaranteed to be secure or error free as 
information could be intercepted, corrupted, lost, destroyed, arrive late or 
incomplete, or contain viruses. The sender therefore does not accept liability 
for any errors or omissions in the contents of this message which arise as a 
result of e-mail transmission or changes to transmitted date not specifically 
approved by the sender.

If this e-mail or attached files contain information which do not relate to our 
professional activity we do not accept liability for such information.