This document discusses controlled throttling in BizTalk. It describes two approaches to implementing throttling: an aggregator orchestration and a pipeline component. The pipeline component approach is preferred as it minimizes message box hops. The document provides tips for implementation including disabling retries and enabling ordered delivery on send ports. It also covers common pitfalls like built-in throttling violating required values. Finally, it discusses lessons learned like the challenges of achieving exact throughput and introducing latency.

1. Controlled Throttling in BizTalk
Ahmed Taha
https://www.linkedin.com/in/ahmedmmtaha/

2. Nice to meet you!
Technical Architect at Link Development
Integration enthusiast
Avid Reader 

3. Overview
 Landscape
 Requirements
 Implementation Approaches
 Implementation Tips
 Demo
 Common Pitfalls
 Lessons Learned
 Final Thoughts
 Recommended Book
 Q&A

4. 3rd party Systems
Landscape
Upstream System Downstream System
Fan-out

5. Requirements
High
Throughput
Input

6. Requirements
Business
Rules

7. Requirements
Back-end
Throughput
Limits

8. Efficient use of Throughput Limits
Requirements
Variable
Back-end
Throughput
Limits

9. Configurable
Date Range
Time Range
Day of Week
Requirements
Configurable
Back-end
Throughput
Limits

10. I like a good challenge!

11. First Approach – Aggregator Orchestration
Throttled
Message
Send Port
Normal
Message
Receive Port
Add
Throttling
Context
Business
Rules
Memory Cache
Send Port
Throttling
Orchestration
SingletonBRE Pipeline Framework
Fan-out

12. Aggregator Orchestration Pitfalls
Orchestration Delay shape accuracy
Inevitable Orchestration persistence points overhead
Zombie Messages

13. Second Approach – Pipeline Component
Throttled
Message
Normal
Message
Receive Port
Add
Throttling
Context
Business
Rules
Memory Cache
Send Port
BRE Pipeline Framework
Send Port
Apply
Throttling
Ordered
Delivery
Fan-out

14. Efficient Throttling solutions should minimize or avoid message box hops
It should be applied at the edges of the solution
Receive PortPipeline
Message Box
Send PortPipeline
Implementation Tips

15. Retry must be disabled on the Send Ports
Ordered Delivery must be enabled on the Send Ports
Cluster Hosts for a highly available solution
Implementation Tips

16. Receive PortPipeline Send PortPipeline
Message Box
2-way Send port
Request1
Response1
Request2
Throttling directly on a 2-way Send port will not be efficient
Implementation Tips

17. Two-way send port processing delay overhead, use Loopback Adapter
BTS RCV
Adapter
BTS RCV
Pipeline
Add Throttling Context
Throttled System Message
NULL
Adapter
Throttling Pipeline (Loopback
Per External System)
Adapter
(External
System)
Throttled Message
Throttling Rules + Caching
Normal Message
Clear Cached System Throttle
Clear Cache
Implementation Tips

18. Demo

19. Examples:
Host Queue Size
Database size threshold
Make sure that Built-in Throttling itself will not throttle your system
Custom
Throttling
Throughputs
Built-in Throttling
Thresholds
Common Pitfalls

20. Receive PortPipeline
Message Box
Send PortPipeline
Built-in Throttling could violate the required throttling values
Common Pitfalls

21. Receive PortPipeline
Message Box
Send PortPipeline
Efficient Throttling solutions should minimize or avoid message box hops
Common Pitfalls

22. Detect and fine tune platform’s built-in throttling under realistic loads,
early on.
Detect the weak points in the artifacts of your solution under realistic
loads, early on.
Conduct load Testing, at different stages during development.
Common Pitfalls

23. BizTalk built-in throttling is not designed to achieve exact throughput values
Achieving controlled, accurate throttling is very challenging, especially when the latency is
required to be at a minimum
It will introduce inevitable latency to the solution which could be minimized to very small
values, few milliseconds
For guaranteed upper limit throughput only, you could apply the throttling component on
the 3rd party system’s Send Port directly
Lessons Learned

24. More and more service providers are adopting API management.
Final Thoughts
Service Provider
BizTalk Server
Service Consumer

25. You could also Apply API management policies that abide by downstream system’s
governance rules, on the Operation level.
Final Thoughts
Service Provider
BizTalk Server
Service Consumer
GetCustomerInfo()
GetCustomerData()

26. Bending the platform or Challenging requirements ?

27. “BizTalk is supposed to be a fast messaging platform” – MS Support
“BizTalk was not designed to do so” – Kevin Lam
Final Thoughts

28. Message Box is a Messaging Queue Implementation
Send PortReceive Port
Message Box
Final Thoughts

29. Final Thoughts
BizTalk supports Delayed Delivery

30. BizTalk Host Queue Table
Final Thoughts
Throttled (Work in progress)
Service Window (Scheduled)

31. Feature Pack 1 – Integration Monday
Final Thoughts

32. Receive Location Schedule Send Port Schedule
Final Thoughts

33. Final Thoughts
Work-in-Progress items in Message box:
“This aspect of BizTalk is critical, as it is not designed to hold too much
information for too long, but to pass the information on and move it out of the
message box.”
– Dan Rosanova - Microsoft BizTalk Server 2010 Patterns

34. Microsoft BizTalk Server 2010 Patterns
Recommended Book

35. BizTalk Server 2010 Unleashed
Recommended Book

36. Q&A
ahmedmmt@outlook.com

37. Thank You