Drawbacks of Inline send ports

Question

Hi,

Are there any drawbacks in using the inline send ports?

Thank,
Vinoth

Answer 1

Hi,

What do you mean by inline send ports. Do you mean inline sends? Or do you mean dynamic send ports?

If you mean inline sends you're actually skipping part of the BizTalk functionality and take a shortcut to improve performance. My personal opinion is that should always try to avoid this way of working as much as possible and only use it if absolutely necessary. There are a couple of obvious drawbacks:  You don't use the messaging send ports and therefor HAT tracking information for this part of your process is not stored. There is also no easy way to configure where you need to sent to and using what protocol, credentials, etc. You do not use hte subscription mechanism which makes it hard to have multiple send destinations, etc.

If you mean dynamic send ports. The strength of dynamic ports is that you have flexible (runtime) way of determining where and how to send a message. This strength comes with the drawback that you as a developer are responsible for storing and retrieving the necessary configuration values (protocol, address, credentials, etc). for sending or worse hardcode these values in the orchestration.
Another drawback is that dynamic send ports always run under the default bizTalk application host which is a disadvantage from scaling point of view.

---

HTH, Randal van Splunteren - http://biztalkmessages.vansplunteren.net - Please mark as answered if this answers your question.

Answer 2

Hi ,

I believe use are using some dot net component to get the data from service or sql database and avoid using Adapter and Physical port.

Disadvantage : since you are not using adapters and physical ports, the application will not benefit from their functional capabilities such as batching, retries, correlation sets initialization, declarative configuration and secondary transports.

Advantage: The advantage of this technique is that for each Solicit Response call made by the orchestration, it allows to eliminate 4 roundtrips to the MessageBox:

• Orchestration Logical Port --> Request --> MessageBox
• MessageBox --> Request --> Physical Send Port
• Physical Send Port --> Response --> MessageBox
• MessageBox --> Response --> Orchestration Logical Port

Now its upto you to decide what pattern to go for.


Regards
Vishnu

---

Vishnu

Answer 3

Well, there are some good things and bad things about this.

Inlide send ports (using a .NET component to make a web service call or similar to this) is helpful for better speed (no messagebox persistance) and is useful for cases where there is no BizTalk adapter that really meets what you need. For example, calling the WSS services which are not fully exposed with the WSS adapter.

To me the main disadvantage of inline send ports is that you lose the ability to have out-of-the-box configuration and for web services this is critical because you will want to change the web service address in deployment. Because an inline component executes in the BizTalk process you would need to use the BizTalk config or some other custom config store (like SSO).

I prefer to move decouple inline sends to a separate process (outside of BizTalk) so I can preserve the default configuration capabilities. This means you would get the advantages of an inline send with better configuration.

Thanks,

---

If this answers your question, please use the "Answer" button to say so | Ben Cline

Answer 4

Hi,

In my solution the orchestration is to only call the WCF services. Already we have a custom repository for all WCF url and binding information then we are loading it dynamically in orchestration. As there are so many wcf calls in the orchestration i could not avoid that many send shapes. 

In order to improve the performance, I had a thought of using the  inline sends. In this case i want to analyse the pros and cons. As we already have a custom store for wcf configuration, do you think it is a good idea to go for inline send.

Please suggest.

Answer 5

In order to improve the performance, I had a thought of using the  inline sends. In this case i want to analyse the pros and cons. As we already have a custom store for wcf configuration, do you think it is a good idea to go for inline send.

Why do you want to improve performance? Because it really IS running too slow or because you just want to?

Unless you are getting errors or angry users because of delays, I'd stick with the built-in functionality using normal sends as far as at all possible.

Use inline sends when the built-in adapters CANNOT help you - not just because you think it is too slow.

That's my thoughts, anyway...

---

eliasen, representing himself and not the company he works for.
Three times MVP and three times MCTS in BizTalk.
Blog: http://blog.eliasen.dk

Answer 6

Inline sends are a Microsoft recommended way for avoiding the MessageBox database - this is a low latency option. Obviously you do not get all of the standard BizTalk functional capabilities by not going through the MessageBox.

It sounds like you have the configuration all handled, inline sends should work fine for you.

Paolo Salvatori has published the BizTalk Optimization Guide samples at http://cid-09dba4a06b360a65.skydrive.live.com/self.aspx/Pubblica/PerformanceOptimizationGuide.zip, and this includes quite a bit of logic using inline sends.

Thanks,

---

If this answers your question, please use the "Answer" button to say so | Ben Cline