前回作成した外部オブジェクトを使ってストアドプロシージャを呼び出してみましょう。
2.外部オブジェクトの使い方
今回はWebパネルから外部オブジェクトを使ってストアドプロシージャを実行してみます。2-1.変数の宣言
外部オブジェクトを使う場合には、変数を宣言しそのデータ型として外部オブジェクトを指定します。呼び出しに使うパラメータの変数宣言し、WebFormに配置します。
2-2.コード
変数として使用するので、GeneXus標準のオブジェクトの様に扱えます。
Event Enter
&MyStoredProcEO.get_customer_id(&CountryId, &CustomerId)
EndEvent
2-3.ビルドして実行
実行時の画面。国番号をINPUTパラメータとして渡し、 顧客番号をOUTパラメータとして受け取ります。 |
実行ボタンをクリックした所。 ストアドプロシージャより返された顧客番号がセットされています。 |
3.制約
以下のGeneXusのデータ型はサポートされていません。- コレクション型変数
- 拡張データ型及びSDT
- 配列(VectorとMetrix)
4.Oracleの注意点
- ストアドファンクションは呼び出せません。ストアドプロシージャ+OUTパラメータを使ってください。
- レコードセット(結果セット)は受け取れません。GeneXusでレコードセットを受け取る仕組みはFor each(Grid、データプロバイダー含)のみになります。
- パッケージを呼び出す場合はメソッドのExternal nameでパッケージ名も含めたストアドプロシージャ名を指定してください。
5.GeneXusでストアドプロシージャを使う是非
最後に、GeneXusでストアドプロシージャを使う是非というお話し。
GeneXusはジェネレーターというツールの性格上、すべてをGeneXusで開発するのが理想です。ただ、GeneXusの仕様上どうしても実現できない事やパフォーマンスの問題が発生する事も事実です。そういったGeneXusだけではまかないきれない時のために外部オブジェクトという仕組みを用意しています。
問題はどこまで適用するか?というスコープになります。適用範囲に関してはプロジェクトの方針にもなりますので、私から「絶対こうだ!!」という事は言えませんが、少なくともGeneXusのメリットや目的から考えるとポーティング(移植性)が一つの重要な観点になります。
GeneXusというと兎角開発生産性や低コストという側面が多く取り上げられがちですが、もう一つの側面はシステムライフサイクルの担保があります。つまり企業がシステムを利用する長い時間の中でハードウェアなどのプラットフォームを変更する事態になっても、GeneXusでナレッジベースを開発・維持していれば、ジェネレーターを切り替える事によって低コストで新しいプラットフォームへの移行が可能になります。
そのシステムライフサイクルとポーティングを前提に考えたとき、GeneXusで開発したシステムにDBMSのストアドプロシージャが多用されていたとすると、どういう事が起きるでしょうか?
手書きのストアドプロシージャは自動的に移行できません(例えばOracleのPL/SQLからMicrosoft SQL ServerのTransact-SQLへ)。つまりストアドプロシージャ部分は全部作り直しになります。当然の事ながら膨大なコストが発生します。又、プラットフォームの変更がなかったとしても、データベースに対する仕様変更(項目の追加・削除やデータモデル変更などの大きな構造変更)が発生した場合もストアドプロシージャの修正コストが膨らみます。
この様に初期開発時の効率やコストだけではなく、将来予測される事態も踏まえた上でストアドプロシージャをどこまで適用するか? 判断をする必要があります。
0 件のコメント:
コメントを投稿