Hello all!

I'm in the analyze phase of a migration project and would like some tips for
the experts.

I'm going to migrate a solution from BTS 2002 to BTS 2006.

I'm quite on top of things except for a quite complex AIC which performs
some key tasks in this solution.

I didn't have much luck migrating AICs in the past (to BTS 2004), but
managed to solve it then by using adapters such as the SQL Adapter etc.

In this solution the AIC is more complex and my solution should preferably
be something I can write in C#.
It's receiving XML data and performs a number of transformation tasks using
SQL Server SPs and finally stores the results in a new Access Database .CAD
file. I'm quite convinced that the SQL Adapter wont be able to handle all
that.

My questions:
- What is the true BTS 2006 counterpart to AICs?
- Can I create an adapter myself? Pointers to docs would be nice.
- What would you do? Optional 

Thanks!

Mikael Östberg

[ Post a follow-up to this message ]

First of all, you do not necessarily have to create an
adapter to do what you want. If your messages(s) are coming into an
orchestration, then you can always call a .Net component or Web Service
directly within you orchestration and pass the message(s) to the .Net
Component or Web Service from the orchestration, then this .Net component
would do your AIC work. If this functionality is used in a number of
different places, then creating an adapter might prove to be beneficial, as
you can resue and configure the adapter in each situation. If you do want to
go the adapter route, I would start off using the Adapter wizard ->
http://www.gotdotnet.com/Community/...e1-fc83b02f57c1

Additionally if you are doing heavy duty Sql Server interaction from an
orchestration via the Sql Adapter, you can use OpenXML functionality in a
stored procedure to shred complex passed XML document(s) from BizTalk into a
series of Temp Tables in a Stored procedure and then let your stored
procedures do the work. You can find an example of using t-sql openxml and
BizTalk here:

http://objectsharp.com/blogs/matt/a...08/31/3209.aspx

Matt

"Mikael Ă–stberg" wrote:

> Hello all!
>
> I'm in the analyze phase of a migration project and would like some tips f
or
> the experts.
>
> I'm going to migrate a solution from BTS 2002 to BTS 2006.
>
> I'm quite on top of things except for a quite complex AIC which performs
> some key tasks in this solution.
>
> I didn't have much luck migrating AICs in the past (to BTS 2004), but
> managed to solve it then by using adapters such as the SQL Adapter etc.
>
> In this solution the AIC is more complex and my solution should preferably
> be something I can write in C#.
> It's receiving XML data and performs a number of transformation tasks usin
g
> SQL Server SPs and finally stores the results in a new Access Database .CA
D
> file. I'm quite convinced that the SQL Adapter wont be able to handle all
> that.
>
> My questions:
> - What is the true BTS 2006 counterpart to AICs?
> - Can I create an adapter myself? Pointers to docs would be nice.
> - What would you do? Optional 
>
> Thanks!
>
> Mikael Ă–stberg
>
>
>

[ Post a follow-up to this message ]

Matt,

Thanks for your answer!

I guess a .Net component in the orchestration will do just fine. The
component will only work in this solution, so there's no point making an
adapter then.

To answer my own question, I guess that .Net components in orchestrations
does what AICs did in BTS 2002. At least in the aspect of what my needs are.

Anyway.

.Net components in orchestrations. What are they called within the Biztalk
sphere? What would I use to hook them up? Is there anything in particular I
need to implement? Docs.?

Thanks!

::m

"Matt Meleski" <MattMeleski@discussions.microsoft.com> wrote in message
news:E9621ACC-5989-4F5C-B1EF-ED9EA991DE96@microsoft.com...
> First of all, you do not necessarily have to create an
> adapter to do what you want. If your messages(s) are coming into an
> orchestration, then you can always call a .Net component or Web Service
> directly within you orchestration and pass the message(s) to the .Net
> Component or Web Service from the orchestration, then this .Net component
> would do your AIC work. If this functionality is used in a number of
> different places, then creating an adapter might prove to be beneficial,
as
> you can resue and configure the adapter in each situation. If you do want
to
> go the adapter route, I would start off using the Adapter wizard ->
>
http://www.gotdotnet.com/Community/...r />
3b02f57c1
>
> Additionally if you are doing heavy duty Sql Server interaction from an
> orchestration via the Sql Adapter, you can use OpenXML functionality in a
> stored procedure to shred complex passed XML document(s) from BizTalk into
a[vbcol=seagreen]
> series of Temp Tables in a Stored procedure and then let your stored
> procedures do the work. You can find an example of using t-sql openxml and
> BizTalk here:
>
> http://objectsharp.com/blogs/matt/a...08/31/3209.aspx
>
> Matt
>
> "Mikael Östberg" wrote:
> 
for[vbcol=seagreen] 
preferably[vbcol=seagreen] 
using[vbcol=seagreen] 
.CAD[vbcol=seagreen] 
all[vbcol=seagreen] 

[ Post a follow-up to this message ]

For an example of calling a .Net Helper Component within an orchestration
the following SDK sample is a good start:

http://msdn.microsoft.com/library/d...amples_gfbs.asp

When authoring .Net helper components that will be called within an
orchestration
try to mark them as [Serializable] and static methods will help too.

If you do not mark as Serializable (not always possible), you will have to
call this components within an atomic scope shape.

Please also goto here for more info:

http://www.traceofthought.net/Perma...9d.
aspx

Matt.


"Mikael Ă–stberg" wrote:

> Matt,
>
> Thanks for your answer!
>
> I guess a .Net component in the orchestration will do just fine. The
> component will only work in this solution, so there's no point making an
> adapter then.
>
> To answer my own question, I guess that .Net components in orchestrations
> does what AICs did in BTS 2002. At least in the aspect of what my needs ar
e.
>
> Anyway.
>
> ..Net components in orchestrations. What are they called within the Biztal
k
> sphere? What would I use to hook them up? Is there anything in particular 
I
> need to implement? Docs.?
>
> Thanks!
>
> ::m
>
> "Matt Meleski" <MattMeleski@discussions.microsoft.com> wrote in message
> news:E9621ACC-5989-4F5C-B1EF-ED9EA991DE96@microsoft.com... 
> as 
> to 
> http://www.gotdotnet.com/Community/...e1-fc83b02f57c1 
> a 
> for 
> preferably 
> using 
> ..CAD 
> all 
>
>
>

[ Post a follow-up to this message ]

Matt,

Thanks for you help!

Calling a .Net Helper Component from an Expression shape might be exactly
the way to.

Thanks!

::m


"Matt Meleski" <MattMeleski@discussions.microsoft.com> wrote in message
news:3B186D64-CD8C-4F9D-8237-0CA23F9AE4AE@microsoft.com...
> For an example of calling a .Net Helper Component within an orchestration
> the following SDK sample is a good start:
>
>
http://msdn.microsoft.com/library/d...fbs.asp

>
> When authoring .Net helper components that will be called within an
> orchestration
> try to mark them as [Serializable] and static methods will help too.
>
> If you do not mark as Serializable (not always possible), you will have to
> call this components within an atomic scope shape.
>
> Please also goto here for more info:
>
>
http://www.traceofthought.net/Perma...dc9a5e3c9d.aspx[vbcol
=seagreen]
>
> Matt.
>
>
> "Mikael Östberg" wrote:
> 
orchestrations[vbcol=seagreen] 
are.[vbcol=seagreen] 
Biztalk[vbcol=seagreen] 
particular I[vbcol=seagreen] 
Service[vbcol=seagreen] 
component[vbcol=seagreen] 
beneficial,[vbcol=seagreen] 
want[vbcol=seagreen] 
http://www.gotdotnet.com/Community/...r />
3b02f57c1[vbcol=seagreen] 
an[vbcol=seagreen] 
in a[vbcol=seagreen] 
into[vbcol=seagreen] 
and[vbcol=seagreen] 
tips[vbcol=seagreen] 
performs[vbcol=seagreen] 
but[vbcol=seagreen] 
etc.[vbcol=seagreen] 
tasks[vbcol=seagreen] 
Database[vbcol=seagreen] 
handle[vbcol=seagreen] 

[ Post a follow-up to this message ]