Yes, it’s been a while. A long while…
I was recently required to import a simple XML file into a set of records in an Oracle table. This sort of integration is pretty simple using BizTalk Orchestrations, but we’re trying to move to an ESB-centric model.
I struggled finding an easy-to-follow guide, so am going to document my findings to help myself, and hopefully others, next time I need to complete a similar task.
The major sticking point was in the creation of the ESB Resolver string for the Routing Messaging Extender (Microsoft.Practices.ESB.Services.Routing).
Note: These settings are just a valid for use in an Orchestration Extender as well as the Messaging one.
The settings for your Routing Resolver are pretty simple to work out, but you need to remember to include the Action from your generated WCF binding file.
The trickier part was the value of the Endpoint Configuration setting:
As highlighted in the above image, ensure the Binding Type is “oracleDBBinding” (case-sensitive), and set your username and passwords as appropriate. The password will be stored in clear-text in the Itinerary, but hopefully you’re using an x.509 certificate to encrypt the contents.
Next up is the BindingConfiguration setting within the Endpoint Configuration setting. This should be considered akin to a mini Xml Document that gets passed to the Adapter at runtime, with a couple of simple, but important, settings:
As can be seen, these settings can be derived from the settings used in the Static WCF-Custom configuration dialog for a binding of the same type. The important thing is the use of < and /> as start and end delimiters.
Save your settings, complete your Itinerary, and you should be interacting with your Oracle database without any need for Orchestrations or inflexible Static Send Ports.
I recently ran into a real conundrum at the end of a deployment when we discovered that we would be sending messages to a one way (i.e. fire-and-forget) web service using the inbuilt WCF adapters.
Easy! Just use a one-way Send port with the WCF-BasicHttp binding! Everything builds and deploys just fine, however, at run time, we started getting the following error messages:
System.ServiceModel.CommunicationException: The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.
A little research highlighted that Microsoft does not support sending from BizTalk to one-way Web Services, as BizTalk uses the response acknowledgement to confirm the original message has actually been delivered (remember, BizTalk is all about “Guaranteed Delivery”). Despite these protestations, sometimes you have to go with “The Customer is Always Right”, even when the customer is actually wrong.
Thanks to a very helpful set of posts by Phillipe, I was able to convince BizTalk to actually send messages, using a “proxy” WCF Service. The proxy accepts and forwards the Request message, and returns an empty Response message back to BizTalk.
We lose a considerable amount of configuration flexibility, as BizTalk is no longer the sole keeper of end-point information, and there is less visibility if something does go down, but it’s a reasonable workaround for an inbuilt limitation of the standard BizTalk adapters.