|
Home > Archive > BizTalk Server Orchestration > May 2004 > Orchestration B2B design (BT2004)
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 |
Orchestration B2B design (BT2004)
|
|
|
| Hi
I'm about to build a web service with the following "flow":
1. User logs in
2. User performs search and receives list of results
3. User picks one of the results and requests details
This could for example be a user logging on, querying yesterday
orders, and then clicks on one specific order to see details.
My Question:
How do I orchestrate this in BizTalk 2004? Especially when I have the
following wishes:
A. I would prefer one single ASMX file (perhaps the authentication
could go in a seperate). As far as I understand, this means one single
orchestration, one single port with multiple operations, true? And if
yes, is it possible to fit all the functionality into one
orchestration?
B. It would be nice, if authentication is not done at every web method
(except checking some token or likewise). I've heard of correlation,
but is that the way to go, and how does it fit with A above.
Hope anyone can help me getting the right direction here :-)
Thnx, Søren
| |
| Matt Milner 2004-05-17, 10:35 am |
| See comments inline:
"Soren" <smollebjerg@hotmail.com> wrote in message
news:e537dd79.0405170053.2b81826e@posting.google.com...
> Hi
>
> I'm about to build a web service with the following "flow":
>
> 1. User logs in
> 2. User performs search and receives list of results
> 3. User picks one of the results and requests details
>
> This could for example be a user logging on, querying yesterday
> orders, and then clicks on one specific order to see details.
>
> My Question:
> How do I orchestrate this in BizTalk 2004? Especially when I have the
> following wishes:
>
> A. I would prefer one single ASMX file (perhaps the authentication
> could go in a seperate). As far as I understand, this means one single
> orchestration, one single port with multiple operations, true? And if
> yes, is it possible to fit all the functionality into one
> orchestration?
>
Yes, one orchestration with a single port and multiple operations works
fine. Have your login operation create some authentication token (could be
as simple as a new guid) and return that to the caller. Also, include this
in a correlation set and initiate that correlation set upon sending the
response to the login. Now, have your client application send the
authentication/correlation token in with future requests and be sure your
receives on the GetList and GetDetails operations Follow that correlation.
This correlation will ensure that your orchestration instance is tied to the
same caller. You may also want to use some listen shapes with delays to
ensure that your orchestration gets cleaned up and finishes even if the user
does not complete the flow. for instance, you might set it up so that
either you get a request for a list, or 5 minutes passes. Likewise, either
you get a request for details, or 5 minutes passes. This way you won't have
a bunch of half finished orchestrations floating out there.
Matt
> B. It would be nice, if authentication is not done at every web method
> (except checking some token or likewise). I've heard of correlation,
> but is that the way to go, and how does it fit with A above.
>
> Hope anyone can help me getting the right direction here :-)
>
> Thnx, Søren
|
|
|
|
|