Another Correlation Question

Home Page › Forums › BizTalk 2004 – BizTalk 2010 › Another Correlation Question

Viewing 1 reply thread
  • Author
    Posts
    • January 24, 2006 at 6:10 PM #12722
      community-content

        Hi.

        after sending a msg, can’t OrchA call OrchB and pass the CorrelationSet as a parameter? That way the instance of OrchB that corresponds to OrchA will be able to pickup the message.

        Gino

      • January 31, 2006 at 6:28 AM #12723
        community-content

          if orchA sends a message and orchB receives it then you dont need to correlate anything. if orchB is set to accept the message of that type it will accept any message and do whatever is necessary. I dont see where correlation comes into the picture. In orchB you need to have an activate receive shape which will receive the message.

          At first i thought you were calling/starting OrchB from OrchA and passing a message but it doesnt seem to be the case.

          Gino

          • January 31, 2006 at 5:50 PM #12724
            community-content

              Right. There’s a distinction between Context field and a Property field

              • January 24, 2006 at 5:05 PM #12725
                community-content

                  I wrote a simple two orchestration correlation demo to simulate a larger problem we were having at client.

                  So basically Orch-A sends a message, Orch-B receives it, remaps it, and sends it out, Orch-A should correlate on it based on an element in a SOAPHeader.

                  To simulate the client environment, all the ports (except the first activating file receive) use \”direct binding\”.

                  Orch-B has the following line of code in a message assignment after a map in a construct block:
                  msgServiceAgentCallResponse(*) = msgServiceAgentCallRequestIn(*);

                  That copies the SOAP Headers to the outgoing message, and I verified through tracing and HAT that the SOAP Headers are there and both the outgoing and incoming match the expected GUID using the BTSSubscriptionViewer.

                  So here’s the problem/question I have – if I don’t set any correlation in Orch-B, the messages don’t correlate. I have to use an \”Initalizing Correlation\” on the send shape of Orch-B to get it to work.

                  My thinking is that Orch-B should not require any knowledge of correlation, as it could theoretically be a web service, a Sharepoint file drop, or some human workflow.

                  Any ideas would be greatly appreciated.

                  Thanks,
                  Neal Walters
                  http://Biztalk-Training.com

                  • January 24, 2006 at 6:32 PM #12726
                    community-content

                      This is an existing system, and we have to work with their existing framework.

                      Here is the exact error I’m getting. Instead of just getting the \”not able to find subscriber\” that you normally get, I get 3 exceptions:
                      1) PersistenceException
                      2) PersistenceItemException
                      3) PublishMessageException.

                      Several posts have suggested that the PeristenceItemException can be caused by an unenlisted orch, but my Orch-A and Orch-B are both enlisted, and Orch-B finishes – even though the exception below is from Orch-B (whose real name is Compassion.BizTalk.BusinessProcesses.Constituent.orchServiceAgentSim).

                      Event Type: Error
                      Event Source: XLANG/s
                      Event Category: None
                      Event ID: 10034
                      Date: 1/24/2006
                      Time: 11:23:26 AM
                      User: N/A
                      Computer: USGDPWV81NB
                      Description:
                      Uncaught exception terminated service Compassion.BizTalk.BusinessProcesses.Constituent.orchServiceAgentSim(86e37f34-27f9-4cc5-469d-296639ae7331), instance 56ce3b91-599c-4762-92c1-6e1643eb7970

                      Exception occurred when persisting state to the database.

                      Exception type: PersistenceException
                      Source: Microsoft.XLANGs.BizTalk.Engine
                      Target Site: Void Commit()
                      Help Link:
                      Additional error information:

                      A batch item failed persistence Item-ID 227b434c-ef4b-4ed4-8d53-9fb5634faa8b OperationType MAIO_CommitBatch Status -1061151998 ErrorInfo The published message could not be routed because no subscribers were found. Please use the Health and Activity Monitoring (HAT) tool to diagnose this situation. .

                      Exception type: PersistenceItemException
                      Source:
                      Target Site:
                      Help Link:
                      Additional error information:

                      Failed to publish (send) a message in the batch. [b:5cad729eb8]This is usually because there is no one expecting to receive this message. The error was The published message could not be routed because no subscribers were found. [/b:5cad729eb8] Please use the Health and Activity Monitoring (HAT) tool to diagnose this situation. with status -1061151998.

                      Exception type: PublishMessageException
                      Source:
                      Target Site:
                      Help Link:
                      Additional error information:

                      Exception occurred when persisting state to the database.

                      Exception type: PersistenceException
                      Source: Microsoft.XLANGs.BizTalk.Engine
                      Target Site: Void Commit(Microsoft.BizTalk.Agent.Interop.IBTMessageBatchEx[], Microsoft.XLANGs.Core.Segment, Microsoft.BizTalk.Agent.Interop.IBTOperationStatus ByRef)
                      Help Link:
                      Additional error information:

                      A batch item failed persistence Item-ID 227b434c-ef4b-4ed4-8d53-9fb5634faa8b OperationType MAIO_CommitBatch Status -1061151998 ErrorInfo [b:5cad729eb8]The published message could not be routed because no subscribers were found[/b:5cad729eb8]. Please use the Health and Activity Monitoring (HAT) tool to diagnose this situation. .

                      Exception type: PersistenceItemException
                      Source:
                      Target Site:
                      Help Link:
                      Additional error information:

                      Failed to publish (send) a message in the batch.[b:5cad729eb8] This is usually because there is no one expecting to receive this message. The error was The published message could not be routed because no subscribers were found. [/b:5cad729eb8] Please use the Health and Activity Monitoring (HAT) tool to diagnose this situation. with status -1061151998.

                      Exception type: PublishMessageException
                      Source:
                      Target Site:
                      Help Link:
                      Additional error information:

                      Neal

                      • January 24, 2006 at 7:39 PM #12727
                        community-content

                          It turns out the issue has something to do with the correlating on the SOAP headers. I built another two orchestrations that were basically identical – except I correlated on an element in the message, not on a SoapHeader.

                          Neal

                          • January 24, 2006 at 11:41 PM #12728
                            community-content

                              We basically determined that this is either a bug or a \”design feature\”.
                              We will proably do a work around for now, and maybe open a support issue with Microsoft.

                              I created a small project with 3 orchestrations to reproduce the error on demand. It is definitely related to trying to correlate on property fields that are not in the message body – i.e. SOAP Headers (and may also be tied to the use of ports with direct binding).

                              Neal Walters
                              http://Biztalk-Training.com

                              • January 31, 2006 at 4:18 PM #12729
                                community-content

                                  Gino – Orch-A needs to basically call Orch-B, but instead of using the CALL shape at this client, they send a message using direct binding and they do correlation.

                                  We opened a Microsoft indicident on this. It turns out that it is a problem with the SOAP Headers. We have a pipeline that promotes the SOAP headers when the file is dropped in a flat file or MSMQ, but there is now way to promote the fields with direct binding – i.e. no pipeline can be assigned to direct binding.

                                  Thus, when Orch-B initializes correlation on the return message, that in effect promotes the field from the SOAP header. This is not a problem when using \”normal\” promoted fields in the message itself.

                                  Interestingly enough, a property can be in the \”context\” message, and still have the isPromoted value set to either true or false. I’m not sure why all context fields are not considered promoted, but they are not – Microsoft said \”by design\” and for efficiency.

                                  Neal Walters
                                  http://Biztalk-Training.com

                  • Author
                    Posts
                  Viewing 1 reply thread
                  • The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.