SOAP attachments header mapper

Maps attachments, as used in the SOAP with Attachments specification, to and from message headers.

SoapHeaderMapper implementation that converts MIME attachments, as used in the SOAP with Attachments (SwA) specification, to and from message headers.

Incoming MIME attachments will converted to message headers, but the (binary) content of the attachments is directly written to disk to prevent reading potentially huge amounts of data into memory. Outgoing MIME attachments will be converted from these same message headers, with the content being read directly from disk. This implies that both the inbound and outbound gateways must have access to the same directory.

The message header used by this header mapper is named emagiz_ws_attachments, with its value being a List of attachments. Each attachment is represented as a Map with the following entries:

• contentId (String): the (unique) Content-ID of the MIME attachment
• contentType (String): the Content-Type of the MIME attachment, e.g. application/pdf
• file (File): the file that contains the (binary) content of the MIME attachment

Normally no attachments equals no emagiz_ws_attachments header on the message, but there is one exception: on the response message of a web service outbound gateway this header is always added, even if there were no MIME attachments in the SOAP response (in this case the header value will be an empty list). This is done to prevent the gateway from copying the original header from the request message to the response message.

When sending attachments with a request, this header mapper will not delete the files containing the content for the MIME attachments, because the web service call might need to be retried later in case of errors. It is up to the user to delete these files after the call succeeded. To make this easier you can use the AttachmentHeader helper class within SpEL expressions. For example, this expression can be used in an expression evaluating request handler advice: T(com.emagiz.components.ws.AttachmentHeader).copy(headers).deleteFiles()

To populate the emagiz_ws_attachments header without using a web service inbound gateway, you can use the same AttachmentHeader helper class. For example, this expression can be used right after a file inbound channel adapter to create attachment headers for files that are picked up by the adapter: T(com.emagiz.components.ws.AttachmentHeader).create().add(null, 'image/png', payload).build()

Note that the first argument for add(...), the Content-ID, is null in this example: this will result in a randomly generated UUID being used. The second argument, the Content-Type, is also optional: if null it will default to application/octet-stream.

To read from the emagiz_ws_attachments header, you can simply use standard SpEL fuctionality. For example, headers.emagiz_ws_attachments[0].file returns the file containing the content of the first MIME attachment.

Ignore incoming

Whether to ignore incoming MIME attachments, i.e. not process them at all and (importantly) not save them to disk. If you are only ever sending attachments, set this to true: otherwise you might quickly run out of disk space, because anyone can just send any number of MIME attachments with their requests or responses.

Note that even when setting this to true, response messages of a web service outbound gateway will still have the emagiz_ws_attachments header, with its value being an empty list. This is done to prevent the gateway from copying the original header from the request message to the response message.

Default is false.

Directory

The directory where the (binary) content of incoming MIME attachments will be stored as files.

When sending MIME attachments this setting is not used, because the full path to the file location is read from the header information. However, when using a web service inbound gateway paired with a web service outbound gateway to forward attachments, practically speaking both gateways must have (shared) access to this directory. This can be achieved by deploying both on the same server.

This directory is only used when ignore incoming is false, in which case make sure to periodically cleanup old files!

Auto create directory

Specify whether to automatically create the directory if it does not yet exist when this header mapper is being initialized.

If set to false and the directory does not exist upon initialization, an exception will be thrown.

Default is true.

Delete outgoing reply files

Automatically delete the files on disk containing the contents for the MIME attachments after sending them in a web service response. When using this feature, make sure that your flow does not send any incoming attachments back in the response: this will cause problems as files might be deleted before the attachments have fully been received.

When sending attachments in a web service request, this header mapper will not delete the files containing the content for the MIME attachments, because the web service call might need to be retried later in case of errors. It is up to the user to delete these files after the call succeeded. To make this easier you can use the AttachmentHeader helper class within SpEL expressions. For example, this expression can be used in an expression evaluating request handler advice: T(com.emagiz.components.ws.AttachmentHeader).copy(headers).deleteFiles()

Regardless of whether you use this feature or not, make sure to periodically cleanup old files as well, otherwise files of messages that do not follow the "happy flow" will remain on disk forever.

Default is true.

Id

Name that uniquely identifies this flow component.

Required