Boomi’s MLLP Server Connector can send synchronous and asynchronous acknowledgements in response to messages received via the MLLP Server Connector. An automatic synchronous response can occur if the sending message requests an acknowledgement and configuration options in the Boomi system enable automatic response or users provide their own acknowledgements.
An automatic asynchronous response can occur when the user uses the Start (Trading Partner) shape and configures a Trading Partner shape in the Acknowledgements path.
The decision tree for when an automatic synchronous response occurs as follows:
The MLLP Server Connector uses identifiers in the EDI envelope to route received messages to integration processes. This is why the listen operation requires you to configure the HL7 sender and receiver application and facility ID or the X12 sender and receiver interchange ID and qualifier. If these identifiers cannot be resolved from the message contents, then the MLLP Server Connector doesn’t know what to do with the message.
The first step to determining the EDI identifiers is to parse the data. If this step cannot be completed, then processing ends immediately. In these cases, the MLLP Server Connector will log a message to the container log and close the MLLP connection. No synchronous acknowledgement is sent.
Similar to when Boomi cannot parse the message, if the data cannot be matched to a listen operation based on the extracted sender and receiver identifiers, the MLLP Server Connector will log a message to the container log and close the MLLP connection. No synchronous acknowledgement is sent.
Matching a listen operation may include matching the client certificate in the SSL handshake to the client certificate specified in the MLLP Server Listen Operation when data is received on a port that is enabled for 2-way SSL. If the certificates do not match, this will also cause a closed connection.
There is a wealth of trace log information available that can be used to debug these types of situations. It is recommended that the user enable the Connector Trace Logging feature via The Properties panel’s Advanced tab in Atom Management when they are debugging closed MLLP connections.
Further debugging of SSL-related issues can be done with the standard Java SSL debug settings using System Properties in the Properties panel’s Custom tab in Atom Management.
Per standard rules in both HL7 and ANSI X12 EDI standards, an acknowledgment is never generated in response to a received acknowledgement.
Boomi has always supported HL7 EDI messages in the MLLP Server Connector. In the April 2024 Release, further support was added for ANSI X12 EDI documents. The rules for checking whether the sender requests an acknowledgement differ slightly based on what message fields are available in each standard.
In an HL7 message, the sender uses the MSH.15 “Accept Acknowledgement Type” and MSH.16 “Application Acknowledgement Type” data elements to indicate whether the receiver should return acknowledgements and under which conditions.
If the MSH.15 segment has a value (not empty), the MLLP server treats this as enabling “enhanced mode” acknowledgements in HL7 (HL7 2.31 2.12.1.2.2). In "enhanced mode" acknowledgements, either a CA “Commit Accept” or a CE “Commit Error” acknowledgement code may be sent back in an automatic acknowledgement. Which is used depends on the value of the MSH.15 and whether the integration process that was invoked completes successfully or not. The application acknowledgement is assumed to be done asynchronously and follows the asynchronous acknowledgement rules outlined in the Asynchronous Responses section in this document.
If the MSH.15 is set to NE “Never”, no acknowledgement will be generated. If it is set to AL “Always”, both CA and CE responses may be returned. If it is set to SU “Successes”, only CA responses will be returned. If it is set to ER “Errors”, then only CE responses will be returned.
If the MSH.15 data element is empty, then the MSH.16 is used to determine whether acknowledgements are sent or not. Regardless of the value of the MSH.16, “original mode” acknowledgements are used from this point forward (HL7 2.31 2.12.1.2.1). When using "original mode" acknowledgements, Boomi responds with AA “Application Accept” and AE “Application Error” acknowledgement codes based on whether the integration process completed successfully. The same HL7-standard processing rules are applied for NE, AL, SU, and ER values of the MSH.16.
If both MSH.15 and MSH.16 are empty, then original mode acknowledgements are used and MSH.16 is assumed to be set to AL “Always”. Boomi configuration is further consulted as described in the “Did the message receiver enable automatic acknowledgement?” section to determine whether an automatic acknowledgement will be sent.
For an X12 message, Boomi can automatically generate a TA1 Interchange Acknowledgement Report as a synchronous response to a MLLP message. The sender uses the ISA.14 “Interchange Ack Requested” field to indicate whether they request the TA1 acknowledgement or not. In the TA1 response, the interchange ack code is set to A “Accepted” and the interchange note code is set to 000 “No Error” on successful process completion. The interchange ack code is set to R “Rejected” and an empty note code on process error.
Assuming that the message sender requested an acknowledgement, the system will check the MLLP Listen Operation to further determine whether an automatic acknowledgement should be generated. Each operation sets this field independently of other operations, so behavior can be customized on a per-integration basis.
For users of the Trading Partner Framework, the automatic acknowledgement flag is enabled based on settings in the Trading Partner Component. For HL7, this is enabled when the Trading Partner > HL7 Standard > Basic HL7 Options > Require Accept Acknowledgements configuration option is set to a value other than Never. For X12, this is enabled when the Trading Partner > X12 Standard > ISA Version / Control Options > Interchange Ack. Requested (ISA14) checkbox is checked.
In the April 2024 Release, Boomi added support for custom synchronous MLLP responses in the MLLP server using the Return Documents shape in an integration process. It is up to the user to construct this message as appropriate for their use case.
In a situation where the criteria is met for the system to generate an automatic acknowledgement (see above), but the integration process also generates a custom response, the custom response will be used and no automatic acknowledgement is done. In the case where the integration process does not complete, the system may still send an automatic acknowledgement even if the integration process has the Return Documents shape in place to override the acknowledgement.
Boomi supports the Return Documents shape in the Trading Partner Framework, but there are some limitations to understand. The Acknowledgements path of the Start (Trading Partner) shape will contain an Application Acknowledgement for an HL7 message or a TA1 and/or 997/999 Acknowledgement for an X12 document. The HL7 message is fully formed, but doesn’t have any batch segments that might be required. Those would typically be constructed using a Trading Partner Shape as part of an asynchronous response. Similarly, the X12 TA1 and 997/999 documents are just the specific segment and transaction without GS/GE or ISA/IEA enveloping applied. If the user wishes to use batch segments or X12 group and interchange envelopes with MLLP and the Return Documents feature, then they must build the batch and/or envelope segments themselves.
If the user is using the Trading Partner Framework via the Start (Trading Partner) Shape, acknowledgement messages may be automatically generated in the integration process and sent down the acknowledgements path. It is typical practice to deliver these responses asynchronously via the Trading Partner shape later in the process.
Whether an acknowledgement is generated is based on both the sender message and Boomi configuration options. For HL7, the MSH.16 is consulted first and then the “Require Application Acknowledgement” setting on the HL7 Standard tab of the sending Trading Partner component. For X12, the “Functional Acknowledgment Options” on the X12 Standard Tab and the ISA.14 value.
For HL7, the acknowledgments generated at this point in the flow are always Application acknowledgements (AA, AR or AE). An AA is generated when data is parsed and validated successfully. The AR is generated when the message version, message type, or processing ID in the MSH header are not provided. The AE is generated when the document fails profile validation. Profile validation must be enabled by setting the profile in the corresponding document type in the Document Types tab for it to apply.
For X12, the acknowledgements generated at this point are 997 Functional Acknowledgements. If the user wants to use the 999 acknowledgment or include a TA1 in the acknowledgement, those options are added to specific document types in the Document Types tab via the “Use 999 Acknowledgement” and “Use TA1 Acknowledgement” checkboxes. The rules for what FA codes are used and under which circumstances are too numerous to be restated here, but they follow similar logic to HL7.
The documents generated in the acknowledgement path are non-enveloped documents. The enveloping is applied by the Trading Partner shape. Communications from the Trading Partner Shape are always done asynchronously with Boomi as the initiator. As mentioned above, the Return Documents shape can be used as a substitute for the Trading Partner shape, but the integration process needs to generate appropriate document envelopes for the data prior to calling the Return Documents shape.
Acknowledgement processing for MLLP relies on a number of settings both in the EDI data that is received and in the configuration of the Boomi integration process. Hopefully this document has shed some light on the various ways acknowledgements can be generated, the conditions under which Boomi will automatically generate an acknowledgement (synchronous or asynchronous), and how you can override the MLLP synchronous response in your integration process as needed.