Geeks With Blogs
Welcome to
Geeks with Blogs
Login
Gregory Van de Wiele
My Other Recent Posts
Some thoughts on Service Location (SL) and Dependency Injection (DI) with BizTalk...
Biztalk Server AS2 certificates
About compatibility…
BizTalk 2006 SDK: new BaseAdapter
Some great news...
‘Processing convoy workflow scenarios’ patent
BizTalk WMI programming: How to write cleaner WMI code a lot faster
Enterprise Library is -also- there...
The BizTalk SQL Server Adapter isolation level
About publisher policy assembly chaining
Post Categories
WCF Data Services
OData
ASP.NET Membership
User Group
AltooNUG
Code Camp
PGHDOTNET
LINQ
BrainCredits
C#
Things I Didn't Know
JSON.NET
Humor
CQRS
Architecture
ASP.NET MVC
WP7
Mobile
Thoughts
Pittsburgh TechFest
COM-InterOp
Integration
SOLR
Archives
February 2010 (1)
December 2009 (1)
September 2009 (1)
August 2009 (2)
July 2009 (1)
June 2009 (2)
May 2009 (2)
February 2009 (1)
December 2008 (1)
September 2005 (2)
April 2005 (1)
March 2005 (2)
February 2005 (1)
November 2004 (4)
October 2004 (2)
September 2004 (4)
El Grego
BizTalk blog
<< BAM Portal Related Document Links That Actually Work
|
Home
|
BAM Typed API alternative >>
Configuring a Static WCF Port to Behave as a Dynamic Port
Comments (1)
|
Share
Yesterday I've tried to reproduce the scenario 'Configuring a Static Port to Behave as a Dynamic Port' from the excellent MSDN article '
Consuming and Hosting WCF Services with Custom Bindings in BizTalk Server
' but with a twist: instead of writing the BTS.OutboundTransportLocation context property inside a custom pipeline component I've tried doing this from inside orchestration.
It didn't work. I had to do it differently. Let me explain...
If you manually promote a custom value for the BTS.OutboundTransportLocation on your outgoing message inside an orchestration message construct and send the message to a static send port, the BTS.OutboundTransportLocation property is magically overwritten with the address from the statically configured send port. The fact that this property is automatically set by the engine seems logical because it is necesarry for a regular static send. I only hoped it wouldn't be overriden when already present.
Why magically? Because it doesn't show up like that in HAT! If you look into HAT the message-context 'before pipeline execution' you can see that the custom value is there: it was successfully written to the context inside the orchestration.
But by adding some traces to a dummy pipeline component I can CONFIRM that those custom values are indeed already erased and reset to the address from the send port configuration @pipeline-execution. This indicates that there is an additional step after tracking and before the adapter triggers the pipeline execution, where the engine adds all sorts of properties from the port configuration. So e
ven when you are using a passthru send pipeline the message 'after pipeline execution' has a different context then 'before pipeline execution'.
Another clear case of opacity ;-)
And that's where my confusion came from. One might wonder why they didn't choose to track
the 'before pipeline execution' right after the engine added its properties. There is probably a good reason for that...
Anyway, I needed to take a step back and reconsider the approach from the article ie setting the value inside a pipeline component. But hardcoding or configuring an address inside a pipeline isn't really 'dynamic'.
So here is the final piece of the puzzle:
Roll in your own 'address' property that is written on the message context inside orchestration and is re-written into the BTS.OutboundTransportLocation property during pipeline execution.
Posted on Tuesday, June 16, 2009 4:26 AM
BizTalk - EAI - B2B
|
Back to top
Related Posts on Geeks With Blogs
Matching Categories
WCF send port behavior
BizTalk - EAI - B2B
RESTful Enterprise Development
BizTalk - EAI - B2B
CharacterTranscoder pipeline component on github.c...
BizTalk - EAI - B2B
Question marks in your flatfile output CONTINUED
BizTalk - EAI - B2B
Question marks in your flatfile output?
BizTalk - EAI - B2B
Comments on this post: Configuring a Static WCF Port to Behave as a Dynamic Port
#
re: Configuring a Static WCF Port to Behave as a Dynamic Port
Had a static WCF (basic) sendport and used a pipeline to retrieve a promotedproperty that is than set as the BTS.OutboundTransportLocation.
It appears to work indeed! All logging (BTS HAT and such) all seem to indicate all works fine. But the destination insists that you're using the wrong URL. Untill you've restarted the service running the send port. Lesson learned; WCF BasicSend port is using caching and does not react well to changing in url's 'in flight'
Left by
Frank Driesens
on Jul 05, 2010 12:42 AM
Your comment:
Title:
Name:
Email: (never displayed)
(will show your
gravatar
)
Comment:
Allowed tags: blockquote, a, strong, em, p, u, strike, super, sub, code
Verification:
Copyright © Gregory Van de Wiele | Powered by:
GeeksWithBlogs.net
Popular Posts on Geeks with Blogs
0
Code Monkey Projectiles - Index
Kindle days are gone and amazon is not gonna accept it.
Geeks With Blogs Content Categories
ASP.Net
SQL Server
Apple
Google
SharePoint
Windows
Visual Studio
Team Foundation Server
Agile
Office
Design Patterns
Web
Azure
Brand New Posts on Geeks with Blogs
0
Kindle days are gone and amazon is not gonna accept it.
How do you run multiple instances of Microsoft Teams?
Benefits of Apple Cider Vinegar
Shaking down the Raspberry Pi 400
Blog is Moving