I have customer-info that is sent by MSCRM and received in biztalk using a oneway wcf receive location. (wshttp)

On the other hand I have several sendports that customerdata is sent to (sql, file, orchestration and wcfcustom)

I find that if the 2 wcf-req/resp-sendports are enlisted (and I believe also if only one is started but returns an error)  all I get is an routing failure in my suspended-non resumable queue,  the message itself is nowhere to be found!  And wasn't sent to any of the other ports as well!

Is there is only one WCF-sendport everything works as expected.

Odd thing is , if I send in a message using file-adapter instead of WCF , everything works OK, even with the two WCF-sendports started.   So why does biztalk behave in this way if I have a message coming in through WCF?

Is there something wrong in my setup of the receivelocation ?  Something else you can point me to?

I'm still testing to see what happens but it's certainly behavior I do not like!

If you don't expect anything meaningful back from the Services you are consuming, you shouldn't use a Solicit-Response WCF Send Port but rather just use the one-way (the one-way can be used even if the Service method actually does have a return type).

You should only use a Solicit-Response Send Port if you have somebody (Orchestration, R/R Receive Port, or another Send Port) that subscribes to the response.

Morten la Cour

To clarify, you're having a problem with WCF-Custom 2-Way (Solicit/Response) Send Ports?

What you're probably seeing suspended is the actual Port instance because there is no one listening for those response messages.

If you don't expect to do anything meaningful with the reply, or just don't care about it, you need to change the 2-Way WCF Send Port to a One Way.

Oh, but I have a port listening for these response-messages,  I just drop them in a folder :-)

I'm indeed not interested in the response that holds no data. (errormessages I am interested in)                      Won't the other applications that return the response have problems if I change to a one-way sendport?They respond but no one listens.......

No the other application wouldn't even know the difference. You would just "throw the response away".

Morten la Cour

The Adapter will still accept the Response message so the Service is satisfied.  If the Port is One Way, the response just isn't submitted to BizTalk.

Tried your suggestion.....it seems it all depends on how the receiving service is implemented.

If everything is OK , no problem....

If the service has problems processing the xml because there is an error in the data  and it doesn't throw an exception , ok.

If the service does throw an exception I see this error in the biztalk eventlog and the message is going to be retried.....(no need to because data is wrong)

So I think the setup will depend on what the receiving service expects...in this case they have kind of a logging in place so you can see those errors inside the application itself.

But there is another application where they expect biztalk to handle errors (store them, send them,.....) 

So if this is the case I will have to use req/resp  (although I'm not interested in the OK-response)

Correct ?

I would still use one-way since you don't need a response. If BizTalk is to handle any SOAP exceptions that might occur, I would enable "Failed Message Routing" on the Send Port, and then have another Port or Orchestration subscribe to the errors from that Port.

Filter: ErrorReport.SendPortName == [Your Send Ports name]

Morten la Cour