5 Ways to use DB/TextWorks with SharePoint

by Jonathan Jacobsen Monday, October 01, 2012 2:53 PM

With each new release, SharePoint becomes both more useful and more prevalent in organizations of a certain size. Used both for intranets and public-facing web sites, SharePoint provides tools to help users communicate, collaborate and share and manage documents and information.

While SharePoint offers document storage and search capabilities itself, many DB/TextWorks users prefer the interface and features they are most used to, and wish to continue using DB/TextWorks to manage their databases and collections. Replicating administrative workflow in SharePoint is often not practical or cost effective. Those with WebPublisher PRO may wish to continue providing web browser search access in that fashion.

Fortunately, it’s quite feasible to use DB/TextWorks and WebPublisher PRO with SharePoint as there are many options for integrating one into the other. However, before rushing to do so, one should consider the consequences, such as:

 

  • If users are used to a particular search interface or syntax, will a switch to SharePoint cause confusion or frustration? Will you continue to provide access to the previous interface?
  • How many records are in an existing SharePoint site compared to ones in the DB/TextWorks databases? Will including the latter in SharePoint overwhelm the site?
  • Will significant capabilities be lost, such as the ability in WebPublisher PRO to create See Also hyperlinks, browse indexes or bring in book covers from Google?

 

A few of the options for integrating DB/TextWorks databases into a SharePoint site are:

 

  1. Use the SharePoint Page Viewer web part to iframe Inmagic WebPublisher PRO search and results pages. This is the simplest approach, but requires that you have WebPublisher PRO and has usability drawbacks (iframes are harder to bookmark, navigate and size correctly). Search results will not appear in any SharePoint site-wide searches, which may be the desired approach if they would overwhelm the results.
  2. Export data from Inmagic databases to a CSV format and import into SharePoint Lists, where they can be searched, sorted, filtered, etc., the same as all existing data in the SharePoint site. A search scope can be defined in SharePoint to allow users to focus a search only on the imported data, if desired. This approach does not require WebPublisher and can be done manually with one or two connector tools, or automated with one or two more.
  3. Export data from Inmagic databases to XML and import as a SharePoint Data Source. As with #2 above, this can be automated. However, the data is less usable without further effort in SharePoint as a Data Source compared to a List.
  4. Set up a connection to the WebPublisher PRO SOAP interface as a SharePoint Data Source, either to import data, or to construct a real-time search interface. As with #1, this requires that you also have WebPublisher PRO installed, and will require further effort to make good use of the data within SharePoint.
  5. Write a custom .NET connector to WebPublisher PRO within SharePoint Business Connectivity Services either to import data or for real-time searching. This requires that you have WebPublisher PRO and requires the most initial effort and skill, but also offers the most options for customization to meet very specific needs.

 

Each of these options has pros and cons based on the effort and skill required to implement, and the features that result. For those with DB/TextWorks but not WebPublisher PRO, option 2 is an excellent choice in that it is not too complex nor costly to implement, but provides reasonably useful results.

This blog post outlines just a few of the issues and options for using DB/TextWorks and WebPublisher PRO with SharePoint. We would be pleased to advise you on the best strategy for your organization and needs.

blog comments powered by Disqus

Month List