Oracle Application Express 統合と変換 <ここに画像を挿入> Oracle Application Express 統合と変換 * 統合と変換について説明するためのスライドを選択してください

Microsoft AccessからAPEXへの移行 移行を推進する要因 部門アプリケーションの統合によるITの一元管理 拡張されてミッション・クリティカルになったアプリケーション Webアプリケーションでの使いにくさ プラットフォームへの依存 不十分なセキュリティ 不十分なスケーラビリティと過剰なネットワーク・トラフィック 課題 移行には労力とビジネス知識が必要 不十分なデータ・モデル設計 文書化されていない 議論のポイント： Microsoft Accessは、IT部門に依存することなく独自アプリケーションを構築できるという点で、ビジネス・ユーザーから人気があります。 始めは単純な部門アプリケーションだったものが重要性と機能性を増すケースはよくありますが、IT部門によるアプリケーション保護は適用されていません。 当初の作成者がいなくなると、アプリケーションについて知る者は誰もいないという場合もよくあります。 このようなアプリケーションのいずれかに障害が発生した場合、通常はIT部門が大急ぎで対応し、何の事前知識もないまま、なんとかアプリケーションを修正しなくてはなりません。 © 2009 Oracle Corporation 2 2

Microsoft Accessの移行 - Oracle SQL DeveloperとOracle APEX Oracle Application Express ワークスペースの作成 移行プロジェクトの作成 Microsoft Access アプリケーションの分析 Oracle Application Express アプリケーションの生成 Oracle Application Express アプリケーションのカスタマイズ 議論のポイント： Microsoft Accessアプリケーションを移行するには、SQL DeveloperとOracle APEXの両方を使用する必要があります。 SQL Developerは、データ・スキーマとデータをOracleデータベースに移行するために使用します。 Oracle APEXは、Accessアプリケーションに含まれるフォーム、レポート、問合せに基づいて初期のデザインを生成するために使用します。 多くの企業で、移行の一環としてAccess表の統合が実施されています（例：5種類の顧客表を1つの顧客表に統合）。 このようなケースでは、多くの場合、組込みのAPEXウィザードを使用してゼロからAPEXアプリケーションを構築する方が素早く結果を得られます。 APEXプロジェクトを作成および生成する際の意義は、初期デザインを生成できる点だけではありません。 Accessアプリケーションのすべてのソースを確認し、分析することができ、これには生成対象でないVBソースも含まれます。 特に、アプリケーションが複雑で文書化もされていない場合、APEX開発者は古い機能を確認することで、代替アプリケーションの作成方法を決定できます。 © 2009 Oracle Corporation

Oracle FormsからAPEXへの変換 変換を推進する要因 ソフトウェアとハードウェアのモダナイゼーション Web 2.0機能の組込み ユーザー・インタラクティビティの向上 既存のデータベース・オブジェクトの利用 既存のIT開発者スキル・セットの再利用 Oracle Forms開発者の新たな獲得が困難 課題 ITアプリケーションの専門家を利用できるかどうか 変換は多大な労力とリソースを必要とする重要な作業 APEXアプリケーションのルック・アンド・フィールは Formsアプリケーションとは異なる 議論のポイント： Oracle Formsは1980年代にリリースされ、製品にふわさしい非常に忠実な支持層を得ています。 Oracle Formsのサポートは廃止されておらず、Oracle Forms 11gが近くリリースされる予定です。 Formsを変換するおもな要因は、旧バージョンのOracle Formsで作成されたアプリケーションは完全なサポートを得られないという点にあります。 既存の開発要員はSQLおよびPL/SQLに精通しており、宣言型環境での作業にも慣れているため、Oracle APEXへの移行は素早く実行できるでしょう。またOracle APEXのApplication Builderも問題なく使用できるでしょう。 開発者が習得する必要があるのは、ツールとパラダイムにおける違い（例：ステートフルとステートレスの違い）です。 変換したAPEXアプリケーションの外観と動作は、古いFormsアプリケーションとまったく同じではないため、変換プロジェクトの全体を通じてユーザーを参加させることが重要です。 Oracle Formsを別のツールに変換するには、多大な時間とリソースを投資する必要があります。 ユーザーの賛同を獲得し、必要な労力すべてを見積もって現実的なプロジェクト計画を策定するため、プロトタイプの作成を強く推奨します。 © 2009 Oracle Corporation 4 4

Oracle Formsの変換 議論のポイント： Oracle FormsからOracle APEX（またはその他のツール）に変換するには、多大な時間とリソースを投資する必要があります。 プロジェクト計画を作成する前に、必要な労力と期待される結果を特定するための概念実証を開始することを強く推奨します。 また、Oracle FormsとAPEXアプリケーションは問題なく共存できるため、大規模アプリケーションの開発は複数のステージやリリースに分割することを推奨します。 1987年以降のOracle Formsの歴史 Forms 2.0、2.3、3.0 - キャラクタ・モード Forms 4.5、5.0、6i - クライアント/サーバー Oracle Forms 9i、10g – Oracle Forms Server Oracle Forms 11g - 開発中 - 大規模で活気のある顧客基盤 - 完全サポートと拡張の継続 ‐ R12までのOracle Applicationsによる使用 - 既存のFormsアプリケーションの移行は必須ではない © 2009 Oracle Corporation

Oracle Formsから移行する理由 Oracle Formsは今後も存続します！ Formsは80年代半ばのクライアント/サーバー以前の古いテクノロジーです。Formsはブラウザから起動されるJavaアプレットを実行しており、HTMLを使用していません。 Formsは最近のブラウザ・アプリケーションとの一貫性を持ち合わせていません。 議論のポイント： Formsは1980年代にリリースされ、製品にふわさしい非常に忠実な支持層を得ています。 Oracle Formsのサポートは廃止されておらず、Oracle Forms 11gが近くリリースされる予定です。 既存のFormsアプリケーションの移行は必須ではありません。 ほとんどのユーザーは、買い物や航空便の予約など、オフィス外で定期的にインターネットを使用しています。 このため、業務用のアプリケーションに対してもこのようなWebアプリケーションに似たルック・アンド・フィールや、より動的なインタラクティビティが求められています。 © 2009 Oracle Corporation 6

Oracle APEXへ移行する理由 Web 2.0に基づく最新のコンピューティング環境への移行 アプリケーションのモダナイゼーションと革新的機能の提供 "すぐに使える"インタラクティブ・レポートとFlashグラフ 既存のForms開発者にとって容易なスキルの移行 どちらも3GLコンパイルの不要なウィザード主導型の宣言的ツール どちらもSQLとPL/SQLを中心としたRAD開発ツール Oracle APEXは無償で データベースの機能を提供 必要なのはデータベースのみ 議論のポイント： インタラクティブ・レポートなどの機能は、ユーザーの期待値を超えるものです。 Forms開発者であれば、APEXアプリケーションの開発方法を素早く習得でき、快適な範囲から離れすぎません。 Oracle Databaseライセンスを持っていれば、追加のライセンスは必要ありません。 © 2009 Oracle Corporation 7

Oracle APEXによるForms変換 この変換機能は Oracle FormsからOracle APEXへのモダナイゼーション・プロジェクトの開始を後押しする手段である FormsコンポーネントからネイティブAPEXコンポーネントへの 自動変換（自動変換できるコンポーネントのみ）である Formsアプリケーションのロジックを簡単に参照する方法である トリガーやその他の変換不可能なロジックの手動変換を追跡するための便利なツールである ただしこの変換機能は “特効薬”ではない Formsエミュレータでもない 保守の困難なコンピュータ生成コードでもない 議論のポイント： 変換機能を"過剰宣伝"しないことが重要 簡単に初期設計を生成し、すべてのFormsソースを調査する機能を提供 Oracle Formsになじみのない新規開発者はOracle Formsをインストールしたり、ツールのナビゲート方法を習得したりする必要はありません。すべてはAPEXプロジェクトにロードできます。 すべてのコンポーネントに注釈が付与されるため、アナリストはFormsソースを確認し、必要なアクションを決定できます。また開発者は完了状況を追跡できます。 Oracle APEXのForms変換は、100%本番対応のAPEXアプリケーションを生成するブラック・ボックス・ツールではありません。 Formsトリガー、プロシージャ、PL/SQLライブラリに実装されたビジネス・ロジックは生成後に手動で再実装する必要があります。 Oracle APEXはFormsとは異なるため、Oracle APEXでアプリケーションを厳密に複製しようとしないでください。 この場合、必要となる手動コーディングが非常に広範囲に及ぶだけでなく、APEXツールの利点を最大活用できなくなります。 生成されるコードは100%標準のAPEXアプリケーションであり、"特殊"なコードは含まれません。 このため、APEXアプリケーションの拡張と保守が容易になります。 実際、標準の'Create Applicationウィザード'を使用し、生成する表と列をすべて指定すると、同じアプリケーションを生成できます。 © 2009 Oracle Corporation 8

Forms変換プロジェクト 正式なプロジェクトとして処理すること プロトタイプ表現のForms プロジェクト計画の作成 分析 範囲 設計 ビジネス・プロセスの改良 変換必要に応じて繰返し 生成後Webコンポーネントの構築 ユーザー受入れ トレーニング Application Expressの注釈の利用 詳細レベルの割当て、追跡、進捗レポート 議論のポイント： Oracle FormsからOracle APEXへの変換はプロジェクトとして処理および管理する必要があります。 プロジェクト計画を作成する前に、必要な労力と期待される結果を特定するための概念実証を開始することを強く推奨します。 初期設計の生成は、変換プロジェクトの一部に過ぎません。 ユーザー受入れとトレーニングが、プロジェクトを成功させるためのキー・ポイントになります。 組込みの追跡機能と注釈を使用して、労力を特定し、完了状況を追跡します。 © 2009 Oracle Corporation 9

Forms変換手順 - 1ページ Oracle APEXへのログイン APEXホームから「Migrations」リンクをクリック Oracle Formsアプリケーションの表をワークスペースから使用できるようにします。 APEXホームから「Migrations」リンクをクリック customers_fmb.xmlとorders_fmb.xmlという2つのファイルを持つ"Customer Items"プロジェクトを作成します。 ブロック・カウントをクリックして両方のブロックを編集し、問合せを検査し、マスター/ディテール以外のブロックの拡張問合せ機能を表示します。 Project Homeで「Triggers」をクリックし、トリガーを表示します。 （これらのトリガーは移行されません。 ） “Applicability”の仕組みについて検討 - FormsのトリガーはAPEXでは必要ありません（例：KEY-）。 'Applicable' = YESでフィルタリング - ビジネス・ロジックを持つトリガーに注釈を追加します。 アプリケーションの作成と実行、テーマの選択など 「Customers」をクリックし、余分な_ID列を削除します。 "San Francisco"でフィルタリングします。 緑色で表示された「EXCELLENT」の信用格付けを選択します。 列を編集し、LOVを選択してみます。 注： ファイルは次のOTNサイトからダウンロードできます。 http://www.oracle.com/technology/obe/apex32/files/forms_conversion.zip 次のOracle By Exampleも参照してください。 http://www.oracle.com/technology/obe/apex32/apex32frmmigr.htm © 2009 Oracle Corporation 10

Forms変換手順 - 2ページ アプリケーションのホームページから「Orders」をクリック Orders queryページに戻り、このページを編集します。 レポート・リージョンを編集し、 新しいSQL Queryに貼り付けます（次のスライドを参照）。 ページを実行します。Formsと同様、コンパイルは必要ありません。 グラフの表示順序を"City"→"sales rep"に変更します。 ホームページのクリーンアップ（APEXアプリケーションの1ページ） リスト・リージョンを編集して“list template override”を変更し、“Horz Images w Label”テンプレートを 使用します。 ナビゲーション・リージョンに相当する「list」リンクをクリックして、リスト項目を編集します。 最初のリスト・エントリをクリックし、アイコンの横にある上矢印をクリックして128x128アイコンを 選択します。次に顧客、注文、項目、在庫に対して次のアイコンを選択します。 © 2009 Oracle Corporation 11

新規注文用のSQL文 select o."ID" as "ID", o."CUSTOMER_ID" as "CUSTOMER_ID", o."DATE_ORDERED" as "DATE_ORDERED", o."DATE_SHIPPED" as "DATE_SHIPPED", o."TOTAL" as "TOTAL", o."SALES_REP_ID" as "SALES_REP_ID", o."PAYMENT_TYPE" as "PAYMENT_TYPE", o."ORDER_FILLED" as "ORDER_FILLED", c."NAME" as "NAME", c."CITY" as "CITY", c."STATE" as "STATE", c."COUNTRY" as "COUNTRY", c."CREDIT_RATING" as "CREDIT_RATING", e."USERID" as "SALES_REP" from S_CUSTOMER c, S_ORD o, S_EMP e where o.CUSTOMER_ID = c."ID“ and o.SALES_REP_ID = e."ID" 注： この問合せはAPEXプロジェクトの顧客向け拡張問合せリージョン内で使用することも、顧客インタラクティブ・レポートの生成後にこのレポート向けの問合せを置き換えて使用することもできます。 © 2009 Oracle Corporation 12