Multi-Site or Distributed Installation

[elcaminoreal]

Hello All,

I have started to evaluate several document management systems for my company and I have been looking at OpenKM. I am very impressed with what I have seen so far, but I have a requirement that I like to ask the community about and see if it is possible to do with OpenKM since I have been unable to find the answer to this question:

I work for a company where we have multiple offices around the country. Each office is independent and works on their own projects mostly, but files/content are also often shared among all the offices. Fast local access to files is very important to us. So my question is as follows:

Can OpenKM be deployed is a distributed or decentralized manner. Is it possible to have a single installation of OpenKM (Centrally hosted) or even multiple installations (One in each office) but have the user interface show all root taxonomies each physically located in each office? Another way to ask this question would be, can we have multiple root taxonomies where each root taxonomy's files are physically located in a different office but the user interface makes all the taxonomies visible to all users in one interface regardless of what physical office they are located in? This would allow fast local access to files that are in that user's local root taxonomy and they would also see the other office's taxonomy and be able to access them, but it would be a bit slower due to Internet bandwidth limitations. But users would be able to view and perform all the usual tasks as they would with a single installation across all the taxonomies (search, check-in, check-out, etc.).

I hope I was able to properly articulate my questions.

I appreciate any guidance and/or suggestions.

[jllort]

What you really want is several installation that are synchronized. We've been thinking last year in some way for doing it, but only it'll be done if some customer demands it, because it's not a trivial scenario, relly it's a very complex one.

Several ways to doing.
1- Easiest is making some descentralized search engine, and every time you search something results are from everywhere, then you connect to the remote installation results
2- Secondly could be only one directon integration master-slave , that mean only will have permissions to read in slave the master data
3- Full bidirectional integration, this could be in real time or daily, second more easiest than first. The problem in bidirectional sincronization is when two users make operations in same nodes at same time ( modify both same document, or simply one users modifies a document and other deletes the parent folder ). Other problem in this kind of scenarios is security ( all systems should have similar users and roles ... that could be a problem too ).

We've been thinking on daily exporting and importing system ( daily differences backup data ) for synchronizing, that's the most easies way for solving it, or crontab task executed each minute for doing it ... but exist the problem of the colisions that I've tryed to explain, and there's no simply way to automatically solve it, someone needs human. In other hand will be more easy sinchronizating only some files ( sharing concept ) than all repository data.

As you can read we've been thinking on it a lot of time, and we've studied solutions and problem on each one, but is not implemented and will never be if some customer not demands it or some developer wants to implementing. It's not the typical case and major users not need it.

Simpliest solution is Internet server, bandwich in this scenario is not badly, and for security could use ssl or VPN, second scenario is better. You'll get medium uploading and fast donwloading.

[elcaminoreal]

Hello jllort,

Thank you for your answer and clarification. Certainly the distributed model is more complex and I can see that at this time, functionality such as this, is in the realm of professional services.

One a somewhat related note, I do have the following followup questions. thank you in advance for your input:

1. I have been looking at the various forum posts in regards to this question but I wanted to ask this question explicitly just to make sure. Is it possible to rename the root repository name from "okm:root" to perhaps something like our company name? the reason I ask is that "okm:root" initially could be somewhat confusing to some users and if we can not have other root repositories, why even show this root repository folder in the user interface. It seems removing it could make the interface simpler.

2. On a related question to the above, Is it possible to have multiple root repositories within the same installation?

3. How does openKM scale in terms of number of documents and concurrent users. We have about 80 users and over 70 thousand documents and growing. Most of the files are Microsoft Office files (i.e. Word, Excel, Powerpoint, many PDF, images and some AutoCAD files). I intend to test the MS Office plugins shortly as well.

Regards,

AMR

[pavila]

1. This modification requires change some parts of the source code, because this is not an usual customer requirement.

2. Actually you can't have several roots, because the root needs to be unique But what is the problem if you create several folders in the first level, each one for a company?

3. The performance of OpenKM scale well in our massive document test, and as reported by several customers with big document repositories.