|
Home > Archive > BizTalk Server General > February 2005 > Message Subscription
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Message Subscription
|
|
| Michael 2005-02-02, 2:50 am |
| I have two schema, both schema share the same root node name and neither has
a target namespace. Note they're not our schema and we must be able to use
them in there current form. Ok, its a very simple orchestration, in fact
almost identical to the solution in that comes with the MQ Adapter SDK. The
only difference being the ports in my orchesrtation are based on the schema
type and not XmlDocument. I'm getting the following errors, has anyone else
solved these problems?
If we run the solution with an XmlReceive on the receive from MQ port then
we get the following entry in the event log.
"There was a failure executing the receive pipeline:
"Microsoft.BizTalk.DefaultPipelines.XMLReceive" Source: "XML disassembler"
Receive Location: "MQS://MQServer/QMgr/QUEUE1" Reason: The disassembler
cannot retrieve the document specification by using this type: "msg". Either
the schema is not deployed correctly, or more than one schema is deployed for
the same message type."
That makes sense as both my deployed schema share the same root node name
and neither has a namespace. After hunting around a bit I found a solution
that involves creating a pipeline, adding an xml disassembler, and explicity
specifying the fully qualified name of the schema in the Document schema
collection. I have also set the allow unrecognized message property to true.
I implemented this solution and receive the following entry in the event
log.
"The Messaging engine failed to process a message submitted by
adapter:MQSeries Source URL:MQS://MQServer/Qmgr/QUEUE1. Details:Could not
find a matching subscription for the message. . This error occurs if the
subscribed orchestration schedule or send port has not been started, or if
some of the message properties necessary for subscription evaluation have not
been promoted. Please refer to Health and Activity Tracking tool for more
detailed information on this failure"
I looked around for a solution to this problem. One being to build a custom
pipeline component and promote a message type. So I assigned a unqiue
namespace to our schema and built the disassembler to promote the
"MessageType" context property. I still got the same error.
Any ideas on what else I can try?
| |
| Stephen W. Thomas 2005-02-02, 2:50 am |
| Hello.
Have you used the Subscription Viewer in the SDK to check and see what
subscriptions are available?
What message type did you define in your Orchestration Port? I think that
is what is causing your problem. Have you thought of accepting the messages
as an Untyped Message? That is, as an XmlDocument. You can always cast it
later on to a schema if you needed to.
You might also want to look at the message context of your failed messages.
Just to see what properties are there and that values they have.
Some other ideas might be to do direct message box binding on the Receive
Port. Then, use BTS. InboundTransportLocation for routing. Just make sure
you change this setting inside the Orchestration or set a custom flag to
processes otherwise when you send the messages it will match the subscription
again.
Hope this helps.
Stephen W. Thomas
http://www.geekswithblogs.net/sthomas
"Michael" wrote:
> I have two schema, both schema share the same root node name and neither has
> a target namespace. Note they're not our schema and we must be able to use
> them in there current form. Ok, its a very simple orchestration, in fact
> almost identical to the solution in that comes with the MQ Adapter SDK. The
> only difference being the ports in my orchesrtation are based on the schema
> type and not XmlDocument. I'm getting the following errors, has anyone else
> solved these problems?
>
> If we run the solution with an XmlReceive on the receive from MQ port then
> we get the following entry in the event log.
>
> "There was a failure executing the receive pipeline:
> "Microsoft.BizTalk.DefaultPipelines.XMLReceive" Source: "XML disassembler"
> Receive Location: "MQS://MQServer/QMgr/QUEUE1" Reason: The disassembler
> cannot retrieve the document specification by using this type: "msg". Either
> the schema is not deployed correctly, or more than one schema is deployed for
> the same message type."
>
> That makes sense as both my deployed schema share the same root node name
> and neither has a namespace. After hunting around a bit I found a solution
> that involves creating a pipeline, adding an xml disassembler, and explicity
> specifying the fully qualified name of the schema in the Document schema
> collection. I have also set the allow unrecognized message property to true.
> I implemented this solution and receive the following entry in the event
> log.
>
> "The Messaging engine failed to process a message submitted by
> adapter:MQSeries Source URL:MQS://MQServer/Qmgr/QUEUE1. Details:Could not
> find a matching subscription for the message. . This error occurs if the
> subscribed orchestration schedule or send port has not been started, or if
> some of the message properties necessary for subscription evaluation have not
> been promoted. Please refer to Health and Activity Tracking tool for more
> detailed information on this failure"
>
> I looked around for a solution to this problem. One being to build a custom
> pipeline component and promote a message type. So I assigned a unqiue
> namespace to our schema and built the disassembler to promote the
> "MessageType" context property. I still got the same error.
>
> Any ideas on what else I can try?
| |
| Michael 2005-02-02, 8:47 pm |
| Hi Stephen,
I tried the untyped message solution. I have made the outbound and inbound
port to MQ use XmlDocument, just as the MQ Adapter SDK sample does. I also
use the PassThru pipeline on the MQ receive port so BizTalk won't try and
resolve the MessageType. I still get the same error in the event log. I
look in the subscription viewer and I see my orchestration with two
properties, ReceivePortID and MQMD_CorrelId.
I look at the context of the suspended message and the ReceivePortId is
promoted and set to the same value I see in orchestration via the
subscription viewer. The suspended message context also has the promoted
MQMD_CorrelId property which again matches the value I see in the
orchestration via subscription viewer.
If the orchestration is there, the receive port id matches up, and the
correlation value matches, I don't understand why I'm getting subscription
errors?
Note because I am using the PassThru pipeline the MessageType is empty.
Does this need to be XmlDocument? If I use the XmlReceive pipeline the
MessageType is set to the root node name and I get the entry in the event log
indicating that multiple schema are deployed and the message cannot be
resolved using this MessageType.
Can you please elaborate on the direct message binding solution. I
understand binding the port to the messagebox. Does this mean this
orchestration will receive every message that is placed in the message box
and I should be doing some routing based on the InboundTransportLocation
after the receive? Can you please explain a little further the comment "set
a custom flag to processes". I'm not sure what you mean by this.
Thanks for you help,
"Stephen W. Thomas" wrote:
[vbcol=seagreen]
> Hello.
>
> Have you used the Subscription Viewer in the SDK to check and see what
> subscriptions are available?
>
> What message type did you define in your Orchestration Port? I think that
> is what is causing your problem. Have you thought of accepting the messages
> as an Untyped Message? That is, as an XmlDocument. You can always cast it
> later on to a schema if you needed to.
>
> You might also want to look at the message context of your failed messages.
> Just to see what properties are there and that values they have.
>
> Some other ideas might be to do direct message box binding on the Receive
> Port. Then, use BTS. InboundTransportLocation for routing. Just make sure
> you change this setting inside the Orchestration or set a custom flag to
> processes otherwise when you send the messages it will match the subscription
> again.
>
> Hope this helps.
>
> Stephen W. Thomas
> http://www.geekswithblogs.net/sthomas
>
>
> "Michael" wrote:
>
| |
| Michael 2005-02-02, 8:47 pm |
| Ok, I think I've found my problem. For the moment I'm just hardcoding the
MQMD_CorrelId to "111111112222222233333334444444455555" within and assign
shape in my orchestration.
I look at the context of the suspened message and see the MQMD_CorrelId is
set to this value plus 12 trailing zeros. So I changed the hardcoding to
" 1111111122222222333333344444444555551111
11111111" and the message was picked
up by the orchestration without error.
It appears my problem was related to correlation because the MQ adapter
appends trailing zeros to the MQMD_CorrelId. That can't be by design can it?
Anyhow, thanks for all your help. It is very much appreciated...
"Michael" wrote:
[vbcol=seagreen]
> Hi Stephen,
>
> I tried the untyped message solution. I have made the outbound and inbound
> port to MQ use XmlDocument, just as the MQ Adapter SDK sample does. I also
> use the PassThru pipeline on the MQ receive port so BizTalk won't try and
> resolve the MessageType. I still get the same error in the event log. I
> look in the subscription viewer and I see my orchestration with two
> properties, ReceivePortID and MQMD_CorrelId.
>
> I look at the context of the suspended message and the ReceivePortId is
> promoted and set to the same value I see in orchestration via the
> subscription viewer. The suspended message context also has the promoted
> MQMD_CorrelId property which again matches the value I see in the
> orchestration via subscription viewer.
>
> If the orchestration is there, the receive port id matches up, and the
> correlation value matches, I don't understand why I'm getting subscription
> errors?
>
> Note because I am using the PassThru pipeline the MessageType is empty.
> Does this need to be XmlDocument? If I use the XmlReceive pipeline the
> MessageType is set to the root node name and I get the entry in the event log
> indicating that multiple schema are deployed and the message cannot be
> resolved using this MessageType.
>
> Can you please elaborate on the direct message binding solution. I
> understand binding the port to the messagebox. Does this mean this
> orchestration will receive every message that is placed in the message box
> and I should be doing some routing based on the InboundTransportLocation
> after the receive? Can you please explain a little further the comment "set
> a custom flag to processes". I'm not sure what you mean by this.
>
> Thanks for you help,
>
>
>
> "Stephen W. Thomas" wrote:
>
| |
| Stephen W. Thomas 2005-02-02, 8:47 pm |
| Hello.
Great to hear you got it to work.
We are using the MQ adapter on my current project and working with untyped
messages. I’ll have to check to see what it is doing to the Corr ID….
Best of luck.
Stephen W. Thomas
http://www.geekswithblogs.net/sthomas
"Michael" wrote:
[vbcol=seagreen]
> Ok, I think I've found my problem. For the moment I'm just hardcoding the
> MQMD_CorrelId to "111111112222222233333334444444455555" within and assign
> shape in my orchestration.
>
> I look at the context of the suspened message and see the MQMD_CorrelId is
> set to this value plus 12 trailing zeros. So I changed the hardcoding to
> " 1111111122222222333333344444444555551111
11111111" and the message was picked
> up by the orchestration without error.
>
> It appears my problem was related to correlation because the MQ adapter
> appends trailing zeros to the MQMD_CorrelId. That can't be by design can it?
>
> Anyhow, thanks for all your help. It is very much appreciated...
>
> "Michael" wrote:
>
| |
| Michael 2005-02-02, 8:47 pm |
| I've just done a little more dedugging and it appears the 0's are being
appended to the correlation_id when the message is sent to the queue.
Basically the app on the other end picks up the correlation_id and inserts it
into the correlation_id of the response.
"Stephen W. Thomas" wrote:
[vbcol=seagreen]
> Hello.
>
> Great to hear you got it to work.
>
> We are using the MQ adapter on my current project and working with untyped
> messages. I’ll have to check to see what it is doing to the Corr ID….
>
> Best of luck.
>
> Stephen W. Thomas
> http://www.geekswithblogs.net/sthomas
>
>
>
> "Michael" wrote:
>
|
|
|
|
|