3

シンプルなウェブベースのデータ入力社内ビジネスアプリがあります。ここで、ビジネスは、ビジネスエンティティを表すデータベースの行にドキュメントを添付できるようにしたいと考えています。ドキュメントには、Word、Excel、PDFを使用できます。

どうすればそれができますか？

さらに別の自家製のドキュメント管理システムを作成するのは良い考えではないと思います。代わりに、サードパーティのドキュメント管理システムを使用して、アプリを緊密に統合することができます。理想的には、すべてのユーザーインターフェイスは、外部システムにアクセスすることなく、アプリケーション内にとどまります。SharePointまたはDocumentumはそれを実行できますか？他にどのようなオプションがありますか？

アプリケーションプラットフォームはJava/Websphereです。WindowsとUnixの両方のインフラストラクチャを利用できます。

4

3 に答える 3

1

どの文書管理システムでも、あなたが要求していることはできると思います。かつて、Sharepoint で同様のことを行いました。システムは、保管されている文書を照会できる API を公開します。統合がどのように行われるかは、使用するソリューションによって異なります。

さまざまなソリューションがさまざまな統合テクノロジをサポートしているため、選択する際には、現在のシステムが構築されているプラ​​ットフォームを考慮する必要があります。たとえば、現在のシステムで .NET を使用している場合、Sharepoint は簡単に統合できます。

多くのドキュメント管理システムは SQL サーバーのようなバックエンド データベースを使用しており、統合はアプリケーションからバックエンド データベースにクエリを実行するのと同じくらい簡単です。

于 2008-11-05T18:09:44.047 に答える
1

それはすべて規模に依存します。ドキュメント管理システムは通常、独自のアプリサーバーとデータベースを必要とし、複雑な API を多数備えており、実際には専用のボックスで実行する必要がある、それ自体が野獣です。

これらは、ドキュメントのライフサイクル (つまり、ワークフロー)、それらのドキュメントに関するロールとアクセス、および明確に定義されたスケジュールでのドキュメントの配置を管理することに関するものです。

ユーザーフォームに対して個別のドキュメントを処理することを計画している場合は、次の形式のテーブルをお勧めします

long : id long : form_id

どちらかと

ブロブ : フォーム

また

Varchar(2) : form_path

フォームテーブルと並行して。プロジェクトを引き継ぐ準備ができていない限り、「ドキュメント管理システム」には近づきません。私が提供できる最善の軽減策は、追加することです

なんでも: document_id

すぐに使用できるドキュメント管理システムのインストールを使用します。

于 2008-11-05T18:45:22.277 に答える
0

私は他のコメンターに同意します.EDRMSシステムはモンスターになる傾向があります.

内部システムを主要な EDRMS 製品と統合しましたが、もう一度統合する場合は、次のことを探します。

  1. 適切に (そして正確に!) 文書化された API。できればいくつかのコード例が含まれています。
  2. かなり大きなユーザーベース、できればまともなコミュニティもある
  3. アクティブなサポート - 非常にアクティブなオープン ソース プロジェクト、またはより熱心な企業のいずれかです。ユーザー数が少ないものや EOL が近いものは購入しないでください。

ところで、あなたはこれらのもので「エンタープライズ」の領域に入っています。時々、あなたがより多く支払うほど、あなたは悪化します。

編集:ここにも一種の同様の質問があります:Subversionは人気のある答えでした。

于 2008-11-05T20:39:16.943 に答える