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

2022-01-24

正月休み明け、仮想マシン上の FileMaker Server 5.5 バックアップが失敗していた

 正月休み明け、Windows 2012 Hyper-V上のWindows 2008 で FileMaker Server 5.5(FMS) を運用している取引先から、「バックアップが失敗している」との連絡がありました。
仮想マシンの構成は以下の通りです。

■Windows 2008仮想マシン(VM)構成
[C:内臓VHD]
[E:内臓VHD]←FMSを実行
[F:外付VHD]←FMSのバックアップ先

 上記Fドライブの特定ディレクトリはReadできるのに、他のディレクトリはReadできず、Writeは全くできないという状況で、図の「I/Oデバイスエラーが発生したため、要求を実行できませんでした。」が出ます。


 そこでFドライブ(外付ディスク)にハード的問題があると思い、このドライブを取り外して別のPCに取り付けてチェックすると、普通にマウントできて、Read/Writeできました。


 気を取り直して、Hyper-V機に同じ外付けドライブを戻してもらい、Hyper-Vマネージャーで問題のVHDを一度取り外して、再度アタッチ。 これによりRead/Writeも、FMSバックアップも実行できるようになりました。

“削除”ボタンで問題のVHDを取り外し、“参照”ボタンで同VHDを再度アタッチ


 休みの前後、取引先でHyper-V機を落とすとき、外付けHDDの電源On/Offの順番を間違ったのが原因かもしれません。

 マシンを落とすときは外付けHDDを最後にOFF、起動するときは外付HDDを最初にON。


(NuckyT)

2021-07-24

まだまだいける FileMaker 5.5/6 ― レガシーFileMaker の延命 2021 ―

 FileMaker 5.5/6 の発売は今から約20年前ですが、巷ではまだまだ使用している会社も多いです。 今回は レガシーFileMaker のサーバとクライアントのOSの互換性に関して、当社の運用実績、検証、推測を基にレポートします。また、レガシーの修正や改変の際に必要となる分析方法についても記します。

※Windows 11 は 64bit マシン専用OSですが、通常は Windows 32bit アプリケーション も運用可能です。 アプリケーションによっては障害が発生する可能性がありますが、32bit アプリである FileMaker Pro 5.5/6 も Windows 11 にインストールし、起動することができます。 2021年10月現在、トラブル無く運用できています。 今後、運用時間を延ばし、本稿にて状況をレポートする予定です。


FileMaker の最強3トップ

注:
  • レガシーFileMakerのOSとの互換性/延命に関するご意見等は、コメント欄にご投稿ください。
  • 本稿に基づき読者がシステムを構築された場合に問題や障害等が発生しても、当社では責任を負いません

FileMaker Server 5.5とWindows OSとの互換性 

 下表はFileMaker Server 5.5(以下、FMS)と Windows OS との互換性を示します。

Windows  OS 互換性 備考
2000 Server FileMaker社による動作保証
2003  当社等の運用実績に基づく[1]
2008 当社等の運用実績に基づく[1]
2012 当社等の運用実績に基づく[2]
2016 当社検証に基づく、非推奨[3]
2019 ? 未検証[4]
     
2000 Pro FileMaker社による動作保証
XP ? 未検証[5]
7 ? 未検証[5]
10 × 当社検証に基づく、非推奨[6]
[1]:「当社他の運用実績」は、当社及び当社顧客の運用実績有
[2]: 運用可。但、FMS管理コンソールでクラッシュするケースあり、以下の「仮想マシン上で FMSを運用する場合」参照
[3]: DB公開はできるがFMS管理コンソールでクラッシュする、非推奨
[4]: 2019はWindows10系である為、公開はできるがFMS管理コンソールでクラッシュすると推定、非推奨
[5]: System7はWindows 2000 Pro(公式サポートOS)に近いため運用できる可能性有、検証の価値有
[6]: FMS管理コンソールでDBを公開できる時とできない時があり非常に不安定、非推奨

FileMaker Pro 5.5/6 とWindows OSの互換性

 下表はFileMaker Pro 5.5/6(以下、FMP)と Windows OS との互換性を示します。
表中、サーバOSが含まれていますが、これはリモートデスクトップサービスを使用し、マルチユーザライセンスのFMPを複数ユーザで使用することを想定しています。

Windows  OS 互換性 備考
2000 Pro/Server FileMaker社による動作保証
2003  当社等の運用実績に基づく[1]
2008 当社等の運用実績に基づく[1]
2012 当社等の運用実績に基づく[1]
2016 当社等の運用実績に基づく[1]
2019 未検証[2]
     
XP FileMaker社による動作保証
7 当社等の運用実績に基づく[1]
10 当社等の運用実績に基づく[1]
11 2021年10月現在テスト中。経過は順調[3]
[1]:「当社他の運用実績」は、当社及び当社顧客の運用実績有
[2]: 2019はWindows10系である為、運用可能と推定
[3]: 2021年10月現在Hyper-VにWindows11を搭載しテスト中。適時本ページで経過をレポート予定。

新設するサーバ機とOSとの互換性(仮想マシン不使用)

 サーバ機の老朽化によるマシン本体のリプレースについて考えます。この時、仮想マシンを使用せずに、新サーバ(物理マシン)に Windows 2000/2003/2008/2012 をインストールし、このOS上で FMS を運用しようとする場合、物理マシンが各OSをサポートしているか否かはチェックポイントとなります。経験上、メーカーが公式対応していないOSであっても動作する可能性は高いですが、メーカーが公式対応を謳っているマシンであれば、それに越したことはありません。

Dellサーバ機のOS互換性

HPサーバ機のサーバOS互換性

仮想マシン上で FMSを運用する場合

次に仮想サーバ上での FMSの運用について考えます。この方法では仮想マシンにWindows 2000/2003/2008/2012 をインストールして、FMS を運用します。
 既に仮想環境を構築済みであれば、マシン調達に伴う金銭的コストを負わなくても済むので、担当者の心理的負担は少ないです(経験者談)。逆にFMSだけのために仮想環境を新たに導入するとなると、コスト大の上、担当の心理的負担も大となります(同談)。

 注意点が一つあります。当方で遭遇した現象ですが、Dell PowerEdge T105 のハイパーバイザ上の仮想マシン(Windows Server 2012R2 )では、 FMS5.5 が問題なく動作していましたが、PowerEdge R330 のハイパーバイザ上の仮想マシン(Windows Server 2012R2 )に FMS5.5 を新規インストールした後にFMS の コンソールで「ファイルメーカー Server」を右クリックして「プロパティ」を選択するとコンソールがクラッシュする、ということがありました。 この時、正常稼働している PowerEdge T105 上 の仮想ディスク(VHD)を丸ごと PowerEdge R330 にコピーして仮想マシンを再構成したところ、コンソールで「プロパティ」を選択することができました。
 このように、一見同じに見えるシステム環境であっれも、FMSで障害が発生することがある、と言う事です。
 
 当社ではFileMakerレガシーの延命を多くうけたまわっており、現在までほぼ成功裡に終わっていますが、リスクがあることをユーザに十分理解頂き、業務を進行することがやはり大切です。
 もっとも、最新のテクノロジーでシステムを構築する!、と言っても、既存システムとの互換性、開発失敗リスク、最新テクノロジー故の不安定性・未成熟性といったリスクもあります。また、ベンダーが勝手に契約条件を変更する近年のサブスクリプションというビジネスモデルも大きなリスクです。

 5G、AI、機械学習、IoT/M2M、DXを行わない企業に未来はない!などと、漠然としたIT用語や根拠不明の言説が巷に溢れる中、現行仕様で満足している、或いは現行仕様を修正・拡張しながら利用できれば十分というシステムも普通にあるわけで、であればレガシーシステムの延命は十分考慮に値すると思います。


Windows Server の Windows Update 

 Windows update を行わなければ FileMaker Server 5.5(FMS) が動作しないということはありませんが、Windows 2008/2012 などの古いOSを運用する際に重要なことなので、本項にて触れておきます。

 通常、新たにサーバ機を購入したり、サーバOSをインストールした際は、Windows update を行い、OS を最新の状態にします。これは以下の理由によります。
  1. セキュリティ上の要請
  2. 運用開始後の Update のリスクを低減する
    運用開始後に Windows update を実施すると、何らかの障害が発生し、運用中のソフトウェアが動作しなくなる可能性があります。できるだけ導入・テストの段階で利用可能な全ての update を当て、運用後のダウンタイムを減らしましょう。
  3. Windows Server がある程度最新の状態でないと動作しないプログラムがある
    ある種のアプリケーションをインストールする際、一定のバージョン以上の Internet Explorer や .NET Framework を要求され、インストールを実行できない、ということはままあります。この一定のバージョンに辿り着くまで、何回か Windows update を行う必要があることがあります。導入時に最新のUpdateを当てておけば、運用後にこれらの作業を低減することができます。
  4. Windows Update 自体が動作しなくなることがある
    後述のように Windows Update エージェントが古いと Update 自体ができないことがあります。

Windows update ができない時 

 FileMaker Server 5.5 と互換性の高い Windows Server 2008/2012 ですが、これらのOS のインストール直後に Windows update を実行すると、 0x80072efe というエラーが発生して、Windows Update が完了しないことがあります。
 このエラーは Windows Update エージェント自体に問題あり、Windows Update エージェントのアップデートプログラムを単独でダウンロードし、これを実行することにより解決できます。

 ※ご利用の Windows Server のバージョンに適合したものをダウンロード後、インストールしてください。

 この他にも、いくつかのアップデートを実行できないこともあります。その場合は Windows Update の順番を変えてみたり、個別にアップデートプログラムをダウンロードしたりして対応する必要が出てきます。

 以上、運用開始後のダウンタイムを低減するために、導入段階で Windows Update をできるだけ進め、OSを最新の状態にしておきましょう。

Windows Server のライフサイクル

 参考までに、Windows Server のライフサイクルの表(2021/07/26時点)を挙げておきます。
Windows  OS サポート終了日 延長サポート終了日
Windows Server 2003 2010/07/13 2015/07/14
Windows Server 2003R2 2010/07/13 2015/07/14
Windows Server 2008 2015/01/13 2020/01/14
Windows Server 2008 R2 2015/01/13 2020/01/14
Windows Server 2012 2018/10/09 2023/10/10
Windows Server 2012 R2 2018/10/09 2023/10/10
Windows Server 2016 2022/01/11 2027/01/12
Windows Server 2019 2024/01/09 2029/01/09

実行速度とテストについて

 物理マシン或いは仮想マシンを問わず、構築した新環境に於ける実行速度が旧環境のそれに比べて明らかに遅い場合、問題となります。 旧環境から新環境への移行業務の早い段階で、必要十分な実行速度が得られているかをユーザに判断してもらうべきです。 業務終了間際に実行速度が遅すぎると判明すると、行った作業が全て無駄になる可能性があります。

 当社では実行速度の可否を判断する際、約12万件の郵便番号情報が入った郵便番号.fp5 のファイルをFMSで公開し、FMPからアクセスして住所フィールド(都道府県+市区町村+町域を1つに結合したフィールド)のソートを行います。 この12万レコードのソートが30~40秒程度で終了する、というのを一応の合格基準としています。
注:
これは未ソートの状態で新たににソートした場合の基準です。一旦ソートされた状態で再度ソートすると、ソート時間が30~40%改善するとがあります。このため、ソートテストは常にソートされていない状態で実行してください。

 ユーザは実行速度には敏感ですので、旧環境と新環境で郵便番号をソートのデモを行うのも良い考えだと思います。

 当方の経験上、コア数やメモリも増やしても、実行速度はほとんど改善されません。ただ、ネットワーク(NIC)の設定を変更することにより、劇的に改善することがあります。これについては、こちらを参照してください。

レガシーFileMaker の分析

 当社では第三者が開発したレガシーFileMakerの保守・開発を引き受けていますが、そのシステムを拝見するとデータベースの正規化が無視されていたり、同種のスクリプトを延々と繰り返していたり(コードの再利用という考えがない)、逆にスクリプトが意味不明に細かく分割されていたり、セキュリティが考慮されていなかったりと、掟破りのシステムを目にすることが少なくありません。

 掟破りシステムに障害があると、当社担当が分析・修正するとなるとなります。熟練開発者が書いたスクリプトでも、その開発者の支援無しに第三者がデバッグするのは元々困難な作業です。 これが非熟練者により開発されたものとなると、通常の十倍からそれ以上の工数を要する大変な作業となります。 このような状況では、スクラッチ開発(一から再開発)お勧めしたいのですが、膨れ上がった掟破りシステムをスクラッチ開発するには、多くの時間と費用を要するため、当社担当がデバッグすることになります。

 さて、このような悲惨な状況下での頼みの綱がデバッガや分析ツールですが、旧FileMaker にも FileMaker Developer 5.5/6 (以下、Developer)という製品があり、これによりデバッグや分析を行うことができます。
 Developerを使うと、下図のようなデータベースデザインレポート(実体は FileMakerのファイル)を作成することができます。 このレポートはシステムの開発量(フィールド、レイアウト、スクリプト等の数)を知るのに有用です。



 一方、検索機能が不十分、というか無いに等しいので、保守や障害対応で特定のオブジェクトの検索を行うには、データベースデザインレポートは不適です。
 例えば、システムの改変時にフィールドAに対して何らかの変更を加える場合、そのフィールドが影響を及ぼすオブジェクト(他のフィールド、スクリプト、レイアウト、値一覧、リレーション)が無いかをリストアップし、それぞれ検討を行い、悪影響があると判断される場合には対応が必要になります。この時、上記のデータベースデザインレポートには、フィールドAを指定して、関連するオブジェクトを抽出する機能がありません。
 この種の検索機能が無いと膨大な作業を人力で行う事になりますが、これは実務上ほぼ不可能となります。このため当社ではオブジェクト検索を行う以下のサブシステムを用意しています。
 

 図の「TPC Database Analyzer」は FileMaker 5.5/6用データベース分析ツールです。[検索条件]に「売上日」と入力して検索を実行すると、[売上日]を含むオブジェクトがすべて検索されます。その検索結果が下図です。


 画面左を見るとレコード数が約3万1千ありますが、これがこのシステムを構成するオブジェクトの数です。該当件数が299となっていますが、これが[売上日]が関連するオブジェクトの数です。約3万1千あるオブジェクトから人力で[売上日]を含むオブジェクトをしらみつぶしに調べるのは、実務上ほぼ不可能ですが、299件であれば一つ一つチェックしていければ、時間はかかると思いますが、熟練の開発者であれば必要な修正を加えることが可能です。

 このような分析ツールは障害や部分改変を行う際に限らず、新システムのスクラッチ開発時に旧システムを分析する際にも非常に有用なツールとなります。
(本項は21/10/14に加筆)
 
(NuckyT)




■ FileMaker 5/6等レガシーシステム関連記事

正月休み明け、仮想マシン上の FileMaker Server 5.5 バックアップが失敗していた(22/01/25投稿)
仮想マシンの外部ディスクでI/Oエラーが出た際の復旧方法

まだまだいける FileMaker 5.5/6 ― レガシーFileMaker の延命 2021 ―(21/07/24投稿)
レガシーFileMaker とOSの互換性、移行時の留意点について

IIS6 + FileMaker Web コンパニオン構成の Web サーバ機で TLS1.2 が動作するようにリバースプロキシを設定する (20/07/06投稿)
TLS1.2 非対応の IIS6 に Web ブラウザアクセス時に警告メッセージが出ないようにする

太古の FileMaker システムを延命させる! ― 後日談FileMaker(17/09/07投稿)
下記記事のレガシー延命スキームの実施と結果について。

太古の FileMaker システムを延命させる!(17/04/25投稿)
Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

FileMaker 5.5/6 をモバイルで使う(16/05/25投稿)
Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。

今なお輝くFileMaker 5.5/6(16/05/23投稿)
レガシーFileMaker の意外な利点。

2020-07-06

IIS6 + FileMaker Web Companion/Web Server Connector 構成の Web サーバ機で TLS1.2 が動作するようにリバースプロキシを設定する

Web ブラウザの TLS1.0/1.1 無効化により Web ブラウザで警告が発生


2015/10/05 に大手4社のWebブラウザが 2020年にTLS 1.0と1.1を無効化すると発表し、2020/07/01 より順次対応が始まった模様です。


今回の Web ブラウザのセキュリティ強化により、最新版の Web ブラウザを使って TLS1.2 非対応の Web サーバにアクセスすると、以下のような警告が Web ブラウザに表示されることがあります。

(以下は 最新のFirefox でアクセスしたときのエラー)

TLS1.2 に対応していないときに Web ブラウザに表示されるセキュリティエラー(Firefox)
Firefox で表示される エラーコード: SSL_ERROR_UNSUPPORTED_VERSION

Windows Server 2003 IIS6 は TLS1.2 非対応のため、別途対策が必要


 新たなセキュリティホールや脆弱性は日々発見されており、サーバOS も Webサーバもアップデートが提供されているものを使用し、できるだけ迅速にアップデートを行うことが推奨されます。しかし、OSやWebサーバのアップデートを行うにはシステムの修正や再構築が必要となり多額の費用が発生することが多々あり、このため止むを得ずレガシーシステムを使わざるを得ない、ということもあります。

 さて、FileMaker 5.5 Unlimited に付属する Web Companion や Web Server Connector は、FileMakerデータベースとIISの橋渡しをしてWebアクセスを可能にするものですが、Web Companion/Web Server Connector は Windows Server 2008のIIS7では動作しません。このため、Windows Server 2000/2003 IIS5/6 と FileMaker Pro 5.5 Unlimited(Web Companion/Web Server Connector)により、Webサイトを運用している企業はいまだにあると思われますが、ここで問題が発生します。IIS5/6 は TLS1.0 までしか対応していないため、この7月以降は上図のようなエラー/警告が発生します(エラーや警告はブラウザによって異なります)。 

Windows Server 2003 IIS6 のサーバ構成(TLS1.2 非対応)

リバースプロキシサーバ + IIS6 で Web サーバを構築

 さて、ここからが本稿の本題です。IIS5/6 + WebCompanion/Web Server Connector を使用しながら、どうすればTLS1.2以降による暗号化を可能にするかということですが、TLS1.2以降に対応した リバースプロキシサーバを立てることによって実現できます。 今回は nginx 1.18.0 によりリバースプロキシサーバを構成しました(下図)

 この構成により、既存の IIS6 の設定を若干変更するだけで、セキュリティが強化され、Web ブラウザに警告・エラーが表示されなくなります。

nginx リバースプロキシ + II6 によるサーバ構成
nginx リバースプロキシ + II6 によるサーバ構成


  以下、設定方法となります。

 なお、本稿はボランティアで提供しており、その内容や結果は保証できません。「書いてある通りにやったら、サーバが壊れた! 責任取れ(怒)!!!」とか、ホントにやめてくださいね。ただ、実行結果をコメントで残して頂く、とかなら大歓迎です。

  1. 既存の証明書の購入元から、PEM 形式の証明書とその秘密鍵を入手
    取得方法はサーバ証明書発行サイトによって異なりますので、詳細は証明書発行会社にお問い合わせください。
    入手した証明書ファイルと秘密鍵ファイルは、C ドライブ以外のできるだけ安全なフォルダに配置しておきます。

  2. IIS6 にインストールされている証明書を削除
    インターネットインフォメーションサービスマネージャを開き、「規定のWebサイト」まで展開し、マウスを右クリックしてプロパティを開きます。


    図のように“サーバー証明書(S)”をクリックし、処理の一覧から「現在の証明書を削除する(R)」をクリックし、“次へ”をクリックします。
    削除前の確認メッセージが出ますので、“次へ”をクリックすると、IIS から証明書が削除されます。

  3. IISの Web サーバポートを変更
    引き続き「Webサイト」タブをクリックし、ポート番号として以下のように入力します。

    IIS6 側のサーバポートを 80 以外に変更
    IIS6 側のサーバポート変更

    TCPポート:8080 (80以外であれば何でも可)
    SSL ポート:(空欄)

  4. nginx をダウンロードし、任意の場所に配置(インストール)

    https://nginx.org/en/download.html にアクセスし、Windows 用の最新安定バージョンをダウンロードし、解凍して任意の場所に配置します。
    今回は nginx/Windows-1.18.0 をダウンロードします。
    ※ Windows Server 2003 環境で解凍を行うと、実行ファイルが自動削除される可能性があります。その場合は、別の PC 上で解凍した後に Windows Server 2003 環境に配置しなおしてください。

  5. nginx.conf ファイルの修正

    nginx フォルダ配下の conf フォルダに配置されている nginx.conf ファイルをリバースプロキシとして動作させるために、以下のように修正します。

    ※事前にnginx.cfg ファイルのバックアップをお取りください。


    以下、環境別に設定が異なる部分は適宜調整してください。

    nginx.conf
    
    #user  nginx;
    worker_processes  1;
    
    events {
        worker_connections  1024;
    }
    
    
    http {
    
        include       mime.types;
        default_type  application/octet-stream;
    
        log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for"';
    
        access_log  logs/access.log  main;
    
        server_tokens off;
        sendfile        on;
        tcp_nopush     on;
    
        keepalive_timeout  65;
    
      gzip on;
        gzip_types text/css application/javascript application/json 
                   application/font-woff application/font-tff image/gif 
                   image/png image/jpeg application/octet-stream;
        
        add_header X-XSS-Protection "1; mode=block";
        add_header X-Frame-Options SAMEORIGIN;
        add_header X-Content-Type-Options nosniff;
    
    
        server {
     
            listen 80;
      
            server_name  yourdomain.co.jp;
    
            location / {
               proxy_pass http://127.0.0.1:8080;
            }
            # redirect server error pages to the static page /50x.html
            #
            error_page   500 502 503 504  /50x.html;
            location = /50x.html {
                root   html;
            }
    
        }
    
        # HTTPS server
        #
        server {
            
            listen 443 ssl;
            server_name yourdomain.co.jp;
    
            ssl_certificate     d:\\app\\cert\\fullchain.pem;
            ssl_certificate_key d:\\app\\cert\\privkey.pem;
      
            ssl_session_cache    shared:SSL:1m;
            ssl_session_timeout  5m;
            ssl_ciphers ECDHE+RSAGCM:ECDH+AESGCM:DH+AESGCM:DH+AES256:DH+AES:
                       !EXPORT:!DES:!3DES:!MD5:!DSS;
            ssl_prefer_server_ciphers on;
    
            location / {
               proxy_pass http://127.0.0.1:8080;
           }
           
        }
    
    }
    
    
    

    proxy_pass で示された URL のポート番号は、手順 3. で指定したものを入力します。
    HTTPS サーバブロックの proxy_pass にも同じものを入力します。

    ここまで修正したら設定ファイルを上書き保存します。

  6. nginx 起動テストを実行

    コマンドプロンプトを開き、nginx フォルダまで移動してから、以下のように入力します。

    nginx

    ※ 起動直後にポートアクセスへの許可を求めるダイアログが表示されたら、すべて許可しておきます。

    Web ブラウザを開き、従来の URL にアクセスします。
    警告メッセージが出ずに従来の Web ページが表示されれば成功です。

    前述の nginx.conf 設定で証明書の設定も行っていますので、http://、https:// ともにアクセステストを行ってください。

  7. nginx を停止

    nginx 起動テストに成功したら、いったん nginx を停止させます。
    コマンドプロンプトをもう一つ開き、以下のように入力します。

    nginx -s stop


    nginx プロセスが終了します。

  8. nginx を Windows サービスとして登録

    nginx を Windows サービスとして登録して常駐させるには、winsw という外部ツールを使います。

    以下のサイトより winsw というツールをダウンロードします。
    https://repo.jenkins-ci.org/releases/com/sun/winsw/winsw/

    ここでは最新版の winsw-2.9.0-bin.exe  をダウンロードします。
    ダウンロード済みの実行ファイルは任意の場所に配置してもよいのですが、nginx と同じフォルダに配置したほうが管理はしやすいかと思います。

    winsw-2.9.0-bin.exe ファイルを配置したら、同じフォルダの中に winsw-2.9.0-bin.xml という名称で空のファイルを作成し、テキストエディタで開きます。

    winsw-2.9.0-bin.xml ファイルに以下のように入力します。
    以下、nginx.exe へのパスは適宜調整してください。

    winsw-2.9.0-bin.xml
    <service>
      <id>nginx</id>
      <name>nginx</name>
      <description>nginx</description>
      <logpath>D:\Program Files\nginx-1.18.0\logs</logpath>
      <logmode>roll</logmode>
      <depend></depend>
      <executable>D:\Program Files\nginx-1.18.0\nginx.exe</executable>
      <startargument></startargument>
      <stopexecutable>D:\Program Files\nginx-1.18.0\nginx.exe</stopexecutable>
      <stopargument>-s</stopargument>
      <stopargument>stop</stopargument>
    </service>    

    修正が終わったらファイルを保存します。

    コマンドプロンプトを開き、winsw-2.9.0-bin.exe を配置したフォルダまで移動し、以下のように入力すると、nginx がサービスとして登録されます。

    winsw-2.9.0-bin.exe install


    インストールに成功すると、以下のような結果が表示されます。

    2020-07-04 00:06:46,000 INFO  - Installing the service with id 'nginx'

  9. nginx サービスの開始
    Windows サービスに nginx が登録されていることを確認し、“開始”をクリックすると nginx が起動し、稼働状態となります。


  10. サーバ動作最終チェック
    Web ブラウザを開き、従来どおりに Web サーバにアクセスし、無事にページが表示されれば終了です。

お疲れさまでした。

    おまけ:

    nginx を Windows サービスから削除する場合は、コマンドプロンプトで以下のように入力します。

    winsw-2.9.0-bin.exe uninstall


    ■ FileMaker 5/6等レガシーシステム関連記事

    太古の FileMaker システムを延命させる! ― 後日談FileMaker(17/09/07投稿)

    下記記事のレガシー延命スキームの実施と結果について。

    太古の FileMaker システムを延命させる!(17/04/25投稿)
    Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

    FileMaker 5.5/6 をモバイルで使う(16/05/25投稿)
    Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。
     

    今なお輝くFileMaker 5.5/6(16/05/23投稿)
    レガシーFileMaker の意外な利点。



    (亀)



    2020-03-16

    FileMaker データベースをSQLスクリプトステップを使用して更新する

     FileMaker は大分以前のバージョンからExecuteSQL関数により、SQLのCRUD(Create、Read、Upudate、Delete)の内、 Read、つまりSELECT 句のみは実行できるようになっています。

     開発者、特に他言語の開発者の中には「なぜ Read はできるのに、Create、Update、Deleteはいつまで経ってもできないのか?」とお腹立ちの向きも多いと思います。 小生もその一人です。
     実は(というほどのことではありませんが)、FileMaker ODBC を使用すると、 「SQLを実行する」スクリプトステップを使用してFMのテーブルを Create(Insert)、Update、Delete することができます。本稿では触れませんが、CRATE/ALTER TABLE といった DDL ― Data Definition Language も一部サポートされていて、テーブルの作成・変更も限定的に実行できます。

     ただ、開発者にとって非常にありがたいこの Create、Update、Delete を活用しているという話は寡聞にして知りません。これは、昔の FileMaker のODBC機能がお粗末で、新しい ODBC を踏み込んで使ってみようと思う人が少ないのが一因かもしれません。小生もその一人です。

     以前、医療レセプト開発のコンサルティング業務を請け賜わったことがあるのですが、数百万行のテーブルがあり、1つのレイアウト上に多数のテーブルからデータを引っ張るといった複雑なシステムで、FileMaker のテーブルオカランスのみではすべての要求情報を1つのレイアウトに表示することはできませんでした。元々はJavaの技術者だったご担当者はいくつもの ExecuteSQL 関数を複数のテーブルに対して実行、結果を変数に格納し、Loopに新レコード作成と値貼り付けを挟み込みむ、といった大変な開発をされていました。この時、上記のような スクリプトステップによるバッチ処理ではなく、INSERT ~ SELECT 等の利用を薦めたのですが、当方においても本手法の採用実績やテストが十分とは言えず、強くは推せませんでした。
     Insert や Update を利用すれば一発でできるところを、ウインドウを開いて、レイアウトを切り替えて、ループして書き込んで、ウインドウを閉じるといった FileMaker 特有の残念な処理を黙々と組み込んでおられたわけです。


    SQLを実行するステップによりFileMaker DBを更新するテスト

     ということで今回、FileMaker ODBC、FileMaker Server 18、 FileMaker Pro 18  の「SQLを実行する」スクリプトステップを使用して、いくつかのテストをしてみました。その結果が下表です。

    表の0:Script batch は FileMaker の通常のスクリプトステップを複数使用した場合
    1:Client SQL は  FileMaker の「SQLを実行する」をクライアントからサーバに対して実行
    2:Server SQL は クライアントから「サーバ上のスクリプトを実行」ステップを使用し、サーバ上で「SQLを実行する」ステップを実行

    「1:Client SQL」と「2:Server SQL 」では、今回のような単純なSQLクエリにおいては速度の違いはほぼありませんでしたが、サーバサイドでSQLを行う場合、サーバだけに ODBC を設定しておけば、クライアント上にODBCをインストール・設定する必要が無いのはメリットです。 

    1列目は実行したテスト内容で、以下で解説します。
    0:Script batch
    1:Client SQL
    2:Server SQL
    1. Update 1 field of 10K records
    7.2sec
    3.0sec
    2.8sec
    2. Update 5 fields of 10K records
    33.0sec
    3.2sec
    2.9sec
    3. Simple import of 10K records
    11.3sec
    6.2sec
    6.1sec
    ※各テストはそれぞれ5回ずつ実行し、所要時間を平均値を載せています。

    1万件のレコードの1フィールドを更新

    上表の「1.Update 1 field of 10K records」では、1万レコードの1フィールドを更新しています。SQLで記述すると以下になります。
    update product set "note1" = 'client sql'
    これをFileMaker のスクリプトでやる場合、product テーブルが設定してあるレイアウトを開き、すべてのレコードを選択して、 note1フィールドを選択後に、「client sql」で全置換するというように、複数のステップが必要になります。全置換を使用しない場合、フィールド値設定ステップを Loop させることになりますが、これは置換ステップよりも時間を要します。
     結果的にはSQLを使用した方が2倍以上高速でした。

    1万件のレコードの5つのフィールドを更新

     「2.Update 5 fields of 10k records」では1万レコードの5つのフィールドを更新しています。SQLで記述すると以下になります。
    update product set note1 = 'sql 10',  note2 = 'sql 20',  note3 = 'sql 30',  note4 = 'sql 40',  note5 = 'sql 50'
    0:Script batch」 では、置換ステップを5回実行しています。結果はSQLを使用した方が5倍高速でした。

    1万件のレコードを別テーブルにインポート

     「3.Simple import of 10K records」では1万件のレコードを別テーブルにインポートしています。SQLで記述すると以下になります。

    insert into invoice (prodId, prodName, price, unit, note) select ID, name, salesPrice, unit, note1 from product



    「0:Script batch」のコアとなるステップは「レコードをインポートする」だけですが、このような単純な処理であっても、SQLの方が2倍弱高速でした。

    過去のテスト

     小社では以前、いくつかの FileMaker 用 Web API を使用し、CRUDのテストを行っており(下記リンク参照)、その際も Create、Update、Delete については ODBC(PDO)が良い(=高速である)結果を得ています。

    参考:FileMaker API別にCRUDのテストをしてみた(2016/12/01)
     今回、ODBCとSQLを実行スクリプトステップを使用しても、3年前と同様に良い結果が得られました。

    SELECT ~ FOR UPDATE について

     SELECT ~ FOR UPDATE は直接データベースを更新する構文ではありませんが、更新の前処理として重要な意味があるので、ここで触れておきたいと思います。
     FileMaker®16 SQL リファレンスガイドによると、FileMaker ODBC/SQL は「FOR UPDATE 句 」をサポートしており、select ~  where ~ for update を実行すれば、where で指定された「各レコードは取得時にロックされ」る筈ですが、「SQLを実行する」ステップでは以下のようなSQLを実行しても、他ユーザは where 句で指定されたレコードを更新できてしまいます(つまりロックされない)
    select * from product where ID =1 for update [of note1, note2]
     もともと「SQLを実行する」ステップで select を実行しても、文字列などの結果が返りません。サーバのログを見ても、実行直後に接続が切れています。ということで「SQLを実行する」ステップは  select ~ for update (レコードロック) をサポートしていないようです。
     ただ、他ユーザがあるレコードを編集している際に、 当該レコードが対象となる select ~ for update 実行すると「[FileMaker][FileMaker] (301): Record is locked by another user.」が返ります。 つまり、FOR UPDATE句により、ユーザは WHERE句 で指定するレコードセット中に編集中のモノがあるかどうかを事前に知ることだけはできます。

     ちなみに、ExecuteSQL関数 はこの FOR UPDATE をサポートしていません。


    更新時の他ユーザ競合エラー
     複数レコードのフィールド値を更新する場合、他ユーザが更新対象のレコードを編集しているとエラーとなります。ただし、フィールド内容を置換スクリプトステップ と SQL の UPDATE ではその内容が異なります。

     フィールド内容を置換ステップでは、置換対象のレコードを他のユーザが編集していると、そのレコードを除くロックされていない全レコードが置換され、FileMaker標準エラーの201(フィールドを変更できません)が返ります。置換ステップの欠点はエラーが起こったレコードが特定できないことで、これは場合によっては致命的です。このため、エラーを放置できない場合は置換ステップに替えて、処理に時間がかかりますが、Loop により各レコードを逐一更新し、エラーを起こしたレコードの主キーを記録して、ユーザに通知するか、エラーを解消するための処理を別途用意することになります。

     これに対し、FileMaker SQL の UPDATE は、1レコードでもロックが発生していると WHERE句で指定されたすべてのレコードが更新されません。あたかもエラーが発生して ROLLBACKされたようにみえます。このときFileMakerは1408(拡張エラー (ODBC)、Get(最終外部エラー詳細)関数は「[FileMaker][FileMaker] (301): Record is locked by another user.」を返します。
     FOR UPDATE句によりレコードセットをロックできれば、更新時の他ユーザ競合によるエラーの懸念も減少すると思うのですが、前述のような状況なのが残念です。

     FileMaker の開発案件もマルチユーザ対応が要件であることが多いと思います。マルチユーザ対応であれば、競合発生時のエラー処理は必須です。この辺の地味な処理の重要性を発注サイドにも認識して頂き、工数を見込んで頂くと共に、検収時のチェックリストにいれましょう。

    SQL実行ステップにより更新を行うメリットと課題


    SQLによる更新を行うメリットをまとめると以下のようになります。

    1. 高速化
    2. スクリプトの簡略化、可読性向上
    3. 他言語からの移行組技術者は使い慣れたSQLにより開発ができる
    4. アクティブレイアウトとは無関係にコマンドを実行できる


     今回は単純な処理のみでテストを行っていますが、多数行に及ぶ複雑な更新・バッチ処理を行う場合、SQLを使用する速度的メリットはさらに大きいと思います。


     FileMaker は過度にレイアウト依存したシステムであるため、上記4のメリットも大きいと思います。スクリプトはレイアウトからフィールドが消去されるとエラーを起こす可能性がありますが、SQLであればその心配はありません。

    スクリプトで複数レコード、複数テーブルに及ぶ処理を実装すると、いちいちテーブルが割り当ててあるレイアウトに移動し、LOOPでグルグル回しながらレコードを作成したり、更新したりするのはコーディング的にも残念ですし、画面がチラチラ無駄に切り替わるのはユーザから見ても美しくありません。


    課題


     FileMaker社はWebサイトでアクセス方法別の許容ユーザ数を公開しており、ODBC/JDBC接続の最大許容値(理論値)は無制限、検証値は50(ユーザ)となっています。
    今後は100~500ユーザ位を想定し、負荷が高い処理でも確実に実行されるか、テストを行いたいと思います。

    以上


    NuckyT