※ 本記事は、Niall Commiskey, Nolan Trouvé, Jerry Mbamoによる"Intelligent Document Processing with Oracle Integration Cloud and OCI AI Vision Service"を翻訳したものです。
2023年8月17日
この記事はNolan TrouvéとJerry Mbamoの作品です。これを幅広いOracle統合コミュニティと共有していただき、ありがとうございます。
Oracle Integration Cloud (OIC)は、他のOCI Cloud Servicesとシームレスに連携し、必要なビジネス・ソリューションを提供します。この投稿では、OICおよびOCI AI Visionサービスでインテリジェントなドキュメント処理を実装する方法について説明します。
さてNolanとJerryに -
請求書のPDFなどの一連の非構造化ドキュメントがあり、自動化された方法で処理する必要があるとします。これらのドキュメントは次のようになります。:
このブログ投稿では、OCI Object Storageからこれらの非構造化ドキュメントを取得し、事前に構築されたAIモデルを通じて実行して、各ライン・アイテムの主要情報、アイテム番号、説明、数量、単価、合計価格などの情報を抽出するスケジュール済プロセスを作成する方法について説明します。このデータが抽出されたら、このデータをターゲット・データベースに挿入します。Oracle Integrationにより、人間の介入を必要とせずにプロセス全体をオーケストレーションできます。
OCI Visionとは?
OCI Visionは、REST APIとして公開されるディープ・ラーニング・ベースで事前構築済のカスタム・コンピュータ・ビジョン・モデルを提供するサーバーレスのクラウド・ネイティブ・サービスです。これは、オブジェクトの識別と検索、テキストの抽出、および領収書や請求書などのイメージやビジネス文書からの表、文書タイプ、キーと値のペアの識別に役立ちます。
OICでの接続の作成
この例では、最初に3つのOIC接続を作成します。:
- Object Storage
- Autonomous Data Warehouse (ADW)
- OCI Vision
バケット接続:
処理の前に、Object Storageバケットを使用して請求書を格納します。
バケットに接続するには、RESTアダプタを使用して接続を作成します。
必要な情報は以下のとおりです。:
- 接続URL - これは、OCIドキュメントのAPIリファレンスおよびエンドポイントのここにあります。
- セキュリティ・ポリシー - OCI Signatureバージョン1を選択し、必要な情報を指定します。これに精通していない場合は、ここから詳細情報をご覧いただけます。
前述の情報が入力された状態で、接続をテストできます。テストが成功した場合は、保存します。
ADW接続:
Autonomous Data Warehouseは、処理された請求書データのターゲット・データベースとして使用されます。
ADWアダプタを介して接続を作成するために必要な情報を次に示します。:
- 接続プロパティ – DBに送信されるトラフィックの処理方法を指定するサービス名を提供します。ADWの場合、オプションはlow、mediumおよびhighです。低いサービス名は、同時実行性が最も高いリソースを表しますが、高いサービス名は、最も高いリソースと最も低い同時実行性を持つ問合せを実行します。詳細はこちらをご覧ください。ADWのサービス名は、データベース名に基づいて作成されます。この文字列を検索するには、OCIコンソールからDBに移動し、「Database connection」をクリックします。
- セキュリティ・ポリシー - JDBC Over SSLセキュリティ・ポリシーを使用します。ウォレットは、OCIコンソールの同じデータベース接続ページから取得できます。ローカル・マシンにウォレットをダウンロードするときに、ウォレットのパスワードの作成が必要になります。OIC接続に戻り、ウォレットをアップロードしてパスワードを入力します。その後、OICから送信される問合せを実行するデータベース・ユーザーの資格証明を入力します。このユーザーに、ターゲット表が属するスキーマへの十分なアクセス権があることを確認してください。
上記に入力した状態で、接続をテストして保存します。
Vision接続:
OCIのVisionサービスに接続するための2つ目のREST接続を作成します。
必要な情報を次に示します。:
- 接続URL - これは、OCIドキュメントのAPIリファレンスとエンドポイントのここを参照してください。
- セキュリティ・ポリシー - OCI Signatureバージョン1を選択し、必要な情報を指定します。ユーザーがテナンシのオブジェクト・ストレージとOCI Visionサービスの両方にポリシーベースのアクセス権を持っている場合は、オブジェクト・ストレージ接続に対して実行した内容をコピーできます。
そのすべての情報が入力された状態で、接続をテストして保存します。
統合の構築
単一の請求書を処理するための統合を構築することから始めます。次に、次のような内容の例を示します。:
このアプリケーション主導の統合は、RESTエンドポイントを介して公開されるカスタムAPIとして設計されています。トリガー後の最初のコンポーネントは、Vision接続を使用してターゲット請求書からテキストを抽出します。残りのロジックは、Visionサービスからのレスポンスを解析してターゲット・データを識別し、最後にそのデータをADWに挿入することです。
RESTトリガー構成
RESTトリガーの構成では、統合を開始するリクエストの構造(渡されるデータを含む)を指定します。"processInvoice"のような意味のある相対URIを指定して、POSTリクエストとして定義できます。また、ターゲット請求書のファイル名に対して、処理される入力パラメータが必要であることも示します。
RESTトリガー統合の入力パラメータの定義は簡単です。「filename」という名前の新しい問合せパラメータを追加し、データ型として文字列を選択します。
Vision構成
次のステップでは、Vision接続を設計キャンバスにドラッグ・アンド・ドロップします。以前に接続で定義したベースURLの末尾にタックアップされる相対URIを指定し、POST操作を選択します。最後のステップでは、リクエスト・ペイロード定義とレスポンス・ペイロード定義の両方のボックスにチェックマークを付けます。ここから、OICで検証されるVisionサービスのanalyzeDocumentエンドポイントに、サンプルのJSONリクエストおよびレスポンスを指定できます。これらのリクエストおよびレスポンスのサンプルは、OICで統合を構築する前にVisionサービスにAPIコールを行うことで取得できます。
Visionリクエストへのデータ・マッピング
次に、Visionサービスへのデータ・マッピングの例を示します。ソースからマップされた唯一の要素は、RESTトリガーへの入力パラメータとして取得されたターゲット請求書のファイル名です。ターゲット・ノードを作成することで、ターゲット側の他のすべての要素がハードコードされています。
変数の初期化
次に、Visionサービスからのレスポンスの解析に役立つように定義したローカル変数を示します。変数を作成するには、「割当」アクションをデザイン・キャンバスにドラッグします。これらのループは、ネストされたfor-eachループの実行時に反復的に更新され、請求書から探している情報の主要部分が抽出されます。変数 "count"は、抽出された現在の単語を表しますが、他のすべての変数は、データベースに挿入しようとしている個々の要素を表します。
定義する解析ロジックは、作業中のドキュメントの構造によって異なります。ネストされたループを使用して、ドキュメントの各ページおよび各ページ内の単語を反復処理できます。このケースでは、検索する情報の前にある単語を特定し、Visionからの応答でその単語を確認した後でカウントを開始します。
ADW構成
現在の明細品目からすべてのターゲット要素を抽出した後、最後のステップでは、これらを新しい行としてADWに挿入します。ADW接続を設計キャンバスにドラッグし、ドロップダウン・メニューから「表に対する操作の実行」を選択します。そこから「Insert」を選択します。
挿入するデータベース内のスキーマおよび表を指定するには、最初にドロップダウン・メニューからスキーマを選択し、次にターゲット表を検索します。
ADWへのデータ・マッピング
ADWアダプタが構成されたので、定義した各ローカル変数のデータをターゲット・データベース表の列にマッピングします。ソースからターゲットに要素を直接マップすることも、OICの変換機能の1つを活用することもできます。この場合は、部分文字列関数を使用して、請求書のPDFの名前から請求書番号を抽出しました。
一度に複数の請求書の処理
作成した統合を改善するために、1つの統合実行で複数の請求書を処理できる2番目の統合を設計できます。次のようになります。:
上の図では、この2番目のフローの全体的な設計を確認できます。これは、事前定義済のスケジュールによってトリガーされるか、アドホック・リクエストとして実行できます。最初のコンポーネントは、Object Storage接続を利用して、ターゲット・バケットに格納されているすべての請求書のリストをフェッチします。ここから、for-eachループをパラレルで実行して各請求書の反復処理を行い、各請求書を非同期に作成した最初の統合に渡すことができます。この新しい統合は、最初の統合を子としてコールする親フローと考えることができます。OICでは、これをローカル呼出しと呼びます。
Object Storage構成
Object Storage接続を設計キャンバスにドラッグした後、まず、接続で定義されたベースURLにタックされる相対URIを指定します。これは、次のスクリーンショットに示すように、ネームスペースの後にバケット名が続きます。バケット内のオブジェクトのリストをフェッチするために、GETリクエストを実行します。最後のステップは、レスポンス・スキーマを構成して、OICがオブジェクト・ストレージから戻されるJSONを解析する方法を理解できるようにすることです。
レスポンス・スキーマを定義するには、OICが自動的に検証するJSONサンプルを再度指定できます。JSONが無効な場合は、エラーが表示され、続行できなくなります。
For Eachループ構成
Object Storageから返された各請求書を繰り返すには、for-eachループを作成します。最初のステップでは、反復処理するコレクションをOICに指示するソース要素を選択します。次のスクリーンショットに示すように、オブジェクト・ストレージからレスポンス・ラッパーの下の子要素を選択します。最後のステップでは、下部のチェック・ボックスをクリックして、各請求書のパラレル処理を有効にします。これにより、子統合によって各請求書が同時に処理され、処理が順番に実行されるよりもはるかに高速になります。
子統合の起動
サブプロセスとしての別のOIC統合の呼出しは、簡単に構成できます。統合アクションをデザイン・キャンバスにドラッグして、ドロップダウン・リストからアクティブな統合を選択します。リソース名や操作タイプなどの子統合のメタデータが自動的に移入されます。
子統合へのデータ・マッピング
親統合の最後のステップは、ループ内の子統合へのデータ・マッピングを完了することです。1つの要素(現在の請求書の名前)のみをターゲット側のファイル名パラメータにマップする必要があります。これにより、子統合でObject Storageバケット内の1つの請求書を識別し、さらなる処理が可能になります。
統合実行のモニタリング
統合をモニターするには、実行をトリガーする必要があります。アクティブな親統合で「実行」をクリックすると、この統合のアドホック実行のリクエストを送信できます。
「トラックのインスタンス」をクリックすると、OICの「可観測性」セクションに移動し、詳細を確認できます。存在すると、現在実行中の統合、実行済の統合、およびそれらの実行のステータスを確認できます。親統合の1回の実行と、子統合の複数の同時実行が表示されます。
ここから、統合を監視する様々な方法があります。エラーが発生した場合は、統合の概要を把握し、問題がどこにあるかをすばやく確認できます。一般に、問題のある領域は赤色の使用に関連付けられます。また、ループが実行された回数も、ループの開始上のボックス内の数字で示されます。この番号は、バケット内にあった請求書の数に直接対応します。
右側には、基本的にOICのバージョンのデバッガであるアクティビティ・ストリームも表示できます。ここから、統合の各ステップの詳細情報を取得します。
子統合を見ると、処理されたすべての請求書について同じ情報にアクセスできます。右下の「アクティビティ・ストリーム」からわかるように、請求書の例の1つには、61語が抽出された単一のページが含まれています。
まとめ
モニタリング・データに基づいて、実行中に何も問題がないと結論付けることができます。最後に、ADWをチェックします。このADWには、処理されたすべての請求書からのデータが必要です。
このブログは、OCI Visionの機能についてもう少し詳しく理解し、OICとの連携によって可能性が高まることを願っています。