|
Home > Archive > BizTalk Server > March 2007 > Biztalk 2002 - 2006 rearchitecture advice
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 |
Biztalk 2002 - 2006 rearchitecture advice
|
|
| mitre7@hotmail.com 2007-03-01, 1:21 am |
| Hi All,
I'm a newbie to Biztalk in general and have been tasked with a hefty
project of rearchitecture of a Biztalk 2002 project to Biztalk 2006.
The 02 project is heavy on mapping, I mean really heavy. There are
roughly 2000 complex maps and as many document specs as the
application is used primarily for document normalization. Basically
all incoming documents are mapped to a canonical format based on
document type. That is if the partner is sending a PO document it
get's mapped to our canonical PO format. The project centers the
mapping around several VB 6 custom pipelines that handle rules and
routing of each canonical doc type we process. A similiar mapping
process occurs for mapping and transporting the canonical doc type
format to the destination partner's required format. There are no
orchestartions in the current project.
Could anyone point me to a good 06 sample that uses allot of maps?
What is the equivalent of a channel in 06?
Are preprocessors unavailable in 06?
I've alos heard it's a pain to process EDI in 06 is that the case,
it's very easy in 02?
Is Biztalk 06 even right for a solution heayv on mapping?
Thanks in advance
| |
| Joerg Fischer 2007-03-01, 7:18 am |
| Hi,
Orchestration is rarely used in BTS2000 / 2002 since its architecture was
quite limited.
There are guidelines available in the BTS2006 online documentation
concerning the migration of BTS2002 projects (in fact, BTS2006 has a type
"migration project" available).
Basically, you must import the maps and then reassign the source and
destination schemas. The maps should work 1:1, however, if they heavily rely
on scripting functoids, be settled to face some trouble here since the
scripting functoid technology changes (based on VBscript / JavaScript in
BTS2002, now C# .NET / VB.NET / J#). BTS 2006 is more performant with its
mapping in comparison to BTS2002.
BTS2006 does not have preprocessors, it has receive pipelines which
effectively are more flexible than preprocessors were.
It sounds you should do a real redesign of the overall solution. Be sure,
however, that everything you did with BTS2002 is more easily done with
BTS2006 ;-)
EDI currently is a bit of pain in BTS2006 (as it was in BTS2002), I
personally use flat file functionality to process it and do not use the EDI
adapter in BTS2006 - it is a mess.
There will be a BTS 2006 R2 available having its EDI subsystem redesigned -
so, if you start your migration now, chances are that you get to the EDI
stuff just with R2 (depending on your project planning).
Sincerely
Joerg Fischer
BizTalk MVP
<mitre7@hotmail.com> schrieb im Newsbeitrag
news:1172720440.453112.82310@a75g2000cwd.googlegroups.com...
> Hi All,
> I'm a newbie to Biztalk in general and have been tasked with a hefty
> project of rearchitecture of a Biztalk 2002 project to Biztalk 2006.
> The 02 project is heavy on mapping, I mean really heavy. There are
> roughly 2000 complex maps and as many document specs as the
> application is used primarily for document normalization. Basically
> all incoming documents are mapped to a canonical format based on
> document type. That is if the partner is sending a PO document it
> get's mapped to our canonical PO format. The project centers the
> mapping around several VB 6 custom pipelines that handle rules and
> routing of each canonical doc type we process. A similiar mapping
> process occurs for mapping and transporting the canonical doc type
> format to the destination partner's required format. There are no
> orchestartions in the current project.
>
> Could anyone point me to a good 06 sample that uses allot of maps?
> What is the equivalent of a channel in 06?
> Are preprocessors unavailable in 06?
> I've alos heard it's a pain to process EDI in 06 is that the case,
> it's very easy in 02?
> Is Biztalk 06 even right for a solution heayv on mapping?
>
> Thanks in advance
>
| |
| devMonkey 2007-03-01, 1:16 pm |
| On Mar 1, 12:02 am, "Joerg Fischer" <me@work> wrote:
> Hi,
>
> Orchestration is rarely used in BTS2000 / 2002 since its architecture was
> quite limited.
>
> There are guidelines available in the BTS2006 online documentation
> concerning the migration of BTS2002 projects (in fact, BTS2006 has a type
> "migration project" available).
>
> Basically, you must import the maps and then reassign the source and
> destination schemas. The maps should work 1:1, however, if they heavily rely
> on scripting functoids, be settled to face some trouble here since the
> scripting functoid technology changes (based on VBscript / JavaScript in
> BTS2002, now C# .NET / VB.NET / J#). BTS 2006 is more performant with its
> mapping in comparison to BTS2002.
>
> BTS2006 does not have preprocessors, it has receive pipelines which
> effectively are more flexible than preprocessors were.
>
> It sounds you should do a real redesign of the overall solution. Be sure,
> however, that everything you did with BTS2002 is more easily done with
> BTS2006 ;-)
>
> EDI currently is a bit of pain in BTS2006 (as it was in BTS2002), I
> personally use flat file functionality to process it and do not use the EDI
> adapter in BTS2006 - it is a mess.
>
> There will be a BTS 2006 R2 available having its EDI subsystem redesigned -
> so, if you start your migration now, chances are that you get to the EDI
> stuff just with R2 (depending on your project planning).
>
> Sincerely
>
> Joerg Fischer
> BizTalk MVP
>
> <mit...@hotmail.com> schrieb im Newsbeitragnews:1172720440.453112.82310@a75g2000cwd.googlegroups.com...
>
Thanks Joerg,
More than likely this will be a full re-architecture effort and not
simply using the migration tool as these maps are all loaded with
vbscript. I'm curious of the best way to structure a new project that
will be heavy on maps. Since this is all compiled stuff and our maps
and schemas change frequently is there a best practice or example of
the best way to set up my applications for minimal downtime during
deployments?
Looks like I have more reading to do before asking anything else.
thanks again
>
>
>
>
> - Show quoted text -
|
|
|
|
|