「快速サーチャーGX」は請求書や領収書をはじめとする各種帳票の一元管理を行う電子帳票システムです。電子取引から書類まであらゆる帳票に対応しており、独自のデータベースにより素早い検索が行えます。また電子帳簿保存法に対応しているため、安心して使用することができます。また、APIによって他サービスとシームレスに連携することも可能です。
今回はASTERIA Warpを使い、快速サーチャーGXへの証憑登録や証憑ファイルのダウンロードを自動化・効率化する方法をご紹介します。必要な設定は全てノーコードで実現できるため、スピーディーに実装を進めることが可能です。
今回は快速サーチャーGX側で公開されているAPIを使用して次の3つの連携処理（フロー）を作成します。
このフローでは、対象となる帳票の画像が電子帳簿保存法の要件をみたしているかをAPIで検証します。
このフローではAPIを利用し、OCR機能で検索キー項目の作成と証憑登録を行います。また今回は電帳法の要件確認と証憑登録を一度に行うために、フローの統合の方法についてもご紹介します。
このフローでは、APIを利用し登録済の証憑ファイルを指定してダウンロードを行います。
今回利用する快速サーチャーGXのAPIの詳細に関しては、株式会社インテック様にご確認ください。また、フロー中で使用するAPIのベースURLは快速サーチャーGXの利用開始案内をご参照ください。
それでは実際にフローを作成していきましょう。
こちらのフローについては、図1のようにコンポーネントを配置します。
図1 コンポーネントを配置した様子
このフローでは、青枠の中に配置している5つのコンポーネントでリクエストボディを作成します。その直後に配置するRESTコンポーネントで電帳法の要件確認を行うAPIリクエストを送信します。
作成するリクエストボディについては、ユーザー情報のXMLデータと対象ファイルのバイナリーデータから構成されるmultipart/form-dataとなっています。そのため、図2のようにコンポーネントをパラレルに配置しそれぞれを出力します。その後、合流地点のMIMEEncodeコンポーネントで1つのmultipart/form-dataにします。
図2 multipart/form-dataを作成する箇所
これらのパラレルに配置する2箇所とその合流地点のMIMEEncodeコンポーネントについて、上記の図に記載がある順番で説明します。
この処理では、まずMapperコンポーネントでユーザー情報のXMLデータを出力します。その後、MIMEEncodeコンポーネントでMIME形式にします。前者に関しては図3のように出力ストリームを設定し、必要なデータをマッピングします。
図3 Mapperコンポーネントの出力ストリーム
今回は扱うユーザー情報を、Const関数を利用して図4のようにマッピングします。
図4 マッピングの内容
もう一方のMIMEEncodeコンポーネントでは、「基本」タブの「Content-Type」プロパティで「application/xml」を指定します。「MIMEヘッダー」タブでは「Content-Disposition」を「form-data; name="xml"」とします。これらは図5、6のように設定します。
図5 MIMEEncodeコンポーネントのプロパティ（「基本」タブ）
図6 MIMEEncodeコンポーネントのプロパティ（「MIMEヘッダー」タブ）
この処理では、まず確認の対象となるファイルをFileGetコンポーネントで指定します。このファイルはバイナリーデータとして出力したいので、図7のように「ストリーム型」プロパティを指定します。
図7 FileGetコンポーネントの出力ストリーム
そしてMIMEEncodeコンポーネントで①と同様に「Content-Type」プロパティや「Content-Disposition」を指定します。これらは対象ファイルの形式に応じて指定してください。
合流地点のMIMEEncodeコンポーネントで、①②で出力されるMIME形式のデータを構成要素としたmultipart/form-dataを作成します。そのために「Content-Type」プロパティで「multipart/form-data」を指定します。
このコンポーネントに①②から矢印を接続する際は、順番に注意する必要があります。今回作成するリクエストボディでは、これらの順番が指定されているためです。このコンポーネントを右クリックした際に、図8のような順番が表示されれば問題ありません。
図8 接続した場合の順番
表示される順番が逆になっている場合は、このコンポーネントを右クリックし「入力順序」を選択、その後に順番を入れ変えてください。
①から③で作成されたリクエストボディを含むAPIリクエストの送信を、RESTコンポーネントで行います。パスやメソッドは図9のように各プロパティで指定します。今回は「URL」プロパティでベースURLを設定しています。
図9 RESTコンポーネントのプロパティ
その後、出力ストリームを右下で定義します。このAPIでは、電帳法の要件である色と解像度、諧調についての判定結果がレスポンスボディに含まれるため、図10のように設定します。
図10 RESTコンポーネントの出力コンポーネント
以上で1つ目のフローは完成です。
こちらのフローについては、図11のようにコンポーネントを配置します。
図11 コンポーネントを配置した様子
配置するコンポーネントに関しては、先ほど作成した電帳法の要件確認を行うフローと同一です。
こちらでもmultipart/form-dataをリクエストデータとしており、その構成要素も同様にXMLデータとバイナリーデータです。そのため配置するコンポーネントの各プロパティは1つ目のフローと概ね同じ内容になります。
ただMapperコンポーネントで設定する出力ストリームやRESTコンポーネントのプロパティについては変更する必要があります。今回は使用するAPIに合わせて図12、13のように設定します。RESTコンポーネントについては、先ほどと同様に「URL」プロパティでベースURLを設定しています。
図12 Mapperコンポーネントの出力ストリーム
図13 RESTコンポーネントのプロパティ
FileGetコンポーネントについては、先ほどと同じファイルパスを指定しています。このような設定にすることで、電帳法の3つの要件を満たしていることを確認し証憑登録を行うといった運用が可能になります。
以上が2つ目のフローの作成手順となります。
ここまでに作成した2つのフローは、1つに統合することで電帳法の要件確認から証憑登録を一度に実行できるようになります。更なる業務効率の向上が期待できるので、今回はこちらについて2つの方法をご紹介します。
1つ目の方法は、コンポーネントをそのままコピーし、他フローでペーストする方法です。コンポーネントはプロパティの設定も含めてコピーが可能なので、今回のようなケースでは必要な作業を減らすことができます。
ただ、コンポーネントの数が多くなってしまうためフローの確認や理解に時間がかかってしまいます。また複数個所で流用した後に修正が必要になった際は、全箇所で作業を行わなければなりません。そのため管理が煩雑になる可能性があります。
2つ目の方法は、サブフロー機能を使用する方法です。この機能により、予め作成したフローを他フローの処理中に呼び出すことが可能になります。フローの呼び出しは図14のようにSubFlowコンポーネントのみで完結するため、配置するコンポーネントの数が少なくなり視認性が向上します。
図14 SubFlowコンポーネントのプロパティ
さらに修正が必要になった際は、呼び出されるフロー1つのみを修正すれば済むため、方法1の欠点を気にせずフローを作成できます。その際は、コンポーネントをダブルクリックするだけで対象フローが表示されるので、ミスなく作業を進めることができます。
こちらの機能はStandardエディション以上でのご提供となるため、共通処理やコンポーネントの数が多くなる場合はぜひご利用ください。
そして、それぞれの方法で実装したフローが次の図15です。
図15 サブフロー利用前後の比較
比較すると、方法2ではコンポーネントの数が減少していることが分かります。
今回は証憑登録を行う処理のみをサブフローとして呼び出しましたが、電帳法の要件確認を行う処理も同様に設定することが可能です。その場合はコンポーネントの数をさらに少なくすることができます。
このようにサブフロー機能を利用すると、全体の見通しを良くすることができ、開発生産性をより向上させることができます。
またどちらの方法でもフローの統合の際、電帳法の要件確認を行うためのRESTコンポーネントの下にBranchコンポーネントを配置しています。
これは電帳法の要件についての確認結果が問題ない場合のみ後続の処理を行うことを目的としています。そのために、このコンポーネントの「条件式」プロパティで判定結果を確認する式を設定します。今回は図16のように「/VerifyResult/@color="true" and /VerifyResult/@resolution="true" and /VerifyResult/@gradation="true"」と設定します。
図16 Branchコンポーネントのプロパティ
この後に行う動作確認は、統合後のフローを利用して進めていきます。
こちらのフローについては、図17のようにコンポーネントを配置します。
図17 コンポーネントを配置した様子
まず上から2番目にFileGetコンポーネントを配置します。今回はリクエストボディの一部に、快速サーチャーGX上のファイルを指定するためのユニークキーが必要になります。ユニークキーは証憑登録の際に快速サーチャーGX上で確認できます。これをCSVファイルで管理しフローの実行時に読み込むことで、ファイルの動的な指定や、複数ファイルを対象とした処理が可能になります。
ユニークキーを入力するファイルを作成した後、図18のように「ファイルパス」プロパティでそのパスを指定します。ファイルの中身については、動作確認時に入力するため、現時点では空で問題ありません。
図18 FileGetコンポーネントのプロパティ
そして図19のように「ストリーム型」を「CSV」に変更し、フィールドを1つ定義します。今回読み込むCSVファイルはユニークキーについての項目のみを持つためです。
図19 FileGetコンポーネントの出力ストリーム
3番目に配置するMapperコンポーネントはリクエストボディを作成する処理に相当します。今回はユーザーIDやパスワードなどから構成されるXMLデータが必要になるため、まず出力ストリームを設定します。ここで設定する「evidence_key」でユニークキーを扱います。設定する内容は図20のようになります。
図20 Mapperコンポーネントの出力ストリーム
また後に配置するコンポーネントでファイルを保存する際は、ファイル名の重複を回避する必要があります。そのために今回はユニークキーをファイル名として使用します。その際に使用するフロー変数を、図21のように設定します。
図21 フロー変数の内容
マッピングでは、ユーザー情報など固定文字列を扱う項目はconst関数を使用します。「evidence_key」など動的な項目については直前のFileGetコンポーネントから出力されるデータを使用しマッピングします。今回は図22のようにマッピングします。
図22 マッピングの内容
そして、今回は複数のユニークキーを扱う場合を想定しているため、このコンポーネントの「ループを開始」プロパティを「はい」に設定します。図23のように設定することで、ユニークキー毎にフローが実行されます。
図23 Mapperコンポーネントのプロパティ
上から4番目のRESTコンポーネントでは、証憑ファイルのダウンロードを行うAPIリクエストを送信します。図24のように各プロパティで送信先のパスやメソッドを指定します。これまでと同じく、ベースURLを「URL」プロパティで設定しています。
図24 RESTコンポーネントのプロパティ
リクエストが送信される際は、Mapperコンポーネントから出力されるXMLデータがリクエストボディとなります。そして、このAPIはバイナリー形式のデータがレスポンスボディとなります。そのため、図25のように「ストリーム型」プロパティを「Binary」に変更します。
図25 RESTコンポーネントの出力ストリーム
次に、出力されたバイナリーデータをファイルとして保存するためにFilePutコンポーネントを配置します。保存先は「ファイルパス」プロパティで設定します。今回は先ほど設定したフロー変数を用いて、図26のようにプロパティ式の機能で設定します。この機能は、プロパティの右側にある歯車アイコンをクリックすることで使用できます。
図26 FilePutコンポーネントのプロパティ
以上で証憑ファイルのダウンロードを行うフローは完成です。
ここでは、作成した2つのフローを実行して動作の確認を行います。
まずは2つ目に作成した、電帳法の要件確認と証憑登録を行うフローから確認します。フロー実行前の快速サーチャーGXについては、図27の通り登録された証憑が存在しません。
図27 快速サーチャーGXの画面（フロー実行前）
フロー実行後に再度この画面を表示します。ファイルが電帳法の3つの要件を満たす場合は、証憑ファイルの登録とOCR機能による検索キー項目の入力が行われていることが確認できます。一方で条件を満たさない場合は、フロー実行後も画面は変化しません。図28はファイル登録やキー入力が行われた場合の様子です。
図28 快速サーチャーGXの画面（フロー実行後）
そして登録が正常に行われた場合は、快速サーチャーGX側のログで図29のようなEvidenceIdが確認できます。
図29 快速サーチャーGXの画面（ログ）
この値がユニークキーとなります。こちらを使用してもう1つのフローを実行し、証憑ファイルがダウンロードされることを確認します。
FileGetコンポーネントで指定しているファイルに、確認したEvidenceIdを図30のように入力します。今回は3回登録を行い、その結果を使用します。
図30 ユニークキーを記載したファイル
その後フローを実行し、ユニークキーをファイル名としたファイルが図31のように保存されていることを確認します。
図31 ダウンロードされたファイルの一覧
登録された証憑ファイルは、図32のように快速サーチャーGXの検索画面でも確認できます。この際に検索結果の行をチェックし右側の証憑表示アイコンをクリックすることで、登録された証憑ファイルを表示することができます。実際に表示すると図33のようになります。
図32 証憑検索画面での確認
図33 証憑表示機能での表示
今回はASTERIA Warpを使用し、快速サーチャーGXへの証憑登録や証憑データのダウンロードの自動化・効率化を行う方法をご紹介しました。この方法は帳票の一元管理を更に快適にするだけでなく、人為的なミスの削減も実現します。また、ノーコードで実装するので、直ぐに効果を実感できます。快速サーチャーGXの更なる活用が可能になるので、ぜひお試しください。
2024年にアステリアに入社。アステリア製品を対象に、コンテンツの作成やプリセールス業務を行っています。
ASTERIA Warp製品の技術情報やTips、また情報交換の場として「ADNフォーラム」をご用意しています。
アステリア製品デベロッパー同士をつなげ、技術情報の共有やちょっとしたの疑問解決の場とすることを目的としたコミュニティです。
