1

nav 2013 と統合される Web アプリケーション (sth のようなダッシュボード) を作成したいと考えています (Nav からデータを取得し、顧客に表示し、データを更新または挿入することもできます)。

Nav では、フィールドのすべての条件と機能を指定したすべてのテーブルとページを作成しました。

これらの条件は、Nav のページからいくつかのデータを挿入する場合に非常に便利です (たとえば、顧客番号を入力すると、この顧客のプロジェクトがページに自動的に表示されます。これは非常に役立ちます)。

ページで作業している場合、Navision ではすべて正常に動作していますが、Web サービスを使用して NAV と通信するアプリケーションでは、テーブルで指定されている条件に多くの問題があります。

私の質問は、nav で「空白の」テーブルを準備し、Web アプリケーション (asp.net) で完全なロジックを作成するか、Nav で指定されたロジックで操作する方がよいですか?

私の意見では：

  • キーの番号付けに関するいくつかの基本的なロジックを除いて、テーブルにはロジックを含めないでください
  • ユーザーがデータを入力できるように設計されたすべての条件は、個別に実行する必要があります (Web アプリの個別のロジックと Na​​v のページの個別のロジック)。
4

1 に答える 1

1

コメントに基づいて、最も簡単な解決策を選択します。

  • ロジックを持たず、Nav エンティティ (タスクやプロジェクト、またはベースにあるテーブルなど) に関連しない一連のテーブル (それらを統合テーブルと呼びましょう) を作成します。コミュニケーション専用のテーブルとなります。
  • ほとんどの通信およびデータ変換ロジックを実行するディスパッチャ コードユニットを作成します。
  • 統合テーブルに基づいて、ディスパッチャ コードユニットとページを公開します。
  • 公開されたページを使用してメッセージを Nav にプッシュし、Nav からデータを読み取ります。
  • メッセージがプッシュされるたびに、カーテン ディスパッチャ メソッドを呼び出して、必要なすべての処理を実行します (Nav へのレコードの挿入と更新など)。
  • XML を返す OData、Pages、または codeunit 関数を使用して、Web フォームに表示する必要があるすべてのデータを読み取ります。私のアドバイスは、統合テーブルとディスパッチャーを介してのみ、Nav ネイティブ テーブルを直接 (ページ経由で) 更新/挿入しないことです。この場合、エラーの管理が容易になります。
  • 古いレコードまたは処理済みのレコードを統合テーブルから定期的に削除します。

これにより、ほとんどのビジネス ロジックを Web アプリ側に保持できますが、ディスパッチャーは常に操作結果を返すため、いくつかの一般的なロジック (制限など) を (ディスパッチャーおよびテーブル トリガーを介して) Nav に配置する機能も維持できます。 Web アプリケーションから送信された天気メッセージが正常に処理されたかどうか。

落とし穴があるかもしれませんのでご注意ください。

于 2014-06-07T10:28:52.890 に答える