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-06-01

    TPC FM-AConnect CTI ― Amazon Connect と FileMaker WebDirect 19 による CTI

    TPC FM-AConnect CTI について

     
     本稿では、Amazon Connect と FileMaker WebDirect 19 を連携させた CTI(Computer Telephony Integration)プロトタイプ・TPC FM-AConnect CTI の仕組みと機能をご紹介します。

     Amazon Connect は、AWS上で構築するクラウドベースの PBX/コールセンターシステムです。レガシーPBXを使用したコールセンターシステムに比べ、初期費用に抑えてシステムを構築できます。
     これによりオフィス内のスタッフはもちろん、テレワーカー(在宅勤務者)でもCTIを利用できるようになります。

    TPC FM-AConnect CTIの主要機能

    1. FileMaker WebDirect 19のアプリ(FM-AConnect WD)を使用した着信時顧客情報ポップアップ(着信した電話番号により顧客データベースを検索し、その顧客情報をオペレータのPC画面に表示する機能)

    2. FileMaker DB に登録された電話番号とオペレータIDに基づく、オペレータへの配信(着信番号別オペレータ割当、例えば顧客DBで顧客AとAを担当するオペレータXが紐付けて登録されている場合、Aの電話番号を着信するとXに転送する

    3. チャット ― テキストによるチャット

    4. 通話記録 ― 音声通話を記録・再生する機能

     WebDirect とは FileMaker で作成したアプリをそのままWeb公開する機能です。FileMaker のデスクトップアプリと高い互換性を有しており、そのほとんどの動作をWebブラウザ上で再現可能です。また、バックエンドとなるデータベースには FileMaker に限らず、ODBC経由で Oracle、MySQL、SQL Server、DB2*1、PostgreSQL*1 を使用することができ、他の開発ツールに比べ短い時間で CTI のフロントエンドを開発することが可能です*2

     Amazon Connect の電話端末となるソフトフォン・CCP もブラウザで動作する Webアプリであるため、WebDirect との親和性、JavaScript による相互の制御性は高いといえます。

    注:
    *1 DB2、PostgreSQL を使用するには、Actual社の ESSアダプタが必要。
    *2 WebDirect については、当社の過去のBlog記事(一覧)をご覧ください。

    仕組みと Amazon Connect の問い合わせフローについて


     以下が TPC FM-AConnect CTI のシステム構成図となります。
    図でCCP (Contact Control Panel)とあるのが Amazon が提供するソフトフォンで、Windows/Mac の Firefox あるいは Chrome 上で動作します。残念ながら、スマホやタブレット、SIPフォンには対応していません。

     顧客からの電話が入ると、まず Amazon Connect が1つ目のCCPに電話を転送し、転送先の CCP はPCのスピーカーから呼び出し音を発生させます。
     

     上記の処理の流れは Amazon Connect の問い合わせフローによって制御されます。
    問い合わせフローとは、問い合わせの一連の処理の流れをシナリオ化したものです。
    TPC FM-AConnect CTI には、以下の 3 つの主要問い合わせフローによって構成されています。

    メインフロー


     窓口となる Amazon Connect の問い合わせフローです。顧客からの着信が音声通話要求なのか、チャット要求なのかによって各サブフローを呼び出します。

     上記の流れを簡易フローチャート化すると、以下のようになります。

    サブフロー:音声通話応答用問い合わせフロー

     メインフローにより、音声通話要求と判断された場合に実行される Amazon Connect の問い合わせフローです。通話着信があってからCCPでの通話が開始されるまでの問い合わせフローは次のようになります。
    TPC Call Automatic Response フロー
    上図は1画面に表示するため、エラー時のフロー転送とハングアップを増やしてます

     
     上図を簡易フローチャートにすると以下のようになります。 
     このとき FM-AConnect WD は着信した電話番号を取得し、その番号によりデータベースを検索し、顧客情報をポップアップ表示します。

     上図を補足解説します。

    1. ログ収集開始では、Amazon Kinesis Stream というデータストリームを有効にし、通話開始時のタイムスタンプを取得します。このタイムスタンプは、Amazon S3 に保存される通話記録ファイル(後述)名をデータベースに保存するために必要となります。なお、Transcribe(AWSの音声→テキスト変換モジュール)を利用する場合も、この Kinesis が必要となります。

    2. Amazon Connect のオペレーション時間設定を使用し、会社の営業時間を設定します。営業時間内であれば次に進み、時間外であれば顧客にその旨を告げる音声アナウンスを行い、通話を終了します。

    3. AWS の Lambda 関数に定義されている FileMaker Data API により、着信電話番号に該当する顧客担当者(担当エージェント)を検索し、通話要求を担当者の CCP に転送を試みます。以下は、転送時の分岐処理。

      • 顧客担当者検出 --- その担当者に通話要求を送信
      • 顧客担当者を検出したが不在 --- 通話可能な担当者に通話要求を送信
      • 顧客担当者未検出(DBに登録無) --- 通話可能な担当者に通話要求を送信
      • 顧客担当者不在 --- 未達メッセージを自動音声アナウンス → 通話終了

    4. AWS の Lambda 関数を使用し、受信した電話番号をJSON形式でWebクライアント(ここでは FM-AConnect WD)に渡します。FileMakerのファイルには「電話番号による顧客検索スクリプト」を用意し、電話番号は引数で渡せるようにしてあります。
      Webサーバ上に配置するHTMLページには 上記のCCP を埋め込んでおき、Lambda が生成したJSON形式の電話番号を取得し、Webビューアに設定してある FileMaker.PerformScript (電話番号で顧客検索スクリプト,  電話番号) を実行します。

      この FileMaker.PerformScript( ) は FileMaker 19 で導入された新機能で、Webビューア内の JavaScript から FileMaker のスクリプトを実行できます。これにより、CCPに着信があると、FileMaker WebDirect のアプリで顧客情報が検索されるようになります。

      CCP(右)に着信すると、WebDirect(左)は自動的に電話番号で顧客を検索・表示する

    5. 担当者の CCP まで通話要求が転送されると、CCP が呼び出し状態となり、✓ボタンをクリックすると通話が開始されます。
     以下の動画では、上記のフローに基づき実装したCTIの着信時顧客情報ポップアップ機能をご覧いただけます。

     

    通話記録再生機能について

     通話記録は音声ファイルとして AWS S3 サーバに保存されます。通話記録ファイルは FileMaker WebDirect アプリケーションの「交信履歴」タブのリストから再生することができます。 
     

    サブフロー:チャット応答用問い合わせフロー

      TPC FM-AConnect CTI にはチャット機能も用意されています。チャット機能のシステム構成図は以下のようになります。

     メインフローにより、チャット要求と判断された場合に実行される Amazon Connect の問い合わせフローです。チャット要求があってから CCPでのチャットが開始されるまでの問い合わせフローは次のようになります。

    Amazon Connect TPC Chat Flow
    上図は1画面に表示するため、エラー時のフロー転送とハングアップを増やしている

     上図を簡易フローチャートにすると以下のようになります。 
     
     上図を補足解説します。
     
    1. 貴社のWeb サイトにチャット開始用のページを用意し、顧客はこのページからチャットを開始します。


       顧客の上図の"Start Chat"をクリックするとチャット用の API Gateway にアクセスが行われ、Lambda 関数によりチャットセッションが開始し、Amazon Connect のチャット応答用問い合わせフローに入ります。

    2. Amazon Connect のオペレーション時間設定を使用し、営業時間をチェックします。時間内であれば次に進み、時間外であれば顧客にテキストでアナウンスを行い、チャットを終了します。

    3. 切断フローとは、エージェント側がチャットを終了したときの処理を定義したフローです。たとえば、チャットのお礼メッセージ、顧客への案内メッセージ、企業プロモーション情報などを送信したり、Amazon Connect の内部処理などを定義したりできます。

    4. 担当エージェントの CCP が呼び出し状態となりますので、✓をクリックするとチャットが開始されます。
    5. チャットが終了すると、上記の 3. の切断フローが実行されます。たとえば、以下のようなメッセージが顧客側に表示されます。

     
     Amazon Connect でシステムを構築するのは上記のようにそれなりの工数が発生しますが、ハードウエアの初期費用が不要で、運用コストも廉価です。また、システム構成もハードウェアを気にすることなく柔軟に変更することが可能です。
     
     コロナ等の感染症や台風・洪水などの自然災害が多発する昨今、オペレータの居場所に拘束されない Amazon Connect の導入は今後増えるものと予想されます。

    以上

    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