以前の記事
はじめに
本稿ではAzure上に構築されたアプリケーションに、帳票生成機能を提供することを想定します。このアプリケーションはWebアプリケーションでもいいですし、Windowsアプリケーションとして実装された業務アプリケーションでもいいでしょう。
ただ共通する想定として「ビジネスロジックはAzure上のWeb APIとして実装される」こととします。そういった環境でDioDocsを利用し、どのように帳票生成サービスを構築するか？ 本稿では底を掘り下げて検討し、実装例を紹介したいと思います。
本稿で作成した帳票生成処理は、再利用可能な形で実装しNuGet上に公開しています。DioDocs自体もNuGetに公開されているので、気軽に試すことができます。ぜひご自身で利用してみてください。
なお本稿は、DioDocsもAzure Functionsも全く利用したことがない方向けに記載しています。
さあ、それではあらためてDioDocsの世界へ足を踏み入れてみましょう！
本稿の構成
本稿は次の4項目で構成されています。
- 全体アーキテクチャの考察
- Azure Functions上での実現検証
- 帳票生成ライブラリの実現検証
- 帳票生成サービスの実装
まずは帳票生成サービスをAzure上でどのように実装すべきか（そもそも「Azure Functionsを利用すべきか？」も含め）検討します。その後、想定通りAzure Functions上で実装可能か検証し、帳票生成部分の実装を検証します。
それらの検証がすべて終わったのち、具体的な実装を紹介します。
環境
- DioDocs for Excel 2.2.1+
- Visual Studio 2019 16.2.3
- Azure Functions 2.0
- .NET Core 2.2
- Microsoft.Azure.WebJobs.Extensions.Storage 3.0.7
全体アーキテクチャの考察
それではアーキテクチャの検討から始めましょう。まず以下の前提があるものとします。
- アプリケーションのビジネスロジックはAzure上でWeb APIとして構築する
- 帳票生成も同様にAzure上で実施する
- 生成された帳票はエビデンスの意味も含め一定期間Azure上に保管する
ありがちなケースではないでしょうか？
この場合、Web APIは実際にはAzure上のApp ServiceやAzure Functionsを基盤として、REST APIなどで実装されることでしょう。また生成された帳票をAzure上に保管する関係から、帳票生成もAzure上で実装されるはずです。
「帳票はPresentationの一部なのでは？ 仮にそうであったとして、PresentationがWebやクライアントアプリケーションとしてクライアントで実行されるのであれば帳票生成もクライアントで実装すべきではないか？」
こうした議論はあるかと思います。
しかし今回は、エビデンスの意味も含めて帳票はAzure上で保管します。クライアントサイドで実装すると、最悪ユーザーのみが所持してサーバー側には保管されないといったことが起こる可能性があります。サーバー側にエビデンスとして必ず保管するのであれば、帳票の生成はサーバーサイドで実施し、サーバーで保管までされた場合のみユーザーに提供すべきでしょう。
帳票の生成は、一般的なWeb APIと比較すると相対的に重く、リソースもそれなりに必要とします。また帳票生成量には波があることも多いでしょう。業務アプリケーションであれば1日の中でピークがあるでしょうし、公開サービスであっても例えば月末は利用量が多いといったことが想定されるでしょう。帳票の種別によっても利用量には偏りがあります。
以上を考慮して全体の構造を検討すると、下図が考えられるのではないでしょうか？
まず帳票生成サービスはAzure Functionsで作成します。
帳票生成はピークに偏りがありますし、帳票別に利用頻度も異なります。またビジネスロジックに変化がなくても帳票のレイアウトは変化することは、ままあります。
そのため、スケールイン・スケールアウトが容易で、アプリケーションと切り離して改修・配備可能であるマイクロサービスは最適な選択肢のひとつではないでしょうか？
帳票の生成にはDioDocsを利用します。DioDocsは次の特徴を持っています。
- ExcelからPDF生成をサポートしている
- 実行環境にMicrosoft Officeのインストールは必要ない
- ライブラリは.NET Standardとして提供される
帳票の生成というのは一般的に特殊な知識が求められます。帳票生成ライブラリの製品ごとに一定レベルの知識が求められ、また必ずしも理解しやすいとも限りません。
それに対してDioDocsはExcelと.NETの基本的な知識があれば利用することが可能です。レイアウトはExcelでデザイン可能ですし、ページングやヘッダーフッター、値のフォーマットといったあたりまでExcelで指定が可能です。
これは学習コストを考慮した場合、驚異的な生産性を発揮するでしょう。
ただしエンタープライズ環境における一括大量印刷系には向きません。その場合には、それに合った製品を選ぶべきで本稿の対象の範囲外となります。
逆に「少量多品種である」「レイアウトの変更が頻繁にある」「特定の帳票製品に習熟したエンジニアを継続的に確保することが困難である」などの要件がある場合、DioDocsは恐ろしいまでの効果を発揮するでしょう。
さてDioDocsを利用する場合、テンプレートとなるExcel（もしくはPDF）が必要です。テンプレートの取得方法は、大きく分けて次の3つが考えられます。
- Azure Functionsのアセンブリにリソースとして埋め込む
- Azure BLOBサービスに保管して取得する
- 帳票生成の際にデータとセットでPOSTする
3．の場合、Azure内外との通信量が増えてしまいますし、通信速度にも制限を受けます。基本的には1．もしくは2．となるでしょう。
- 今回は帳票生成のロジックに変更がなくても、テンプレートだけ変更することがありえる
- 非エンジニアが帳票のレイアウトのみを変更することがありえる
こうした想定のもと、2．の方式を選択することとしました。特に後者にとっては大きなメリットです。これはExcelからPDF生成が可能なDioDocsならではの強みです。
具体的な保管・取得先としてAzure BLOB Storageを利用します。
帳票生成時に動的に変動するデータはサービスの利用者（といってもソフトウェアですが）からJSON形式でPOSTしてもらい、帳票のテンプレートはBLOBサービスから取得します。それらをもとにExcelに値を設定したのちにPDFを生成し、いったん生成されたPDFはBLOBサービスに保管します。利用者には保管したアドレスを返し、別途BLOBサービスから取得してもらうことを想定します。
