Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

FIX: A hotfix is available that provides additional Delivery Mode properties for the Minimal Lower Layer Protocol send and receive adapters in BizTalk Accelerator for HL7 in a BizTalk Server 2010 environment


View products that this article applies to.

Summary

This article describes a hotfix that provides two additional Delivery Mode properties for Minimal Lower Layer Protocol (MLLP) send and receive ports when you use the BizTalk Accelerator for HL7 in a Microsoft BizTalk Server 2010 environment:
  • Use MLLP Transport Acknowledgement
    This property is available in both one-way receive ports and one-way send ports.
  • Suspend Request Message on MLLP Transport NAK
    This property is available only in one-way send ports.
The MLLP receive adapter supports both one-way and two-way request response modes. If the receive adapter is configured, HL7 processing uses the Ordered Delivery parameter. This guarantees that the order of message delivery is maintained. When the MLLP receive adapter operates in two-way mode, the adapter does not receive a new message from the upstream system until the adapter generates an application (MSA) acknowledgement for the previous message to the upstream system. The generated ACK/NAK is sent to the message box database (MessageBoxDB). MessageBoxDB waits for the next polling interval before it sends the ACK/NAK to the upstream system.

The upstream system sends only one message at a time and only after it receives an ACK/NAK. Additionally, the BizTalk polling interval is configured, and the Ordered Delivery parameter is set to True. This means that the number of messages that are processed per second is limited. This hotfix provides for additional configuration for one-way send and receive ports. It does not affect the ACK/NAK. However, it significantly increases the number of documents that are processed per second.

You should use performance counters to take a baseline before and after you apply this hotfix. When you benchmark, you should submit a reasonable number of messages over a reasonable period. For example, you could use the following:
  • For the BizTalk:Messaging category, use the Documents processed/Sec counter.
  • For the BizTalk:Messaging Latency category, use all available counters.

One option to increase the number of documents that are processed per second is to lower the MaxReceiveInterval setting for the BizTalk host. Depending on the overall environment, on the tuning of the computer that is running Biz Talk Server 2010, and on the volume of documents that are processed, lowering the MaxReceiveInterval setting could have an adverse effect on the performance of the instance of SQL Server. For SQL Server tuning and for BizTalk tuning, refer to all available technical articles.

↑ Back to the top


More Information

Note This hotfix also resolves an issue in Microsoft BizTalk 2010 Accelerator for HL7. For more information about this issue, click the following article number to view the article in the Microsoft Knowledge Base:
2454887  Events might be incorrectly logged for an MLLP-based message in BizTalk 2009 Accelerator for HL7 on a computer that is running Microsoft BizTalk Server 2009 or Microsoft BizTalk Server 2010 

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft website: Note The "Hotfix download available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Prerequisites

You must have Microsoft BizTalk Accelerator for HL7 (BTAHL7) installed to apply this hotfix.

Restart information

You may have to restart your computer after you apply this hotfix. If you are not prompted to restart, you must restart BizTalk services. For more information about this procedure, refer to the Readme.txt file that is included in this hotfix package.

Replacement information

This hotfix does not replace a previously released hotfix.

File information

The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time item in Control Panel.

File nameFile versionFile sizeDateTimePlatform
Microsoft.solutions.btahl7.mllp.dll3.9.526.2116,60807-Jun-201115:27x86
Microsoft.solutions.btahl7.shared.dll3.9.526.292,04007-Jun-201115:27x86
Mllpreceive.exe3.9.526.226,45607-Jun-201115:27x86
Mllpsend.exe3.9.526.226,44807-Jun-201115:27x86

↑ Back to the top


About the hotfix

Message flow after the hotfix is installed and configured

After you apply and enable this hotfix, the MLLP adapter submits any message that is received by the MLLP adapter to MessageBoxDB. The End Point Manager (EPM) calls back the adapter together with the submission status in the BatchComplete method. This causes the adapter to send the commit ACK/NAK to the upstream system. In turn, the upstream system receives the ACK/NAK and then sends the next message. The BatchComplete method is independent of the MaxReceiveInterval setting and is called immediately after the message is submitted to BizTalk successfully.

As soon as the message is ready to send, the send adapter transmits the message to the downstream system. The ACK/NAK is expected if the Use MLLP Transport Acknowledgement property is set to True. If the send is an ACK, BizTalk finishes the processing successfully. If the send is a NAK, and if the Suspend Request Message on MLLP Transport NAK property is set to True, the message is suspended directly without retrying. However, if the Suspend Request Message on MLLP Transport NAK property is set to False, BizTalk will retry based on the send port retry interval settings. (By default, the Suspend Request Message on MLLP Transport NAK property is set to False.)

The following diagram shows the message flow:
Message flow
  1. The message that is sent by the upstream system sending application is processed by the MLLP receive adapter.
  2. The MLLP adapter submits the message to BizTalk/EPM.
  3. The EPM calls back the adapter about the message submission status. The EPM does this in the Batch Complete method.
  4. A commit ACK/NAK is generated by the MLLP adapter and is based on the Batch Submission status. The ACK/NAK is sent to the sending application.

    Note If the Batch Submission status is Success, the adapter returns the ACK. However, if there is a failure or if the submission times out (for example, if the Batch Complete method call times out), the adapter returns the NAK to the sending application.

  5. The EPM hands over the message to the MLLP send adapter for transmission.
  6. The MLLP send adapter sends the processed message to the downstream system.
  7. The transport level ACK/NAK is expected by the MLLP send adapter to complete the communication.
  8. If the message in step 7 is an ACK, the adapter asks the EPM to delete the message. Otherwise, the adapter has to ask the EPM for a retry that is based on the retry interval setting. A new option is provided in the send port configuration setting for suspending the message directly, without a retry, if an MLLP NAK is received. By default, this option is set to False. If this option is set to True, the message will be suspended directly, without a retry, if an MLLP NAK is received.

Transport Level ACK/NACK format

The website contains the following information:
  • Example of an MLLP Commit Acknowledgement:
    <SB><ACK><EB><CR>
  • Example of an MLLP Negative Commit Acknowledgement:
    <SB><NAK><EB><CR>
Notes
  • In these examples, <SB> refers to the Start Block character (1 byte). This corresponds to the <VT>ASCII character, or <0x0B>.

    This should not be confused with the SOH or STX ASCII characters.
  • In these examples, <ACK> or <NAK> refer to the acknowledgement character (1 byte. Corresponds to the <ACK> ASCII character, or <0x06>) or the negative-acknowledgement character (1 byte. Corresponds to the <NAK> ASCII character, or <0x15>).
  • In these examples, <EB> refers to the End Block character (1 byte). This corresponds to the <FS> ASCII character, or <0x1C>.
  • In these examples, <CR> refers to the Carriage Return character (1 byte). This corresponds to the <CR> ASCII character, or <0x0D>.
  • Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.

How to configure the receive and send ports to use the new properties

Configure the receive and send ports as follows.

Note The receive and send port settings can be used independently or together.

Receive port configuration
  • The port must be a one-way port.
  • The Ordered Delivery parameter must be enabled.
  • You must set the Use MLLP Transport Acknowledgement property to True to enable transport level acknowledgment. By default, this property is set to False for existing ports or for new ports.
Receive port
Send port configuration
  • The port must be a one-way port.
  • The solicit-response mode must be set to No.
  • The Ordered Delivery parameter must be enabled.
  • You must set the Use MLLP Transport Acknowledgement property to True to enable transport level acknowledgment. By default, this property is set to False for existing ports or for new ports.
  • You must set the Suspend Request Message on MLLP Transport NAK property to True if the messages need to be suspended directly without being retried when a Transport NAK is received from a downstream system. Otherwise, the message will be retried for the number of times that is set in the transport advanced options of the send port. By default, this property is set to False for existing ports or for new ports.
Send port

About the "Use MLLP Transport Acknowledgement" property

The following table describes the expected behavior of one-way or two-way ports that use the Use MLLP Transport Acknowledgement property. The required combination of settings must be applied as described in the "How to enable the hotfix" section.

Notes
  • "Upstream system" refers to the sending application. It sends messages to BizTalk. These messages are incoming to BizTalk.
  • "Downstream system" refers to the receiving application. It receives messages from BizTalk. These messages are outgoing to BizTalk.


Kind of portMLLP V2 Option OnMLLP V2 Option Off
One-way receiveSend MLLP ACK/NAK to the upstream system in the BatchComplete method.No change in the behavior. In this situation, no ACK/NAK is sent to the upstream system.
Two-way receiveNo change in the behavior. In this situation, the HL7 ACK/NAK in the TransmitMessage method is sent to the upstream system.

Note This option is not supported. For example, ignore even if the value is set to True.
No change in the behavior. In this situation, the HL7 ACK/NAK in the TransmitMessage method is sent to the upstream system.
One-way sendThe MLLP ACK/NAK from the downstream system is waited for after the message is transmitted.No change in the behavior. In this situation, the ACK/NAK from the downstream system is not waited for after the message is transmitted.
Two-way send or one-way send with solicit-response mode enabledNo change in the behavior. In this situation, the HL7 ACK/NAK from the downstream system is waited for after the message is transmitted.

Note This option is not supported. For example, ignore even if the value is set to True.
No change in the behavior. In this situation, the HL7 ACK/NAK from the downstream system is waited for after the message is transmitted.


Two-way receive and send port behavior is not changed. One-way receive and send port behavior is also not changed unless the Use MLLP Transport Acknowledgement property is set to true.

For more information, refer to the MLLP adapter documentation. If one-way receive and send ports have the appropriate configuration, performance improves. If the Use MLLP Transport Acknowledgement property of a two-way port or a one-way port is set to false, the kind of ACK that is generated continues without changes. In this situation, the kind of ACK that is generated depends on the BTAHL7 Configuration Explorer settings for the application that is sending the message. The value in fields MSH 15 and MSH 16 of a specific message can override this setting. However, if the Use MLLP Transport Acknowledgement property of a two-way port or a one-way port is set to false, you can set the configuration for applications that expect static ACKs only by using the BTAHL7 Configuration Explorer. Time-out behavior for the port remains unchanged..

The expected behavior in corner cases when the properties are used is as follows:

RECEIVE
  • WrongMLLPFormat: the message is not submitted to BizTalk.
  • WrongHL7Format: the message is submitted to BizTalk, and a MLLP ACK/NAK is transmitted that is based on the Batch Completion status.
  • TransmittingSocketIssue: the MLLP ACK/NAK is not transmitted, although the message is submitted to BizTalk.
  • ReceivingSocketIssue: the message is not received and therefore is not submitted, and no MLLP ACK/NAK transmission is sent.
  • If a submission to BizTalk fails, a NAK is transmitted.
  • If a negative status of Batch Complete is received, a NAK is transmitted.
SEND and send port property "stop sending subsequent messages on current message failure" = True
  • WrongMLLPFormat: the message is suspended because the MLLP ACK/NACK cannot be read. Processing will not continue until the suspended messages are cleared.
  • WrongHL7Format: the message fails before it reaches the adapter. Processing will not continue until the suspended messages are cleared.
  • TransmittingSocketIssue: the message is suspended. Processing will not continue until the suspended messages are cleared.
  • ReceivingSocketIssue: the message is suspended. Processing will not continue until the suspended messages are cleared.

The expected behavior when the Suspend Request Message on MLLP Transport NAK property is set to True or to False is as follows:
  • When the Suspend Request Message on MLLP Transport NAK property is set to True and a NAK is received, the message is suspended without a retry to send it.
  • When the Suspend Request Message on MLLP Transport NAK property is set to the default setting of False, a retry to send the message is started, based on the send port retry interval settings.

Changes to the MLLP SDK Utility

The MLLP SDK Utility includes the following new parameters. All other parameters remain unchanged. For more information, refer to the product documentation.
  • For MLLPReceive.exe, use the new parameter to return the MLLP ACK/NAK after the message is received. For example:
    MLLPReceive /p 12000 /sb 11 /eb 28 /cr 13 /MLLPTransACK
    MLLPReceive /p 12000 /sb 11 /eb 28 /cr 13 /MLLPTransNAK
  • For MLLPSend.exe, use the new parameter to wait for MLLP ACK/NAK. For example:
    MLLPSend /sb 11 /eb 28 /cr 13 /f "C:\HL7\ls.txt" /I 127.0.0.1 /p 11000 /UseMLLPTransACK

↑ Back to the top


References

For more information about how to manage performance settings in BizTalk server, visit the following Microsoft Developer Network (MSDN) website:For more information about messaging performance counters, visit the following MSDN website:For more information about Ordered Delivery of Messages, visit the following MSDN website:For more information about BizTalk 2010 Accelerator for HL7 (BTAHL7), visit the following Microsoft website:For more information about the IBTBatchCallBack.BatchComplete method, visit the following MSDN website:For more information about BizTalk Server hotfixes, click the following article number to view the article in the Microsoft Knowledge Base:
2003907 Information about BizTalk Server hotfixes

↑ Back to the top


Keywords: kbautohotfix, kbhotfixserver, kbfix, kbsurveynew, kbexpertiseinter, kbbug, kb, kbqfe

↑ Back to the top

Article Info
Article ID : 2564013
Revision : 2
Created on : 4/10/2020
Published on : 4/10/2020
Exists online : False
Views : 482