|
Home > Archive > BizTalk Server Orchestration > February 2006 > MSMQT quick question
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 |
MSMQT quick question
|
|
| CranCran77 2006-02-06, 5:53 pm |
|
If I submit 3 messages to MSMQT from my orchestration, does MSMQT
insure that the message is actually delivered to the remote system
before it begins transmission of the next message to that system?
What happens if message 2 of 3 cannot be delivered. What happens to
message 3 in the queue?? What will HAT show?
Thanks
Chris
| |
|
|
| CranCran77 2006-02-08, 2:57 am |
| Hi Tomas!
What I had originally setup as a long running single transaction type
orchestration that acted as a resequencer, basically consuming input
messages from a single port using a sequential type convoy method to
insure a single instance execution of this orchestration. We did not
want this orchestration to be invoked multiple times due to it's
nature.
This orchestration consumed messages and persisted them to a hash table
within a C# class if the message received was out of sequence. Once
the sequence had been detected, the messages would begin to fire.
I had setup a nested scope within my long running orchestration and
included a send shape along with a catch exception to suspend the
orchestration should the transmission fail for that message in
sequence. The send port was marked as "Delivery Notification" and also
with "Ordered Delivery".
I hooked in the MySAP 2 adapter to this port in the bind window and
fired up the system. What I noticed was that consistently transfers to
SAP were missing. When I looked at the event log and my own debugging
statements, everything looked fine. It showed where messages were
received, many times out of sequence, were persisted, and then
transferred to SAP successfully from the message store as the sequence
was identified. Nothing showed errors. I even added a 3s delay
immediately following the transfer of documents to SAP and yet still
noticed documents were lost. I couldn't explain it, made no since. We
traced the connection and noticed nothing :-( ...
I followed this configuration by plugging in the MSMQT adapter on this
send port rather than the MySAP send port. Then I setup a MSMQT
receive port for the same queue that the orchestration was sending to.
I set the filter option on the MySAP send port to map those messages
received on the MSMQT receive port to it and restarted the
orchestrations and no missing documents, What?!
Resequencer Orchestration ---> MySAP send port [LOST DOCUMENTS]
Resequencer Orch -> Send MSMQT -> Rcv MSMQT -> Send MySAP [OK]
Any idea why? Maybe I'm just not clear on the restrictions or maybe
there is something special that the MySAP adapter is doing that
involving the MSMQT adapter in the middle, it helps eliminate the
problem.
Nevertheless, my concern was that the resequencer sets the transmission
successful once the MSMQT acknowledges receipt of the message, not
delivery to the end of the queue (my assumption), so in this scenario,
that is why I was curious what happens if my orchestration pushes 3
messages to the queue and message 2 is never received by the remote SAP
system?
I guess as long as the receive MSMQT receives it, it's not an issue
because it will be immediately rerouted to the SAP send port which will
show suspended/etc in HAT if there are delivery issues, correct?
And lastly in this scenario, if message 2 gets suspended by the SAP
adapter send port, will message 3 stay in the receive MSMQT queue until
message 2 is delivered or is it possible that message 3 will still get
sent regardless?
At the end of the day, I have to insure documents transmit in FIFO
100%!
Chris
| |
| Tomas Restrepo \(MVP\) 2006-02-08, 7:48 am |
| CranCran77,
> What I had originally setup as a long running single transaction type
> orchestration that acted as a resequencer, basically consuming input
> messages from a single port using a sequential type convoy method to
> insure a single instance execution of this orchestration. We did not
> want this orchestration to be invoked multiple times due to it's
> nature.
>
> This orchestration consumed messages and persisted them to a hash table
> within a C# class if the message received was out of sequence. Once
> the sequence had been detected, the messages would begin to fire.
>
> I had setup a nested scope within my long running orchestration and
> included a send shape along with a catch exception to suspend the
> orchestration should the transmission fail for that message in
> sequence. The send port was marked as "Delivery Notification" and also
> with "Ordered Delivery".
>
> I hooked in the MySAP 2 adapter to this port in the bind window and
> fired up the system. What I noticed was that consistently transfers to
> SAP were missing. When I looked at the event log and my own debugging
> statements, everything looked fine. It showed where messages were
> received, many times out of sequence, were persisted, and then
> transferred to SAP successfully from the message store as the sequence
> was identified. Nothing showed errors. I even added a 3s delay
> immediately following the transfer of documents to SAP and yet still
> noticed documents were lost. I couldn't explain it, made no since. We
> traced the connection and noticed nothing :-( ...
>
> I followed this configuration by plugging in the MSMQT adapter on this
> send port rather than the MySAP send port. Then I setup a MSMQT
> receive port for the same queue that the orchestration was sending to.
> I set the filter option on the MySAP send port to map those messages
> received on the MSMQT receive port to it and restarted the
> orchestrations and no missing documents, What?!
>
> Resequencer Orchestration ---> MySAP send port [LOST DOCUMENTS]
> Resequencer Orch -> Send MSMQT -> Rcv MSMQT -> Send MySAP [OK]
>
> Any idea why? Maybe I'm just not clear on the restrictions or maybe
> there is something special that the MySAP adapter is doing that
> involving the MSMQT adapter in the middle, it helps eliminate the
> problem.
>
I'm not sure what might be going on with the SAP transmit. Are you using the
MySap adapter from MS? I don't have any experience with it, but looking
around, I did find out there's a Batch Size property for it on the send
handler configuration... perhaps that affects the result somewhat.
I would also try one other thing: Enabling tracking on the SAP SendPort. At
least, that way if the message was indeed transmitted you should be able to
find it stored in HAT (since you say you're not seeing them right now as if
they had been submitted succesfully).
> Nevertheless, my concern was that the resequencer sets the transmission
> successful once the MSMQT acknowledges receipt of the message, not
> delivery to the end of the queue (my assumption), so in this scenario,
> that is why I was curious what happens if my orchestration pushes 3
> messages to the queue and message 2 is never received by the remote SAP
> system?
>
> I guess as long as the receive MSMQT receives it, it's not an issue
> because it will be immediately rerouted to the SAP send port which will
> show suspended/etc in HAT if there are delivery issues, correct?
Yes, they should.
> And lastly in this scenario, if message 2 gets suspended by the SAP
> adapter send port, will message 3 stay in the receive MSMQT queue until
> message 2 is delivered or is it possible that message 3 will still get
> sent regardless?
No, I don't think so. I think that once you skipped the orchestration
forcing order, then you have no guarantee of ordered delivery. I think what
you'll see in this scenario is that the SAP adapter suspends the message,
and just picks up the next one. That said, this might be something that
works better in BTS2006 with the new ordered delivery support for sendports,
which has an option to accomplish what you want.
I'd try to find out a way to make the SAP send port behave, I think. Else,
you could try putting a secondary ordering orchestration between the MSMQT
receive port and the SAP SendPort (this could be a very simple convoy) so
that you can guarantee FIFO in this side of the equation (though it sure
will hurt performance somewhat). You might as well skip MSMQT in this kind
of environment and just use direct binding, for that matter.
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
| CranCran77 2006-02-08, 5:54 pm |
| Well, given that our go-live date is Saturday and code freeze was this
evening, I had to get creative. We found a small flaw with my overall
solution using my design anyways so it probably was for the best that
this issue came up and forced me back to "reality" :-)...
In the end I had to get creative on the receive port side of my overall
solution and to allow records into the orchestration that were not
order dependant (multi-running orchs) and to reduce it down to a single
running orch at a time where applicable based on data in the polling
table that the receive port queries.
This solution is working nicely at the moment. While it's probably no
where near as efficient as the other solution was, it bypasses a
logistical dependancy problem that surfaced from the other solution and
aids in controlling the order of the delivered documents with no data
loss.
The polling logic also is smart enough to maintain integrity that if
the send port fails to deliver the document to SAP, the orchestration
suspends, does not mark the record as having been sent and until so,
the receive port won't return any more documents for biztalk to
transfer. This is ideal at the moment and a single check periodically
makes sure that no records are stuck and alerts a tech if one is to
jumpstart the poller again.
Not ideal, but works for the moment anyways...
|
|
|
|
|