|
Home > Archive > BizTalk Server Orchestration > August 2005 > How implement an 'Approval'?
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 |
How implement an 'Approval'?
|
|
| N Thorell 2005-08-11, 5:52 pm |
| aIs there a simple of way of integrating a human approval in an orchestration?
Since I know nothing about HWS, I had to have 2 orchestrations, one before
and one after the approval. And the Approval is done in an ASP.NET page that
flags the approval in a database. And the second orchestration starts with an
SQL-Adapter polling the flag. It works, but I am probably missing the point
with BizTalk orchestrations, right? Or could a solution consist a set of tiny
orchestrations?
If I send email instead, how can I get the answer back?
Or do I have to learn HWS? What about all the other tools, like InfoPath,
SharePoint or whatever ...
I mean, I probably need an approval form that is more integrated with BizTalk.
| |
| Scott Colestock 2005-08-12, 5:56 pm |
| Ignoring HWS for a second, there is no reason you can't have a single
orchestration that maintains state relative to an approval process - and
that state doesn't have to reside in a database (it can reside in a
long-running orchestration.)
When your orchestration launches (from whatever event causes that to
happen), it can eventually reach a point where it simply waits to receive an
"approval" message (that contains some element of data to correlate on.)
Your ASP.NET app can send such a message via HTTP, MSMQ, web service, or
what have you.
You might be tempted to say, "yeah, but with that database table, I can run
some reports on how many oustanding approvals there are..." but BAM will do
the same thing and much more.
Scott Colestock
www.traceofthought.net
"N Thorell" <NThorell@discussions.microsoft.com> wrote in message
news:13377A18-66F7-4C5E-8514-97F0B356C358@microsoft.com...
> aIs there a simple of way of integrating a human approval in an
> orchestration?
> Since I know nothing about HWS, I had to have 2 orchestrations, one before
> and one after the approval. And the Approval is done in an ASP.NET page
> that
> flags the approval in a database. And the second orchestration starts with
> an
> SQL-Adapter polling the flag. It works, but I am probably missing the
> point
> with BizTalk orchestrations, right? Or could a solution consist a set of
> tiny
> orchestrations?
> If I send email instead, how can I get the answer back?
> Or do I have to learn HWS? What about all the other tools, like InfoPath,
> SharePoint or whatever ...
> I mean, I probably need an approval form that is more integrated with
> BizTalk.
| |
| N Thorell 2005-08-26, 7:53 am |
| But I need to understand one thing. I am calling a stored procedure to do a
SELECT * from XXX where id=@id and status='Approved' for xml auto
but I am not sure what is supposed to happen if there is no match (which is
the normal case here)?
In an earlier orchestration, BizTalk was waiting until there was at least
one row to return. But in my new project, it always returns immediately. How
is it supposed to behave. Wait or not? If it always returns immediately (SQL
request-response), then I have to use a 'loop shape' to call it periodically,
right? But it would be more convenient to just sit there and wait. I mean, an
orchestration is a 'state machine', right?
But I got into other problems earlier. BizTalk seemed to lock the table, so
I had to stop the orchestration temporarily, manually, to be able up modify
the 'status' from the outside.
"Scott Colestock" wrote:
> Ignoring HWS for a second, there is no reason you can't have a single
> orchestration that maintains state relative to an approval process - and
> that state doesn't have to reside in a database (it can reside in a
> long-running orchestration.)
>
> When your orchestration launches (from whatever event causes that to
> happen), it can eventually reach a point where it simply waits to receive an
> "approval" message (that contains some element of data to correlate on.)
> Your ASP.NET app can send such a message via HTTP, MSMQ, web service, or
> what have you.
>
> You might be tempted to say, "yeah, but with that database table, I can run
> some reports on how many oustanding approvals there are..." but BAM will do
> the same thing and much more.
>
> Scott Colestock
> www.traceofthought.net
>
>
>
> "N Thorell" <NThorell@discussions.microsoft.com> wrote in message
> news:13377A18-66F7-4C5E-8514-97F0B356C358@microsoft.com...
>
>
>
| |
| N Thorell 2005-08-29, 5:56 pm |
| I was NOT able to return any meaningfull status from the stored proocedure if
the SELECT didn't match any rows. So, now I have chosen to always return the
column in the WHERE clause and do the comparison in BizTalk instead. I am
using a Loop Shape to poll status every minute. I works nicely, but I still
don't know why I was unable to return the @@rowcount and retreive it in
BizTalk. In my case it was zero most of the time, and the xml-message just
showed the root element.
So it is really hard to test for 'success' of a stored procedure.
"Scott Colestock" wrote:
> Ignoring HWS for a second, there is no reason you can't have a single
> orchestration that maintains state relative to an approval process - and
> that state doesn't have to reside in a database (it can reside in a
> long-running orchestration.)
>
> When your orchestration launches (from whatever event causes that to
> happen), it can eventually reach a point where it simply waits to receive an
> "approval" message (that contains some element of data to correlate on.)
> Your ASP.NET app can send such a message via HTTP, MSMQ, web service, or
> what have you.
>
> You might be tempted to say, "yeah, but with that database table, I can run
> some reports on how many oustanding approvals there are..." but BAM will do
> the same thing and much more.
>
> Scott Colestock
> www.traceofthought.net
>
>
>
> "N Thorell" <NThorell@discussions.microsoft.com> wrote in message
> news:13377A18-66F7-4C5E-8514-97F0B356C358@microsoft.com...
>
>
>
|
|
|
|
|