BizTalk Server Framework - Disaster Recovery Recommendations

Author

Disaster Recovery Recommendations

Tim

2004-02-08, 8:41 am

Hi

I'm trying to recommend to a customer the best approach
for Disaster Recovery.

We have several systems integrated using a biztalk
solution. However, the majority of the messages
originate from one system only.

The question that is being asked is, should that system
provide the ability to retransmit messages by holding
some form of message storage capability? Or, should we
build that into our biztalk solution? Or, should we put
the emphasis on the target systems to maintain their own
relevant disaster recovery procedures?

I've been searching for some time now and I can't seem to
find any recommendations. Have any of you come accross
this before?

Thanks

Nick Malik

2004-02-08, 8:41 am

If the messages are not too big, consider using MSMQ for message sending.
You get:
a) reliable delivery (store and forward)
b) backup and restore
c) transactional support
d) intelligent routing

The sending side would not have to worry about queueing the message.

In general, I would recommend that it is up to the EAI tool to provide
reliability, not the feeding system. Most EAI tools, including Biztalk, use
message queueing as a way of insuring reliable message delivery.

Hope this helps,
--- Nick

"Tim" <tnichols@manpowersoftware.com> wrote in message
news:a14e01c3eb30$30c106e0$a401280a@phx.gbl...
> Hi
>
> I'm trying to recommend to a customer the best approach
> for Disaster Recovery.
>
> We have several systems integrated using a biztalk
> solution. However, the majority of the messages
> originate from one system only.
>
> The question that is being asked is, should that system
> provide the ability to retransmit messages by holding
> some form of message storage capability? Or, should we
> build that into our biztalk solution? Or, should we put
> the emphasis on the target systems to maintain their own
> relevant disaster recovery procedures?
>
> I've been searching for some time now and I can't seem to
> find any recommendations. Have any of you come accross
> this before?
>
> Thanks

2004-02-08, 8:41 am

Thanks Nick

Message Queuing is used by the sending system. The
problem we have is more one of being able to Retransmit
messages that may have been lost since the last Backup
was taken and the time of the target system failure. In
essence they have been delivered successfully, but the
resultant data modifications have been lost as a result
of the Restore.

In essence we need to know what was the last message
processed by the target system and to resend them from
storage.

I represent the vendor of the sending system and am
attempting to avoid having to re-write our interface to
accomodate these requirements.

We have suggested MSMQ Journaling as an approach or
writing to a 'Backup' message queue. However, the
customer is insistent that we provide them with the
ability to 'request' message ids on demand. This doesn't
fit particularly well with our model.

What I am really trying to guage is, what is the normal
approach for this? I agree that the EAI tool should be
focal point of this effort as it is the most 'aware'
system. It seems from what I have read there is a great
deal of independence on the disaster recovery
capabilities of the various linked systems and transports.

Thanks Again
>-----Original Message-----
>If the messages are not too big, consider using MSMQ for
message sending.
>You get:
>a) reliable delivery (store and forward)
>b) backup and restore
>c) transactional support
>d) intelligent routing
>
>The sending side would not have to worry about queueing
the message.
>
>In general, I would recommend that it is up to the EAI
tool to provide
>reliability, not the feeding system. Most EAI tools,
including Biztalk, use
>message queueing as a way of insuring reliable message
delivery.
>
>Hope this helps,
>--- Nick
>
>"Tim" <tnichols@manpowersoftware.com> wrote in message
>news:a14e01c3eb30$30c106e0$a401280a@phx.gbl...
put[color=blue]
own[color=blue]
to[color=blue]
>
>
>.
>

Nick Malik

2004-02-08, 8:41 am

Hello again,

Their reply doesn't make a lot of sense to me. If they are doing
incremental backups of their database, and the data is stored on a reliable
media (read: RAID arrays), there should never be a need for this.

It sounds like they want you to fix, in sofware,what they should be fixing
in hardware and SQL Server best practices.

It might be cheaper for you to buy them a RAID enclosure and/or a DLT-2 Tape
Library.
-- Nick

<anonymous@discussions.microsoft.com> wrote in message
news:a00901c3eb36$10c604c0$a501280a@phx.gbl...[color=blue]
> Thanks Nick
>
> Message Queuing is used by the sending system. The
> problem we have is more one of being able to Retransmit
> messages that may have been lost since the last Backup
> was taken and the time of the target system failure. In
> essence they have been delivered successfully, but the
> resultant data modifications have been lost as a result
> of the Restore.
>
> In essence we need to know what was the last message
> processed by the target system and to resend them from
> storage.
>
> I represent the vendor of the sending system and am
> attempting to avoid having to re-write our interface to
> accomodate these requirements.
>
> We have suggested MSMQ Journaling as an approach or
> writing to a 'Backup' message queue. However, the
> customer is insistent that we provide them with the
> ability to 'request' message ids on demand. This doesn't
> fit particularly well with our model.
>
> What I am really trying to guage is, what is the normal
> approach for this? I agree that the EAI tool should be
> focal point of this effort as it is the most 'aware'
> system. It seems from what I have read there is a great
> deal of independence on the disaster recovery
> capabilities of the various linked systems and transports.
>
> Thanks Again
> message sending.
> the message.
> tool to provide
> including Biztalk, use
> delivery.
> put
> own
> to