|
Home > Archive > BizTalk Server Orchestration > May 2006 > One Orchestration or Many?
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 |
One Orchestration or Many?
|
|
| Anil Kripalani 2006-05-08, 1:14 pm |
| Just wanted to get an opinion from the BizTalk experts on the following
situation: We have a flat file that contains many record types, and have
setup a solution to import this data, using several orchestrations (one per
record type). Does anyone have thoughts on the pros and cons of one
orchestration vs. many, when processing a single file? For example, any
issues regarding transaction boundaries, health and activity tracking, etc.?
Thanks,
Krip
| |
| Lucas R. Vogel 2006-05-09, 1:13 am |
| Anil,
Why not create a Listen shape in your orchestration that captures all of the
message types created by the flat file? Perhaps you could use some kind of
correlatin so that all of the message types associated with the one flat file
are processed together in the same orchestration.
Lucas
--
===========
Lucas R. Vogel
"Anil Kripalani" wrote:
> Just wanted to get an opinion from the BizTalk experts on the following
> situation: We have a flat file that contains many record types, and have
> setup a solution to import this data, using several orchestrations (one per
> record type). Does anyone have thoughts on the pros and cons of one
> orchestration vs. many, when processing a single file? For example, any
> issues regarding transaction boundaries, health and activity tracking, etc.?
>
> Thanks,
> Krip
>
>
>
| |
| Anil Kripalani 2006-05-10, 1:15 pm |
| Thanks for the tip Lucas. We'll look into using the Listen shape with a
Correlation.
What if there is no correlation between the rows? In other words, records
can be processed independently of one another. Any benefits to one
orchestration?
Thanks,
Krip
| |
| Lucas R. Vogel 2006-05-11, 1:16 am |
| In your case, correlation probably isn't what you're looking for. You will
want to have multiple orchestrations when the orchestration logic is
significantly different for each message type.
One other possibility you may want to explore is using the MessageBox
directly without any orchestrations. Depending on what you are doing, you can
harness the publish-subscribe architecture of the MessageBox in conjunction
with the send and receive ports. This is likely more helpful to you than my
earlier correlation suggestion - you'll want to use that in order to
correlate message instances with orchestration instances.
Lucas
--
===========
Lucas R. Vogel
"Anil Kripalani" wrote:
> Thanks for the tip Lucas. We'll look into using the Listen shape with a
> Correlation.
>
> What if there is no correlation between the rows? In other words, records
> can be processed independently of one another. Any benefits to one
> orchestration?
>
> Thanks,
> Krip
>
>
>
| |
| Anil Kripalani 2006-05-29, 5:21 pm |
| Here's our latest on this: We have left processing of the various record
types of a file as individual orchestrations, and created a parent
orchestration that receives the file and calls the individual orchestrations
with the same message (via parameter). This seems to work well.
One of the benefits of an approach like this is control over the entire
processing of a file, like transaction atomicity. However if I mark the
parent orchestration with Transaction Type Atomic, a failure in one of the
called orchestrations does not result in a SQL roolback of records already
committed from previous work. Is there a way of getting the entire
orchestration (with all called orchestrations) to be part of one
transaction? I read somewhere about transactions not carrying to the SQL
Adapter. Is DTC not used?
Thanks,
Krip
| |
| Lucas R. Vogel 2006-05-29, 5:21 pm |
| To the best of my knowledge, what you're trying to do with Atomic
orchestrations goes beyond the scope of the transaction you are trying to do
-- in other words, I don't think BizTalk supports atomic transactions across
nested orchestrations. You will have to configure your calling orchestration
with a custom compensation handler to roll back any changes you've made...
Lucas
--
===========
Lucas R. Vogel
"Anil Kripalani" wrote:
> Here's our latest on this: We have left processing of the various record
> types of a file as individual orchestrations, and created a parent
> orchestration that receives the file and calls the individual orchestrations
> with the same message (via parameter). This seems to work well.
>
> One of the benefits of an approach like this is control over the entire
> processing of a file, like transaction atomicity. However if I mark the
> parent orchestration with Transaction Type Atomic, a failure in one of the
> called orchestrations does not result in a SQL roolback of records already
> committed from previous work. Is there a way of getting the entire
> orchestration (with all called orchestrations) to be part of one
> transaction? I read somewhere about transactions not carrying to the SQL
> Adapter. Is DTC not used?
>
> Thanks,
> Krip
>
>
>
| |
| Anil Kripalani 2006-05-30, 7:15 am |
| Lucas,
OK, I've actually now simplified my setup so that I have just one
orchestration - it makes two send's on two send ports - they each call
stored procedures. The whole thing runs serially, and I've set the
Transaction Type on the orchestration to Atomic. If I raise a fatal error
from a stored procedure called from the second send port, records from the
first send port are still committed. So my question stands: Can I do a
transaction in an orchestration that properly carries to the SQL Server
database?
-Krip
| |
| Lucas R. Vogel 2006-05-30, 1:14 pm |
| Anil,
I would suggest taking a look at 'Scenario 2: Using Transacted Adapters with
Atomic Transactions' in the BizTalk documentation : http://tinyurl.com/lmb48 .
Lucas
--
===========
Lucas R. Vogel
"Anil Kripalani" wrote:
> Lucas,
>
> OK, I've actually now simplified my setup so that I have just one
> orchestration - it makes two send's on two send ports - they each call
> stored procedures. The whole thing runs serially, and I've set the
> Transaction Type on the orchestration to Atomic. If I raise a fatal error
> from a stored procedure called from the second send port, records from the
> first send port are still committed. So my question stands: Can I do a
> transaction in an orchestration that properly carries to the SQL Server
> database?
>
> -Krip
>
>
>
|
|
|
|
|