Hi Adel. Thanks for the info. i will try this one and see. The OML i have currently i something i cannot share as it is in my organization's server. Maybe i can recreate it in my personal enviroment then share here it here. The screenshot the send, is the OML available for sharing, so that i can try to refer to it to see i can make my existing one work or not. Give me some time, i will share my personal OML soon 

Hi Killian. It looks like the built in functionality for multipart is for consume api only. In my case i need to send an excel file uploaded into outsystems, to be sent to an external server through expose API. 

so this is how it looks...when user uploads file it will be like 

The variables and client action for this feature 

I followed this exactly like in the youtube tutorial. i believe file uploaded here only remains in the variable. not stored anywhere else within outsystems

so what i want is the uploaded files to be send to my external server through expose rest api. ..so this is where i am stuck.
first i want to know those files need to be stored in an entity or not. if yes, i doubt it can save multiple file uploaded in at once by a user can be stored as single record. 
Then from here i would like to know the way to create the expose api, so that i can send this files to my backend server which is an python api flask application. so when i consume this outsystems endpoint in my backend python application, it should be stored in a specified folder within the server.

is this possible?

Hi Alekandram,

You are asking a lot of questions, about a lot of different subjects. I'll try to answer them as far as space here allows:

1. If you want to expose a REST API that receives multipart/form-data, you indeed need this Forge asset. It wasn't clear to me that you wanted to expose, rather than consume, a multipart/form-data API;
2. Like with all REST APIs you expose, you receive the data from the caller of the API, and you need to handle that data. Basically, an exposed REST API method is just like any other Action, in that you need to handle whatever input you get;
3. Whether you want to store the files in the database is up to you. In general, this is a good idea if you want to have them available or process them at a later stage;
4. If you receive multiple files at once, you should probably store them in the database one by one (the alternative is just storing the entire received message, but I wouldn't do that);
5. If you want to send files to another API, you are not exposing the API, but consuming it. So if you have an API set up in Python, you need to consume the Python REST API;
6. If you consume a Python API, and you are sending files to it, storing those files is of course something your Python API must handle;
7. You can store the files wherever the Python API can store them. Obviously, if Python is not running on your server, then you cannot store any files on that server.