Post: Multipart Upload

Note

This feature is only available on-premises, as of API Fortress version 20.2.0.
This feature also requires that you update the “remotedownloadagent” to the latest version as well.

The following instructions are to show how to make a POST call with an entire file included in the data.

Mounting a Volume

For multipart, API Fortress will look for files in the /data directory, so you’ll have to mount a volume to the /data directory. For example, if you’re using docker-compose, it’s done like this:

  • Navigate to the /core/ directory.
  • Stop “apifortress” but issuing the following command:
    sudo docker-compose stop apifortress
  • Open the “docker-compose.yml” file. 
  • There is a section labeled “#APIFORTRESS DASHBOARD”, at the bottom of this section there will be a “volumes” section.  
  • Here you will see “# – ./data:/data” you can uncomment this line by getting rid of the “#”
  • This will create a folder called “data” in the “/core/” directory.
    volumes:

- ./tomcat_conf/conf:/usr/local/tomcat/conf

# - ./bin:/usr/local/tomcat/bin

- ./data:/data
  • Now start the “apifortress” service again by issuing the following command:
    sudo docker-compose up -d apifortress

Make a Multipart POST Call

Now that we have a directory mounted we can make the POST call using a file from the “/data/” folder. 

  • You can add a “post parameter” to your POST call to load the file into.
  • Give the post parameter a name and craft the value using the following notation: “@file:filename.extension”.
  • If the name matches a file in the /data/ directory, then the whole form becomes a form-data type, and the file will be uploaded as a multipart.

Update Input

The update input component allows you to persist a variable defined inside of the test so that the value will be accessible outside the current scope of the test. Usually, the component is used in conjunction with the set variable component. First, we set a variable. Then, we make it available outside of the current test with the update input component. We pass the update input component the name of the variable that we need to persist outside of the test. The component will first try to update a variable of the same name in the current input set. If that doesn’t exist, it will search for a global variable of the same name. If there is no global variable of the same name, it will check the vault. If the variable doesn’t exist there, it will create one with the same name. Important note: the update input component works only outside of the composer. That is to say, it will only function when a test is executed from the Test List, the Scheduler, or via the API. In the image above, after calling the login endpoint, we have created a variable called access_token with the set var component. Then, we have updated the value with the update input component. In doing so,  the value of the variable will persist throughout and the value can be used in follow-on tests.  

Databases – JDBC (direct)

The JDBC component allows a test to query data from a database. Typical use cases are:
  • to retrieve data items to use as input data
  • to perform data driven testing
The currently supported databases are: MySQL, PostgreSQL, and Microsft SQL Server. Configuration keys:
  • Url: the JDBC url to the database. Depending on the database type, URLs will look like the following:
    • jdbc:mysql://database.example.com/databaseName
    • jdbc:postgresql://database.example.com/databaseName
    • jdbc:sqlserver://database.example.com;databaseName=databaseName;
  • Driver: the type of driver; you can choose it from the options available in the drop down:
    • org.postgresql.Driver
    • com.microsoft.sqlserver.jdbc.SQLServerDriver
    • com.mysql.jdbc.Driver
  • Username: the username to access the database
  • Password: the password to access the database
  • Content: the SQL query
  • Variable: the name of the variable that will store the results
The result of the query will be represented as an array where each item is a row. Every row is a key/value map, as in:
[
  {"id",123,"first_name":"John","last_name":"Doe"},
  {"id",456,"first_name":"Annie","last_name":"Doe"}
]
Therefore, you can then iterate over the results to use them according to your needs. To see another way to connect to a database using the API Fortress Helper Utility click here!

database data base sql mysql jdbc database data base sql mysql jdbc database data base sql mysql jdbc database data base sql mysql jdbc.

Delete

The I/O operations you can do are: GET, POST, PUT, PATCH and DELETE. From the composer, choose ‘Add Component’ and then choose the type of operation you want to do.   Once done, you will have a form to fill up: Parameters:
Name Type/Value Required
Url Url Yes
Variable String Yes
Expect String No
Mode ‘json’,’xml’, ‘html’,’text’ Yes
Params String No
Url: the url of the resource you want to test. It could be the full url of the resource or a string with variables using the $. (i.e. ‘https://domain/resourcename’ or ‘https://${domain}${endpoint}’) Variable: the name of the variable that contains the response. It will be the name you will refer during the test. Expect: it is an optional field and needs to be filled only if the expected behavior differs from a positive response (i.e. 404,500 vs. 200,201 etc.). This is useful when looking to test negative responses and validate error messages.

Possible values are ‘<statusCode>|VALID’ or ‘<statusCode>|INVALID‘. VALID means the payload type is the one selected in the “mode” field (JSON,XML), while INVALID means the opposite. Some examples:
  • 404|VALID : 404 is expected with valid payload
  • 422|VALID : 422 is expected with valid payload
  • 500|INVALID : 500 is expected with invalid payload
Multiple status codes can be expected by adding them all (i.e. 200|302|400|500|VALID) Mode: it’s the type of the response you want to test. Params: the optional list of params you want to add to the query string. To do so, tap on ‘Add parameter’. The params can either be a String value (in that case, the value will always be the same for all the requests; to do so, just put the value in the related field and choose ‘String value’ from the drop down menu) or a Variable (in that case the value will be taken dynamically and could changed from time to time; to do so, put the name of the variable inside the field and choose ‘Variable’ from the drop down menu). Using the above example: let’s say that varName is defined as a boolean value so it can be either ‘true’ or ‘false’, in that case, there will be two requests; the first one will be a GET request to ‘https://mydomain/endpoint?firstParam=paramValue&secondParam=true’, parsing it as ‘json’ and saving it in the ‘payload’ variable; the second one, will be a GET request to ‘https://mydomain/endpoint?firstParam=paramValue&secondParam=false’, parsing it as ‘json’ and saving it in the ‘payload’ variable. When all things are set up, you can confirm it by tapping on the ‘tick’ icon in the top right corner. After that, if you need to add headers, params or a body to the request you can do it by selecting the request and then tapping on the ‘Add component’: all the available components for each operation will be visible.

Config

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Header

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Post Param/Put Param/Patch Param/Delete Param

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Post Body/Put Body/Patch Body/Delete Body

Name Type/Value Required
Content-Type ‘application/json’, ‘text/plain’, ‘application/x-www-form-urlencoded’,’text/xml’ Yes
Content String No
 

Patch

The I/O operations you can do are: GET, POST, PUT, PATCH and DELETE. From the composer, choose ‘Add Component’ and then choose the type of operation you want to do.   Once done, you will have a form to fill up: Parameters:
Name Type/Value Required
Url Url Yes
Variable String Yes
Expect String No
Mode ‘json’,’xml’, ‘html’,’text’ Yes
Params String No
Url: the url of the resource you want to test. It could be the full url of the resource or a string with variables using the $. (i.e. ‘https://domain/resourcename’ or ‘https://${domain}${endpoint}’) Variable: the name of the variable that contains the response. It will be the name you will refer during the test. Expect: it is an optional field and needs to be filled only if the expected behavior differs from a positive response (i.e. 404,500 vs. 200,201 etc.). This is useful when looking to test negative responses and validate error messages.

Possible values are ‘<statusCode>|VALID’ or ‘<statusCode>|INVALID‘. VALID means the payload type is the one selected in the “mode” field (JSON,XML), while INVALID means the opposite. Some examples:
  • 404|VALID : 404 is expected with valid payload
  • 422|VALID : 422 is expected with valid payload
  • 500|INVALID : 500 is expected with invalid payload
Multiple status codes can be expected by adding them all (i.e. 200|302|400|500|VALID) Mode: it’s the type of the response you want to test. Params: the optional list of params you want to add to the query string. To do so, tap on ‘Add parameter’. The params can either be a String value (in that case, the value will always be the same for all the requests; to do so, just put the value in the related field and choose ‘String value’ from the drop down menu) or a Variable (in that case the value will be taken dynamically and could changed from time to time; to do so, put the name of the variable inside the field and choose ‘Variable’ from the drop down menu). Using the above example: let’s say that varName is defined as a boolean value so it can be either ‘true’ or ‘false’, in that case, there will be two requests; the first one will be a GET request to ‘https://mydomain/endpoint?firstParam=paramValue&secondParam=true’, parsing it as ‘json’ and saving it in the ‘payload’ variable; the second one, will be a GET request to ‘https://mydomain/endpoint?firstParam=paramValue&secondParam=false’, parsing it as ‘json’ and saving it in the ‘payload’ variable. When all things are set up, you can confirm it by tapping on the ‘tick’ icon in the top right corner. After that, if you need to add headers, params or a body to the request you can do it by selecting the request and then tapping on the ‘Add component’: all the available components for each operation will be visible.

Config

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Header

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Post Param/Put Param/Patch Param/Delete Param

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Post Body/Put Body/Patch Body/Delete Body

Name Type/Value Required
Content-Type ‘application/json’, ‘text/plain’, ‘application/x-www-form-urlencoded’,’text/xml’ Yes
Content String No
 

Put

The I/O operations you can do are: GET, POST, PUT, PATCH and DELETE. From the composer, choose ‘Add Component’ and then choose the type of operation you want to do.   Once done, you will have a form to fill up: Parameters:
Name Type/Value Required
Url Url Yes
Variable String Yes
Expect String No
Mode ‘json’,’xml’, ‘html’,’text’ Yes
Params String No
Url: the url of the resource you want to test. It could be the full url of the resource or a string with variables using the $. (i.e. ‘https://domain/resourcename’ or ‘https://${domain}${endpoint}’) Variable: the name of the variable that contains the response. It will be the name you will refer during the test. Expect: it is an optional field and needs to be filled only if the expected behavior differs from a positive response (i.e. 404,500 vs. 200,201 etc.). This is useful when looking to test negative responses and validate error messages.

Possible values are ‘<statusCode>|VALID’ or ‘<statusCode>|INVALID‘. VALID means the payload type is the one selected in the “mode” field (JSON,XML), while INVALID means the opposite. Some examples:
  • 404|VALID : 404 is expected with valid payload
  • 422|VALID : 422 is expected with valid payload
  • 500|INVALID : 500 is expected with invalid payload
Multiple status codes can be expected by adding them all (i.e. 200|302|400|500|VALID) Mode: it’s the type of the response you want to test. Params: the optional list of params you want to add to the query string. To do so, tap on ‘Add parameter’. The params can either be a String value (in that case, the value will always be the same for all the requests; to do so, just put the value in the related field and choose ‘String value’ from the drop down menu) or a Variable (in that case the value will be taken dynamically and could changed from time to time; to do so, put the name of the variable inside the field and choose ‘Variable’ from the drop down menu). Using the above example: let’s say that varName is defined as a boolean value so it can be either ‘true’ or ‘false’, in that case, there will be two requests; the first one will be a GET request to ‘https://mydomain/endpoint?firstParam=paramValue&secondParam=true’, parsing it as ‘json’ and saving it in the ‘payload’ variable; the second one, will be a GET request to ‘https://mydomain/endpoint?firstParam=paramValue&secondParam=false’, parsing it as ‘json’ and saving it in the ‘payload’ variable. When all things are set up, you can confirm it by tapping on the ‘tick’ icon in the top right corner. After that, if you need to add headers, params or a body to the request you can do it by selecting the request and then tapping on the ‘Add component’: all the available components for each operation will be visible.

Config

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Header

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Post Param/Put Param/Patch Param/Delete Param

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Post Body/Put Body/Patch Body/Delete Body

Name Type/Value Required
Content-Type ‘application/json’, ‘text/plain’, ‘application/x-www-form-urlencoded’,’text/xml’ Yes
Content String No
 

Post

The I/O operations you can do are: GET, POST, PUT, PATCH and DELETE. From the composer, choose ‘Add Component’ and then choose the type of operation you want to do.   Once done, you will have a form to fill up: Parameters:
Name Type/Value Required
Url Url Yes
Variable String Yes
Expect String No
Mode ‘json’,’xml’, ‘html’,’text’ Yes
Params String No
Url: the url of the resource you want to test. It could be the full url of the resource or a string with variables using the $. (i.e. ‘https://domain/resourcename’ or ‘https://${domain}${endpoint}’) Variable: the name of the variable that contains the response. It will be the name you will refer during the test. Expect: it is an optional field and needs to be filled only if the expected behavior differs from a positive response (i.e. 404,500 vs. 200,201 etc.). This is useful when looking to test negative responses and validate error messages.

Possible values are ‘<statusCode>|VALID’ or ‘<statusCode>|INVALID‘. VALID means the payload type is the one selected in the “mode” field (JSON,XML), while INVALID means the opposite. Some examples:
  • 404|VALID : 404 is expected with valid payload
  • 422|VALID : 422 is expected with valid payload
  • 500|INVALID : 500 is expected with invalid payload
Multiple status codes can be expected by adding them all (i.e. 200|302|400|500|VALID) Mode: it’s the type of the response you want to test. Params: the optional list of params you want to add to the query string. To do so, tap on ‘Add parameter’. The params can either be a String value (in that case, the value will always be the same for all the requests; to do so, just put the value in the related field and choose ‘String value’ from the drop down menu) or a Variable (in that case the value will be taken dynamically and could changed from time to time; to do so, put the name of the variable inside the field and choose ‘Variable’ from the drop down menu). Using the above example: let’s say that varName is defined as a boolean value so it can be either ‘true’ or ‘false’, in that case, there will be two requests; the first one will be a GET request to ‘https://mydomain/endpoint?firstParam=paramValue&secondParam=true’, parsing it as ‘json’ and saving it in the ‘payload’ variable; the second one, will be a GET request to ‘https://mydomain/endpoint?firstParam=paramValue&secondParam=false’, parsing it as ‘json’ and saving it in the ‘payload’ variable. When all things are set up, you can confirm it by tapping on the ‘tick’ icon in the top right corner. After that, if you need to add headers, params or a body to the request you can do it by selecting the request and then tapping on the ‘Add component’: all the available components for each operation will be visible.

Config

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Header

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Post Param/Put Param/Patch Param/Delete Param

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Post Body/Put Body/Patch Body/Delete Body

Name Type/Value Required
Content-Type ‘application/json’, ‘text/plain’, ‘application/x-www-form-urlencoded’,’text/xml’ Yes
Content String No
 

Get

The I/O operations you can do are: GET, POST, PUT, PATCH and DELETE. From the composer, choose ‘Add Component’ and then choose the type of operation you want to do.   Once done, you will have a form to fill up: Parameters:
Name Type/Value Required
Url Url Yes
Variable String Yes
Expect String No
Mode ‘json’,’xml’, ‘html’,’text’ Yes
Params String No
Url: the url of the resource you want to test. It could be the full url of the resource or a string with variables using the $. (i.e. ‘https://domain/resourcename’ or ‘https://${domain}${endpoint}’) Variable: the name of the variable that contains the response. It will be the name you will refer during the test. Expect: it is an optional field and needs to be filled only if the expected behavior differs from a positive response (i.e. 404,500 vs. 200,201 etc.). This is useful when looking to test negative responses and validate error messages.

Possible values are ‘<statusCode>|VALID’ or ‘<statusCode>|INVALID‘. VALID means the payload type is the one selected in the “mode” field (JSON,XML), while INVALID means the opposite. Some examples:
  • 404|VALID : 404 is expected with valid payload
  • 422|VALID : 422 is expected with valid payload
  • 500|INVALID : 500 is expected with invalid payload
Multiple status codes can be expected by adding them all (i.e. 200|302|400|500|VALID) Mode: it’s the type of the response you want to test. Params: the optional list of params you want to add to the query string. To do so, tap on ‘Add parameter’. The params can either be a String value (in that case, the value will always be the same for all the requests; to do so, just put the value in the related field and choose ‘String value’ from the drop down menu) or a Variable (in that case the value will be taken dynamically and could changed from time to time; to do so, put the name of the variable inside the field and choose ‘Variable’ from the drop down menu). Using the above example: let’s say that varName is defined as a boolean value so it can be either ‘true’ or ‘false’, in that case, there will be two requests; the first one will be a GET request to ‘https://mydomain/endpoint?firstParam=paramValue&secondParam=true’, parsing it as ‘json’ and saving it in the ‘payload’ variable; the second one, will be a GET request to ‘https://mydomain/endpoint?firstParam=paramValue&secondParam=false’, parsing it as ‘json’ and saving it in the ‘payload’ variable. When all things are set up, you can confirm it by tapping on the ‘tick’ icon in the top right corner. After that, if you need to add headers, params or a body to the request you can do it by selecting the request and then tapping on the ‘Add component’: all the available components for each operation will be visible.

Config

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Header

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Post Param/Put Param/Patch Param/Delete Param

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Post Body/Put Body/Patch Body/Delete Body

Name Type/Value Required
Content-Type ‘application/json’, ‘text/plain’, ‘application/x-www-form-urlencoded’,’text/xml’ Yes
Content String No
 

I/O Operations

The I/O operations you can do are: GET, POST, PUT, PATCH and DELETE. From the composer, choose ‘Add Component’ and then choose the type of operation you want to do.   Once done, you will have a form to fill up: Parameters:
Name Type/Value Required
Url Url Yes
Variable String Yes
Expect String No
Mode ‘json’,’xml’, ‘html’,’text’ Yes
Params String No
Url: the url of the resource you want to test. It could be the full url of the resource or a string with variables using the $. (i.e. ‘https://domain/resourcename’ or ‘https://${domain}${endpoint}’) Variable: the name of the variable that contains the response. It will be the name you will refer during the test. Expect: it is an optional field and needs to be filled only if the expected behavior differs from a positive response (i.e. 404,500 vs. 200,201 etc.). This is useful when looking to test negative responses and validate error messages.

Possible values are ‘<statusCode>|VALID’ or ‘<statusCode>|INVALID‘. VALID means the payload type is the one selected in the “mode” field (JSON,XML), while INVALID means the opposite. Some examples:
  • 404|VALID : 404 is expected with valid payload
  • 422|VALID : 422 is expected with valid payload
  • 500|INVALID : 500 is expected with invalid payload
Multiple status codes can be expected by adding them all (i.e. 200|302|400|500|VALID) Mode: it’s the type of the response you want to test. Params: the optional list of params you want to add to the query string. To do so, tap on ‘Add parameter’. The params can either be a String value (in that case, the value will always be the same for all the requests; to do so, just put the value in the related field and choose ‘String value’ from the drop down menu) or a Variable (in that case the value will be taken dynamically and could changed from time to time; to do so, put the name of the variable inside the field and choose ‘Variable’ from the drop down menu). Using the above example: let’s say that varName is defined as a boolean value so it can be either ‘true’ or ‘false’, in that case, there will be two requests; the first one will be a GET request to ‘https://mydomain/endpoint?firstParam=paramValue&secondParam=true’, parsing it as ‘json’ and saving it in the ‘payload’ variable; the second one, will be a GET request to ‘https://mydomain/endpoint?firstParam=paramValue&secondParam=false’, parsing it as ‘json’ and saving it in the ‘payload’ variable. When all things are set up, you can confirm it by tapping on the ‘tick’ icon in the top right corner. After that, if you need to add headers, params or a body to the request you can do it by selecting the request and then tapping on the ‘Add component’: all the available components for each operation will be visible.

Config

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Header

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Post Param/Put Param/Patch Param/Delete Param

Name Type/Value Required
Name String Yes
Value String or Variable Yes
 

Post Body/Put Body/Patch Body/Delete Body

Name Type/Value Required
Content-Type ‘application/json’, ‘text/plain’, ‘application/x-www-form-urlencoded’,’text/xml’ Yes
Content String No