Document vs Exchange level Acknowledgement

Acknowledgment are of two types,

1. Document Acknowledgment - Acknowledgment which is sent/consumed by the document layer and it caters more for sending validation, translation status, it can also be considered as Application acknowledgement.

e.g Functional Acknowledgment(997)/Control in EDI/HL7 protocol.

Typically Functional acknowledgment are send/received by B2B, however there is always a fallback option to send FA by the back end application only for a use case which cant be handled by B2B.

e.g To send some of the specific segment in the inbound business message as part of the outbound control/FA, for which there is no mapping in B2B Functional Acknowledgment. Back end Application need to generate the Functional acknowledgment using the internal property of the inbound business message.

How to enable Document level Acknowledgment

The flag isFunctionalAck required controls whether an FA is needed are not. Make sure to define a Document Type with the name and revision of 997/4010(any) or control/D3 with an attached Business action in the agreement.

2. Exchange Acknowledgment/MDN/Ack

Exchange level acknowledgment are called MDN in AS2 and Acknowledgment in RNIF and eBMS case. Exchange level acknowledgment signifies the status of validity of Exchange message, verify,decrypt functionality and sends a negative
acknowledgment to the initiator of the business message for any issues.

How to enable Exchange level Acknowledgment

The flag IsAcknowledgement handled by B2B enables B2B to generate and consume Exchange level Acknowledgment. However it is possible to delegate this functionality to back end application by setting this flag to OFF.

Various Acknowledgement in EDI

I have already talked a little bit about Functional Acknowledgement. Typically it is called 997 in X12 and is defined in each and every version of X12 such as 4010,4020 etc, where as the same is called Control in EDIFACT and is of version D3.

In the EDI world, people often get confused Functional Acnowledgement with Exchange/Transport level acknowledgement and also the Application level confirmation such as Purchase order Acknowledgment such as 855.

Exchange Level Acknowledgement/Trnasport Level :

Acknowledgement such as MDN i.e Message disposition notification in AS2 or Acknowledgement in EBMS specified the aknowledgement of the business message
in the enterprise only w.r.t meeting the security aspects such as verifying the signed message and decrypting the encrypted message and uncompress it if it is a compressed message and it do nothing w.r.t the payload validity or the business level integration.

Functional Acknowledgement :

Functional Acknowledgement as a Best Practices is handled in most of
the cases using B2B Application level and it caters to validation of the business message w.r.t any defined grammer such as schema,DTD or anything specific to EDI and it also specifies the translation status etc.

It is also possible to handle this in the back end application by delegating the Functioanl Acknowledgement generation to the back end application , however the correllation happens in the B2B.

The flag isFunctionalAck required controls whether an ACK) is needed are not. The flag isFunctionalAclHandledbyB2B controls whether FA is required and it is generated in B2B or it comes from Back End application such as BPEL. This option is useful only when isFunctionalAck required is YES. The flag isFunctionalAclHandledbyB2B should be set to 'YES', unless there is special way ACK is generated outside B2B. Functional Ack is generated using the XEngine in B2B and captures all the translation and validation errors.

To enqueue a query response from BPEL to B2B, populate the replyToMsgID field of
IPMessage with the MsgID field of the incoming message.

Application Acknowledgement :

Application Acknowledgement such as Purchase order Acknowledgement is from the ERP application and caters to the process integration status.

Acknowledgement in Oracle AS B2B for HealthCare Protocol

Oracle AS B2B supports various types of Acknowledgement as part of HealthCare Protocol offering.

1. Functional Acknowledgement : The flag isFunctionalAck required controls whether an HL7 ACK) is needed are not. The flag isFunctionalAclHandledbyB2B controls when FA is required whether it is generated in B2B or it comes from Back End application such as BPEL. This option is useful only when isFunctionalAck required is YES. The flag isFunctionalAclHandledbyB2B should be set to 'YES', unless there is special way ACK is generated outside B2B. Functional Ack is generated using the XEngine in B2B and captures all the translation and validation errors.

2. Immediate Ack : The turn around time of Functional Acknowledgement is considered to be little high for some business critical healthcare application as it captures both translation, validation error and is generated by Xengine. An alternative in which case is Immediate Ack which is generated and transmitted in the TCP transport layer instead of the Document layer in case of FA resulting in response time as low as 1 sec.

Oracle AS B2B can send immediate acknowledgment in three modes and the same can be mentioned using the tip.property

oracle.tip.adapter.b2b.hl7.immediateAck= <mode>

default : B2B will parse the incoming HL7 message and generate ack from it.
In this mode b2b can send the ack to the sending application with correlation details (ex. Control number from the incoming Message, Sending App.. etc)
Hence TP Application can correlate the incoming ACK message.

simple : B2B will send the pre-defined ack message to the sender and will not parse the message.

custom : B2B will read the custom HL7 ack message based on a configurable file content.
oracle.tip.adapter.b2b.hl7.immediateAckFile = < file path >

Reads the file from the above location and send it as in ACK to the sender.