Re: BizTalk Solution Structure

Yeah,
It's for easier and faster work.
Example:
maps changes more frequently then schemas. If you separete them in different
projects you coud build a map project faster.
Example:
if you have 20 schemas and 20 maps you can store them in one project but you
have to make the "map/schemas specific" names like m_.../s_.... Or you can
separete then in different projects.

Look at this problem as separate files into folders/subfolders at.

Regards,

--
Leonid Ganeline,
BizTalk Developer
http://public.fotki.com/leogan/

"Tomas Restrepo (MVP)" <tomasr@xxxxxxxx> wrote in message
news:OdX$zxL0FHA.1040@xxxxxxxxxxxxxxxxxxxxxxx
> Samuel,
>
>> I've heard that packaging components for a BizTalk project according to
>> their
>> type turns out to be good design.
>>
>> I interpret this statement as creating one project for orchestrations,
>> one
>> for schemas, one for maps and so on, inside my .net solution and making
>> references among the projects.
>
> Yes, but it also means that you can combine it alongside with functional
> partitioning. For example, you project might involve doing both orders as
> well as inventory integration, and you might decide to keep both separate.
> In such a scenario, you'd have Orders.Schemas, Orders.Orchestrations,
> Inventory.Schemas, Inventory.Orchestrations and so on.
>
>> Except for the visually clean and pure structure, I don't really see the
>> benefits from doing this. Do you?
>
> Deployment and versioning. it allows you to version items independently,
> up to a point. For example, your business process might change, but your
> schemas not. With this, you can version your business process and deploy
> the new version of it (even alongside the original one) without having to
> break compatibility with your existing schemas. Things like that.
>
>
> --
> Tomas Restrepo
> tomasr@xxxxxxxx
> http://www.winterdom.com/
>


.

Relevant Pages

  • Re: Slow deploys
    ... New schemas, maps, orchestrations, pipelines and any new 'exposed' ... deployment. ... Schemas can be bench tested in the designer by validating instances ...
    (microsoft.public.biztalk.general)
  • Maps, Schemas, Application set up and hosts
    ... I'm working with a solution that will have many, many, maps and many, ... many, schemas. ... In my common application, I was going ... Do I need to add references to all my partner schemas ...
    (microsoft.public.biztalk.general)
  • Slow deploys
    ... Our Biztalk project has gotten pretty large and thus deployments are taking ... upwards of 5 minutes. ... deploy is needed is if amy mew artifacts (schemas, maps, orchs, ports) are ...
    (microsoft.public.biztalk.general)
  • Re: Schema/Map Best Practice Question
    ... > all the deployed assemblies for schemas when we are processing documents. ... > As to unenlisting/re-enlisting ports, I haven't tested this but I believe ... > | Should ALL schemas and maps for a BTS2004 installation be in the same ...
    (microsoft.public.biztalk.server)