Better support for low latency scenario's
Zero messagebox low latency scenario's
Matthew Robinson commented
Or in any other plural for that matter
Matthew Robinson commented
No need for an apostrophe in "scenario's" :-)
Jaap van popta commented
As a reaction to the questions; I my 2 cents on this:
I support this idea and then in the way that you can implement a scenrio where you do'nt have the message box roundtrips for the Pub Sub.
The hosts are always polling for work and that means a delay of max half a second (when you don't tune the settings) so when you have multiple actions you have multiple half a seconds delay which leads to not a very fast situation.
So if you need a fast scenario, for instance if you have a user waiting, you are required to build a solution outside of BizTalk, so you cannot use things as Ports/Mappings/Schema's/Orchestrations in the way that you would in BizTalk.
So when you would have the possibility to still use these artefacts but you could choose whether or not to use the Messagebox you would be able to host this stuff in BizTalk.
Of course this would have implications for guaranteed delivery etc.. but at least you would have a choice, if you would build it in let;'s say a WCF .Net service you also would not have this (automatically)
Jaap van Popta
The feature to specify if/when a orchestraton should be persisted could of course also help.
Sql server alteady has in memory tables that are also persisted.
For large files filestream could be used which.
But i agree in a scenario where there is only passthrough on both sides a direct connection could be made. But then Biztalk needs to check this confition everytime any port is updated.
Adam smeal commented
Scenario: messaging only in high volume realtime HL7 processing (or any high volume messaging only environment).
With simple subscriptions, say receive port only, persistence is unnecessary. Get that message in and out the door - would guarantee ordered inbound delivery in my scenario.
Could think of others.
Toon Vanhoutte commented
Leverage redis for in memory pub/sub? :-)
Pieter Vandenheede commented
It would be great to have some kind of setup which might skip the MessageBox all together and have some in-memory processing with the downside of having no persistence.
Vikas Bhardwaj commented
In my view, latency as low as it can be. This is desired especially when exposing services in BizTalk. In such cases, Message box can add to the latency especially for synchronous operation where consumer is waiting for BizTalk to respond. I understand there are ways to improve the latency, however, its one functionality if available as an option, will be a great feature.
This is very good feedback, what specifically do you mean by low latency and no message box. Do you have scenario this would apply to?
Thomas E. Canter commented
How low? 1 ns, 1 microsecond, 1 millisecond?