- This topic has 4 replies, 1 voice, and was last updated 9 years, 6 months ago by
.
-
Posts
-
-
My schema is exposed as web service, an orchestration subscribe it for the message coming in.
Problem:
When I deploy it either through MSI or Visual Studio, BizTalk reports problem "The Messaging engine failed to process a message submitted by adapter:SOAP Source URL:/…. Details:The published message could not be routed because no subscribers were found. " When I examine the subscription properties using BizTalk Administration console, turns out
Property Operator Value Group by http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {B6784C8C-DF2E-4255-BE4C-5249A155CCF2} And http://schemas.microsoft.com/BizTalk/2003/soap-properties.MethodName == CCValidateSrv Or http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {B6784C8C-DF2E-4255-BE4C-5249A155CCF2} And http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == http://Manulife.Insurance.BigEasy.Mockup/2006#Msg And http://schemas.microsoft.com/BizTalk/2003/system-properties.InboundTransportType != SOAP And
These subscription expression looks weird, especially the last line, why BizTalk automatically adds "InboundTransportType!=SOAP" to the subscription?
When I manually change the binding to an other adapter, enlist the orchestration, after that, I manually change the binding to SOAP, the subscription becomes normal, which areProperty Operator Value Group by http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == http://Manulife.Insurance.BigEasy.Mockup/2006#Msg And http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {65BD0023-DBE0-40D7-B513-E883D7D4A759} And What is going on with BizTalk???
-
It’s kind of funny to see this. I was having the exact same problem a few days ago. I got around it by doing exactly what you did – change the subscription and set it back.
I think this problem came up when I used the Wizard to create the Receive Port for me or maybe when I used the Last Binding inside the Orchestration.
If I remember correctly, I think that exposing the Orchestration port didn’t have this problem.
-
Thanks for the reply. Although I am not using Wizard to create the receive port (in stead, I manually create a SOAP port and bind the orchestration), it turns out the same weird result. This problem becomes even critical when I tried to export the MSI and deploy to staging server, manually modify the binding property is not the final solution … A bug of BizTalk 2006?
-
I don’t think it’s a bug. I think it’s by design and probably for a good reason.
I remember my problem better now; I was getting routing failures like you and looked at the subscriptions. My problem was the MethodName of the Server that was sending in the message. It was using “SomethingElse” and was expecting CCValidateSrv (in your case).
I think the subscription is set up this way to allow multiple Receive Ports to process many different methods (i.e. types of requests). I fixed it by chancing the method name sent by the service.
If you export an Orchestration as a Web Service, the Method Name is the Port Operation Name. If you expose a schema as a web service, I’m not sure where it gets the method name. I bet if you look at the WSDL of the service, you’ll see CCValidateSrv as the method name. Maybe you are not consuming the WSDL correctly?
In my case, the method name was set on the client side.
Oh, you might also want to look at my sample about Untyped Web Services. I don't remember what I did to the Method Name…
Hope this helps.
-
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.