Sharing Large Live Data

[Frank Bishop]

We have a problem in that we have an outside company handle our online
conference sessions so they handle the registrations. The data is of
registrations is sent back to us as an excel sheet (after the session
ends). Mapping this data back to our production database to report
demographics is labor intensive sometimes.

Would it be possible or recommended to push out a live xml web service
(to be consumed by the outside company) of all our active customers
(thru a secure connection of some sort...SSL?)They could bounce this off
the person registering online and add other logic if they are a non
customer. I would still need a registrant report after the fact.

Suggestions appreciated.
Thanks
FB

 

[Ben Strackany]

You could do that. If your customer list is huge and/or they're downloading
the data a lot, a different data sharing mechanism might be better (e.g.
FTPing CSV files that they pick up daily, etc.). You could also just send
them updates (i.e. list of people subscribed/unsubscribed since XX date)
instead of your entire list.

If the data size is still too big, it might be better to instead publish a
web service method like CheckUserRegistration() where they pass a user's
information & you return whether they're in your system or not. It has the
advantage of being a real-time check (instead of a daily download that might
get out of date as the day progresses), and it might also be faster than
huge, repeated downloads. You could also expose a web service method
allowing them to POST registration information, instead of sending you
Excel.

When they send you Excel, you could use the Excel COM object or ADO.NET to
load the data programmatically into your system. I am assuming that the
labor intensive aspect often comes w/ bad data, not necessarily importing
good data.

In terms of securing web services, SSL is good (maybe w/ custom certificates
that you generate), but has a performance impact. You could also look at WSE
(http://msdn.microsoft.com/webservices/building/wse/default.aspx) in terms
of web service security.

HTH,