ラベル PHP の投稿を表示しています。 すべての投稿を表示
ラベル PHP の投稿を表示しています。 すべての投稿を表示

2017-06-02

大容量のSQLテーブルもOK! ― FileMaker 16 を帳票作成ツールとして使う

 FileMaker Server 16 (以下、FMS16)ではPDF出力をサポートするようになりました。FileMaker Pro はもともと帳票/レポートを簡単に作成できるツールして利用されてきましたが、サーバサイドでPDFが作成できるようになり、面倒なWeb帳票の設計・実装が実に簡単、且つ短時間のうちに行えるようになりました。 データベースは FileMaker でも SQL/XMLデータベースでもOKです。 本稿では MySQL の1500万件のテーブルからデータを抽出し、遅延無くPDFを出力する方法の概要を記します。

開発・運用環境

FileMaker Pro (Advanced) 16 ― 帳票作成ツール*1
FileMaker Server 16/IIS/PHP ― サーバ*2

 *1 帳票を作り、簡単なスクリプトを書くだけであればFileMaker Pro 16(¥4万前後)で事足りますが、複雑なスクリプトを書くには開発用(デバッガ付)の FileMaker Pro Advanced (¥7万前後)が必要です。
 *2 FileMaker Server 16 はFM社直売で¥99,000 (税抜)です。

 FileMaker Server 16 (の カスタムWeb公開 =CWP)の理論上の最大接続数は 2,000、検証接続数は500 ですので(詳細はこちら)、¥20万弱で本格的な帳票開発・運用環境が構築できる可能性があります。

本稿の目的と概要図

Webブラウザ上でから 入出庫システム(バックエンドはMySQL)にアクセスし、入庫伝票をPDF形式で作成・表示することを目的とします。 帳票を構成するテーブルに1000万件単位レコードが存在する場合にも、ユーザにストレスを与えない程度の実行速度で、入庫伝票PDFを表示することも目指します。以下が実装手法の概要図となります。



実装手法

入出庫明細テーブルには 約1500万のレコードがあります。 FileMaker で数十万件を超すテーブルからデータを抽出してPDF帳票を遅延無く作成するには、上図の FMS ⇔ MySQL 間の設計がキモとなります。今回は一般的な FileMaker ESS(External SQL Source 機能)を使う手法 と、原始的な ODBC データ取込を使う2つの手法を実装・テストしました。

実装手法1 ―  FileMaker ESS を使用  データ件数が多くなると低速化する

  1. 本手法では ESS を使用し、MySQLのテーブルを FileMaker のファイル内に直接配置します。下図の「_入庫」や「_取引先_入庫」などがそれに相当し、これらはシャドウテーブルとも呼ばれます。
    ESSは FileMaker 内から直接 MySQL のテーブルを読み書きでき便利なのですが、数十万行を超す大きなテーブルを扱う時には速度が低下するなどの問題があります。ESSの問題点については、古い記事になりますがこちらを参考にしてください。

  1. 入庫伝票レイアウトの開発は FileMaker Pro (Advanced) のGUIを利用し、テーブル内のフィールドや罫線、テキストなどのオブジェクトを配置しながら作成すると、慣れた人なら 短時間で完成すると思います。  
FileMaker Pro により作成した入庫伝票イメージ

  1. 次に FileMaker のスクリプトメーカーで、PHP から渡ってきた入庫No による検索、入庫伝票レイアウトの選択、PDF保存などを行うスクリプト(「実装手法概要図」の「特定のスクリプト」)を作成します。
  2. 最後に PHPファイルからそのスクリプトを実行するように指定します。

実装手法2 ― ODBCデータ取込 を使用 データ件数にかかわらず高速

  1. 本手法では独立した FileMaker ファイルを一つ用意し、その中に FileMaker のテーブル(vw入庫伝票、下図参照)を用意します。

    このテーブルに MySQL から必要最低限のデータを取り込み、そのデータを FileMaker レイアウトを使用してPDF形式で出力します。

    注:ESS は使用せず、したがって MySQL のシャドウテーブルも配置しません。
  2. MySQL側に入庫伝票に必要なテーブル(本例では、入出庫明細、取引先、入庫、商品の4テーブル)を結合した入庫伝票用ビューを作成します。

    ビューの作成は必須ではありませんが、ビューが無いとFileMaker内に4つのテーブルを用意し、4回SELECTクエリを発行して用意したテーブルに対応するMySQLのテーブルデータを取り込む必要があります。ビューを使用すれば、テーブル、クエリー、取込とも1つ/1回で済むので、実行速度的にも有利です。特別な事情がなければ、ビューを使用しましょう。

  3. FileMaker を使用して入庫伝票レイアウトの作成します。テーブル構成が異なるので実装手法1とはその作成方法は異なりますが、FM開発者にとっては容易な作業と思います。
  4. 次にPHPから渡ってきた 入庫No を使用し、 ビューに対して SELCTクエリーを発行し、結果を vw入庫伝票テーブルに取り込み、入庫伝票レイアウトを選択して、PDFを保存するスクリプトを作成します。
  5. PHPからこの FileMaker スクリプトを実行して、PDFを作成・表示する部分は実行手法1と同様です。

テスト結果

上記2つの手法による実装をブラウザからテストしてみました。HTTPリクエストからPDFが表示されるまでの時間は以下の通りです(テストは各5回ずつ実行し、その平均値を記載しています)。

実装手法1: 77秒
実装手法2: 1.2秒 

 その差は圧倒的でした。シャドウテーブルを配置するESSは、SQLクエリーの発行を FileMaker がすべてやってくれるので便利な反面、膨大なクエリーを発行するため速度低下を招きます。 その点、 ファイル内にESSシャドウテーブルを配置せず、SQL SELECT文を自身で指定し、その結果を FileMaker テーブルに取り込む ODBCデータ取込は大きなSQLテーブルに対しては圧倒的に有利です。

思ったこと

実装手法2であれば、数千万件のデータを持つSQLデータベースの帳票作成環境として、その使用に耐えそうです。 実装手法1は10万~20万件程度のテーブルであれば利用可能と思われます。

本稿では SQLデータベースを取り上げましたが、旧FileMaker Server の Webシステムを温存しつつ、下図のように FMS16 を併行運用し、FMS 16 は PDF出力用サーバとして使用する方法も考えられます。

PDF出力をしたいが、 FM16へのアップグレードはできない場合、検討の価値はあるかと思います。





(土屋)




2016-12-06

Slim フレームワークの REST(PDO) および RESTfm を使って CRUD のテストをしてみた

 先日の記事『Slim フレームワークの REST による FileMaker データベースへのアクセス』では、REST URI 経由で FileMaker DB アクセス実験を行うために Silm フレームワークを採用しました。
 この記事ではWeb クライアントからの GET 要求を受領してから、 FileMaker データベースに PDO 経由で SELECT クエリを発行してデータを戻すという、Slim REST 側の操作方法を簡単にご紹介しました。

 今回はこの Slim フレームワークの REST 機能のパフォーマンステストに加え、RESTfm でもテストを行ってみました。
 RESTfm は、Goya 社 MIT ライセンスで公開しているオープンソースの PHP コードであり、 FileMaker Server で公開されているデータベースに対する REST API 機能を簡単に実装できます。

 とても便利!と思ったのは、REST に不慣れなプログラマが「 あるテーブルのレコードにアクセスする方法を知りたい」と思ったときに、RESTfm 環境の index.html にアクセスするだけで、その URI を知ることができることです。 
 例えば、「EasyApp15‗p」データベースにログインすれば、任意のレイアウトのそれぞれのレコードへの URI が自動表示され(下図)、商品レイアウト上のレコード ID 10951 へのレコードにアクセスするためのリンクが表示されていることが確認できます。


 また、URL の最後の部分のファイル拡張子は .html ですが、これを .json、.xml、.txt、.fmpxml などに書き換えるだけで、自動的に変換表示してくれるのもよいですね。これは、PHP でプログラムしたことがある方ならわかりますが、結果セットを簡単に見ることができ、とても楽ちんです。


 さて、本題に戻りますが、今回のパフォーマンス検証では、クライアントの Web ページから GET(取得 READ)、POST(新規作成  CREATE)、PUT(更新 UPDATE)、DELETE(削除) 要求を発行しました。

 比較用として、記事「 FileMaker API別にCRUDのテストをしてみた」で採用した API も一緒にグラフに掲載しておりますので、 併せて参考にしてください。

テスト環境

サーバ: Xeon 2.2GHz(1Core)/4GB RAM(Hyper-V 仮想マシン)
OS/Webサーバ: Windows Server 2012/IIS 8.0
FileMaker Server: Ver 15
使用言語: PHP
使用DB: FMEasy在庫 IWP/WD R1.5 (パイロット版)
使用REST API:
 Slim フレームワーク(PDO を使用)
 RESTfm 4.0.8 (FileMaker API for PHP を使用)
テスト概要:
 Slim フレームワーク REST URI 経由、および RESTfm の URI 経由でCRUD(Create/Read/Update/Delete)を行う簡単な Webアプリを作成・実行。

備考:
  1. Slim フレームワークから FileMaker データベースへの接続オブジェクトは PDO(ODBC)です。
  2.  RESTfm はその仕様上、内部的には FileMaker API for PHP で FileMaker Server に接続します。

 Slim フレームワークは Composer を使ってインストールします。
 詳しくは以下のリンクをご覧ください。
 https://www.slimframework.com/docs/start/installation.html

 RESTfm の最新版は 4.0.8 です。(2016/12/06 現在)
 以下のリンクよりダウンロードできます。
 https://github.com/GoyaPtyLtd/RESTfm/releases

 各テストはそれぞれ5回実施して開始から終了までの時間をプログラム上で測定。各5回の平均値を基にデータを作成しました。

Slim フレームワークを使用し、100件のレコードを REST URI 経由で検索・表示した際のブラウザウインドウ(FireFox)

RESTfm を使用し、100件のレコードを REST URI 経由で検索・表示した際のブラウザウインドウ(FireFox)

GET メソッドによる Readテスト 1


テスト内容:
 94万レコードを持つテーブルから該当件数が N 件になるようにレコードを検索し、その中から100レコードのみを表示

結果: XML圧勝! Slim は遅いね

該当件数がN件になるようにレコードを検索し、その中から100件を表示

          No. of found                     recs
APIs
0 15000 30000 300000 600000 900000
FM API for PHP 0 0.22 0.34 1.76 3.28 4.74
XML 0 0.19 0.25 1.68 3.26 4.71
PDO 0 0.65 0.72 2.47 4.18 5.91
Slim REST PDO 0 0.46 0.63 3.86 7.3 10.69
RESTfm 0 0.88 0.91 2.32 3.91 5.4


補足:
 対象レコード件数が 1万件前後までは他の API とさほどパフォーマンスの差は感じられませんが、2万件あたりから差は開いていき、3万件を超過すると Slim REST PDO グラフ線(エンジ色)の傾斜は急激にきつくなっています。

 これに対し、RESTfm (黄色のグラフ線)は、該当件数が90万件でも、その中から 100件取り出す程度であれば、PDO よりもパフォーマンスは良いようです。


GET メソッドによる Readテスト 2


テスト内容:
 94万レコードを持つテーブルで 該当件数が3万件になるように検索し、N 件のレコードを表示

結果: FM API for PHP と XML が有利 Slim と RESTfm はやはり遅い

該当件数が3万件なるように検索し、その中から N件を表示

         No of fetched                    recs
APIs
0 100 500 1000 2500 5000 7500 10000
FM API for PHP 0 0.34 0.81 1.36 4.32 6.99 10.51  
XML 0 0.25 0.55 1.09 2.88 6.04 10.58 16.19
PDO 0 0.72 0.74 1.28 3.45 5.18 7.46 10.24
Slim REST PDO 0 0.64 1.6 2.75 6.15 12.32 18.22 23.72
RESTfm 0 0.97 4.31 7.97 19.25      


補足

 100 件程度のデータを取り出すなら、やはり FM API for PHP および XML がパフォーマンスに優位性がみられます。
 取得件数が 5000 件を増えると PDO が優位になってきます。

 全体的にみて、Slim も RESTfm も取り出すデータ件数が増えるにしたがい、極端にパフォーマンスが低下しているのがわかります。

 2500件取得時には、Slim(注:Slimは PDO を使用) は PDO(注:Slim不使用の生PDO) の約 1.8倍の応答時間となっており、RESTfm は PDO の約 5.6倍の応答時間となっています。
 1万件取得時には、Slim は PDO の約 2.3倍の応答時間、RESTfm (注:FM API for PHP を使用)にいたっては、5000 件以降はサーバタイムアウト(30秒)が発生し、計測不能となっています。


CREATE テスト


テスト内容:
 94万レコードを持つテーブルに対して 100件のレコードを PHP のループにより作成。その後、作成した100件のレコードを検索して表示。

備考:
  1. Slim フレームワークは、内部処理をある程度自由にプログラミングできるため、クライアント側から 100回 POST 要求を発行するパターンと、1 回の POST 要求で Slim フレームワーク側で 100 レコードをループ作成する方法で計測を行いました。
  2. RESTfm は、URI のパターンは定型化されていますが、1件レコード作成用の URI と複数のレコード作成を一回のリクエストで実現するバルク処理用の URI が用意されているため、それぞれで計測を行いました。

    1件レコード作成用 RESTfm  URI パターン
    /RESTfm/{datagase}/layout/{layout}

    バルク作成用 RESTfm  URI パターン
    /RESTfm/{database}/bulk/{layout}

    それぞれ、POST メソッドにて json 形式のデータを送信。

結果: PDOの圧勝!ただ、バルク処理なら Slim PDO もいい感じ


100レコード連続作成結果

補足
 クライアント側から 1 回リクエストを発行し、REST 側で 100 回レコード作成したほうが、クライアントから 100 回リクエストを発行し、そのたびに 1 回レコードを作るよりパフォーマンスがよくなるのは当然ですけどね…

DELETE テスト


テスト内容:
 94万レコードを持つテーブルを使用。FM API for PHP と XML では100レコードが対象となるように検索を実行。その後に PHP のループによりレコードを1件ずつ削除。PDO および Slim では DELETE table WHERE ~により、100件を一度に抽出して一括削除。
 RESTfm では、100レコードが対象となるように検索を実行後、バルク処理を使ってレコードを一括削除。

備考:
バルク作成用 RESTfm  URI パターン
/RESTfm/{database}/bulk/{layout}

DELETE メソッドにて json 形式の削除対象データを送信。


結果: PDO 圧勝だが、Slim も RESTfm もバルク処理ならパフォーマンスはよい

100レコード削除結果



UPDATE テスト


テスト内容:
 94万レコードを持つテーブルを使用。FM API for PHP と XML では100レコードが対象となるように検索を実行。その後に PHP のループによりレコードを1件ずつ更新。 PDO および Slim では UPDATE table SET ~ WHERE ~により、100件を一度に抽出して一括更新。 更新後、更新対象となったレコード100件を検索して表示。
 RESTfm では、100レコードが対象となるように検索を実行後、バルク処理を使ってレコードを一括更新。

備考:
バルク更新用 RESTfm  URI パターン
/RESTfm/{database}/bulk/{layout}

注:PUT メソッドにて json 形式の更新データを送信。


結果: PDO圧勝!Slimも奮闘。ただ、RESTfm は連続更新は苦手みたい


100レコード更新結果

結論:


 Web アクセスをする場合、間に何か挟めば余分なトラフィックが発生しますので、低速になるのはあたりまえです。というわけで、これは納得の結果です。

 すべてが自己完結するような Web アプリケーションを一から組めば、パフォーマンスに優れ、かつかゆいところに手が届くものができるかもしれませんが、それなりのコストと時間がかかってしまうことがネックとなります。

 多少パフォーマンスを犠牲にしてしまうことが許容される業務環境で、Web アプリケーションをなるべく短期間で開発する場合は、Slim のような REST フレームワークや、RESTfm のような既成 REST モジュールを採用することは選択肢としてありでしょう。

 しかしながら、どれを採用するにしても、覚えることが増えることには変わりません。

 Slim フレームワークの場合は、GET/POST/PUT/DELETE などの送信メソッドに対応した便利な機能が多数用意されていますが、それらを組み合わせてそれぞれの要求に応答した処理を行うには、担当プログラマが検討してコーディングする必要があります。
 組み方によっては、効率的にデータベースアクセスができるものが仕上がるという柔軟性はあります。

 RESTfm に関しては、操作用の定型 URI があらかじめ提供されているため、開発者がやりたいことさえ把握していれば、比較的高速に Web アプリケーションを完成させられるでしょう。Slim フレームワークに比べれば、覚えることが少ないのは良いと思います。
 ただし、RESTfm は FileMaker API for PHP を経由しますので、FileMaker API for PHP のパフォーマンスに縛られます。さらに、RESTfm 内部でも処理を行いますので、その分の処理コストが上乗せされます。
 つまり、FileMaker API for PHP が不得手な処理を RESTfm 経由で連続してやらせたりすると、パフォーマンスは極端に低下してしまいます。


 Web プログラミングは、長い目で見れば開発コストよりも運用コストの方がものを言います。特に、多数のクライアントを抱える Web サイトや、短時間に何人ものユーザが集中的にアクセスするようなサイトですと、Web サーバのパフォーマンス問題は避けては通れない話です。

 それぞれの特徴やパフォーマンスをある程度比較検討したうえで、業務要件に適したツール選択を行うのが失敗しない Web 開発につながるでしょう。


参考リンク:
Slim フレームワーク (英語)
Slim フレームワーク ユーザガイド (英語)
RESTfm (Goya 社)(英語)
RESTfm オンラインマニュアル (英語)
RESTfmがオープンソースに (Not only FileMaker)


(亀)

2016-07-06

FileMaker でレスポンシブなWebアプリを作る

 FileMaker(以下、FM)のデータベースを FileMaker Pro 以外のクライアント ― ブラウザ、iPhone/iPad、Android ― でも運用する場合、開発環境をFMにすべきか、カスタムWeb にすべきかを考えると思いますが、その際に考慮べき事項を比較表にまとめてみました。

×: terrible,  △: limited,  〇: OK,  ◎: Excellent
 
Go
WebDirect
Custom Web
開発費用
(Devlopment cost)
×
ライセンス費用
(License cost)
×
×
サーバ機費用
(Server machine cost)
×
×
ライセンス体系
(License policy)
×
×
開発の容易さ
(Ease of development)
×
コードの再利用性
(Code reusability)
×
×
開発の柔軟性
(Development flexibility)
×
×
レスポンシブ性
(Responsive Web Design)
×
×
Android等非iOS機との互換性
(Android compatibility)
×
スケーラビリティ
(Scalabilty)
×
他DBへの移植
(Migration to other DBs)


この表からは、
圧倒的ではないか、カスタムWebは

という感じですが、FMの世界では「開発費用」と「開発の容易さ」が他の要素を圧倒し、Go やWebDirect が採用されやすいのではないでしょうか。逆に言えば、他の要素が重要なプロジェクトでは、FMは使用されないのです。
 
 とは言いいつつ、 FM のカスタムWeb という需要は少なからずあり、またスマホ普及に伴う Mobile First な要望もあり、小社としてもまたーりとそれらにお応えしたい、と愚考している次第です。
 そんなわけで、『FMEasy在庫 IWP/WD R1.5』(以下、FMEasy在庫)をバックエンドに使用し、 iPhone/iPad だけではなく Android 等の非iOS デバイスにも対応したレスポンシブな Webアプリのプロトタイプ開発にトライしていきたいと思います。

開発環境

使用データベース: FileMaker(fmp12)
使用ライブラリ: jQuery、jQuery Mobile
対応デバイス: PC、タブレット、スマホ(非iOSデバイスを含む)


開発方針・目標

第1フェイズ


以下の方向で、FMEasy在庫の出庫関連機能をWebアプリ化→プロトタイプを作成する。
  1. マルチデバイス対応、RWD(Responsive Web Design)採用
    たとえばこんな感じで……。

    【PC利用時】

    Windows Chrome


    【タブレットPC利用時:縦置き】

    Nexus 7, Android, Chrome --- Portrait


    【タブレットPC利用時:横置き】

    Nexus 7, Android, Chrome --- Landscape


    【スマートフォン利用時】

    FreeTel Priori 3, Android, Chrome

  2. XML/fx.php/FM API for PHP/PDO(ODBC)の比較テストを適時実施
     →最適なAPIを決める(努力をする)
  3. 出庫伝票照会機能作成
  4. 出庫伝票追加・更新機能作成
  5. 出庫伝票検索機能及び一覧表示機能作成
  6. 出庫伝票PDF出力機能作成

第2フェイズ

  1. 第1フェイズで作成した機能をライブラリ化
  2. ライブラリを他のDBへ対応させる(PDOなら簡単なんじゃないかな)

第3フェイズ

  1. 上記ライブラリを使用することにより、お客様にレスポンシブなシステムをリーズナブルな価格で提供する
    \(^_^)/

 いろいろ書いてますが、予定は未定ですw


本ブログの関連記事について

 本ブログで今後公開予定の RWD によるカスタムWeb関連の記事は、カスタムWeb による開発を検討されているお客様に小社で開発したプロトタイプの仕様やテスト結果をご覧いただき、プロジェクト検討の一助になることを目指しています。


ということで、次回はこのプロトタイプの照会機能についてご紹介したいと思います。

(亀) 

2013-01-24

FileMaker IWP (インスタントWeb公開) で一覧を表示させる方法

 前回の記事で、インスタントWeb(IWP、Instant Web Publishing)では、一度にリスト表示できるレコード件数が 25 件という制限があるため、リストレイアウトは向いていないというような内容に触れました。

 そこで今回は、FX.php と Web ビューアを使うことによって、IWP 上でリスト表示させる実行方針について紹介します。

 FX.php による検索操作方法は、FX.php のマニュアルをご覧ください。
 以下は、それ以外の部分について簡単に説明します。


1. IWPを使ったページのリロードと印刷方法の情報を流用して、FileMaker Pro レイアウト上に Web ビューアを一つ置き、検索実行用の php ファイルを指定します。

 初期状態は、以下のようにパラメータは無しで指定します。




2. 次に、レイアウト上の“検索”ボタンが実行されたら、指定条件(上記の例では[g氏名fr検])に入力された値をパラメータとして Web ビューアに渡して処理を実行するようにスクリプトを作成します。

 以下は、スクリプト内のWeb ビューアの設定で、URL へ移動するオプションを選択し、検索文字列として $str に格納された検索条件を付加しているところです。


 これにより、“検索”ボタン実行時に、上記の URL に切り替わり、指定された php ファイルの中で検索条件を取り出して FX.php で検索を行い、その結果をリスト形式で展開すれば、その結果リストを照会したり、印刷したりすることができるようになります。


3. ここまで設定し、IWP で表示を確認すると、以下のようになります。。
 ページ上のオレンジ色で示された部分が検索条件指定フィールド、ピンク色で示された部分が Web ビューア(IWP 上ではインラインフレーム)となります。



 [氏名]に「川」を入力して、“検索”ボタンを実行し、「川」を氏名に含む人物を一覧させた場合のイメージは、たとえば以下のようになります。

ご覧のように、氏名の一覧表示が可能となります。

データ作成でズボラをかましてしまいましたので、[氏名]と[ふりがな]に同じものが表示されていますが、これらのフィールドはそれぞれ別フィールドとなっております。




 ピンク色で示したインラインフレームを印刷するようにすれば、一覧をプリンタに出力することができます。


以上

(亀澤)


【IWP関連記事】

【弊社のIWP関連製品・サービス】






2013-01-16

FileMaker IWP (インスタントWeb公開) 上で JavaScript を使い、ページのリロードと印刷を行う方法

 FileMaker Pro/FileMaker Pro Advanced, FileMaker Server Advanced で インスタントWeb公開(Instant Web Publishing, 本記事では IWP で統一)を行うと、FileMaker Pro で開発したレイアウトをそのまま Web に公開してデータベースの更新や照会ができるようになります。

 現行で最新バージョンとなっている FileMaker 12 では、FileMaker Pro/FileMaker Pro Advanced の場合は、最大 5 ユーザまで Web での同時使用が可能となっており、これに対し、FileMaker Server Advanced の場合は最大 100 ユーザまで Web での同時使用が可能です。


 ただし、FileMaker Pro 本体に比べると、IWP には仕様上の制限があるため、開発時にそれらの制限を十分に考慮する必要があります。

 IWP でできないことは以下のとおりです。
  1. オブジェクトフィールドへのファイルのアップロード
  2. データのインポート/エクスポート
  3. FileMaker Pro のデータから PDF ファイルや Excel ファイルを作成
  4. FileMaker Pro のレポート閲覧
  5. レイアウト、レポート、スクリプト作成
  6. 警告音、メッセージポップアップ表示
  7. 印刷コマンド実行
 また、この他にもスクリプトトリガ、スクリプトステップ、条件付き書式などでも IWP に対応していない動作がありますので、FileMaker Pro 本体と IWP を併用する形でデータベースを運用する場合は、FileMaker Pro 側と Web 側での動作の違いに気を付けながら開発を進める必要があります。


 さて、今回は、上記に示した IWP の仕様制限のうち、1. オブジェクトフィールドへのファイルのアップロード、および 7. 印刷コマンド実行について対応方針を考えてみることにします。


【オブジェクトフィールドへのファイルのアップロード】

 オブジェクトフィールドそのものへファイルをアップロードする代わりに、php を使って Web サーバ上にファイルをアップロードし、そのファイルへのリンクを FX.php を使って FileMaker Pro データベースに書き込みます。

 FileMaker Pro 側の設定は、レイアウト上に以下のような Web ビューアを配置し、アップロード処理および FX.php 書込み操作を記述した php ファイルを指定します。



 php ファイルは Web サーバ上に配置してください。また、[Web ビューア内容とのインタラクションを許可] チェックボックスには必ずチェックを入れておきます。

 そのあと、IWP でデータベースを開くと、たとえば以下のようなページが表示されます。


 イメージとしては、ファイルアップロード後は、矢印が示すフィールド [FileURL] にそのファイルへのリンクを表示させるようにしたいわけですが、FX,php はバックグランドで操作されますので、ここは動的には変化しません。

 これを、JavaScript コマンドをページアップロード後に呼び出されるように組むことで、ページをリロードさせて反映させようというわけです。

 画面上に、「この部分が Parent」と表記しておりますが、Web ビューア(ピンク色)を自分自身とした場合、外のエリア(紫)が親 (parent) となりますので、JavaScript では parent に向けて処理をするようにします。



 parent.location.reload();


リロード後のイメージ



 FX.php を使った FileMaker Pro データベースへのデータ書込の話題は、以下の記事群をご覧ください。

【印刷コマンド実行】

 FileMaker Pro の印刷コマンドは、IWP では実行できません。
これでは、顧客一覧、見積書、請求書などの帳票を IWP で印刷したいときに不具合があります。

 この対策として、上記のファイルアップロード例と同じ要領で Web ビューアを配置し、印刷ボタンを配置したページを指定します。





 ファイルには、フォームの 印刷ボタンをクリックすると、JavaScript で以下のような関数を呼び出し、 parent ページを印刷するようにします。



function reportprint()
{
parent.focus();
parent.print();

}



 これにより、Web ブラウザの印刷ダイアログが表示されます。



 上図のように、印刷ボタンの部分もページとして印刷されてしまいますので、Web ビューアを配置する場所は 2 ページ目の先頭あたりにくるようにし、印刷時は 1 ページ目を選択するようにすると都合が良いでしょう。

以上

(亀澤)



【IWP関連記事】

【弊社のIWP関連製品・サービス】




2009-12-24

ODBC ドライバ DataDirect SequeLink を使って FileMaker Pro にアクセスしたときの問題点

 FileMaker Pro 対応の ODBC ドライバは DataDirect SequeLink となっていますが、今回はこのドライバを使って FileMaker Pro にアクセスした場合の問題点について書いていきます。

備考:
1. php から ODBC 接続する方法として PDO を使っています。PDO を有効にするには、php.ini の以下の行を追加し、Web サーバを再起動しておく必要があります。

  extension=php_pdo.dll
  extension=php_pdo_odbc.dll

2. PDO ではシステム DSN を指定する必要があるため、SequeLink ドライバを指定して適当な名前のシステム DSN を事前に登録しておく必要があります。
php ソースの記述例は次のとおりです。
//$dbh = new PDO ("odbc:DSN=データソース名;UID=ユーザー名;PWD=パスワード");

try {
     $pdo = new PDO("odbc:dsn=test;host=127.0.0.1", "Admin", "somePWD");
 $sql = "select * from testdb where recno=1";
 $rec = $pdo->query($sql);
               //レコードセットから特定の列を取りだすときは bindColum を使用
 $rec->bindColumn("ID", $ID);
     $rec->fetch();

 echo $ID;

} catch(PDOException $e){
    var_dump($e->getMessage());
}

 上記のような php スクプトを連続操作を実行すると、ODBC ドライバの動作が不安定になることがわかりました。
 
 返されたエラーは次のとおりです。

1) Session refused by service, connection closed.

 このエラーはサーバプロセスが接続要求を受理できなかったときに発生します。
 このエラー発生後、FileMaker Pro ファイルを閉じたり、一度 Windows をログオフしたりしたのですが、それでも現象が改善せず、マシンを再起動することによってようやく復旧しました。

2) Maximum number of sessions reached.

 このエラーは設定済のアクティブセッション数を超過した場合に発生し、その後のクライアント接続要求は拒否されてしまうようです。
 このエラー発生後、ファイルメーカー Pro ファイルを一度閉じることによって復旧しました。

 以下のサイトにエラーコードの一覧が用意されていますので、その他のエラー内容と原因も参照できます。
SequeLink のエラーメッセージ一覧

 ただ、これだけ動作が不安定だと、ODBC 接続実験としては面白いですが、とても運用レベルには耐えられないという印象です。また、CD に付属の SequeLink は 64bit 対応ではないため、別途購入する必要がある(しかも金額不明)というのも利用者を遠ざける原因になってしまうかもしれません。
SequeLink® 5.5 Client for ODBC 製品紹介ページ


ODBC 接続に関する続きの記事はこちら:
API 別/サーバ別FileMaker カスタムWebパフォーマンス比較

2009-12-22

IIS の php から FileMaker Pro ファイルをオープンするのに四苦八苦

 Windows Server 2003 の IIS で php ファイルから FileMaker Pro ファイルを開くという操作を試しているのですが、どうもうまくいきません。

【目標】
 IIS で公開されている test.php というファイルからサーバディスクに配置した dbopen.vbs を起動し、vbs から FileMaker Pro ファイル test.fp7 を開く。

dbopen.vbs の中身は次のとおりです。ここでは、FileMaker Pro アプリケーションのインスタンスを作成し、それからローカルコンピュータの test.fp7 を開いて showMSG というスクリプトを実行するという流れになっています。このファイルを作って単独で実行すると正常に動作することは確認済みです。


Dim FMApp
Dim FMDocs, myOpenFile

Set FMApp = CreateObject("FMPRO.Application")
FMApp.Visible = True
Set FMDocs = FMApp.Documents
Set myOpenFile = FMDocs.Open("c:\hoge\test.fp7" ,"Admin","somePwd")
myOpenFile.DoFMScript ("showMSG")

Set myOpenFile = Nothing
Set FMDocs = Nothing
Set FMApp = Nothing



【試した操作】
1. IIS 経由で php を実行すると、その実行者は IUSR もしくは NETWORK SERVICE になるため、実行権限を必要なファイル群に与える必要があります。dbopen.vbs は WScript.exe から起動させるため、System32 ディレクトリの中にある WScript.exe に IUSR の実行権限を付与しました。
2. これだと dbopen.vbs で CreateObject を使って FileMaker のインスタンスを作成する時に書き込みエラーが発生するため、IUSR ではなく、ログイン中のユーザアカウントで実行できるよう、PsTools の psexec.exe を使って vbs のみログインユーザ権限で実行するようにしました。

PsTools の紹介とダウンロードはこちら

以下のように test.php のソースに指定しました。


$retval = `C:\hoge\PsTools\psexec.exe -u Administrator -p somePassword1234 -d WScript.exe C:\hoge\dbopen.vbs`;


備考:
1. psexec.exe に IUSR アカウントを割り当て、実行権限を付与しておく必要があります。
2. ``で囲ったコマンドラインがシェルコマンドとして解釈されるため、ここでは exec()関数を使用していません。
3. -d はスクリプトの終了を待たずに psexec を終了させるためのスイッチです(異常終了時のプロセス残留回避)。
4. vbs ファイルは単体では認識されないため、WScript.exe を明示的に指定する必要があります。

 このように設定してから Web ブラウザより test.php を実行すると、ブラウザが読み込み中状態となってしまいます。そこでタスクマネージャを起動して確認してみると、実行者 NETWORK SERVICE のプロセスとして psexec.exe が残っていることがわかりました。

【現象】
 psexec の実行ユーザが NETWORK SERVICE になっていると、デスクトップにそのアプリケーションが表示されず、バックグランドプロセスとして残留してしまいます。
 二台の Windows Server 2003 環境で実行したところ、一台は test.fp7 がデスクトップに表示され、showMSG スクリプトまで表示されたのですが、もう一台のマシンがどうもうまくいきません。

 psexec に NETWORK SERVICE を割り当てて実行権限を付与したり、IIS マネージャのアプリケーションプールのセキュリティアカウントを NETWORK SERVICE 以外に設定するなど試したのですが、やはりプロセスがバックグランドで残留したままの状態となります。


 IIS で運用中の php スクリプトからシェルコマンドでアプリケーションを起動し、そのアプリケーションをデスクトップに表示させる方法をご存じの方は、情報をお待ちしております。

2008-11-25

64 ビット版 Windows Server 2008 の IIS7 で php が動くようにする

64 ビット版の Windows Server 2008 に 32 ビット版のみ提供されている php5 をインストールするのには、ちょっとコツがいることがわかりました。

従来の方法ではまず動かない

従来どおりにインストールを行い、phpinfo() を表示させようとすると、エラー 503 が表示されました。ISAPI フィルタもハンドラマッピングも php 向けに指定したにもかかわらずエラーが表示されるので、ネットで調べてみると、DefaultApplicationPool の「32ビットアプリケーションの有効化」を[True]にすると良いとあったので、True にしてみたところ、程なくして DefaultApplicationPool が停止してしまいました。

そのときに報告されたものがこのイベントエラーです。

イベントID:2280
モジュール DLL C:\Windows\system32\RpcProxy\RpcProxy.dll を読み込めませんでした。このデータはエラーです。

暫く試行錯誤を繰り返していたのですが、この環境では ISAPI フィルタによる設定は無理そうだということがわかってきたので、途中で FastCGI を使う方法に切り替えました。

FastCGI で PHP を動かす
IIS 7 のインストールオプションで、CGI を選択して IIS7 をインストールすることによって、php-cgi.exe を呼び出して実行させることが可能です。

手順を説明します。
1. php5 の最新版をダウンロードして、適当なところに配置する(例:c:\php)。
php5 はここからダウンロードできます。
2. php.ini-recommended ファイルをコピーして php.ini というファイルに名称変更し、これをメモ帳などで開いて次に該当する行を修正して保存する。
(先頭のセミコロンを外して修正。該当するものがない場合は行を追加。)

fastcgi.impersonate = 1
cgi.fix_pathinfo=1
cgi.force_redirect = 0
open_basedir ="c:\inetpub\wwwroot"
extension_dir = "./ext"

3. コントロールパネルより「システム」をダブルクリックして、左ペインのメニューから「システムの詳細設定」をクリック。“環境変数”ボタンをクリックして システム環境変数の一覧に表示される path 変数に php へのパスを追加。
(c:\php; を追加すれば良いです。)

4. インターネット インフォメーション サービス(IIS) マネージャーを開き、ハンドラマッピングから「モジュールマップの追加」を選択し、以下の情報を追加。

要求パス:*.php
モジュール: FastCgiModule
実行可能ファイル(オプション): C:\php\php-cgi.exe
名前:PHP

OK を押して保存します。

5. IIS を再起動して、php テストページを表示させる。
以下のファイルを作って phpinfo(); を入れた php ファイルを作成してブラウザで表示確認。

php の情報ページが表示されれば成功です。

今回は以下のサイトを参考にしました。
Using FastCGI to Host PHP Applications on IIS 7.0

2008-07-11

【応用その4】FX.php を使ってアンケートフォームを MySQL 対応にしてみる

 サンプルデータベースと PHP ソースコードはこちらからダウンロードできます。(本アーカイブは、不定期に差し替えが行われる可能性があります。あらかじめご了承ください。)

 *FileMaker API for PHP を使ったアンケートフォーム作成をお読みになっていない方は、先にこちらをご覧ください。

 FX.php は MySQL データベースへの接続にも対応しているため、アンケートフォーム作成の延長として、今回は既存のコードに MySQL データベースへのデータ書込機能を実装してみることにします。

 * 操作にあたっては、MySQL Server がインストールされていることが前提となりますので、予め MySQL Server のインストールと、文字化け対策のためにデフォルト文字セット(utf8)が有効になるように設定しておいてください。

 まずは、データベースを準備します。付属の create_table.php の $rootPass に MySQL の root パスワードを設定して同スクリプトを保存し、local の web サーバで実行してみてください。Comment データベース、cgi テーブル、webuser とそのパスワードが生成されます。作成するテーブル列は、create_table.php を参照してください。
 
 以下、次の順に Comment.php へコードを追加していきます。
1.使用するデータベース種別を MySQL にします。
データベース種別

2.接続先の MySQL サーバポート番号を指定します。デフォルトは 3306 です。
MySQL ポート番号

3. あとは既存の FX.php 接続とほぼ同じですが、最後のデータ書き込みのところで、FMNew() の代わりに PerformSQLQuery() 関数を使います。引数は第一パラメータに SQL クエリ文を指定し、残りはデフォルト値を指定します。

 PerformSQLQuery($query,true,false,'object');

 この部分をコードで表したものが次のとおりです。(列名)と値を使って $query SQL クエリ文をセットし、次の PerformSQLQuery で指定して実行します。
query

 FX.php & MySQL の組み合わせで実行可能になっているコードを Comment_mysql.php に用意してありますので、併せて確認してみてください。

参考リンク:
MySQL オフィシャルサイト

2008-07-09

【応用その3】アンケートフォームにセッションを追加してみる(リロード対策)

 サンプルデータベースと PHP ソースコードはこちらからダウンロードできます。(本アーカイブは、不定期に差し替えが行われる可能性があります。あらかじめご了承ください。)

 *FileMaker API for PHP を使ったアンケートフォーム作成をお読みになっていない方は、先にこちらをご覧ください。

 PHP 経由で FileMaker データベースにデータ書込を行う手法として、簡易アンケートフォームの作り方をベースに説明を進めてきました。
 すでにお気付きの方もいらっしゃるとは思いますが、実はこのままでは実際の運用には不向きな部分があります。

 それは、最後のお礼ページです。
 このページが表示される直前に FileMaker データベースへのデータ書込とメール送信を同時に行うわけですが、Web ブラウザのリロードボタンを押してページをロードするたびに同処理が実行されてしまうため、ゴミデータとゴミメールが増えてしまう可能性があります。
 実際問題として、お礼のページをリロードしてしまうユーザも結構多かったりするので、リロード操作が行われてもデータ送信、メール送信は一回だけ実行するような仕組みが必要となります。

 これを効率よく処理する方法として、PHP のセッションをここで組み込んでみることにします。
 PHP のセッションはスーパーグローバル配列と呼ばれ、読み込まれたページにかかわらず値を保持しておくことができるものです。FileMaker のグローバル変数に共通している部分もあるので、そう捉えると理解しやすいと思います。

 ユーザによるページリロード対策は、データ書込とメール送信が行われたかどうかを判断し、それが No なら書込・メール送信を許可、Yes なら不可にすればよいわけです。これをフラグを使って表現するとさらに明確になります。仮にフラグ名 を done フラグとしましょう。

 未書込の状態 --- done フラグはオフ (FALSE、偽)
 書込済の状態 --- done フラグはオン (TRUE、真)

 done フラグがオフ(FALSE)のときに書き込みを実行し、その操作が終わったら done フラグをオン(TRUE) にします。

 この値をセッションに入れておくことで、ページが何度リロードされても呼び出しはセッションから行うため、一度オンになったフラグはオフになることはありません。

 この処理を PHP で記述すると次のようになります。
1. セッションの開始と有効期限を決めます。
セッション開始
 セッションの有効期限のデフォルトは 180 分ですが、簡易アンケートで特に詳細な確認が必要なわけではないため、ここでは有効期限を 5 分にしています。5 分経過するとセッションは破棄されて無効となり、その後にページをリロードすると、白紙のページが表示されるようになります。
 session_start() 関数でセッションを開始するわけですが、この関数は、セッションが存在しない場合は、新たにセッションを作成します。これに対し、セッションがすでに存在している場合はそのセッションを再度呼び出します。つまり、このアンケートフォームで言えば、最初にアンケート入力フォームのロードを行った時点でセッションの作成を行い、それ以降、ページがロードされたり次のステップに進むたびに session_start() 関数から同一のセッションを呼び出すわけです。

2. 次に、done フラグの初期化を行います。
セッション初期化
 初回ページロード時に一度だけ done フラグに FALSE (データベースへの書込とメール送信が行われていない状態)をセットします。

3. お礼のページを出すときに、done フラグが FALSE であることを確認し、それに該当すれば FileMaker データベースへのデータ書込とメール送信を行い、その後に done フラグに TRUE (データベースへの書込とメール送信が完了した状態)をセットします。
 以下、赤線を引いた部分に注目してください(コードが長いため、中略を入れてあります)。
done フラグのセット

 これでセッションの実装が終わりました。サンプルコードを使って動作を確認してみてください。

2008-07-04

【応用その2】FX.php を使ったアンケートフォーム作成 --- 従来のファイルメーカー Pro データベースで Web アプリケーション作成

 サンプルデータベースと PHP ソースコードはこちらからダウンロードできます。(本アーカイブは、不定期に差し替えが行われる可能性があります。あらかじめご了承ください。)

 *FileMaker API for PHP を使ったアンケートフォーム作成をお読みになっていない方は、先にこちらをご覧ください。
 
 さて前回の FX.php 解説に引き続き、今回は FX.php を使って従来の FileMaker データベースにアクセスする方法について触れてみることにします。今回もまた、今まで使ってきたアンケートフォームにちょっと修正を入れるだけです。アンケートフォーム作成のおさらいが必要な方は、こちらを先にご覧ください。

 FileMaker API for PHP を利用するためには、FileMaker Pro 9 と FileMaker Server 9 がインストールされていることが条件となるため、従来に比べるとコスト的に敷居が高くなってきています。安定したデータサーバ運用を目指すのなら、もちろんこれらを導入するのが確実ですが、FileMaker Pro 5.x/6 で機能的に十分に満足している方には、ちょっと手が出にくいパッケージであることも確かでしょう。

 そこで、FX.php と FileMaker Pro 5.x/6 の Web コンパニオンプラグインを組み合わせてもデータベースへの書き込みを実現できるため、既存のシステムをそのまま Web 公開データベースとして活かすことも可能となります。
 ただし、通常版は 10 アクセスユーザ数(10 IP アドレス)という制限が伴うため、現実的な運用にあたっては FileMaker Pro 5.x/6 Unlimited が必要になることは注記しておきたいと思います。

 それでは実際に既存のサンプルコードを修正していくことにしましょう。
 処理は前回の FX.php 接続とほぼ同じですが、今回はそれに加え、文字コードの変換が必要となります。
 FileMaker Pro 9 では内部コードを UTF-8 で処理しているため、ソースが UTF-8 で記述されていれば問題はなかったのですが、FileMaker Pro 5.x/6 では内部コードを Shift-JIS で扱うため、このままデータを送るとエラーが起こったり、文字化けが発生してしまいます。

 そこで、今までの処理に文字コード処理を追加します。

  1. FX を使用することを宣言する(FX インスタンスを作成する)。

  2. 使用するデータベース名とレイアウト名を指定する。

  3. 使用するユーザ名とパスワードを指定する。

  4. データ送信時の文字コードを Shift-JIS に変換する。

  5. 追加するフィールドと、そのデータを指定する。

  6. レコード追加を実行する。



 上記を FX.php の記述規則に従って置き換えると、次のようになります。

 赤線を引いた部分と、赤で囲った部分が前回と異なってはいますが、その他はすべて同じです。
 指定の通り、FX インスタンス作成時に、使用するデータソース(データベース)が FileMaker Pro5.x/6 であることを知らせます。
 そして、データ送信前に文字コードセットを UTF-8 から Shift-JIS(SJIS) に置き換えます。

 ただし、FMP7/8/8.5/9 に対してこの文字コード変換を行うとデータ書き込みに失敗してしまうため、必要に応じて、データソースが FMPro5/6 のときだけ文字コード変換を行うという条件を追加する必要があります。
 この条件を追加するとこのようになります。

 変数 $databaseType には、コードの最初の方で予め "FMPro9" もしくは "FMPro5/6" のいずれかを設定しておきます。こうしておくことによって、使用するデータソースに応じて処理を切り替えられるので便利です。
 ソースの詳細は、サンプルコードをご覧になってみてください。

 先に PHP ソースについて解説しましたが、最後に FileMaker Pro 5.x/6 データベースファイルの作成と設定方法について説明します。

1. データベースファイルを作成します。FileMaker Pro 5.x/6 を起動し、Comment.fp5 というファイルを作成し、以下のフィールドを作成します。

 [RecID]、[作成日]、[作成アカウント]、[修正日]、[修正アカウント]は管理用のフィールドですが、作成しておくと便利でしょう。

2. レイアウト名を cgi に変更します。
3. 「アプリケーション環境設定」ダイアログを出し、プラグイン一覧より、Web コンパニオンにチェックを付けて「設定」ダイアログを開きます。

 セキュリティに「ファイルメーカー Pro アクセス権」を指定し、TCP/IP ポート番号に 80、もしくは 591 を指定します。

4. ファイルの共有設定で、以下のようにチェックを付けることによって Web コンパニオンを公開します。


5. パスワードを指定します。図のように、web というパスワードを作成し、web で公開させる最低限のアクセス権を決めます。

 この他にフルアクセスを許可するパスワードが必要となりますので、ここでは Admin を作成してあります。

 以上で準備が整いました。
 FMPro5/6 用の設定を施した comment_fp5.php というファイルをサンプルに用意してありますので、参照してみてください。

参考: FX.php vs FileMaker API Benchmarks Discussion(英文)

2008-07-03

【応用その1】FX.php を使ったアンケートフォーム作成

 本記事は2008年に FileMaker 9 の環境下で執筆されました。2016年11月現在、FileMaker の最新バージョンは 15 となっていますが、15 においても本記事の内容はなお有効と思われます。
 一方Ver 15 では WebDirect と呼ばれる 機能があり、これにより PHP などで Webプログラミングを行うことなく、 FileMaker デスクトップアプリとほぼ同様の操作がブラウザ上でも可能となります。WebDirect は開発が非常に楽になる半面、ライセンス費用やブラウザとの互換性等に問題があります。 したがって、高速開発性(RAD)を重視し、ブラウザ互換性をある程度無視できる環境では WebDirect は FX.php の代替となる可能性があります。

 参考: アンケートシステム・プロトタイプ


 *FileMaker API for PHP を使ったアンケートフォーム作成をお読みになっていない方は、先にこちらをご覧ください。

 さて、前回まで 4 回にわたって FileMaker API for PHP によるアンケートフォームの作成方法を解説してきましたが、今回はさらに FX.php による FileMaker データベースアクセス機能も実装してみることにします。

 FX.phpiViking.org によって無償で提供されている FileMaker アクセスクラス群で、FileMaker Pro 5~ 9 に幅広く対応しているため、FileMaker API for PHP が実現できない環境のユーザでも FX.php を使うことによって php からのアクセスが可能となります。

 インストール方法も簡単で、ダウンロードして解凍した FX フォルダを Web サーバの適当な場所に配置するだけです。

 それでは実際にやってみましょう。
 Comment.fp7 を開き、「アカウントとアクセス権の管理」ダイアログを出し、そこからすでに登録済の Webuser を選択して「アクセス権セット...」を選択して以下のダイアログを開きます。

 FX.php は xml によるデータアクセスを行いますので、反転部分のように、「XML Web 公開でのアクセス- FMS のみ(fmxml)」にチェックを付けて保存します。

 これで FileMaker の FX.php 向け Web 公開の準備が整いました。

 さて、次は FX.php 向けのコードを追加していきます。
 まずは、コードの最初の方で FX.php をロードします。今ある Comment.php から FX.php が辿れるように設定してください。

 require_once '../../FX/FX.php';

 そしていつものように、日本語で手順を考えてみます。

  1. FX を使用することを宣言する(FX インスタンスを作成する)。

  2. 使用するデータベース名とレイアウト名を指定する。

  3. 使用するユーザ名とパスワードを指定する。

  4. 追加するフィールドと、そのデータを指定する。

  5. レコード追加を実行する。

 
 こうして見てみると、前回のデータベース書込手順とほとんど変わらないことがわかりますね。
 あとは上記の内容を FX.php 向けに書き換えていくだけです。

 一行目のデータベース接続にサーバ名、ポート番号、データソース名(FMpro9)を明示的に指定する必要がありますが、その他メソッド名に差異はあるものの、前回の FileMaker API for PHP のコードとさほど形式が変わらないことがおわかりいただけるでしょう。

 サンプルコードの方に FX.php と FileMaker API for PHP の切り替え操作も盛り込んでありますので、併せて確認してみてください。


※サンプルコード
サンプルデータベースと PHP ソースコードはこちらからダウンロードできます。(本アーカイブは、不定期に差し替えが行われる可能性があります。あらかじめご了承ください。)