A tool for bulk importing from a database table of external data. Something that would, for example, take 100 rows in a table of your company’s products, and create 100 product content items, wholly or partially filling-in the fields of each content item with some or all of the values from the database columns. A simple mapping interface would determine which columns correspond to which fields.
Other examples could include importing a university’s course list, or importing from a database of your organisation’s staff to create contact content items. There are other ways of putting this data on to a web site, e.g. web-server scripting such as Perl or ASP. But unless the data exists as content items in Rhythmyx, they cannot be linked into slots by content contributors.
We do see the use case for importation of external content as items rather than purely “virtualization” of external data (lookups, external URL items, etc.) Actual items allow for down stream processing of what was imported, such as workflow, added content and other types of filtering.
We also recognize the Web Services SDK, while it has two sample content loaders in it, is still a fair amount of work for many cases.
In the Community Marketing Solution, we took that SDK and built the “RSS Importer” which is a bulk loader of anything with an RSS feed. It imports each item in the feed as a Rhythmyx content item. (If you can slap an RSS layer onto your DBMS it might even work here, though I’m not suggesting this is the real answer.) The Analytics Integration Solution also has a data importer, but again, it’s very different (the data is only semi-imported for use during assembly).
So far, the reason we haven’t done much with a generalized DBMS importer is that every customer case with data imports has been very custom and very different from every other one. It’s been very hard to nail down any common requirements. In that case, the proposed importer ends up only slightly less complicated than the underlying Web Services API, or using the older XML Server functions and mapping DB columns to XML.
Some key areas for consideration on how to simplify have been:
key management and synchronization (can/must the import handle updates of items when the corresponding data row changes?)
table schema complexity (does the importer deal with this, or do we just assume the DBMS side solves it, for example, they create a View and we only support importing “rows” from that?)
Anyway, it’s an interesting area, something we do look at.
I’d say the latter. Most people who will be setting up a Rhythmyx system would know how to massage the data on the DBMS side prior to importing. SQL is, after all, a robust, comprehensible, extensively-documented, open standard that makes sense to most web developers. An importer that only allowed simple one-to-one relationships between columns in an SQL view and fields in a content type would cater for many people’s data import needs. Not everyone, but a lot.