コラム

Oracle APEXでマイグレーション③
~Excel帳票出力とLDAP認証を含むビジネスロジック移行のポイント~

こんにちは、Verasym事業部の黒田です。
前回の第2章では、Oracle APEXを活用した画面設計の移行についてご紹介しました。今回はその次のステップとして、画面の裏側を支える「ビジネスロジックの移行」に焦点を当てます。

Oracle APEXでは、ノーコードによるプロパティ設定に加え、SQLやPL/SQLを活用したローコード開発によってビジネスロジックを構築できます。また、外部システムとのAPI連携やサーバレスコンピューティングとの組み合わせ等にも対応しており、柔軟なサーバー側の設計が可能です。
現行システムのソースコードを一部流用することで、開発効率を高めることはできますが、すべての機能がそのまま流用できるわけではありません。

本ブログでは、まずOracle APEXにおけるビジネスロジックの基本的な考え方を整理します。そして「現行システムの既存コードを流用してどこまで対応できたのか」「どこで手作業によるコーディングが必要だったのか」をご紹介します。さらに、移行作業の中で特に課題となった「Excel形式での帳票出力」と「LDAPによるログイン認証」の2つのロジックに対して、どのような対応を行ったのかを詳しく解説します。

▼Oracle APEXでマイグレーション 全5章
第1章:老朽化対応と刷新のポイント
第2章:レイアウト再現のコツ(スクロール付きレイアウト対応、複雑なレイアウト設計)

1) Oracle APEXにおけるビジネスロジックと移行方針

まず、Oracle APEXにおけるロジック構築の基本を整理し、現行システムのどの部分を流用し、どこを再構築したのか手順を解説します。

1-1) Oracle APEXにおけるビジネスロジックとは?

Oracle APEXのビジネスロジックは、ノーコード開発を基本としつつも、必要に応じて柔軟にローコードでロジックを構築することができます。例えば、アプリケーションの動作制御、データ処理、入力検証、ビジネスルール実行といったアプリの根幹となる処理を指します。ユーザー操作をトリガーに実行されるサーバー側/クライアント側の処理も対象です。

主な実装手段は次の3つです。

プロパティ設定(ノーコード)
画面項目(アイテムやボタンなど)の表示制御、必須チェックなどをGUIで簡単に設定


クライアント側の処理である動的アクションの設定(ローコード)
動的アクションの実行によりクライアント側の処理(JavaScript)を実行するためのロジックや操作を指します。


サーバー側の処理であるプロセスの設定(ローコード)
サーバー側の処理(PL/SQL)はデータベースサーバー上で実行されるロジックや操作を指します。


ノーコードからコードベースまで幅広く対応できるため、業務要件に合わせた設計が可能です。


動的アクション・プロセスとは?

・動的アクションとは?
クライアント側の動作(JavaScript)
ページ上でユーザーが操作を行ったり、特定のイベントが発生したりしたときに、サーバーにリクエストを送信せずにクライアント側(ブラウザ)で実行される処理を定義するための機能

・プロセスとは?
サーバー側の動作(PL/SQL)
サーバー側で実行されるロジックや処理を定義するための機能
主にページのロードや送信など、特定のイベントが発生したときに実行する

1-2) 現行システムASP.NETからの移行方針

今回の移行では、Oracle APEXの標準機能を最大限に活用し、コーディングを出来るだけ減らせるように開発を進めました。

Oracle APEXでは、プロパティ設定や動的アクションなどのノーコード・ローコード機能を活用することで、多くのビジネスロジックを簡単に構築することができます。しかし、プロパティ設定によるノーコードの構築では対応しきれない箇所もあり、多少のコーディングが必要となる場合があります。

そこで今回の移行では、既存システムのロジックコードを可能な限り流用する方法を活用しました。ゼロからコーディングするのではなく、既存コードを調整し活用することで開発効率を高めることを目指しました。
実際にASP.NETで構築された現行システムでは、PL/SQLやJavaScriptで記述されたロジックが多く存在しており、これらをOracle APEXの「プロセス」や「動的アクション」に組み込むことで、比較的容易に再利用できました。
しかし、流用した既存コードの調整だけではすべての機能に対応できず、再構築が必要でした。それらに対しては調査を行い、別の方法を見つけ出し解決しました。

2) 現行システムのロジック移行と課題

2-1) 移行対象システムの機能の種類

移行対象となったASP.NETシステムには、多くの機能が組み込まれていました。

主なロジックは以下の通りです。
・ボタンを押下した時に入力した情報を初期化する機能
・入力した値によってクライアント上で計算処理を行う機能
・表形式の入力画面で追加する最大行を制限する機能
・Excel形式で帳票を出力する機能
・社内LANアカウント認証でのLDAPによるログイン認証する機能

これらはユーザー操作に応じたクライアント側の処理とサーバー側でのデータ処理によるロジックのほとんどがノーコード・ローコードで構築できます。多少コーディングが必要な箇所の移行にあたっては「どこまで既存コードを流用できるか」が重要なポイントとなりました。

2-2) 既存コードの流用によるロジックの移行

現行システムではJavaScriptとPL/SQLでロジックが記述されていたため、多くの処理をそのまま流用できました。また、一部機能に関してはプロパティ設定をマウス操作のみのノーコードで簡単に構築することができました。

(※処理の流れの一例を示すフロー図)


以下では既存コードの流用によるロジック構築(ローコード)部分をご紹介します。

ユーザー操作をトリガーとする処理:「動的アクションの設定」
ボタン押下や入力値変更に応じた処理は、Oracle APEXの「動的アクション」機能を利用しました。既存のJavaScriptコードを一部調整し、現行システムのJavaScriptコードを流用しました。
動的アクションを活用して構築した主なロジック詳細は以下をご覧ください。


動的アクションの対象ロジック

・検索ボタン押下時のロジック
→検索条件の入力チェック部分で既存のJavaScriptコードを一部修正して流用している

・「回数、単価」に入力した値によって、「金額と合計」の計算結果ロジック
→計算のロジックを既存のJavaScriptコードを一部流用している

・申請データの削除を行うボタン押下時のロジック
→データを削除するテーブルが複数あるため既存のPL/SQLを一部修正して流用している

サーバー側の処理:「プロセス」
データベース更新や計算処理などは、Oracle APEXの「プロセス」機能にPL/SQLコードを流用しました。既存のSQLロジックを再利用することで、ゼロからのコーディングを回避しました。
これにより、新規コーディングを最小限に抑えながら、統一性と保守性の高いロジック構成を実現しました。
プロセスを活用して構築した主なロジック詳細は以下をご覧ください。


プロセスの対象ロジック

・印刷ボタンのロジック
→プロセス内で既存のコードを一部流用し、Oracle APEXと外部のアプリケーションを連携することでExcel形式の帳票出力をしている

・領収書添付のロジック
→これは動的アクションとプロセス両方の方法を組み合わせている

しかし、すべての機能が流用可能だったわけではありません。
流用することができずゼロからのコーディングし再構築したロジックや別のアプローチが必要なロジックなども存在しました。
以下では特に課題となった2つのロジックに対して行った課題解決の工夫やその結果についてご紹介します。

2-3) 課題となった機能:Excel形式での帳票出力とLDAPによるログイン認証

今回対象となった課題は以下の2点です。

【課題①】Excel形式での帳票出力
業務要件として、Excel形式での帳票出力が必須でした。しかし、Oracle APEX標準のExcel形式での出力は画面表示内容をそのまま出力する方式であり、帳票レイアウトや集計処理には不向きです。

具体的な課題は以下の通りです。
・レイアウト調整が自由にできない
・集計や罫線・条件付き書式などに対応できない
・既存帳票テンプレートを再現できない


【課題②】LDAPによるログイン認証
社内の認証基盤により、社内LANアカウント認証が必須でした。初期は独自の認証処理をPL/SQLで構築することを検討しましたが、以下のような課題が浮上しました。
・LDAP接続の仕様理解と実装に時間がかかる
・認証処理のセキュリティ担保が難しい
・メンテナンス性に乏しく、将来的な変更に対応しづらい


次節では、こうした技術的な課題をどのように解決したのかについて具体的にご紹介していきます。

3) 課題への対応方法

流用が困難な一部機能については、OCIのサービスやOracle APEXの標準機能を活用することで現行システムのビジネスロジックを再構築しました。
【課題①】Excel形式での帳票出力 → OCI Document Generatorを活用(OCIサービス)
【課題②】LDAPによるログイン認証 → APEX認証スキームを活用(Oracle APEXの標準機能)

3-1) 課題①:Excel形式での帳票出力(テンプレート設計・SQL連携・OCI連携)

Oracle APEXの標準機能では、Excel形式で帳票を直接出力する機能が限られており、現行システムの要件を満たすには不十分でした。
そこで、OCI(Oracle Cloud Infrastructure)サービスを活用し、Excel形式での帳票出力を実現しました。

(※全体の流れを示すフロー図)

Excel形式での帳票出力の実現には、以下の3ステップで対応を行いました。

①テンプレート設計
Excel(.xlsx)形式で帳票テンプレートを作成し、罫線やフォント、ヘッダーなどを事前に定義します。
次に取得したいデータをテンプレート(Excelファイル)内のセルに、変数名を{#データ・ループ名}{カラム名(列名)}{/データ・ループ名}形式で記載します。
(※データ・ループ名はOracle APEX特有の名称で、抽出したデータをテンプレートへマッピングする際に使用します。)


②SQLによるデータ抽出
設計したテンプレートに差し込むためにOracle APEX内でSQLを用いて必要なデータを抽出します。
SQL文で問い合わせを記述し、そのSQL問い合わせ毎にデータ・ループ名を設定します。


③OCI Document Generatorとの連携
Oracle APEXからOCI Document GeneratorのAPIを呼び出し、テンプレートとデータを渡すことで帳票を生成します。
そこから取得したデータとテンプレートファイルをJSON形式でOCI Document Generatorへ送信します。


OCI Document Generatorとは?

Oracle Cloud Infrastructure (OCI) のサービスの1つで、事前構成済みのサーバーレス関数を使用して、ユーザーがコードを書くことなくドキュメント生成できるようにするツールのことです。
この機能を利用することで、Officeテンプレート(例:.xlsx)とJSON形式のデータを組み合わせ、PDFやExcelファイル(.xlsx)などのドキュメントを自動生成できます。

・サーバーレス関数とは?
サーバーの管理やインフラ構築を意識せずに、コードを実行できるクラウドサービスの仕組みです。必要なときに関数が呼び出され、処理が完了すると自動的にリソースが解放されます。
課金は実行時間とリソース消費分のみです。

そしてOCI Document Generatorがテンプレートに取得したデータをマッピングしたものをJSON形式でOracle APEXへ送信し、Oracle APEX内でExcel形式に戻した状態のものがダウンロードできます。


実際にファイルのダウンロードを行い以下のようにデータが反映されたExcel形式の帳票が出力できました。


このアプローチにより、帳票の体裁や集計ロジックを柔軟に設計でき、従来の帳票出力と同等の品質を確保できました。

3-2) 課題②:LDAPによるログイン認証(認証スキーム機能によるログイン認証の実装)

調査の結果、Oracle APEXには標準で認証スキームが用意されていることがわかりました。
そのため、独自開発を行わず、標準の認証スキームを採用して対応しました。

Oracle APEXでは、LDAPによるログイン認証を「認証スキーム」として簡単に設定でき、社内認証基盤と連携したログイン認証機能を効率的に実装できます。 そのため、独自の認証処理を流用する必要がなく、設定のみで対応しました。
ここでは、独自実装では得られないOracle APEX標準機能の利点が大きく貢献しました。

必要最小限の情報で簡単設定
Oracle APEXでLDAPによるログイン認証を設定するには、たった4つの情報を入力するだけで十分です。

これらを管理者に確認するだけで、複雑な設定は不要です。Oracle APEXの管理画面から数ステップで認証機能を組み込むことができます。

Oracle APEXで用意されている機能を活用することで以下のメリットが得られます。

セッション管理や認証処理はOracle APEXが自動化
独自に認証機能を作成すると、セッション管理やセキュリティ対策など、多くの要素を自分で設計・実装する必要があります。しかし、Oracle APEXではこれらの処理をすべて自動で管理してくれます。
これにより、開発者はアプリケーションの機能開発に集中でき、認証周りのトラブルも減少します。

メンテナンスが楽で運用負荷も軽減
LDAPによるログイン認証をOracle APEXに組み込むことで、ユーザー管理はLDAP側で一元化されます。Oracle APEX側でユーザー情報を個別に管理する必要がなく、以下のようなメリットがあります。
・ユーザー追加・削除はLDAP側で完結
・パスワードポリシーもLDAPに準拠
・Oracle APEXで開発したアプリケーションの運用負荷が大幅に軽減
結果として、セキュリティと運用効率の両方を高めることができます。

これらにより、複雑な実装負荷、セキュリティ確保、運用の煩雑さはすべて解決され、Oracle APEXの認証スキーム機能を活用した効率的かつ安全なLDAPによるログイン認証の実装が実現しました。

3-3) 移行結果と振り返り

Oracle APEXでは、画面構築からビジネスロジック実装までをノーコード・ローコードで効率的に進めることができました。特に重要だった点は次の2つです。

既存ロジックの流用による開発期間短縮
流用率は約60~70%。動的アクション・プロセスと組み合わせることで、保守性の高い構成を再現できました。
OCIサービスとの連携による機能拡張
Oracle APEX単体では対応が難しかった「Excel形式での帳票出力」や「LDAPによるログイン認証」については、OCIサービスとの連携や認証スキーム設定を活用することで、現行システムと同等の機能を再現することができました。

この取り組みにより、柔軟性と拡張性を兼ね備えたビジネスロジックを構築できました。
今後の開発においても、再利用可能で有効なアプローチになると考えています。

最後に

本章ではビジネスロジックの移行を通して、既存コードの流用とOCI連携を組み合わせたことにより、Excel形式での帳票出力やLDAPによるログイン認証といった複雑な要件にも柔軟に対応できることをご紹介しました。ノーコード・ローコードの機能を活かしつつ、PL/SQLやAPIを組み合わせた設計により、短期間で高品質な移行を実現できました。

次回の第4章では、「AIの活用」をテーマに、Oracle APEXとAIを組み合わせた開発効率化と品質向上に向けた取り組みをご紹介します。
具体的には以下のような観点でご紹介します。
・生成AIの解説
・Oracle APEXでの生成AI活用事例

Oracle APEXとAIの融合がもたらす新たな可能性にご期待ください!

連載バックナンバー