Our client has a CRM application (let's call it
A) and a custom built Windows application (VB.NET) (let's call it
B) that directly writes to and reads from the CRM database.
A is used (mainly) to manage clients and their orders. Application
B is used to manage all the products our client sells.
Our client wants us to build a webshop (
C) using ASP.NET WebForms so they can sell the products they manage with
B. All of their clients and orders should be present both in
A and in
B will take care of all the communication to
A, will have to come up with a way to let
C synchronise their data.
This is something relatively new to us. We have done something like this in the past, but I really don't like the way it was solved there:
When someone orders something in the webshop, C puts the order in an XML-file, zips the XML-file and sends it to an FTP-server in the network of A. A monitors the directory on the FTP-server, unzips each new file, processes the XML, creates a new XML-file, zips it and sends it to an FTP-server in the network of C. C monitors the directory on the FTP-server, unzips each new file and processes the XML.
In addition to this, each night A generates an XML-file for each table in its database, zips them and sends them to the FTP-server in the network of C. C unzips the files and lets SSIS process the XML-files to update the database of C.
I really don't like that.
There must be other ways, right? We probably need single record sychronisation and batch synchronisation. How is this usually tackled? Webservices? Something custom like Rhino ETL? Something else?
Update: It would be nice if you could also give a short explanation of how the technology you propose is typically used and how it impacts the different applications.