Orphan Responses Received or Type Conflict? RRS feed

  • Question

  • I have a design where BizTalk 2013 exposes a single port/operation to be consumed by an internal client.
    Once executed, in an orchestration the data is mapped and tested then sent to an external client via 1 port with 2 operations (web reference type). The operation used depends on various values within the data. Though the requests are different, either of the 2 operations in this case have identical response schema.

    When sending the TypeA data to the first operation, the external client receives the data and sends the response. The response is received by BizTalk and processed normally.
    When sending the TypeB data to the second operation, the external client receives the data and sends the response. The response never makes it back into the orchestration. Error details are below.

    For TypeB responses only, which are identical to TypeA responses, I am getting an error message that seems to indicate orphans when I search online for possible solutions. None of my searching has yielded anything helpful.
    The error message is: "The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended." Returning MessageType is TypeB.Response.

    Here is how the WSDL that we are consuming is set up.

    I've tried various pipeline settings and schema and hoped something would allow it to handle TypeB.Response but I have not been able to figure out why it is ignoring the response and presenting as an orphan when the identical TypeA.Response is working properly.

    The response is processed normally when tested via SoapUI directly and it seems to only be a problem when executing the TypeB via BizTalk.

    Monday, January 7, 2019 7:13 PM

All replies

  • Do you always expect to get both a TypeA and TypeB response back to your Orchestration?

    How are the sends and receive shapes organised in the Orchestration?  e.g. are they parallel, in sequence, in a wait shape?   You are going to have to give us more details on your Orchestration, as that is probably where the issue lies, rather than any pipeline setting.

    You say TypeA and TypeB response are identical, that could be the issue, as you it does not know which Response shape to go back to in the Orchestration.  Have you tried adding a filter on the receive shapes in the Orchestration on some promoted property on the response message so it knows which one belongs to which?

    Monday, January 7, 2019 8:21 PM
  • Here is a mockup showing what is happening.

    TypeA branch runs as expected and response looks correct.
    Else (TypeB) branch sends the data but is unable to process the identical response.

    I am not familiar with how to add a filter on the receive shape as suggested but I will try to look at that now.
    I'm not sure what we would promote since the responses are identical.

    Here is a sanitized version of the response.

    • Edited by Ben.B Monday, January 7, 2019 9:09 PM
    Monday, January 7, 2019 9:09 PM
  • For some reason the image doesn't show up here in the forum but I can see it an the notification email.  So I will post it here again.

    So you only send out one request, either the TypeA or go down the else branch.  How does the TypeA process know that it needs to process the message rather than the TypeB process and visa versa?   There must be something in the message that routes it correctly?  In which case you do not need the If before the Send and the Receive, just send it and receive it back and let message routing take care of it.

    If the maps are identical as well, then you don't need the If shape at all

    If you are using the Logical Send Port Operation to route the message, then you have to add a filter to the Receive_3 and Receive_2 shapes.  Check what context properties the response messages have and see if there is something that distinguishes A from B
    Monday, January 7, 2019 9:23 PM
  • The picture was to show the organization as requested. I can't send the entire orchestration. It is probably 800 shapes and is many pages long. I distilled it in a mock up so you could see the pattern as asked but that seems to have distracted from the question.

    There are various promoted parts of the messages and it gets remapped far more times than is healthy before getting sent.

    There are no wait shapes and the image posted shows the basic logic flow (I should have deleted those maps so they were not confusing).

    All of the sending is working, just the identical response from the web service that we are consuming seems to be the hangup.

    I can't shake the feeling that this should be a simple fix and has to be a common error but I don't have the language to describe it properly.

    Monday, January 7, 2019 9:55 PM
  • Actually, you can only use Filters on an Receive Location that is Activate = True

    So what you need to create a Correlation Set based on some unique property (or properties) in the message you are sending, and that also has to be in the Response and can be promoted.

    Initialize the Correlation Set on the Send shapes, and Have the Receive shapes use the same Correlation Set as the Following Correlation Sets.

    See Correlation Sets for more details and some examples

    Although this still might not solve it, as usually if you are sending through a two way logical port it auto correlates.  So there must be something else in the logic of your Orchestration that is off that you aren't showing.   

    Try creating a really simple application that does the same thing, and see if you can reproduce the issue.

    Monday, January 7, 2019 10:03 PM
  • I will look into the Correlation Sets.

    Thanks for your patience on this.

    Monday, January 7, 2019 10:05 PM