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.
Related
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?
I have the following itinerary:
A one way receive location passes a message to an orchestration where an inner message is extracted (unable to do this in a map).
The returned message from the orchestration is then mapped and the
result of that map, mapped again. Using the Microsoft.Practices.ESB.Services.Transform service.
This is then passed to a web service, via the Microsoft.Practices.ESB.Services.Routing service, which fires fine but I am not receiving the expected response which I want to write to file. The message that does get written to the file is the message passed to the web service rather than the expected response. Testing the web service using a simpler itinerary i.e. one without orchestration extenders shows that the web service works as expected.
The OffRamp is from the GlobalBank.ESB example application.
How can I get the required response from the web service?
So finally managed to find a solution to this for which I have to give full credit to this guy
The problem is Microsoft.Practices.ESB.Services.Routing Service only provides one way operation, so even if you mark your resolver with two-way message exchange pattern it wont work.
If you check Microsoft.Practices.ESB application in BizTalk Admin console, it has one one way dynamic send port Microsoft.Practices.ESB.Agents_2.1.0.0_Microsoft.Practices.ESB.Agents.Delivery_DeliveryPort_31bf3856ad364e35 which is bound to orchestration Microsoft.Practices.ESB.Agents.Delivery. When you use Orchestration extender and use Microsoft.Practices.ESB.Services.Routing service, this port is used to send any call and because this is one way port, you do not get response.
You need to use a Two-way orchestration in callwebservice shape. A sample Two-way orchestration is in MultipleWebServices ESB Sample. If you deploy that orchestration and register it as itinerary service and use it in callwebservice shape, it will work.
and it more or less did :) Deploy the orchestration and register it to the ESB as an itinerary service by adding an entry to the esb config between the itineraryServices node:
<itineraryService id="04BD6120-06E4-43D3-A56F-2FF061D59862" name="ESB.MultipleWebServices.Orchestrations.TwoWayRouting" type="ESB.MultipleWebServices.Orchestrations.TwoWayRouting, Biztalk.EsbGeneric.Orchestrations, Version=1.0.0.0, Culture=neutral, PublicKeyToken=140bc5dcbb9afcea" scope="Orchestration" stage="None"/>
Create an id using guidgen, the type is made up of the name and assembly of the orchestraiton (comma seperated) in the Admin Console and will vary depending on the application that you have deployed to. scope and stage are as shown above.
Initially I had an error on the send port Biztalk.HoopleEsbGeneric.Orchestrations_1.0.0.0_ESB.MultipleWebServices.Orchestrations.TwoWayRouting_RoutingPort_140bc5dcbb9afcea but changing the send and receive pipelines to PassThruTransmit and PassThruReceive respectively solved this.
I'm receiving an error when I'm attempting to consume a web service:
Cannot read the token from the 'Timestamp' element with the 'http://docs.oasis- open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd' namespace for BinarySecretSecurityToken, with a '' ValueType.
Not quite sure
The client is an asp.net web application, making a call. From Wireshark, one can see the post going in, and the response coming back, but then it errors out like this.
To give some background, this is a WCF calling on a java served web service.
You may need to add a security timestamp soap header to the message. Look at this SO question where they had the opposite problem but it may be helpful to look at their configuration. Also, you may save yourself some grief if you can use one of the WCF Interop Express bindings for accessing a java service implementing WS-Security.
Is it required to use a RESTful
service to be able to make a ajax
call to a wcf service (for example: by using
WebInvoke attribute on Operation
contracts)
Once a service is made RESTful by adding a webHttp binding on the service host, can the host have other endpoints as well? (wsHttp or netTcp)
Is it required that the aspNetCompatibilityEnabled be set to true for a service that has webHttp binding (and can this setting coexist for other endpoints)
I understand I can use both JQuery and ScriptManager for making WCF calls on the client. Why should I use one over the other?
Answers
No.
AJAX is typically used for sending simple HTTP GET ("REST") requests. It doesn't have to be so. You could also format a payload using a SOAP envelope, and POST it to the endpoint. In that case the WCF service would have to be wsHttp or basicHttpBinding, at least. Here's an example of using VBScript to create and send a SOAP request, but you could do the same in Javascript. You can't use the more advanced SOAP extensions, like WS-Security, XML DigSig, and so on. Well, you could but it would be impractical. For example, I don't know of any XML canonicalization library in Javascript, which is essential for doing WS-Security or digital signatures. There are 17 similar obstacles. Result: you can't use the more advanced SOAP extensions when calling from Javascript.
.
If you use jQuery ajax, you'll need to use the beforeSend callback on the ajax request to set the SOAPAction header.
.
Having said that, it's a lot easier to process json in a Javascript program, than it is to walk the DOM of an XML document. In other words, you're better off using JSON/REST when connecting from Javascript to WCF, instead of SOAP. Sometimes it's not an option, I guess.
Yes
A WCF service can have multiple endpoints and they can listen on the same or different transports such as HTTP, net.tcp, net.pipe, or net.msmq.
No. aspNetCompatibilityEnabled just enables some ASMX-like features on the server. It affects how the service is designed, and it is independent of the message signature. It does preclude the use of non-HTTP protocols. For more on this, see Wenlong Dong's article.
as for which framework to use on the client - which is easier? I don't have experience with ScriptManager, but the decision criteria is pretty simple. jQuery works just fine, and is appropriate if you already use jQuery. If you don't have or want jQuery, you can use XmlHttpRequest to send SOAP or REST requests. If those are somehow inappropriate, use something else.
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.