I believe this is a Launch Service design, CloverETL Ninja; level 24.
Got an idea though. Broken down, that would look like:
- Create an output dictionary as writable channel and content type set to something like multipart/mixed; boundary="..."
- Build pieces of your multipart response in different writers; or one, depending what you'd like your parts to look like (use write to port to do that)
- Add to your raw data specific content types and boundary closures
- Write the whole string in stream to the output
- All of the above as dictated by W3C RFC1341 https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
All of the above also completely untested and strictly theoretical. Let me know if that works :)) See attached screenshots as I'd imagine it.
But since not so many systems are capable of consuming multipart responses; what I'd suggest is to use combination of input parameters which would format the output as desired and implement caching algorithm, so you can store the raw data and format upon next (separate) request.You'll get the same thing with less on an headache, but multiple calls of the same LS endpoint.
Or, as Pedro suggested. Zip/Tarball bunch of files together and return it.
Is that your project requirement or what is the drive of having multipart response if you don't mind me asking?