We currently have a CRM solution that is the central database that needs to
receive data from about 4 different sources (Web, Call Center, Financials,
etc.) on one LAN.  Each source can have new individauls added or be an
existing individual in CRM but any transaction that comes through the other
sources must get into the CRM system as an activity or transaction.  There
are many different data cleansing, formatting, and validating services that
need to take place in order for the data to get into the CRM system and some
logic in generating new records when needed, etc..  Currently, the planned
approach is to replicate the CRM database in 4 different databases so each
source can query their own and process accordingly using Replication and DTS
.
Could this process be better handled using BizTalk Orchestration and
Integration or are we better off with the SQL approach?

[ Post a follow-up to this message ]

Hey John,
We've recently done an almost exact implementation with the use of
BizTalk.  We used the BizTalk server platform as a Master Data
synchronization bus for first phase with the thought of moving eventually to
a design using either Process or Entity Integration
(http://msdn.microsoft.com/architect...tml/intpatt.asp).
Couple of pluses up front for using BizTalk was

1) Interface abstraction - New applications and sites can now query
information directly from our BizTalk based Services hub to get CRM related
information.  We went ahead in phase one to expose data services that would
perform the lookup and retrieval of common elements from the CRM systems.

2) Data cleansing - We can now verify record uniqueness through some
orchestrations we exposed using the Publishing wizard.

3) Offload caching - Because BizTalk is responsibly for all data movement
between systems, we have also been able to build some "master" tables that
increase data access efficiencies by returning pre aggregated data.  This is
somewhat a pattern (Entity Aggregation) but in a simple form at the moment.

Performance has not been an issue and these are large CRM implementations
along with one custom one as well.

"John" <John@discussions.microsoft.com> wrote in message
news:4F285C7E-FCD1-4EDC-AEAF-365B3F4AF82B@microsoft.com...
> We currently have a CRM solution that is the central database that needs
> to
> receive data from about 4 different sources (Web, Call Center, Financials,
> etc.) on one LAN.  Each source can have new individauls added or be an
> existing individual in CRM but any transaction that comes through the
> other
> sources must get into the CRM system as an activity or transaction.  There
> are many different data cleansing, formatting, and validating services
> that
> need to take place in order for the data to get into the CRM system and
> some
> logic in generating new records when needed, etc..  Currently, the planned
> approach is to replicate the CRM database in 4 different databases so each
> source can query their own and process accordingly using Replication and
> DTS.
> Could this process be better handled using BizTalk Orchestration and
> Integration or are we better off with the SQL approach?

[ Post a follow-up to this message ]

Jason,

Thanks for the information!  I have another question or two if you don't
mind.  How did you achieve this data synchronization in BizTalk without doin
g
some kind of replication.  Are you reading and writing directly to the CRM d
b
or did you create some kind of Master db?  Any info. you have is helpful.
Thanks.


"Jason Storey" wrote:

> Hey John,
>     We've recently done an almost exact implementation with the use of
> BizTalk.  We used the BizTalk server platform as a Master Data
> synchronization bus for first phase with the thought of moving eventually 
to
> a design using either Process or Entity Integration
> (http://msdn.microsoft.com/architect...tml/intpatt.asp).
> Couple of pluses up front for using BizTalk was
>
> 1) Interface abstraction - New applications and sites can now query
> information directly from our BizTalk based Services hub to get CRM relate
d
> information.  We went ahead in phase one to expose data services that woul
d
> perform the lookup and retrieval of common elements from the CRM systems.
>
> 2) Data cleansing - We can now verify record uniqueness through some
> orchestrations we exposed using the Publishing wizard.
>
> 3) Offload caching - Because BizTalk is responsibly for all data movement
> between systems, we have also been able to build some "master" tables that
> increase data access efficiencies by returning pre aggregated data.  This 
is
> somewhat a pattern (Entity Aggregation) but in a simple form at the moment
.
>
> Performance has not been an issue and these are large CRM implementations
> along with one custom one as well.
>
> "John" <John@discussions.microsoft.com> wrote in message
> news:4F285C7E-FCD1-4EDC-AEAF-365B3F4AF82B@microsoft.com... 
>
>
>

[ Post a follow-up to this message ]