私は C# 開発、および Dynamics GP の eConnect と Web サービスを初めて使用します。いくつかの情報源から、Web サービスは機能が多少制限されており、eConnect の上に独自の Web サービスを構築することが必要または望ましい場合があるという考えを拾いました。
私は疑問に思っています、誰かがそれが高レベルで何を伴うかを説明できますか?
私は C# 開発、および Dynamics GP の eConnect と Web サービスを初めて使用します。いくつかの情報源から、Web サービスは機能が多少制限されており、eConnect の上に独自の Web サービスを構築することが必要または望ましい場合があるという考えを拾いました。
私は疑問に思っています、誰かがそれが高レベルで何を伴うかを説明できますか?
eConnect で使用できる機能のほとんどは、いくつかの例外を除いて、Dynamics GP の Web サービスを通じて公開されます。たとえば、GP Web サービスを使用して販売注文に税金を明示的に指定することはできませんが、eConnect を使用するとできます。統合のニーズが確実に満たされるように、GP Web サービスのドキュメントを確認することをお勧めします。
GP Web サービスは、eConnect の上に追加のレイヤーを追加します。バックエンドで eConnect を使用します。別個のセキュリティ層と例外ハンドラを提供します。これらのニーズがある環境では、これは有益かもしれませんが、GP Web サービスのインストールと保守は簡単ではないため、コストがかかります。
私は何度かあなたが求めていることを発展させてきました. eConnect 呼び出しをカプセル化する C# WCF サービスを作成しただけです。サービスの詳細を自分で管理するため、インストールとメンテナンスがはるかに簡単になります。さらに、ロジックをより適切にカプセル化し、他のアプリケーションから難読化することができます。もちろん、作成する他のサービスと同様に、セキュリティと例外処理ロジックを考慮する必要があります。
たとえば、私の WCF サービスには、次のような非常に単純な操作を含めることができます。
string CreateCustomer(name, address);
サービスのロジックでは、すべての eConnect 呼び出しを実行し、作成された顧客番号を返します。
最終的に答えは「場合による」です。エンティティごとに厳格なセキュリティが必要な場合 (販売注文にはアクセスできますが、ユーザーごとに注文書にはアクセスできません)、またはインストールしたい商用製品を構築している場合は、GP Web サービスを選択します。 Dynamics GP の複数の異なるインストールで。GP Web Services がクライアント先に既にインストールされて使用されている場合は、一貫した環境を維持するために、可能であればそれらを使用するようにします。
クライアントに GP Web サービスがまだインストールされておらず、Dynamics GP とやり取りするための単純なインターフェイスが必要な場合は、独自の WCF を作成してロジックをカプセル化し、サービスのコンシューマーにとって統合をできるだけ単純にすることを選択できます。
考慮すべきもう 1 つのことは、Dynamics GP には、フィールド サービスや製造の統合など、eConnect または GP Web サービスでは実行できないことがいくつかあるということです。そのような場合、私はしばしば独自の WCF を作成し、可能な場合は eConnect を使用し、eConnect が機能をカバーしていない場合は SQL 更新を使用します。
アーキテクチャの決定が長期的に維持されるように、現在の統合ニーズと将来必要になる可能性があるものについて必ず検討してください。
また、eConnect と GP Web サービスの選択に関する詳細については、この優れた記事をお読みください。