I need to call a web service that has multiple parameters with BizTalk. With the SOAP adapter, I could send a multi-part message (one part for each parameter). However, I would like to use the WCF-BasicHttp adapter instead, since the SOAP adapter has been deprecated since BizTalk 2009.
From various sources, I see that the WCF adapters do not support calling multi-parameter operations (see for example Scenario 4 in http://seroter.wordpress.com/biztalk-and-wcf-part-v-publishing-operations-patterns/)
Is there any way to workaround this limitation, for example by developing a custom pipeline component?
You are right: WCF adapter doesn't support multi-part messages which is a miss. There is excellent post on the topic here: http://blog.sabratech.co.uk/2009/08/biztalk-wcf-adapter-and-multipart.html
If having multi-part message is important for some reason you can still use SOAP adapter in BTS2010. To add Web Reference click "Advanced" on the "Add Service Reference" popup and then "Add Web Reference". This should work but WCF adapter is considered better for many reasons.
Did you consider mapping all parts from your multi-part message to single WCF request message and then mapping response back?
Related
I currently need to configure a dynamic send port to connect with an ASMX web service that does not conform to WS-I Basic Profile v1.1. Specifically, R9981, which states "An ENVELOPE MUST have exactly zero or one child elements of the soap:Body element." The web service I'm consuming is expecting a body with multiple elements, causing the SOAP body to look like:
<Body>
<FirstElement />
<SecondElement />
</Body>
I have tried using both WCF-BasicHttp and WCF-Custom adapters with no success. It seems that the BizTalk WCF adapters can just not handle a SOAP body with more than one element.
On the receive location, I wrap the message under one element using a template to solve the issue of the message traveling through BizTalk and I thought I could simple intercept the message with a custom send pipeline / custom component to strip out the wrapping element. I then tried a custom behavior extension with a message inspector, but that still occurs before BizTalk's WCF "BizTalkBodyWriter" does its work.
As I'm using the ESB 2.1 toolkit, I cannot use the HTTP adapter to create my SOAP message from scratch. My last thought would be I would need to create a custom WCF LOB adapter, but before I go down that route I want to make sure I'm not overcomplicating things here and there isn't an easy way I've just overlooked.
The solution was to create a custom message encoder. I followed WCF Interoperability and Extensibility - Part One as a guide.
We have WCF web service defined with 6 Operations with the single endpoint. This service is created by using "BizTalk WCF service publishing wizard". Basically end user will send the message by calling the particular “WCF SOAP ACTION” of the service. BizTalk resolves the itinerary based on the “SOAP ACTION” using BRE resolver.
Now the requirement is to do the load test with above service
To generate load for the service, we are using LoadGen. But we are having technical challenge specifying the WCF Action(operation) name in LoadGen. Do anyone have any idea how can we do this?
FYI., In our implementation, BizTalk ESB resolves the itinerary based on the “WCF Action” using BRE resolver and not with message type. By using message type, we able to resolves the itinerary using BRE resolver. But the requirement is use WCF Action(operation) name and not the message type to resolve the itinerary in BiaTalk ESB, because multiple operation uses same message type but do different action.
Any help would be highly appreciated!
Thanks
Sudhakar
For WCF services LoadGen cannot create a custom action header for the SOAP action. For basic profile binding you may try to use SOAPSection and define SOAPHeader nodes. That would exclude the use of WCFSection. A better option would be to change the WCF service to accept any action [OperationContract(Action="*")]
So in the TryReceive() method construct the message object and return it to the engine which will be submitted to the message box. My scenario requires the receive-response message exchange pattern, in a way that adapter will send a reply back to the LOB system when the incoming received message is successfully committed to the messaggebox, where should I send the response message?
Thanks.
It looks like you want to expose some of you application schemas as a WCF service. You can do this by using the WCF Service Publishing Wizard, which you can find in the BizTalk program menu (from All Programs).
If this is the case and you want further guidance then reply to this via a comment and I will expend this answer.
WCF LOB Adapter SDK supports this scenario as mentioned here http://msdn.microsoft.com/en-us/library/bb798121%28v=bts.10%29.aspx.
It seems like a combination of Synchronous Inbound and Asynchronous Outbound.
I am designing a Biztalk solution which requires client applications to subscribe and receive only a certain subset of event messages depending on their user permissions. Subscription will be done through topic or content based routing. The client will subscribe once and receive many messages until they choose to unsubscribe.
Client applications will number in the 100s and subscribed topics could change on a regular basis, so defining an individual send port from Biztalk for each reciever isn't a viable solution.
I have thought I could build an additional message broker service which holds the individual client subscriptions and distributes messages sent from a biztalk port.
I have also seen that a recipient list pattern can be build using orchestrations. This appears to me to still follow a request-response pattern though and I am after 1 way subscribe message to many returned event messages.
My message broker solution seems to me to be doubling up on what Biztalk should be good at so I imagine I am missing some important functionality somewhere. Has anyone tried such an application before and can give some pointers? Should I be investingating the ESB toolkit as a solution? I have had a look on the net but nothing makes it very clear for this type of topic-subscription model.
Thanks,
Phil
Do take a look at the ESB Toolkit. You can use the itinerary functionality that it adds to BizTalk, either with one of the built-in resolvers (e.g., UDDI) or with your own custom resolver. This allows you to route messages based on configuration (stored in Business Rules or elsewhere).
You will find a developer-oriented overview video of the ESB Toolkit on MSDN, which is a decent introduction to the design process and tooling. There are several other helpful videos there as well.
Your specific scenario can accomplished with a single itinerary, as described here. Use a receive pipeline with the ESB Dispatch Disassembler component, configure multiple resolvers, and for each resolver a new message is produced.
There are also two samples to look at:
The Itinerary On-Ramp Sample - builds a set of SOAP headers that contain the itinerary that you create in the test client, loads the specific message file from disk, appends the itinerary headers to the message, and submits it to the ESB through an Itinerary on-ramp for processing.
The Scatter-Gather Sample - Also appends SOAP headers containing the itinerary to the message, which is submitted to the ESB through an on-ramp for processing. A Broker orchestration analyzes the settings for its itinerary step, retrieves a collection of resolvers associated with the itinerary step, and for each of those resolvers resolves the service endpoint. After that, the orchestration activates the proper ServiceDispatcher orchestration instances to dispatch the outbound request messages.
You should also look at "How to: Route a Single Message to Multiple Recipients Using an Itinerary Routing Slip" or perhaps look into creating a custom itinerary message service (documentation is here).
Using the BizTalk ESB Toolkit 2.0
We are working on a project where we need to call a proxy to a web service which is a DLL. We have no problems doing this via an orchestration since you can use a static port and configure it to use the SOAP adapter with the web service setting pointing at the assembly in the BizTalk Admin interface. In the itinerary though there doesn't seem to be an obvious way to do this since dynamic ports don't have the option to use the SOAP adapter.
There is a good reason why we want to do this, don't worry.
Following on from this, we implemented a custom adaptor provider but are having problems getting it to work.
We followed an (old) example shown here:
The custom adaptor provider inherits from BaseAdapterProvider and overrides the SetEndPoint(Dictionary, IBaseMessageContext) method.
The method extracts the assembly name, type name, and method name that are passed in via the resolver dictionary and then writes them to the pipeline context:
pipelineContext.Write("TypeName",
"http://schemas.microsoft.com/BizTalk/2003/soap-properties", typeName);
pipelineContext.Write("MethodName",
"http://schemas.microsoft.com/BizTalk/2003/soap-properties", action);
pipelineContext.Write("AssemblyName",
"http://schemas.microsoft.com/BizTalk/2003/soap-properties", assembly);
and sets the transport type to soap:
pipelineContext.Write("TransportType",
"http://schemas.microsoft.biztalk.practices.esb.com/itinerary", "SOAP");
In all other respects the adapter provider is nearly identical to the example shown in the link above, except for the obvious change from SMTP to SOAP.
The adapter provider assembly is signed, GACed, and added to the esb.config.
The adapter provider is called from an itinerary that only calls the service and then returns the response. We are testing the itinerary from the Itinerary Test Client that is shipped with the toolkit. Event logging within the custom adapter shows that the adapter code is being called. The problem is that the message is not being routed to the service proxy. The event viewer gives the following error:
The Messaging engine failed to process
a message submitted by adapter:SOAP
Source
URL:/ESB.ItineraryServices.Response/ProcessItinerary.asmx.
Details:The published message could
not be routed because no subscribers
were found. This error occurs if the
subscribing orchestration or send port
has not been enlisted, or if some of
the message properties necessary for
subscription evaluation have not been
promoted. Please use the Biztalk
Administration console to troubleshoot
this failure.
Investigating the suspended service instamces in Group Overview shows two things:
The values for assembly name, type name, and method name are being set correctly.
The message body is missing.
We have tried configuring the send and receive pipelines on the send port to be both XMLTransmit/XMLReceive and ItinerarySendPassthrough/PassthroughReceive and it makes no difference.
Is there something obvious we might have missed? Do you have to explicitly pass the message body through? If so how?
EDIT:
Following a request from the BizTalk ESB Toolkit forum I am posting screen shots of the itinerary, context and send port filters.
Itinerary,
Context,
Port filters.
Many thanks, Nigel.
first of all I'll say you are trying to over engineer the solution. Adapter development is not trivial and there are various things you need to take in to consideration. Developing and Deploying adapters are categorized as platform changes, which effects your whole environment, so if you are not familiar then your shouldn't do it. I would recommend you taking some other route. At this point I personally don't have enough insight into ESB internals, so won't be able to comment on it. At worst case you may be better off using the .NET proxy dll directly inside your orchestration (expression or message shape) rather than building an adapter. Even though its not recommended approach, still I feel its better than custom adapter approach.
Semantically, I don't see why a solution that involves a WCF-BasicHtpp adapter would not work in your scenario. In any case, I would definitely try to see what happens with a WCF-BasicHttp adapter, and once I got a working solution, I would switch to a custom SOAP adapter if that is really necessary.
Currently, your solution is weird - in the sense that you have an On-Ramp directly connected to an Off-Ramp. I've never seen that in any of my itineraries. You might need to create an intermediate messaging or orchestration Itinerary service in betweeen.
Otherwise, the message effectively gets published to the message box and obviously there is no subscribers for it, hence the error you encounter.