如何将简单的数据输入应用程序与文档管理系统集成？
我们有简单的基于网络的数据输入内部业务应用程序。 现在，企业希望能够将文档附加到数据库中代表业务实体的行。 文档可以是Word、Excel、PDF。
我们怎样才能做到这一点？
我认为创建另一个本土文档管理系统不是一个好主意。 相反，我们可以尝试使用第三方文档管理系统并与我们的应用程序紧密集成。 理想情况下，所有用户界面都将保留在应用程序内，而无需访问外部系统。 sharepoint 或 documentum 能够做到这一点吗？ 还有哪些其他选择？
应用平台为Java/Websphere。 我们提供 Windows 和 Unix 基础设施。
We have simple web-based data entry internal business app.
Now business wants to be able to attach a document to a row in the database that represents business entity. Document can be Word, Excel, PDF.
How can we do that?
I think creating yet another home grown document management system is not a good idea.
Instead we can try to use an third party document management system and integrate tightly form our app.
Ideally all user interface will stay within application, without going to an external system.
Is sharepoint or documentum capable of doing it?
What other options are there?
The application platform is Java/Websphere. We ave both Windows and Unix infrastructure available.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为任何文档管理系统都可以满足您的要求。 有一次我们对 Sharepoint 做了类似的事情。 该系统公开了一个 API，允许您查询存储的文档。 集成的具体方式取决于您寻求的解决方案。
选择时需要考虑当前系统构建的平台，因为不同的解决方案支持不同的集成技术。 例如，如果您当前的系统使用 .NET，那么 Sharepoint 将很容易集成。
许多文档管理系统使用 SQL Server 等后端数据库，集成就像从应用程序查询后端数据库一样简单。
I think any document management system can do what you are requesting. At one time we did something similar with Sharepoint. The systems expose an API that allows you to query documents that are stored. Exactly how the integration happens depends on the solution you go for.
You need to consider the platform on which your current system is built when choosing because different solutions support different integration technologies. For instance, if your current system uses .NET then Sharepoint would be easy to integrate.
Many document management systems use a backend database like SQL server and integration could be as easy as querying the backend database from your application.
这一切都取决于规模，文档管理系统本身就是一个庞然大物，需要自己的应用程序服务器和数据库，拥有大量复杂的 API，并且确实应该在专用的盒子上运行。
它们实际上是管理文档的生命周期（即工作流程）、围绕这些文档的角色和访问，以及按照明确定义的时间表处置文档。
如果您计划处理一些与用户表单相对应的单独文档，我建议使用
long : id 形式的表格
long : form_id
与
blob : form
或
Varchar(2) : form_path
与表单并行。 我会远离“文档管理系统”，除非你准备好让它接管你的项目。 我可以提供的最好的缓解措施是添加一个
whatever : document_id
到您的表中，并使用开箱即用的文档管理系统安装
It all depends on scale, document management systems are typically beasts in their own right that require their own appserver and database, have a host of complex APIs, and really ought to be run on a dedicated box.
They are really about managing the lifecycle of documents (i.e. workflows), roles and access around those documents, and the disposition of the documents on well defined schedules.
If you are planning on handling some individual documents pared against a user form, i'd suggest a table in the form of
long : id
long : form_id
with either
blob : form
or
Varchar(2) : form_path
in parallel to your form table. I'd stay away from a "document management system" unless you are prepared for it to take over your project. THe best mitigation i can offer for that would be to add a
whatever : document_id
to your table, and use a very out of the box installation of your document management system
我同意其他评论者的观点，EDRMS 系统往往是怪物。
我已将内部系统与主要 EDRMS 产品集成，如果我再次这样做，我会寻找以下内容：
顺便说一句，你已经进入了“企业”领域，这些东西； 有时你付出的越多，你得到的就越糟糕。
编辑：这里还有一个类似的问题：Subversion 是一个流行的答案。
I agree with the other commenters, EDRMS systems tend to be monsters.
I have integrated an internal system with a major EDRMS product, and if I was doing it again I would look for the following things:
BTW, you are into 'Enterprise' territory with these things; sometimes the more you pay the worse you will get.
EDIT: There is also a sort of similar question here: Subversion was a popular answer.