Best Practice for .NET component in BizTalk Project

Tom

Hi all:

What are the best practices to when to write custom .NET components in a
BizTalk project? Or what are the common scenarios that would be best using
custom .NET components?

Thanks,

Jan Eliasen

On Sat, 8 Dec 2007 10:59:02 -0800, Tom <>
wrote:

>What are the best practices to when to write custom .NET components in a
>BizTalk project? Or what are the common scenarios that would be best using
>custom .NET components?
I am not sure there wxists best practices on this... I tend to realy
try to avoid them. Others tend to go to them quickly. Baiscally, I
only use them if I can not do what I need inside BizTalk.

--
eliasen, representing himself and not the company he works for.

Private blog:

Private email:

Richard Seroter

Personally, I like to make sure that if anything fails within an "expression"
or "construct" shape, that it's very obvious. That is, I don't put so much
custom code into an orchestration that debugging becomes difficult.

If you're concerned about debugging, reuse and such, consider putting the
code in a custom component. I like to treat an orchestration as process flow
only, where the DRIVERS of that process flow (rules, logic) exist elsewhere.

But, each case is different, and you want to make sure you have the most
secure, scalable, easy-to-maintain solution for your needs.
--
Richard Seroter



"Jan Eliasen" wrote:

> On Sat, 8 Dec 2007 10:59:02 -0800, Tom <>
> wrote:
>
> >What are the best practices to when to write custom .NET components in a
> >BizTalk project? Or what are the common scenarios that would be best using
> >custom .NET components?
> I am not sure there wxists best practices on this... I tend to realy
> try to avoid them. Others tend to go to them quickly. Baiscally, I
> only use them if I can not do what I need inside BizTalk.
>
> --
> eliasen, representing himself and not the company he works for.
>
> Private blog:
>
> Private email:
>