Most of the integration scenarios includes database systems among the interlocutors.
If the database is not large, and contains a simple architecture of entities, develop interfaces is not so difficult.
Otherwise, if the architecture of entities and relationships is very complex and the occupation of space is hundreds of GB, it might be more difficult to write interfaces.
In this scenario, you can find thousands of tables, views, stored procedures with hundreds of lines of code and functions.
In these contexts, often we not even have visibility of the services that we going to call, and the risk of generating dead lock on tables is extremely high. This risk could increase, especially in the case of use of techniques such as message de-batching where BizTalk Server generates multiple thread with a perfect parallelism.
To overcome this, if you don’t have the opportunity to act within the stored procedures correcting the architecture of the lock, it is possible to enable the “ordered delivery” option on the WCF send port.
“When the port bound to the transport is marked for ordered delivery, then BizTalk Server enforces ordered delivery by ensuring that the transport does not get the next outbound message until the current one has been successfully sent. To achieve this, BizTalk Server passes each message to the transport’s adapter in a single batch and waits until the adapter has successfully deleted the message from the message box before delivering the next message, in another batch, to the adapter.”
Obvious that this is only an extreme measure and it is advisable to apply it only if is acceptable for the process, serializing the calls to the database, that even if they occupy a very small percentage of the whole process, still represent a bottleneck.