While testing the Hyland Adapter with BizTalk Server, Hyland Software has observed the following behavior:
-
When abruptly stopping a BizTalk application, or the application's host instance, Hyland Software has observed that a BizTalk application with no orchestrations typically sends fewer messages to the Non-resumable queue than a BizTalk application with orchestrations. While an orchestration is a useful component for transforming a message, it is not required to deploy a BizTalk application.
-
When abruptly stopping a BizTalk application, or the application's host instance, while the BizTalk application is processing messages, BizTalk will respond in one of the following ways:
-
Continue processing messages.
-
Re-process events that were in the queue prior to system shut down, causing duplicate messages.
-
Place events in the Non-resumable queue.
-
-
If you must stop a running BizTalk application, select the Partial Stop - Allow running instances to continue option. Stopping an application in this manner results in fewer or zero events in the Non-resumable queue.
-
It is considered a best practice to configure exception handling within the orchestration. Doing so provides graceful termination of service instances and corresponding messages.
-
It is considered a best practice to configure the orchestration's Transaction Type as Atomic or Long Running. Doing so helps mitigate the probability of inconsistent message states and decreases the number of messages that are sent to the Non-resumable queue.
-
For inbound operations, if the Hyland Adapter cannot reach the OnBase Application Server to clear events from the OnBase database tables after BizTalk receives an event, but before the event can be sent from BizTalk, the Hyland Adapter attempts to connect to the OnBase Application Server. When the Application Server does not respond to the Hyland Adapter, attempts to reconnect occur every 90 seconds. During this time period, the Hyland Adapter does not attempt to clear any events and the BizTalk application continues to poll for new events at the configured polling interval. When the Hyland Adapter connects to the OnBase Application Server, events that have been sent are cleared. If the Hyland Adapter is unable to connect to the OnBase Application Server after 10 attempts (15 minutes), it stops attempting to connect and sends the events through BizTalk. Restarting the BizTalk application results in any event that were not cleared from the OnBase database tables to be reprocessed. Since the Hyland Adapter already processed these events without clearing them from the OnBase database tables, this results in duplicate messages.
-
For outbound operations, if BizTalk cannot reach the OnBase Application Server after the Application Server receives a request, but before BizTalk can receive a response, BizTalk attempts to reconnect based on the configured interval. If the Hyland Adapter is unable to connect to the OnBase Application Server after the configured number of attempts, the instance is suspended in BizTalk. Because the Hyland Adapter did not receive a response, resuming the suspended instance causes a duplicate message. Duplicate messages can also occur after the first attempt to connect to the OnBase Application Server, if this attempt was executed within OnBase, but failed before the response was received. In this case, BizTalk is only aware that it did not receive a response and resends the request after the specified period.