ディプロイ統合紹介

1.Webアプリケーションの概念

1.ローカルデザイナーを通じて管理ポータルを開くと管理ポータルのURLが次のようなURLで始まります。（既定のポートは8075）

http://localhost:8075/webroot/decision/

2.このURLを他の人と共有すると、他の人はローカルの管理ポータルにアクセスすることができません。また、ローカルデザイナーを閉じ、再びこのURLにアクセスすると、管理ポータルのページは表示できなくなります。デザイナを閉じてこのURLに再度アクセスすると、管理ポータルが表示できなくなります。

3.このURLを他人にシェアしても、ローカルなポータルなので、他人はそのURLからポータルにログインできません。デザイナを閉じると、ビルドインサーバも止まりますので、このURLからはポータルへアクセスできません。

4.デザイナのビルドインサーバは、デザイナの使用に必要なwebページのみ提供しており、完全なwebアプリではないため、webからいつでもどこでもアクセスすることができません。

5.オンラインデモ(本質的には１つのポータルである)にアクセスすると、urlはhttp://jpdemo.finereport.com/webroot/decisionから始まっていることが分かります。他の人もブラウザにこのリンクを入力すると、このオンラインデモにアクセスできます。

6.オンラインデモは１つのオンラインアプリでありますので、いつでもどこでも利用することができます。

7.ローカル帳票プロジェクトもオンラインデモも、FineReportに基づいて構築してあるプロジェクトです。両者の区別として、オンラインデモはwebサーバから、帳票プロジェクトをwebからアクセスできるURLにしていることであります。このローカルプロジェクトをwebアプリにするという過程は「デプロイ」と言います。

2.デプロイの原理

デプロイの具体的な方法について、この節の他のマニュアルをご参考ください。Tomcat、WebLogic、またはJbossをwebサーバにすることをお勧めします。このマニュアルでは、主にローカルの帳票プロジェクトをwebアプリにデプロイする原理について説明します。

1.下の画像は、デプロイ済みの帳票プロジェクトの原理を説明しています。

①:ユーザがURLを入力しました。このURLはとある帳票にアクセスするリンクであるとします。

②:webサーバはブラウザからのリクエストを受け、リクエストの内容を読み取ります。データベースの読み書きをするし、クエスト・連動などのダイナミックな操作をしているので、本質的に言えば、帳票は一種の「ダイナミックリソース」であります。しかし、webサーバは直接的にダイナミックなリソースを処理してリスポンスすることが不可能です(しかし、静的リソースは問題なく処理できます)。そこで、webサーバはリクエストをServlet(Server Applet)コンテナに転送して、Servletにダイナミックリソースの処理を委ねます。

③-⑤:コンテナのServletは、FineReportが開発した一連のJARファイルであります。JARファイルは、データベーの読み取り、パラメータの生成など、グラフの作成、データの表示など、帳票ページ作成に必要な操作を処理しています。

⑥:Servletがリクエストを処理して、完成した帳票をServletコンテナに戻します。

⑦:Serveltコンテナが閲覧可能な帳票ページをブラウザにリスポンスします。こうして、ユーザは帳票を確認することでできます。

2.上述の過程は、次の2点に縮約できます。

• Servletを含むWebサーバが、ユーザからのリクエストを受けて(URLを解析する)、ユーザのリクエストにリスポンスする(帳票の表示)。

• Finereportがユーザのリスポンスを処理する。具体的に言えば、開発者が開発したテンプレート(本質的には帳票の構造を保存しているファイル)に基づいて、帳票のロジックをユーザが閲覧できる形にする。

ゆえに、webサーバでFineReportの帳票をwebページの形でブラウザに送る必要があります。

3.FineReportには、Tomcatがビルドインされており、Finereportのインストール位置に入ると、中にserverのディレクトリーがあります。serverのディレクトリーには、Tomcatの設置ファイルがあり、localhost:8075から始まるURLを使って、ローカルコンピューターから帳票を閲覧できる設定となっています。

4.しかし、ローカルマシンにおけるこのビルドインのTomcatサーバは、他のデバイスからのアクセスをサポートしていません。サーバ(Linuxサーバまたは自分のPCなど、サーバになるコンピューターを指します)を用意して、webサーバ(Tomcatなど、ウェブサービスに必要なサーバのソフトウェアです)を構築しなければなりません。帳票プロジェクトのファイルをwebサーバに組み込み、webサーバを実行することで、帳票プロジェクトもwebアプリとして利用できます。すでにwebサーバを構築している場合、帳票プロジェクトにビルドインされているファイルを直接的にwebサーバに置くこともできます。

5.以上では、二種類のデプロイ方法を紹介しました。それぞれ0からwebサーバを構築する[独立デプロイ]と、帳票プロジェクトを在来のwebサーバに置く[埋め込み型デプロイ]であります。実際の状況からデプロイの方法を選ぶことができます。

1.統合の背景

1.普通では、FineReportを１つの独立したwebアプリの形でデプロイします。ユーザは、IDとパスワードを使ってポータルにログインしてから帳票を閲覧できます。しかし、企業では、時にCRM、OA、MESなど複数の業務システムを持っており、どのシステムも一度ユーザIDとパスワードを入力しなければ使えないとしたら、利便性が非常に悪くなります。

2.統合することで、１つのアカウントですべてにシステムにログインすることができます。ユーザがどれかのシステムにログインすると、ログイン情報がタイムアウトしない限り、どのシステムにもアクセスすることができます。つまり、統合はSSOの一種の実現であります。

2.SSO(シングルサインオン)の原理

1.SSOは、HTTP、oAuth、CASなど、様々な方法で実現できます。FineReportでは、HTTPに従って一連のログイン・ログアウトAPIを開発しており、在来のシステムのフロントエンドを編集して、簡単にSSOが可能になります。oAuthとCASで実現するSSOは、比較的複雑だが、アカウントセキュリティが保障されます。oAuthは、ポータルにログインする操作を一種のサービスとしてその他アプリ(例えば企業の他のシステム)とライセンス付与の過程を連動する仕組みです。その他システムは、アカウントの内容を取得することなく、ポータルにログインする権限を取得することができます。CASは、アカウント認証専用のプラットフォームを構築することで、統一したプラットフォームからすべての業務システムへと認証サービスを提供します。ただし、CASの認証過程は、Finereportのログイン・ログアウトAPIを必要としています。

2.ここでは、FineReportが提供しているAPIを例に、SSOの原理について紹介します。

二つのシステムがあるとします。１つはFineReportから構築された帳票プロジェクトであり、もう１つは、その他業務システムであるとします。ここでは、一回のログインで二つのシステムにアクセスする方法を紹介します。session、token、cokkieの基本概念を知っておくと、より簡単に理解できます。

• session:認証が成功すると、サーバからsessionが作成されます。つまり、sessionには、ユーザのログイン状態が保存されています。sessionを作った後、サーバからブラウザへとsessionの索引となるsessionidが発給されます。ユーザがシステムにアクセスするたびに、tokenの認証をします。ログインがタイムアウトしていなければ、sessionidからユーザに保留されているsessionを見つけ、ページへのアクセスを許可します。逆にログインがタイムアウトしていれば、sessionidが対応しているsessionを消去します。次回のアクセスは、再度ユーザIDとパスワードを入力しなければなりません。

• token:ユーザ認証が成功すれば、サーバからブラウザへとtokenが発給されます。tokenは、ログインのタイムアウト時間を記入してある、暗号化されたユーザ情報であります。tokenは、ブラウザのcookieに保存されています。システムにアクセスする度に、サーバはtokenを解析して、認証をします。

• cookie:ブラウザにtokenとsessionidを保存しています。