Suggestions for implementing an interface between two document management systems [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

I developed a Document Managment System (DMS) as a Delphi client server application that stores files as BLOB fields in a SQL Server Db using the FILESTREAM feature.

As more opies of the software are sold I recieve the request the connect it to other document managemnt systems, in the broadest sense "other DMS mean":

1 "structured folders") some folders in a harddrive that are accessible only to a restrict number of users (imagine a shared network folder accessible only from 3 users) - this could be a "real way of storing documents" or just the result of a daily export from another system (documents are extracted by a batch procedure daily from another DMS).

The foldernaming in this case has some rules, for ecample if documents are associated to customers or employees the strucure will be something like:

\\Docs\Employees\COdE01\cv.pdf
\\Docs\Customers\CodC02\Invoice.xls

(in this exaple CodEXX stands for Employee Code XX, Anc CodCXX for the Customer case)

2 webservices)

many DMS expose (secure) webservices to access(read)/insert/update/delete documents so in this way it is possible to keep my system in sync with the other DMS.

3) other functions / tools)

other DMS has tools (like command line tools to be run with parametersor stored functions) to perform access/insert/update/delete

Anyway in general the bidirectional sync is a problem, in my case i am more interested in 1 way, so basically accessing docs stored somewhere else

Which techniaues you can suggest to create a configurable feature?

Answer 1

Develop your own API, so client applications (whether written by you or by somebody else) can use it to read/write data from your system.

Choose the underlying technology of that API based on how well it fits with presumed functioning of the clients. For example, if most clients are expected to be remote and in diverse languages, web services are a good candidate. If most clients are expected to be in-process (if that even makes sense for your system) and native, a C-based API might be the way to go. And everything in between...

You'd then use APIs of both "source" and "target" system to achieve the integration.