aIs there a simple of way of integrating a human approval in an orchestratio
n?
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 a
n
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 tin
y
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 BizTal
k.

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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 (SQ
L
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, a
n
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 ru
n
> some reports on how many oustanding approvals there are..." but BAM will d
o
> 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... 
>
>
>

[ Post a follow-up to this message ]

I was NOT able to return any meaningfull status from the stored proocedure i
f
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 ru
n
> some reports on how many oustanding approvals there are..." but BAM will d
o
> 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... 
>
>
>

[ Post a follow-up to this message ]