|
Home > Archive > BizTalk Server General > October 2004 > Scheduled tasks
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]
|
|
| Hugo Rodger-Brown 2004-10-19, 7:47 am |
| How can I create an alert if no messages of a type are received before
a certain date? I've been thinking I could create an orchestration
that is initiated by a control message (that contains the date), then
listens for messages of the desired type, and posts an exception
message if nothing appears, but I have a bit of a problem with these
types of "control" orchestrations as I don't think BizTalk should
manage the external systems?
Does anyone have any more experience with situations where messages
are governed by individual schedules, that are not necessarily
attached to the message (might require lookup.)
My initial advice to the client was that the end system that is
expecting to receive the messages should control the alerts, but
unfortunately they don't see it that way, and they want BizTalk to
control the schedule.
| |
| Balaji Thiagarajan 2004-10-19, 5:49 pm |
| Suggestion:
Instead of throwing an exception, you can send an SMTP alert message from
the orchestration and continue to look for the message. This is one of the
most common B2B requirement.
--
Balaji Thiagarajan
MCP (BizTalk)
http://biztalkbits.blogspot.com
--
"Hugo Rodger-Brown" <hugorodgerbrown@hotmail.com> wrote in message
news:67eb92b.0410190532.64ed62b5@posting.google.com...
> How can I create an alert if no messages of a type are received before
> a certain date? I've been thinking I could create an orchestration
> that is initiated by a control message (that contains the date), then
> listens for messages of the desired type, and posts an exception
> message if nothing appears, but I have a bit of a problem with these
> types of "control" orchestrations as I don't think BizTalk should
> manage the external systems?
>
> Does anyone have any more experience with situations where messages
> are governed by individual schedules, that are not necessarily
> attached to the message (might require lookup.)
>
> My initial advice to the client was that the end system that is
> expecting to receive the messages should control the alerts, but
> unfortunately they don't see it that way, and they want BizTalk to
> control the schedule.
| |
| Hugo Rodger-Brown 2004-10-21, 7:47 am |
| Thanks for the suggestion - that's exactly what we had intended to do
already, and isn't really the problem. The issue is the fact that in
order for the orchestration to work like this it will have to be
instantiated before the deadline for each message (deadlines are set
for each message, NOT message-type).
Which means that BizTalk must proactively find out what messages are
expected, then fire up a 'listening' orchestration instance for each
expected message (again - not message-type, each *message*), all of
which seems totally counter-intuitive.
See my blog posting here for more details:
http://hugorodgerbrown.blogspot.com...wonderland.html
| |
| Balaji Thiagarajan 2004-10-21, 7:47 am |
| In the past, I use to store these kind of deadline datetimes in a SQL Table
and used a custom service to trigger an email.
--
Balaji Thiagarajan
MCP (BizTalk)
http://biztalkbits.blogspot.com
--
"Hugo Rodger-Brown" <hugorodgerbrown@hotmail.com> wrote in message
news:67eb92b.0410210226.33b6e336@posting.google.com...
> Thanks for the suggestion - that's exactly what we had intended to do
> already, and isn't really the problem. The issue is the fact that in
> order for the orchestration to work like this it will have to be
> instantiated before the deadline for each message (deadlines are set
> for each message, NOT message-type).
>
> Which means that BizTalk must proactively find out what messages are
> expected, then fire up a 'listening' orchestration instance for each
> expected message (again - not message-type, each *message*), all of
> which seems totally counter-intuitive.
>
> See my blog posting here for more details:
>
> http://hugorodgerbrown.blogspot.com...wonderland.html
| |
|
| You could build a couple of orchestrations:
1. a starter orchestration. This one has to be a singleton with physical
receiving port being a timer adapter. So periodically the timer adapter posts
a new message to the orchestration.
Every time such timer message is received the orchestration does a lookup of
your db table to find what messages -instances are expected and their
deadlines.
For each message-instance expected the orchestration runs a new "time
controller" orchestration.
2. a "time controller" orchestration. This one has to correlate on message
-instance type. If it's activated very first message of a given type and
starts counting the timeout, otherwise ignore the message.
So you will have one timer orchestration and multiple "time controllers"
orchestrations running at any given moment in your system.
AlexS.
"Hugo Rodger-Brown" wrote:
> Thanks for the suggestion - that's exactly what we had intended to do
> already, and isn't really the problem. The issue is the fact that in
> order for the orchestration to work like this it will have to be
> instantiated before the deadline for each message (deadlines are set
> for each message, NOT message-type).
>
> Which means that BizTalk must proactively find out what messages are
> expected, then fire up a 'listening' orchestration instance for each
> expected message (again - not message-type, each *message*), all of
> which seems totally counter-intuitive.
>
> See my blog posting here for more details:
>
> http://hugorodgerbrown.blogspot.com...wonderland.html
>
| |
| Hugo Rodger-Brown 2004-10-25, 7:48 am |
| Thanks Alex.
I've designed the orchestrations already (though not using a "timer"
orchestration as you suggest - I don't really want to get into custom
adapter creation, and am not aware of a timer adapter that is freely
available - I'd love to know if one exists), and am more interested in
the fundamentals of the design.
With my purist hat on I see the responsibility for scheduling messages
as belonging to the end applications - BizTalk being responsible for the
transformation, routing, end-point abstraction etc., etc.
What we actually have in this situation is one application updating
data, publishing the data for a subscribing remote application, with
BizTalk deciding whether to push the update through or not, which seems
very confused. It's really about whether BizTalk should do it, rather
than whether it could do it.
As I keep telling the client - BizTalk *can* do almost anything you want
it to, but you have to ask whether it's appropriate or not. I'm really
looking for a solid argument that I can present to the client to
persuade them of this.
I do appreciate the scheduling of data transfers on a per-schema basis,
but I have a problem getting my head round the per-message schedule, as
it seems completely antithetical to the concept of a message-driven
architecture.
Hugo
| |
|
| Hugo,
A sample of Timer Adapter is included in the "generic" adapter available from
http://msdn.microsoft.com/library/d...04_gasample.asp
When deciding on the role Biztalk can provide the following consideration
may be useful:
- fitness into the application architecture. Obviously you should not
change your design just to bring BTS into the picture. However Biztalk shows
a good example of SOA but not forcing it in your solution. In your example
BTS can be used to extend functionality of the app as it relates to
scheduling messages.
- cost savings (buy vs build).
- resources and etc.
You solid argument can be a solid application architecture with design
including appropriate analyses.
Many other considerations can come to the picture but they are probably very
specific to your solution.
AlexS.
"Hugo Rodger-Brown" wrote:
> Thanks Alex.
>
> I've designed the orchestrations already (though not using a "timer"
> orchestration as you suggest - I don't really want to get into custom
> adapter creation, and am not aware of a timer adapter that is freely
> available - I'd love to know if one exists), and am more interested in
> the fundamentals of the design.
>
> With my purist hat on I see the responsibility for scheduling messages
> as belonging to the end applications - BizTalk being responsible for the
> transformation, routing, end-point abstraction etc., etc.
>
> What we actually have in this situation is one application updating
> data, publishing the data for a subscribing remote application, with
> BizTalk deciding whether to push the update through or not, which seems
> very confused. It's really about whether BizTalk should do it, rather
> than whether it could do it.
>
> As I keep telling the client - BizTalk *can* do almost anything you want
> it to, but you have to ask whether it's appropriate or not. I'm really
> looking for a solid argument that I can present to the client to
> persuade them of this.
>
> I do appreciate the scheduling of data transfers on a per-schema basis,
> but I have a problem getting my head round the per-message schedule, as
> it seems completely antithetical to the concept of a message-driven
> architecture.
>
> Hugo
>
|
|
|
|
|