FileMaker公式テキスト中級編！！！
中級編では、
中級開発者として複数の利用者を想定してシンプルなカスタムAppを作成する
といった内容になります。
全１６章です。
前回は、13章『モバイル/ FileMaker Go』について学びました。
👉FileMaker 中級編（13章）
今回は、14章『運用を計画しよう』についての知識を学びます。
運用準備
業務で使用するようなカスタム App には、
開発作業をする（セキュリティやパフォーマンスの考慮）「開発担当者」、
管理作業をする（安定、安全、信頼が必要）「運用管理者」が必要です。
業務に関するシステムを、日々、使えるように動かし続けることを「運用」と呼びます。
システムの運用には次の点が重要です。
・安定性 ・安全性 ・信頼性
カスタム App の使われ方
システムの運用で重要なことは、
・カスタム App のファイルを物理的にどこに配置するか
・どのような方法でユーザが使用するか
・複数のユーザから使用されるかどうか
・カスタム App とクライアントは、どこから、どのように接続(アクセス)するか
・ユーザがカスタム App にアクセスするクライアントのハードウェアはなにか
・ユーザがカスタム App にアクセスするアプリケーションはなにか
(FileMaker ProFileMaker Go、Web ブラウザのいずれか)
上記が曖昧だと開発が進められません。
ユーザが単独で使用(スタンドアロン)
共有せず、クライアントのハードウェアにカスタム App のファイルを保存する方法です。
例えばこのような状況
・複数のユーザから使用されるかどうか → 1 人のみ
・カスタム App とクライアント → 同ハードウェア上
・ユーザがカスタム App にアクセスするクライアントのハードウェア → iPad
・ユーザがカスタム App にアクセスするアプリケーションはなにか → FileMaker Go
次のような場合に、スタンドアロンを使用します。
・ネットワーク環境がない場所での使用が必要
・データの共有が不要である
注意点は、ユーザ 1 人ずつがファイル、データを管理しなければいけません。
ファイルが壊れてしまいバックアップをとっていなかったらデータが無くなってしまいます。また、後からデータの一元化をしたくなったとしても簡単にはできません。
あらかじめ同期について考えておく必要があります。また、 新しい機能を追加することに備えて、新しくリリースされたファイルを差し替えする手順(データ移 行が必要かどうかなど)も考える必要があります。
ユーザがホストにアクセスして使用(クライアント/サーバー)
サーバーにカスタム App ファイルを保存して共有する方法です。FileMaker Cloud や FileMaker Server がホストして共有し、クライアントからのアクセスを可能にします。
例えばこのような状況
・複数のユーザから使用されるかどうか → 2 人以上
・カスタム App とクライアントのアクセス → ネットワーク(有線 LAN または Wi-Fi)
・ユーザがカスタム App にアクセスするクライアントのデバイス
→ パソコン または iPhone や iPad
・ユーザがカスタム App にアクセスするアプリケーションはなにか
→ FileMaker Pro または FileMaker Go または Web ブラウザ
次のような場合に使用します。
・ネットワーク環境がある
・データの共有が必要
※ネットワーク環境があれは通常はこちらを選択します
ホスト >>> カスタム App ファイルへ同時に 2 人以上のユーザがネットワークからアクセスして使用できるようにすること。
クライアント >>> ホストにアクセス(接続)するのがクライアント。
※FileMaker Pro のホスト
FileMaker Pro もファイルをホストできますが、検証作業を主な目的としています。
本番運用環境 では使用できません。FileMaker Cloud や FileMaker Server を利用してください。
カスタム App の使われ方は、どのような選択をするとしても運用の安定性、安全性、信頼性をできるかぎり確保できるように計画します。
同期
ユーザがネットワークの無い場所でも使用できるようにスタンドアロンのカスタム App の使い方を選択したけれど、使用後のデータはクライアント/サーバーでホストされているカスタム App に反映したいという場合があります。
「データの同期」が必要です。大きく分けて2種類あります。
・一方向
モバイルデバイスのカスタム App から、サーバーでホストされているカスタム App へデータを送信するだけ、あるいはその逆という形です。
※データの集約を目的にすることが多い
・双方向
モバイルデバイスのカスタム App と、サーバーでホストされているカスタム App の両方でデータを送信するという形です。
※データを集約し双方が同じ内容にすることを目的とする
同期のポイント
●同期する項目
同期するカスタム App 同士が同じファイルでデータが違うだけであれば、同期項目の合致が 容易です。違う場合は、どの項目がどの項目へ同期されなければならないのか(マッピング)を 考える必要があります。
●競合
1 つのレコードが同期する両方のカスタム App に含まれていて両方が修正された場合「競合」 と呼びどのように競合を解決するのかについてルールを決定します。「競合の解決」といいます。
主キーは UUID が便利
『あるレコードと他のレコードが同じ情報の内容違いであるかどうか』を照合するためにレコードの 「主キー」を使います。このとき、UUID を使った主キーを採用していると照合がスムーズです。
例えば、同じ UUID のレコードで『どちらが新しいものか』について比較するには「修正タイムスタンプ」を比較すれば良い、と考えることができます。
●削除
レコードの削除についてもルールが必要です。
●一方向と双方向の混在
マスタ情報は、一方向(サーバーでホストされているカスタム App からモバイルデバイへ)、 イベント情報は、双方向というような 1 つのカスタム App の同期に 2 種類が混在することがあります。
●同期のタイミング
常に行うのか、一定期間で行うのか、などです。
詳細は、ヘルプやクラリス・ジャパン株式会社のナレッジベース「データベースの同期 – アプローチの 概要」(https://support.claris.com/s/answerview?language=ja&anum=000024001)
FileMaker Cloud または FileMaker Server によるホスト
クライアント/サーバー方式で FileMaker Cloud または FileMaker Server を利用する場合、共有方法がいくつかあります。アクセスできるクライアントのアプリケーションが決まっています。
・通常 → FileMaker Pro(macOS または Windows)、FileMaker Go(iOS/iPadOS)
・FileMaker WebDirect(Web 公開)→ Web ブラウザ
・カスタム Web(Web 公開) → Web ブラウザ( FileMaker Cloud は非対応)
・ODBC / JDBC からのアクセス → ODBC / JDBC クライアント
(FileMaker Cloud は ODBC インポートのみ)
●他のカスタム App
すでに FileMaker Cloud または FileMaker Server を利用している場合、基本的な設定が既に済んでいるかもしれません。その場合、変更する必要があるかを検討します。共有されるすべてのカスタム App ファイルについて有用な設定になることを目指します。
●複数の共有方法
1 つのカスタム App に複数のクライアントタイプからのアクセス方法を選択できます。
マルチユーザと呼びます。1 つでもすべてでもどの組み合わせでも可能です。
●FileMaker クライアント
FileMaker Pro、FileMaker Go、FileMaker WebDirect への Web ブラウザ接続の 3 種類を「FileMaker クライアント」と呼びます。それぞれの特徴があります。
FileMaker Pro
パソコンのスペックの高さに比例して処理能力が期待できます。複数のウインドウ、豊富なフォントの表示が可能であること、また、ほぼすべてのスクリプトステップが利用できます。
FileMaker Go
iPhone や iPad は、画面サイズがパソコンよりも小さく、処理能力もパソコンよりも劣る場合があります。しかし、署名キャプチャ、バーコードや NFC(近距離無線通信)タグのスキャン、iBeacon、TouchID / FaceID の対応、センサー情報の取得など独自の機能を利用したカスタム App を提供することができます。また、画面サイズが小さいことを逆手にとり、必要最低限の項目などに集約された誰にでもわかりやすいレイアウトデザインと操作性を実現することができます。
FileMaker WebDirect
ほとんどのパソコンやデバイスには Web ブラウザがインストールされています。そのため、アプリケーションをインストールせずに使用を開始できます。ただし機能が限定されます。
その他のアクセス
FileMaker Server を利用する場合は、カスタム Web 公開と ODBC / JDBC クライアントからのアクセスも可能です。
ハードウェアとアプリケーション
別の面から運用の準備をします。ハードウェアとアプリケーションです。
FileMaker Cloud のコンピュート(処理能力)タイプ、FileMaker Server のホスト専用機有無や、接続する FileMaker クライアントの種類などは、カスタム App の使われ方により、何を準備する必要があるかわかります。
↓↓↓
これらをいつ準備するのかを計画しなければなりません。
(1)ハードウェアとアプリケーションを購入する
(2)ハードウェアをセットアップする
(3)ハードウェアにアプリケーションをインストールする
(4)アプリケーションを設定する
上記のように様々な準備やそれにかかる期間、購入の決定には様々な担当者からの承諾が必要となる場合があります。
●購入
必要な品について決定します。
・システムを運用するために必要なハードウェアの台数と OS、スペック(仕様や性能)
・システムに必要なアプリケーションの名称(種類)、バージョンと本数
ハードウェアのスペックに最低限必要な内容は、インストールするアプリケーションと関係します。 アプリケーションが動作するために必要な推奨環境が指定されています。
既存のものを利用する場合 『いまあるもので条件を満たしているかどうか』を確認します。※推奨環境については、クラリス・ジャパン株式会社の Web サイト
https://www.claris.com/ja/を参照してください。
●必要なセットアップ内容
ハードウェアとアプリケーションの入手について決定したらセットアップについて検討します。
・システムを運用するために必要なハードウェアへのセットアップ内容
企業や団体で利用されるハードウェアには、
・ネットワークの設定
・OS のアカウントの設定
・OS のセキュリティの設定(ファイアウォールなど)
上記などのセットアップが必要になります。
必要なポート番号の許可
ポート番号の決定は、カスタム App の使われ方により違います。
それ以外にもカスタム App によって必要な設定を決定します。
※詳細はクラリス・ジャパン株式会社のWeb サイトのナレッジベース
「FileMaker Server によって使用されるポート番号」
https://support.claris.com/ s/answerview?anum=000025632&language=jaで、最新情報を参照してください。
●インストールと設定
次にアプリケーションのインストールと設定を誰が実施するかを計画します。
これらの作業、つまりどれぐらいの数のハードウェア、アプリケーションを発注し、納入後にセットアップ、インストールと設定を行うのか、その作業時間を予測して期間を計画し、実行します。
きちんと計画して運用準備作業を行うことで、運用の安定性、安全性、信頼性を高めます。
データの準備
ハードウェア、アプリケーション、ネットワークの他に、リリースされるカスタム App にも準備が必要です。主にセキュリティとデータの準備です。
ユーザ
カスタム App にアカウントとパスワードでログインするユーザを登録します。
マスタ情報
各種マスタ情報を登録します。
例えば「見積作成管理システム」なら次のようなデータです。
・顧客情報
・顧客担当者情報
・商品情報
・自社情報
・自社担当者情報
これらの情報がないとイベント情報(例えば見積情報)が作成することができません。
新しいシステムの利用開始前に、主なマスタ情報は登録済みにしておかなければいけません。
情報の登録作業→データ移行 という
※値一覧
カスタム値の値一覧の内容も運用前に見直します。（テスト用のデータが残っているかもしれません）
データ移行
既にマスタ情報(顧客情報や商品情報など)がスプレッドシートファイルや、他のシステムに存在している場合、それを利用してデータの「移行」を実施します。
大まかに2種類があります。
●手入力
ばらばらで紙に書いたものしかないなどの場合、手入力で情報 を登録します。
●インポート
いくつかに分散していても、どこかにまとまっていても入力されているデータがある場合は、専用のインポート機能をカスタム App に作成してデータ移行を実施します。
〜基本的な手順〜
(1)データを集める
(2)集めてきたデータの項目を揃える
(3)データの項目が、カスタム App の項目が合致するか確認する
例 郵便番号が 123-4567 と 1 項目になっているか、123 と 4567 の 2 項目かなど
(4)合致させたデータ項目の内容とカスタム App で想定している内容に合致するか確認する
例 住所の数字の全角半角など
(5)これまでの作業で分かった内容を元に、必要があれば 1 箇所にデータを集めて加工する
(加工作業用のカスタム App を作ったりスプレッドシートを使ったりする)
(6)複数の種類のデータをインポートする場合の順番を考える
例 顧客情報をインポートしたあと振られた主キーを顧客担当者情報に外部キーとして入力するなど
(7)データ移行機能を作成する
すぐに実行してはいけません。この移行は失敗すると大変です。
実際には、業務が休みのタイミングや夜間のタイミングで、短期で確実にデータ移行を行わなければいけません！！！
失敗は許されません😖何度もテストしましょう👍
(8)データ移行の具体的で詳細な手順を考え、手順書を作成する
(9)テスト用のファイルを準備してリハーサルを行う
(10)データ移行を実行する
●データの運用
マスタ情報の運用方法にはポイントがあります。他のシステムの情報で置き換える必要があるかです。テーブルやフィールド項目に影響があるからです。
例 企業や団体の基幹システムに顧客情報や商品情報があってカスタム App に必要な場合、 両方に同じようなマスタ情報を持って更新するよりも連携した方が効率的です。
・直接他のシステムの情報を利用する
・定期的なインポートで最新情報に置き換える
のどちらが良いかを考えます。
●イベント情報のデータ移行
イベント情報(例えば見積情報)のデータ移行は、マスタ情報よりも作業期間がかかります。
ほとんどの場合、新しいカスタム App と移行したいデータの構造が違うからです。
イベント情報の移行は大変なことが多いです。
本当に必要かどうか、しっかりと検討してください。
イベント情報は、マスタ情報の登録後にデータ移行作業を実行する必要があります。そのため、さらに充分な作業期間を確保するようにします。
管理の準備
管理運用の準備も必要です。
管理者を決定する
カスタム App を運用していくには、開発担当と運用担当の両方が必要です。
●開発担当
カスタム Appについて作業します。運用開始後に発見されたバグを解決したり、ユー ザの意見を検討し、定期的、あるいは任意のタイミングで修正や機能の改善や追加をします。
●運用管理担当者
運用について作業します。バックアップが定期的に実行されているか、不具合が起きていないかを確認し、問題があった場合に対処したり、あるいは専門の部門や部署へ連携します。
※セキュリティ
管理者についてもセキュリティを考えます。
開発や運用管理が複数の人で行われる場合、[完全 アクセス] アクセス権セットのアカウントは共有せず、1 人に 1 つ設定します。
運用の 1 日を考える
管理者が決定したら、運用開始後の予定も立てる必要があります。
1 日の間になにが起きるか考えます、主に以下のようなことが考えられます。
・カスタム App をユーザが使用できるように継続してホスト
・定期的なバックアップ
・定期的なバッチ処理
バックアップとバッチ処理が同時に実行されないように考える必要があります。
(バッチ処理については後述します)
もう少し長い期間で考えます。そして、緊急時の対応についても考えておかなければなりません。
つまり、
・通常の、運用の 1 日の中で行うこと
・あらかじめ計画して運用を停止/再開すること
・計画になく運用が中断すること
この 3 点について準備します。
・FileMaker Cloud または FileMaker Server で設定した内容を記録する
・設定や作業の手順書を作成する
上記を行っておくと良いです。
運用管理は開発とは違う側面を考えることが多くなります。運用を全く初めて行う場合は、戸惑うことも起きるかもしれません。経験値を蓄積していきましょう。
運用開始までの期間を考える
ハードウェア、アプリケーション、カスタム App へのデータ移行、これらの作業期間を考えることで、運用開始までの計画を立てることができます。
運用までには様々な段階があります。
(1)ハードウェアとアプリケーションを購入する
(2)ハードウェアをセットアップする
(3)ハードウェアにアプリケーションをインストールする
(4)アプリケーションを設定する
(5)カスタム App にマスタ値をデータ移行する
(6)運用の予定と対応を準備する
（↑上記はこれまでに確認した内容↑）
(7)カスタム App を共有する
(8)カスタム App への接続テスト
・運用のルールを考える
・運用開始日を決定する
●運用のルール
カスタム App をユーザが使っていく上で、ユーザがどのようなルールで管理をするかです。
開発者が担当する、あるいは、別途に担当者を設定することがあります。
例えば、2 点についての管理ルールです。
・マスタ値の管理
・アカウントの管理
複数のファイル
カスタム App の設計で、ファイルの構成を考えることが必要になる場合があります。
データ分離モデル
複数のファイルで作成されたカスタムAppは、1つのファイルにすべて(データ、テーブル、関連、 スクリプト、レイアウト、アクセス権限など)が入っているために取り扱いが簡単です。
↓↓↓
これをあえて複数のファイルに分けて 1 つのカスタム App とする場合があります🙄
※開発作業が完了した後からファイルを分けることはとても大変なため、設計の段階で決めておきます
●分離モデル
ファイルを『インターフェースファイル』 『データファイル』の2つに分けて開発、運用します。
インターフェースファイル
レイアウト、スクリプト、計算式
データファイル
テーブル、フィールドなどのデータ。
＜分離する利点＞
運用開始後にリリースする必要がある場合（メンテナンスなどで）、インターフェースファイルの差し替えだけで済む場合があります。リリース作業が短時間で済むために、運用停止期間も短くなります。
⇩単一モデルのリリース作業の場合。。。
1 つのファイルで運用している場合、リリース時には、現在のデータを新しくリリースされるファイルに移し替える必要があります。
メンテナンス中に増えたデータをインポートする必要があり、手間と時間がかかってしまう。
分離モデルの注意点もたくさんあります。開発も複雑になります時間もかかります。
詳しくは解説しませんが、使用の際には十分な配慮が必要です。
●データファイルをさらに分割
マスタ情報のデータが大容量である場合、データファ イルを分けてバックアップの頻度を下げるという選択肢もあります。これはイベント情報のデータよりも、マスタ情報のデータの方が静的である、つまり新規作成、変更、削除作業が少ないという考え方によるものです。
●インターフェースファイルだけユーザ側に
共有されているカスタム App を FileMaker Go から使用する場合、インターフェースファイ ルをモバイルデバイスのローカルに保存するという方法があります。サーバーとの通信がほとんど データ内容だけになるため処理が早くなる期待ができます。ただしモバイルデバイスはパソコンと比べてスペックが低いため、シンプルな画面、処理を心がけるようにします。
複数のカスタム App
同じ企業や団体で使用する複数のカスタム App がある場合、共通のマスタ情報を使用する方が開発面、管理面ともに効率が高いかもしれません。
『アカウントが同じ内容でカスタム App ごとにアクセス権セットが違う』
ような設定にすれば同じアカウントで、複数のカスタムAppを使えて便利です。
このような場合、外部認証サーバーを導入できることがベストな 運用です。外部認証が利用できない場合、アカウント管理用のカスタム App を作成するなどを検討 しても良いかもしれません。
以上で14章は終わりです。
次回は15章「セキュリティ」について学習していきます😄
コメント