What’s right & wrong with WCF-WebHTTP Adapter?
Download as PPTX, PDF1 like2,144 views
This document discusses the pros and cons of using the WCF-WebHTTP adapter in BizTalk, including issues with Azure service bus relays, error handling, and the JSON encoder and decoder. Workarounds are presented for common problems, such as relays only supporting the base URL and the encoder/decoder having date/time and number formatting issues. The document provides links to blog posts with more details on issues and workarounds for the WCF-WebHTTP adapter in BizTalk.
What’s right & wrong with WCF-WebHTTP Adapter?
- 1. Sponsored & Brought to you by What is right & wrong with the WCF-WebHTTP Adapter? Colin Dijkgraaf Integration Consultant at Datacom http://www.twitter.com/CDijkgraaf Mark Brimble Principal Integration Architect at Datacom http://www.twitter.com/brimblemark
- 5. Premises for this talk
- 7. The Good, Bad and Ugly Story
- 8. •Re S T What do you use the WCF-Web HTTP Adapter for?
- 9. Why does the adapter not do what it is supposed to do?
- 10. Issues with WCF-WebHTTP adapter
- 13. Azure service bus relays only work for the base URL
- 16. HTTP 500 error not detected and other error codes are missing
- 17. Message type not set on error
- 18. HTTP status code not set on error
- 19. No OOTB way to suppress 404 status code
- 21. https://cdijkgraaf.wordpress.com/2016/08/12/biztalk- 2013-r2-known-bugs-issues-quirks/ Workarounds for other WCF-WebHTTP issues
- 22. Issues with JSON Encoder and Decoder
- 23. Decoder drops trailing 0’s after the decimal
- 24. Encoder adds a outputs a Integer as a decimal
- 25. Encoder adds a time to a Date
- 26. Encoder changes date-time timezone
- 28. https://cdijkgraaf.wordpress.com/2016/08/12/biztalk- 2013-r2-known-bugs-issues-quirks/ Workarounds for the JSON Encoder and Decoder
- 29. Premises for this talk
- 30. Acknowledgements
- 31. Thank You Twitter: #integrationmonday Website: http://www.integrationusergroup.com/
Editor's Notes
- #3: BizTalk has been our integration tool of choice for the last 12 years Colin and I have written a book about it.
- #4: Colin and I love BizTalk and for many years I have written blogs about integration.
- #5: Colin and I love BizTalk and for many years I have written blogs about integration.
- #6: We are going to tell you why the WCF-WebHTTP adapter requires some workarounds. How did we became so grumpy about this adapter? The next slide shows our last project which we worked on for the last year.
- #7: We decided that all service endpoints would be REST/JSON because we had a view that eventually we would lift everything in to Azure at some point. We have lived with the WCF-WebHTTP adapter and the JSON encoder and decoder for the last year and have had to develop many custom workarounds to make this work. In this talk we are going to share our pain with you.
- #8: The rest of the talk will be broken into three parts.
- #9: REST best suited for limited bandwidth and resources where you need to process simple Create, Read, Update , Delete type operations. It uses HTTP protocol to send messages in XML or JSON. It is now ubiquitous for mobile devices
- #10: Colin has listed many issues on his blog and in this talk we will discuss each one , one by one with demos and workarounds.
- #12: First we will start by looking at issues with the Azure service Bus Relays with WCF-WebHTTP adapters. This is a pattern we have used a lot. A SaaS application sends a JSON message to a Azure Service Bus Relay from BizTalk server. This overcomes many challenges if you wish to expose a WCF service hosted on premise. There a re no requirements for proxy or firewall changes, provided outbound ports are open for HTTPS traffic. An outbound connection is opened to Azure and once this connection is established, bidirectional communication is enabled between the service and the client. The key point here is that an outbound request is initially being made from within the corporate network boundary and kept open, with no requirement for inbound access for external consumers.
- #13: The JSON message is decoded on the receive port into an internal XML message. Internal message is map to another format on the send port
- #14: Relays only work for the base url. As soon as you add a resource you get back a 202 “AddressFilter mismatch. The reasons for this have been comprehensively explained by Johann Cooper in a blog which I will reference after a demo. He used the WCF-WebHTTP adapter in BizTalk 2013 but his comments also apply to BizTalk 2013R2 and BizTalk 2016 Tap release. The demo will show the problem and then a workaround….and for a special treat I will show you this in the BizTalk 2016 TAP release.
- #16: We have shown in the demo that the WCF-WebHTTP adapter has issue when use a Azure Relay and that you must use a custom behaviour to overcome this problem.
- #17: 500 HTTP errors behave differently from other non 200 HTTP status codes. Other error codes it throws a fault exception. Hard to handle 404 errors in a messaging only solution
- #18: SOAP fault message does not have the context property MessageType Cannot map or catch Fault on the Logical Port in the Orchestration
- #19: InboundHttpStatusCode or InboundHttpStatusDescription context property not set for faults. Makes handling of exceptions more difficult
- #23: Next we list some issues with the JSON decode and encoder that are also listed on Colin’s blog. Once again we will demo each one and then present a workaround.
- #30: We have told you why the WCF-WebHTTP adapter requires some workarounds and demonstrated these to you.