8

私はSharepointでいくつかの大きなERPアプリケーション（いくつかのレガシーアプリが書き直され、いくつかの新しいアプリ）を開発する任務を負っています。Sharepointに慣れてくると、チームサイトの作成の価値と容易さがわかります。オンラインや書籍で見つけた例はすべて、イントラネット部門のポータル、または次のようなシンプルな基幹業務アプリに合わせて調整されています。大規模なレガシーERPシステムを持たない企業。複数の異なるレガシーシステムにインターフェイスし、複数の部門にまたがる大規模なアプリケーションを作成する場合、SharepointでカスタムWebパーツを構築するのは道のりではないと私は信じ始めました。

Sharepointは、大規模なERPアプリケーションを作成およびホストするための実行可能なアプリケーションフレームワークですか？

もしそうなら、誰かがそのようなシステムのアーキテクチャを説明している参考文献を教えてもらえますか？

そうでない場合は、それを使用しないための議論として引用できる参考文献を誰かに教えてもらえますか？

4

5 に答える 5

9

過去 15 年間 ERP アプリケーションを書いてきた者として、ERP 製品を構築する上で Sharepoint は非常に悪い選択だと思います。

  • Sharepoint のテーブル構造は、レポートの作成には非常に効果的ではありません。
  • データを検証する機能は非常に限られています。
  • ドキュメント間の関係シップの整合性を維持するために私が認識しているネイティブ サポートはありません。

SharePoint は、データが豊富なアプリケーションを構築するためのプラットフォームとしてではなく、既存の LOB アプリケーションへのポータルとしてうまく機能します。

于 2009-05-25T23:54:34.807 に答える
5

現在、Sharepoint で記述されたクライアント用の ERP システムを展開しています。私はこれに約 1 年間取り組んできましたが、私が見た限りでは、Sharepoint は物事をより複雑にするのと同じくらい多くの障害をもたらしました。

物事がより簡単になりました：

  • 認証情報は AD に自動的に同期されます。
  • すぐに使用できるドキュメント処理とバージョン管理。
  • 優れたオフィス統合。

ひどかったこと:

  • Sharepoint のやり方を学ぶ必要があります。
  • ERP に別の依存関係があります。
  • それはかなり不格好です。

決定を下す前に、Real World SharePoint 2007: Indispensable Experiences From 16 MOSS and WSS MVPsを読むことをお勧めします。

于 2009-01-29T13:34:57.130 に答える
3

大規模な ERP インストールの一部として、職場で SharePoint 2007 (MOSS) を使用しています。ビジネス データ カタログを多用して外部システムと連携し、それらのデータを MOSS ポータル内で表示および検索できるようにしています。

私たちのアーキテクチャでは、ERP データに対する CRUD 操作は、ERP 基幹業務システムで処理されます。次に、MOSS と BDC が ERP データベースからデータを引き出し、さまざまなポータル ページに埋め込まれたデータグリッドとして表示します。たとえば、HR サイトには、保留中のパフォーマンス レポートの現在のステータスを追跡するための MOSS ページがあります。

MOSS と BDC のもう 1 つの魅力的な機能は、BDC データソースを MOSS 検索サービスに公開できることです。たとえば、ユーザーが MOSS 検索を使用して John Smith を検索すると、John Smith の公開 ERP レコードが検索結果にインライン化されます。検索結果のリンクをクリックすると、ユーザーは MOSS ページではなく、ERP システムの適切なページにリダイレクトされます。

私たちは、MOSS を ERP システムとしてのみ使用しているわけではありませんが、ERP システム上のプレゼンテーションおよびレポート レイヤーとして使用しています。

于 2009-01-29T14:03:13.733 に答える
2

SharePoint でカスタム Web パーツを構築することは、複雑なレガシ システムに対応する方法ではありません。

メイン ナビゲーション用のカスタム ナビゲーション プロバイダー (たとえば、xml ファイルに基づく) を作成した場合でも、SharePointは多くのマイレージを提供します。これにより、カスタムの asp.net ページが SharePoint の一部であるかのように表示され、1 つのすべてを網羅するアプリのように見えます。

人々が 1 つの巨大なアプリケーションを必要とする唯一の理由は、技術的なアーキテクチャの理由よりも、情報アーキテクチャ、ルック アンド フィール、見つけやすさに関係していると思います。

スキン化され、SharePoint 情報アーキテクチャにリンクされ、メイン インターフェイスから検索可能な適切なアプリケーション用に個別の Web サイトを作成するソリューションは、ERP の「エンタープライズ」部分の「必要性」を解決できます。本当に別々のアプリケーションです。

私が使用するメンタル モデルは、SharePoint でアプリを構築することではなく、SharePoint でアプリを公開するための「ウィンドウ」を作成することです。

于 2009-01-29T21:14:49.353 に答える
2

MS Dynamics AX システムは、Sharepoint を広範に利用しています。実際、ベース AX オブジェクトからデータを直接抽出する Web パーツなどをユーザーが構築できるようにするツール キットがあります。これは、Sharepoint 統合AX+SPについて少し説明しているリンクです。現在、Sharepoint 内に常駐していない AX のかなりの部分がまだありますが、アプリケーションのかなりの部分を Sharepoint で有効にするという方向性が示されています。ERP システム全体が Sharepoint インフラストラクチャ内に常駐できるとは思いませんが、MVC の観点からは、確実に View インフラストラクチャになる可能性があります。これがまさに MS が向かっている方向のように思えますが、私は MS の将来の計画について仮説を立てているだけです。

于 2009-01-29T13:29:46.127 に答える