nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damiano Giampaoli <Dami...@searchink.com>
Subject About NIFI-3620: Multipart support in invokeHTTP.java
Date Mon, 11 Dec 2017 16:10:37 GMT
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:diahala@searchink.com> <mailto:damiano@searchink.com> damiano@searchink.com<mailto:damiano@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.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message