How to send attachments to a 3rd party REST service in a SetFields REST filter?

Reference documentation: https://docs.bmc.com/docs/ars2002/calling-third-party-rest-apis-in-a-remedy-application-909638089.html#Callingthird-partyRESTAPIsinaRemedyapplication-multi(Optional)Toaddattachmentdatainformation

NOTE:  File encoding can be done in binary format only.  However, if the 3rd party REST service requires the file in another format such as base64, a filter / run process operation can do that conversion.

The following requirements must be met for the attachment data to be sent:
1. The attachments have to be mapped in the Request mapping and are mapped to the Attachment field (not the Attachment pool)
2. The attachments also have to be mapped in MultiPart info
3. A null entity with any name should be created in multipart info
4. All data that is not a file will only be sent if it is linked to the null entity created in step3

Consider the following points when you perform request mapping for attachment data:

1. The AR System server sends data from an attachment field in multiple parts. 
2. The first part is the JSON for the non-attachment field type. 
3. The subsequent parts are binary attachment data. 
4. The parts are separated by using keys. 
5. We support the content disposition only for form data.
6. We do not support child form attachment entries for the parent-child relationship.

Details: 1 The attachments have to be mapped in the Request mapping


Details: 2 The attachments also have to be mapped in MultiPart info

• The key for "attach-Attachment1" is just a formality.  It could have any format name and doesn't need to match to Request Mapping.  For example, it could be the word 'files'
• The value for "attach-Attachment1 has to be in a single line as follows:  ATTACH_FIELD_KEY:536870914#MULTSEP#ATTACH_HEADER_DATA_TYPE:application/octet-stream#MULTSEP#Content-Transfer-Encoding:binary
• The minimal format would be ATTACH_FIELD_KEY:<<attachment_field_id>>#MULTSEP#ATTACH_HEADER_DATA_TYPE:application/octet-stream
• Additional headers can be specified by adding  #MULTSEP#header-name:header-value
• Any header added will be part of the mime part but would not modify the way files are encoded.  From the Helix perspective, the attachments are always sent in binary format

Details : 3. A null entity with any name should be created in multipart info

• Notice that multipart info has a key labeled "something" with NULL value.   If this NULL entry is not present, the attachments would not be sent.   The 'something' matches to the request mapping.
• The first key should have NULL value for attachments to be considered. If the first key doesn't have a NULL value, an ARERR 9130 error will be sent when invoking the REST call. 

Details 4. All data that is not a file will only be sent if it is linked to the null entity created in step3

• Besides the attachments the key "something|will be sent" is the only piece of data that will be transferred as part of the REST request.