Handling Multipart Payloads / Attachments
Source Connectors - Receiving Attachments
Source Connectors - Sending Attachments
Destination Connectors - Sending Attachments
Destination Connectors - Receiving Attachments
Setting an Arbitrary Boundary Parameter
Source Connectors - Receiving Attachments
Source Connectors - Sending Attachments
Destination Connectors - Sending Attachments
Destination Connectors - Receiving Attachments
Setting an Arbitrary Boundary Parameter
Recommendations
Explore
Interoperability Connector Suite User Guide
Destination Connectors - Receiving Attachments
All of the Interoperability Suite source connectors (PIX/PDQ/XCA/XCPD/XDS.b) will automatically detect incoming multipart responses, and store any extra attachments as message attachments on the message. For additional information, see the About Message Data and Attachment Handlers sections in the Mirth® Connect by NextGen Healthcare User Guide. Parent topic: Handling Multipart Payloads / Attachments
Interoperability Connector Suite User Guide
Source Connectors - Receiving Attachments
All of the Interoperability Suite source connectors (PIX/PDQ/XCA/XCPD/XDS.b) will automatically detect incoming multipart requests, and store any extra attachments as message attachments on the message. For additional information, see the About Message Data and Attachment Handlers sections in the main Mirth® Connect by NextGen Healthcare User Guide. For example, if you use one of the destination connectors to add an attachment: Then your source connector will automatically extract that attachment and store it along with the incoming message. You can then view this message in the message browser: You can also retrieve this attachment within a script, see the Attachment JavaScript Functions section in the main Mirth® Connect by NextGen Healthcare User Guide for more info. Parent topic: Handling Multipart Payloads / Attachments
Interoperability Connector Suite User Guide
Destination Connectors - Sending Attachments
All of the Interoperability Suite destination connectors (PIX/PDQ/XCA/XCPD/XDS.b) support the same MTOM attachments settings as the Web Service Sender destination (see the Mirth Connect by NextGen Healthcare User Guide for more information). To include attachments, enable Use MTOM and populate the attachment table: Parent topic: Handling Multipart Payloads / Attachments
Interoperability Connector Suite User Guide
Setting an Arbitrary Boundary Parameter
You can use an arbitrary value for the boundary parameter, given it does not exceed 70 bytes in length and consists only of 7-bit US-ASCII (printable) characters. Parent topic: Handling Multipart Payloads / Attachments
Interoperability Connector Suite User Guide
Source Connectors - Sending Attachments
All of the Interoperability Suite source connectors (PIX/PDQ/XCA/XCPD/XDS.b) support sending attachments back with the SOAP response payload as a multipart response. To do this, you add a MultipartResponseSettings object into the response map (or channel map) with the key "responseMultipartSettings". For example: var bodyHeaders = Maps.map(); bodyHeaders.put( "X-Custom-Body-Header" , Lists.list( "testing" )); bodyHeaders.put( "X-Custom-Body-Header2" , Lists.list( "testing2" )); var attachments = Lists.list();// Create message attachment here in channel and use that var attachmentId = addAttachment( "testing" , "text/plain" , true ).getId(); var attachment1 = new ResponseMultipartAttachment(attachmentId); attachments.add(attachment1); // Set custom attachment content var attachment2 = new ResponseMultipartAttachment(); attachment2.setContent(FileUtil.decode( "iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0IArs4c6QAAAAZiS0dEAP8A/wD/oL2nkwAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9kFD
Mirth® Connect by NextGen Healthcare User Guide
Destination Settings
These are general settings that apply to all destination connectors. They include configuring the destination queue, whether to validate responses, and whether to re-attach attachments on outbound messages. Item Name Description A Queue Messages Never: Disable the destination queue. On Failure: Attempt to send the message first before queuing it. This will allow subsequent destinations and the Postprocessor to use the response from this destination if it successfully sends before queuing. Always: Immediately queue the message. Subsequent destinations and the Postprocessor will always see this destination's response as QUEUED. B Advanced Queue Settings Configure how often to re-attempt queued messages, increase queue threads, and more. C Validate Response Select Yes to validate the response. Responses can only be validated if the response transformer's inbound properties contains a Response Validation section. If validation fails, the message will be marked as queued or errored. For add
