2013-08-29

HA 構成されている SonicWALL のファームウェアの更新方法

 HA 構成済の SonicWALL でファームウェアをアップグレードする場合は、主格機側でアップデート操作するだけで、副格機のファームウェアも自動的にアップデートされるようになります。


 HA 構成の概要と設定方法については、以下の記事をご参照ください。


 それでは、ファームウェアのアップデート手順をご紹介します。


【ファームウェアのダウンロード】

1. MySonicWall にログインします。

https://www.mysonicwall.com/

2. 「ダウンロード」→「ダウンロードセンター」の順に選択すると、ダウンロードセンターページに移ります。


 上図のように、[言語設定]に「Japanese」、[ソフトウェア種別]にお使いの SonicWALL のモデルと同じものを指定してから、利用可能なファームウェアをクリックすると、ダウンロードが始まりますので、任意の場所に保存してください。

3. MySonicWALL からログアウトします。


【ファームウェアのアップロードと起動】

 SonicWALL からダウンロードしたファームウェアを、SonicWALL 主格機にアップロードして起動することによって、新しいファームウェアが主格機、および副格機に同時に反映されます。

1. SonicWall 主格機の管理インタフェースにログインします。

2. 「システム」→「設定」の順に選択すると、設定ページが開きます。
 現在起動中のファームウェアのバージョンを確認し、必要に応じてメモを取っておきます。

3. 下図のように、“ファームウェアのアップロード”ボタンをクリックし、先ほどダウンロードしたファームウェアを指定して“アップロード”ボタンをクリックすると、確認メッセージが表示されます。



 主格機、副格機ともに正常に動作していることを確認してから“OK”ボタンをクリックすると、ファームウェアのアップロードが始まります。

4.  アップロードされたファームウェアがリストに表示されます。

 ページ下部に「ファームウェアが正常にアップロードされました。」という正常メッセージが表示されていることを確認してから、下図のように、新しいファームウェアの起動ボタンをクリックします。



5. この操作には 4 分ほど所要することと、主格機、副格機ともにファームウェアが反映されるため、社内でネットワーク利用のない時間帯に実行することを強くおすすめします。


 準備が整ったら、“OK” をクリックし、暫く待っていると主格機、副格機が再起動されます。


注意:
ファームウェアの更新に成功すると、古いファームウェアは起動リストには表示されなくなります。


以上です。





2013-08-26

SonicWALL で HA (高可用性)設定を行う

思ったより面倒だった SonicWALL の HA セットアップ

 SonicWALL の OS 5 では、比較的容易に冗長構成ができるようになっています。
 これは高可用性(High Availablity, 以降 HA)と呼ばれます。

 同モデルのメイン(主格)機とバックアップ(副格)機を用意して繋げておくことによって、主格機が電源障害やシステム障害などにより動作不能になった場合に、ネットワークの設定が自動的に副格機に移り、クライアントユーザはダウンタイムなしでネットワークを利用できるようになるといういうものです。

 意外に面倒なHA 構成、設定、確認方法をまとめてみました。





【用意するもの】

1. SonicWall  2 台

 OS 5 以上、同モデル機器、ファームウェアのバージョンが一致していることが条件です。
 当方は Sonic WALL TZ205W で操作を行いましたが、上位機でも、OS 5 であれば、ほとんどの操作で共通している部分も多いと思います。

2. クロスケーブル (カテゴリー6): 1 本

 SonicWALL 同士を繋ぎ、一定の間隔で稼働状態をチェックする(ハートビート)ために使います。

3. WAN スイッチ用のハブ: 1 台

 WAN 回線を分配するためのハブです。
 この他に、WAN ケーブル(ストレート) 1 本、LAN ケーブル(ストレート) 2本が必要になります。

4. LAN 用のハブ: 1 台

 二台の SonicWall、クライアント PC を繋ぐための LAN 用のハブです。
 台数分の LAN ケーブル(ストレート)が必要になります。




【設定用クライアントPCの準備】


 クライアント PC の NIC の設定で、IP 設定のゲートウェイを 192.168.168.168 (SonicWALL 管理インタフェースのデフォルト)にします。

 たとえば、以下のように設定します。





【副格機の設定】


 副格機側は、スイッチポートの設定のみを行います。


1. 副格機となる SonicWALL の LAN ポート (X0) と クライアント PC の Ethernet ポートをストレートケーブルで繋ぎ、SonicWALL に電源を投入します。



2. http://192.168.168.168/ にアクセスし、ユーザ名を admin、パスワードを password でログインします(製品出荷時のデフォルト)。

3. 管理インタフェースより、「高可用性」 → 「設定」の順に選択します。

 下図のように、「高可用性を有効にする」のチェックボックスのチェックが外れていること、そして、「バックアップ SonicWALL」 のシリアル番号が「000000000000」になっていることを確認します。



 上記のような状態になっていない場合は、工場出荷時の設定に戻し、最初からもう一度やり直してください。

 SonicWALL を工場出荷時の設定に戻す方法は、こちらをご覧ください。
 SonicWALL の初期化(工場出荷時設定)方法


4. PortShield グループより、X2~X4 ポートの設定を解除します。

 PortShield は、デフォルトでは、X2~X4 のスイッチポートにクライアント機器を接続してネットワーク利用できるようになっていますが、HA 構成をする場合は、X2~X4 ポートの PortShield 設定を解除(未定義)に変更する必要があります。

 管理インタフェースより、「ネットワーク」 → 「PortShield」 グループ の順に選択します。

 以下のように、 PortShield グループの設定ページが表示されますので、下図のように X2、 X3、X4 ポートをクリックして黄色に反転させ、選択状態にしてから、“設定”ボタンをクリックします。

注:
ポートを選択できない(黄色に反転しない)場合、「ネットワーク」→「インターフェイス」を選択し、目的のポートの「ゾーン」を「未定義」に指定します。


5. 複数のスイッチポートを編集するためのサブページが開きますので、その中から、「ポートシールド インタフェース」のプルダウンをクリックし、[未定義] を選択して“OK”をクリックします。



6. 元の PortShield グループ設定ページに戻りますので、ポートの X2、X3、X4 が黒抜きになっていることと、ポートシールドの状態が 「未定義」になっていることを確認してください。



7. 管理インタフェースからログアウトし、副格機の電源を落とします。


以上で副格機側の設定は終了です。




【主格機の設定】

1. 副格機に接続していた LAN ケーブルを、 主格機となる SonicWALL の LAN ポート (X0) に繋ぎ替え、アクティブな WAN ケーブルを WAN ポート (X1)に繋ぎ、電源を投入します。



2. 社内の WAN および LAN が正しく動作するように、ネットワーク設定を行います。
(ここではこの操作は省略)

3. PortShield グループより、X2~X4 ポートの設定を解除します。

 PortShield は、デフォルトでは、X2~X4 のスイッチポートにクライアント機器を接続してネットワーク利用できるようになっていますが、HA 構成をする場合は、X2~X4 ポートの PortShield 設定を解除(未定義)に変更する必要があります。

 この設定方法は、前述の副格機の設定と同様ですので、ここでは省略します。

4. 管理インタフェースより、「高可用性」 → 「設定」の順に選択します。

 下図のように、「高可用性を有効にする」のチェックボックスにチェックを入れ、「バックアップ SonicWALL」 に副格機のシリアル番号を入力してから“適用”ボタンをクリックします。


注:
“適用”クリックで「HAでのインターフェースへのIP割り当ては、「静的」である必要があります」とエラーがでる場合、WANに接続するか、「ネットワーク」→「インターフェース」で「ネットワークモード」を「静的IP」に設定します。


5. 管理インタフェースからログアウトし、主格機の電源を落とします。


以上で、主格機側の設定は終了です。




【MySonicWALLに HA 構成を登録する】


 主格機のライセンス構成を副格機に引き継ぐには、MySonicWALL で主格機/副格機の関連付けを行う必要があります。

1. https://www.mysonicwall.com/ にログインし、主格機および副格機の SonicWALL の製品登録を行います(クイック登録でシリアル番号を入力するだけなので、ここでは省略)。

2. 「製品管理」より、主格機として登録した SonicWALL のリンクをクリックし、サービス管理ページを表示させ、ページ下部の「関連済み製品」より、「HA Secondary」 をクリックします。



3. 関連付けが可能な SonicWALL のシリアル番号が表示されますので、副格機となる SonicWALL のシリアル番号を選択してから、“関連”ボタンをクリックします。



 以上でライセンスの関連付けは終了です。

 関連付けを確認する方法は、「製品管理」より、副格機として登録した SonicWALL のリンクをクリックし、サービス管理ページを表示させます。



 上記のように、「このセカンダリ装置はプライマリ装置により管理されています。いくつかのサービス有効化は、プライマリ装置にリダイレクトします。」という表記があれば、主格機と副格機でライセンスの共有がなされていることになります。

 また、「使用可能なサービス」欄で、目的のサービスが「購読済」になっていることも必ず確認してください。




【ケーブルを正しくつなぐ】


 主格機と副格機が正しく動作するように、ケーブルを繋ぎます。

 以下のような接続モデル図を考えた場合のケーブル接続をしてみます。




1. ハブを 2 台用意し、電源を投入します(WAN スイッチ用、LAN スイッチ用)。
 このとき、SonicWALL には電源をまだ入れないでください。

2. WAN スイッチ用のハブにケーブルを接続し、主格機および副格機の WAN ポート (X1) にそれぞれストレートケーブルを繋ぎます。

WAN スイッチ用ハブのイメージは以下の写真のとおりです。



3. LAN スイッチ用のハブにケーブルを接続し、主格機および副格機の LAN ポート (X0)にそれぞれストレートケーブルを繋ぎます。

LAN スイッチ用ハブのイメージは以下の写真のとおりです。



4. SonicWALL 主格機に電源を投入します。

5. 主格機と副格機の X4 ポートどうしをクロスケーブルを繋ぎます。
 SonicWALL では、 X4 ポートを HA 構成用に使います。

ここまで設定が終わると、SonicWALL のケーブル接続は次のようになります。



6. SonicWALL 副格機に電源を投入します。





【主格⇔副格の切替動作チェックを行う】

 主格、副格それぞれの SonicWALL にケーブルが正しく接続され、電源が投入されていることを確認したら、いよいよ切替動作チェックを行います。


1. 主格機 SonicWALL の管理インタフェース(企業の設定によって異なるが、たとえば http://192.168.1.1/ )にログインします。

2. ログイン先が「プライマリ SonicWALL」 になっていることを確認し、続いて「高可用性」→「設定」の順に選択し、状況が、以下の赤囲みのように、バックアップ状況が「待機」になっていることを確認します。

 このとき、副格機 SonicWALL のテストランプ(工具マーク)が、青色→オレンジ色に交互に点滅していれば、主格機と副格機の通信が正しく行われていることを示します。




 このとき、バックアップ状況が「なし」になっている場合は、ケーブル接続、または PortShield の設定に誤りがある可能性がありますので、本記事の当該項目をご覧になりながらもう一度お試しください。

3. 管理インタフェースからログアウトし、主格機 SonicWALL の電源ケーブルを抜きます。
10 秒 ~ 15 秒ほど待ってから、主格機用の管理インタフェース(企業の設定によって異なるが、たとえば http://192.168.1.1/ )にログインします。

4. ログイン先が「バックアップ SonicWALL」になっていることを確認し、「高可用性」→「設定」の順に選択し、状況が、以下の赤囲みのように、バックアップ状況が「動作」になっていることを確認します。

 このとき、副格機 SonicWALL のテストランプ(工具マーク)が、青色になっていれば、副格機が動作状態になっていることを示します。



5. 主格機 SonicWALL と同じネットワーク状態になっていることを確認し、LAN、WAN アクセスの動作状態を確認してから、管理インタフェースからログアウトします。

 そして、再び主格機 SonicWALL の電源を投入します。

7. 15秒~20 秒ほど待ってから、主格機用の管理インタフェース(企業の設定によって異なるが、たとえば http://192.168.1.1/ )にログインします。

8. ログイン先が「プライマリ SonicWALL」 になっていることを確認し、続いて「高可用性」→「設定」の順に選択し、状況が、以下の赤囲みのように、バックアップ状況が「待機」になっていることを確認します。

 つまり、制御が元の主格に戻ったということになりますね。

 このとき、副格機 SonicWALL のテストランプ(工具マーク)が、青色→オレンジ色に交互に点滅していれば、主格機と副格機の通信が正しく行われていることを示します。

注:
主格機の復旧時に自動的に主格機が稼働するようにするには、「高可用性」→「詳細」で、「先制(プリエンプト)モードを有効にする」ボックスをチェックします。ここをチェックすると、主格機がアクティブな場合、主格機が稼働します。ここがオフになっていると、主格機が復旧しても、主格機は「待機」のままとなります。





【HA構成が動作しているときに、副格機の状態を調べる方法】

 SonicWALL で HA 構成が確立されて、動作しはじめると、副格機の工場出荷時の設定は主格機の情報で上書きされてしまうため、http://192.168.168.168 で副格機の管理インタフェースに入ることはできなくなります。

この代わりに、主格機側で、管理インタフェース専用の仮想 IP を主格機および副格機に割り当てることによって、管理インタフェースにログインできるようになります。

 手順は以下のとおりです。


1. 主格機 SonicWALL の管理インタフェースにログインします。

2. 「高可用性」→「監視」の順に選択し、監視設定ページに移ります。
 ここで、下図のように X0 ポートの設定アイコンをクリックします。


3. インタフェース 'X0' の監視設定サブページが開きます。

 下図のように、[プライマリIPアドレス](主格機に割当)、[バックアップIPアドレス](副格機に割当)に同ネットワーク上で利用可能な IP アドレスを入力してから、[プライマリ/バックアップIP アドレスでの管理を許可する] チェックボックスにチェックを付け、“OK”ボタンをクリックします。




 上記の例では、http://192.168.1.101 で副格機の管理インタフェースにアクセスできるようになります。



以上です。


2013-08-14

Windows 8 Pro をドメインに参加させたら、スタート UI のアプリが使えなくなって大慌て

 Windows 8 Pro をインストールして、ドメインに参加させると、Windows 8 のスタート UI に表示されているアプリケーションにまったくアクセスできなくなっていることに気づくことでしょう。



 Windows 8 アプリの対象ユーザは、Microsoft アカウント(クラウドで管理する)を対象にしているのが問題のようです。

 まあ、Microsoft アカウントを登録して、ログインしなおせば Windows 8 アプリを使えるようにはなりますが、Windows ドメインで共通で使っているアカウントがあるのだから、できればそれを使いたいという場合もあるでしょう。

 その場合は、以下の手順でレジストリ情報を一部書き換えることによって、ビルトインアカウント(たとえば Administrator)で Windows 8 アプリを使えるようになります。


1. カーソルを画面の右端下まで移動してチャームを表示させ、検索アイコンをクリックします。


2. アプリ検索用のボックスが表示されますので、regedit と入力します。



 画面左に該当するアプリが表示されますので、アイコンをクリックすると、レジストリエディタが開きます。


3. レジストリキーの一覧より、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken を展開します。



4. FilterAdministratorToken の値を 0 から 1 に変更します。



5. レジストリエディタを閉じてコンピュータを再起動すると、ビルトインアカウントで Windows 8 のスタート画面のアプリを使えるようになります。



Windows 8 がプリインストールされいてるコンピュータに Windows 8 Pro をインストールする方法

Windows 8 を Windows 8 Pro にアップグレードしようとしたら、「問題が発生したため、PC を再起動する必要があります。INACCESSIBLE_BOOT_DEVICE」と表示されて大慌て


Windows 8 には二つのエディションがあり、Pro 版でなければ Windows 8 をドメインに参加させることができません。



一筋縄ではいかなかった Windows 8 → Windows 8 Pro へのアップグレード

 Windows 8 がプリインストールされているコンピュータを購入した場合、社内ドメインに参加させるには、前述のとおり、Windows 8 を Pro 版にアップグレードする必要があります。

 当方の場合は、Pro 版をインストールしようとしたところ、何度かつまづくことになってしまいましたので、備忘録として手順を記載しておきます。


1. Windows 8 がインターネットに接続されていることを確認します。

2.  Windows 8 にログインし、Windows 8 Pro インストールディスクを挿入してから、エクスプローラーを開き、インストーラーを起動します。
 
3. “今すぐインストール”をクリックします。

 

「一時ファイルをコピーしています」という画面に切り替わりますので、しばらく待っていると、以下のような画面が表示されます。




 
 このとき、「オンラインで今すぐ更新プログラムをインストールする(推奨)」を選択します。
 ここでドライバ情報の確認と更新が行われます。

重要:
 当方の場合は、最初にこの選択しを無視してしまったため、インストール途中で再起動がかかった際に、ドライバの問題が発生してしまいました。

 具体的には、青い画面に以下のような文字列が表示され、その後は無限再起動ループに陥ってしまいました。

「問題が発生したため、PC を再起動する必要があります。
エラー情報を収集しています。その後、自動的に再起動します。
詳細については、次のエラーを後からオンラインで検索してください INACCESSIBLE_BOOT_DEVICE」


 ですから、更新プログラムのインストール作業は必ず実行してください。

 途中でドライバの互換性の問題が検出された場合は、そのレポートがデスクトップに作成されますので、問題のあるドライバを事前に手動でアンインストールしてください。


4. 無事にドライバの問題が解消されたら、再度 Windows 8 Pro のセットアップを実行します。
 ライセンス条項では、「同意します」チェックボックスにチェックを入れます。


 
5. インストールの種類選択が表示されますので、ここでは「アップグレード:Windows をインストールし、ファイル、設定、アプリを引き継ぐ(U)」を選択すると、アップグレードインストールが始まります。



 
 これ以降は特にユーザ選択を伴いませんので、説明は省略します。


Windows 8 Pro にアップグレードした後の、プロダクトキーの入力方法

 Windows 8 と Windows Pro のプロダクトキーが異なる場合は、Windows 認証には失敗してしまいます。

 具体的には、以下のようなメッセージが表示されます。

「ファイル名、ディレクトリ名、またはボリューム ラベルの構文が間違っています。(エラー コード 0x8007007B)」

 この場合は、プロダクトキーを新たに入力する必要があります。

1. 画面の右端をスワイプしてチャームを表示させ、「検索」をクリックします。

 

2. アプリの検索画面が表示されますので、検索ボックスに SLUI 03 と入力します。

 

すると、画面の左端に SLUI 03 というアプリが表示されますので、クリックします。


3. 「Windows のライセンス認証」という名前の画面が表示されますので、ここで Windows 8 Pro のプロダクトキーを正しく入力してください。


 
 プロダクトキーの照合が正しくできたら、画面右下の“ライセンス認証”というボタンがアクティブになりますので、クリックするとこのプロダクトキーを使って認証が行われます。


 




2013-07-25

簡単? FileMakerで在庫管理(6) ―― 場所別在庫レコードの作成方法

 ブログ記事「簡単? FileMakerで在庫管理(3) ―― 倉庫など場所別に在庫数を把握する」では、倉庫等の場所別の在庫数算についてご紹介しました。
 今回は、同機能のキモとも言える場所別在庫レコードの作成方法についてユーザ様よりお問い合わせをいただいたので、以下にその概要をご紹介します。

場所別在庫レコードの作成方法

1.場所別在庫テーブルとそのレコードの作成方針


 先の記事で紹介した場所別在庫算出方法では、下図のような場所別在庫テーブルが必要となります。



 ここで必要十分なレコードは、在庫場所テーブルと商品テーブルのデカルト積となります。


例:
在庫場所TBのレコード
A(倉庫)
B(倉庫)
C(倉庫)

商品TBのレコード
X(商品)
Y(商品)
Z(商品)

場所別在庫TBレコード
AX
AY
AZ
BX
BY
BZ
CX
CY
CZ

 さて、場所別在庫テーブルでデカルト積となるようにレコードを生成すると、各倉庫の在庫(=[c場所別在庫数])に漏れはなくなりますが、倉庫に一度も入出庫が発生していない商品がある場合、余分なレコードが存在することになってしまいます。

 たとえば、倉庫Aにおいて商品Xは入出庫したことがあるが、商品Y、Zについては入出庫が一度も発生していない場合、AXレコードは必要ですが、AY、AZレコードは、通常は不要です。
 処理速度が遅くテーブル結合が貧弱な FileMaker では、余分なレコードを極力作成しないように設計すべきでしょう。

 ということで、今回の仕様においては、入出庫登録を行う際に場所別在庫テーブルに当該商品のレコードの登録有無をチェックして、未登録の場合のみ、レコード登録を行うようにします。


2.実装概要


◇リレーションシップ

場所別在庫_入出明細#出庫 (新設、出庫明細TBと場所別在庫TBのリンク用)
場所別在庫_入出明細#入庫 (新設、入庫明細TBと場所別在庫TBのリンク用、下図)
[このリレーションを使用して、このテーブルでのレコード作成を許可]の✔を忘れずに

◇スクリプト

g確定Btn (変更、OnRecordCommitで実行されるスクリプト)
  • 入庫/出庫画面のレコード確定(OnRecordCommit)時に、入出明細ポータルをチェックし、場所別在庫レコードが存在しなければ、同レコードを作成します。
    下図の赤いフィールドは場所別在庫_入出庫明細#入庫::在庫場所IDフィールドですが、これが空欄であるということは、[在庫場所ID]=5(座間倉庫)の当該商品の場所別在庫レコードが存在しないということを意味します。その場合は、[入庫場所ID]の値を[場所別在庫_入出庫明細#入庫::在庫場所ID]に入れ、場所別在庫レコードを作成します。
  • 本スクリプト実行時になんらかのエラーが発生した場合は、エラーが発生した旨のダイアログを表示し、ダイアログ内の“OK”ボタンでレコード確定を中止し、“レコード復帰”ボタンで明細行の作成をキャンセルするようにします。
    場所別在庫レコードの作成に失敗しているにも関わらず入出明細レコードのみ確定されると、その入庫数分の在庫はシステムから消失してしまうので注意が必要です。

3.その他

  • 万が一、関連する場所別在庫レコードがない入出明細レコードが発生した場合に備え、入庫/出庫テーブルに[c在庫場所ErrMsg]フィールドを作成し、エラーが発生した場合にのみ画面に表示する、というのは用心深い良いプラクティスと言えるでしょう。
  • 場所別在庫テーブルは巨大化しやすいので、場所別在庫が0で且つ入出庫が最近発生していない場所別在庫レコードを削除するバッチ処理を検討しておくことが望ましいです。

2013-07-24

簡単? FileMakerで在庫管理(5) ―― 倉庫間移動

 当ブログの在庫関連記事 簡単? FileMakerで在庫管理(3) ―― 倉庫など場所別に在庫数を把握するでは、「FMEasy在庫 R1.0」をベースに倉庫などの在庫場所別に在庫数を算出する方法について概容を説明しました。

 そんな折、「FMEasy在庫 R1.0(開発版)」のユーザ様から、倉庫間移動に関するご質問を頂戴しましたので、今回はその手法をご紹介します。

商品の倉庫間移動


 まず、下図の青色で囲った部分をご覧ください。



 出庫画面に移動先を入力するための[移動先ID]フィールドを配置しています。
 倉庫間移動が発生する場合、ユーザは移動先のIDを入力した後、“倉庫移動”ボタンをクリックします。すると、出庫画面で入力した出庫明細と同内容のデータが入庫にも作成されるという流れになります。


下準備


 取引先マスタに「倉庫間移動」という管理項目を登録しておきます。
 このとき、倉庫間移動の[取引先ID]は「41」であったと仮定してみます。


倉庫移動スクリプト


 倉庫移動ボタンに割り当てるスクリプト仕様はおおまかに以下のとおりです。
  1. $moveTo 変数に移動先IDをコピー。
  2. 出庫明細(ポータル)内のすべての商品ID/出庫数を $prodArrayに変数配列として格納。
  3. 新規ウインドウで入庫レイアウトを開き、新規レコードを作成。
  4. [入庫場所ID]フィールドには変数1、[仕入先ID]フィールドには「41」を入力。同時に[入庫日]、[担当ID]、[伝票区分]にも適切な値を入力。
  5. $prodArray 変数に格納した出庫明細の要素を、入庫明細の商品ID/入庫数に展開。同時に各[在庫場所ID]には $moveTo 変数に保持されている値を設定。
  6. 入庫レコード確定。

 このスクリプトの実行結果は下図のようになります。



注:
  • 入庫明細作成時、場所別在庫テーブルに座間倉庫用の商品が登録されているかチェックし、無ければ登録する。 ここをミスると、商品がシステム上から消失してしまうので、要注意。
  • 入庫画面の[備考2]に移動元のIDと[場所名](倉庫名)を記録するとわかりやすい。
  • 取引先テーブルに各倉庫名を登録、さらに在庫場所テーブルに[取引先ID]フィールドを新設し、そこに各在庫場所に対応する[取引先ID]値を記録し、[仕入先ID]には上記「41」の代わりに、その倉庫の[取引先ID]を入力するのも良い。
  • 社内倉庫間の移動であるから、[仕入単価]は適切に処理 ― 例えば0を入力― する。
  • 倉庫が隣接しておらず、日単位のタイムラグが発生する場合、“倉庫移動”実行タイミングや[入庫日]の値を考慮すること。

2013-06-28

IIS7 でサイトページの内容の一部を自動的に書き換える方法

 Apache では、mod_layout モジュールを使ってページ内容の一部を書き換えたり、URL を変更したりすることができますが、 IIS7 単体ではできません。

 しかし、Microsoft サイトで提供されている URL 書き換えモジュール(URL Rewrite Module) を使うと、同様の操作が可能となります。

 今回は、この URL 書き換えモジュールを使って、ページの文末を書き換える方法について説明します。


1. URL Rewrite Module 2.0 をマイクロソフト公式ダウンロードサイトよりダウンロードし、IIS7 を運用中のサーバにインストールします。

Microsoft URL Rewrite Module 2.0 for IIS 7 (X64) ダウンロード
Microsoft URL Rewrite Module 2.0 for IIS 7 (X86) ダウンロード


 インターネット インフォメーション サービス (IIS) マネージャを起動すると、以下のように、URL 書き換えアイコンが表示されていればインストール成功です。



2. サーバ全体で書き換えを適用する場合は、左ペインのサーバ名をクリックしてから、URL 書き換えアイコンをダブルクリックします。

 URL 書き換えの規則を管理するウィンドウに切り替わりますので、画面下部の「HTTP 応答のヘッダーまたはコンテンツに適用される送信規則」のセクションをクリックし、次に右ペインより「規則の追加...」をクリックします。



3. 送信規則のセクションで「空の規則」が選択されていることを確認し、“OK” をクリックします。


  送信規則の編集ウィンドウに切り替わります。



4. 名前と必須条件を決めます。

 [名前(N)] に任意の名前を入力し(下図では adcode)、[必須条件(P)]の一覧より「<新しい必須条件の作成...>」を選択すると、下図のように必須条件編集ダイアログが表示されます。



 ここで、[名前] に任意の条件名を入力し(下図では bodyEnd)、[仕様] は「正規表現」が選択されていることを確認してから、“追加”ボタンをクリックすると、下図のような正規表現指定ダイアログが表示されますので、以下のように入力します。



 [条件の入力(C)] {RESPONSE_CONTENT_TYPE} (デフォルト)
 [入力文字列が次の条件を満たしているかどうかをチェック] パターンに一致する(デフォルト)
 [パターン(T)] ^text/html
 [大文字と小文字を区別しない] チェック付き(デフォルト)

 ここまで入力が終わったら、“OK” ボタンをクリックすると、必須条件の追加ダイアログに戻りますので、内容を確認してから “OK” をクリックして閉じます。



5. 書き換え用のテキストを設定します。

 画面中央の[パターン]に書き換えるタグを入力し(下図では
)、アクションのセクションでは、[アクションの種類(Y)] は「書き換え」(デフォルト)、[アクションのプロパティ]には任意の文字列を入力します。


 ここでは、ページの末尾を Powered by Tsuchiya Planning Company </body> で書き換えるという規則を指定したものです。

 ヘッダ部分を書き換えるのであれば、[パターン] を </head>、にし、[アクションのプロパティ] に任意の文字列や制御コードと記述し、</head> で閉じるようにします。
 すべての操作が終わったら、ウィンドウ右上の“適用”をクリックします。


6. ページをロードして、設定が反映されていることを確認します。

 試しに、http://localhost/iisstart.htm にアクセスしてみましょう。
 以下のように、指定した文字列がページの最後に表示されていれば成功です。




 この方法を応用すると、サイトのすべてのページにアクセス解析のトラッキングコードを自動挿入したり、ページの先頭や末尾に広告を自動挿入したりすることができます。




2013-06-05

売上猫くん Standard R5(FileMakerランタイム)からPDF出力

  『売上猫くん Standard R5』をダウンロードされた方から、「PDF出力はできないの?」といったお問い合わせを受けることがあります。FileMakerでランタイムされたシステムでは、PDF出力の機能は使用できなくなるのですが、PDF 作成ソフトを利用すると、PDF 出力が可能となります。このPDF作成ソフトでおススメなのが、PDFCreatorというフリーソフト。 フリーといえども侮ることなかれ。 小社の得意先では毎月末、千以上のPDFファイル(ページ数なら数千ページ)をPDFCreator でバッチ作成しています。 が、実行環境によっては出力できない可能性もあります。導入にあたっては、予めPDFCreatorをダウンロードし、十分テストを行うよう、お願いいたします。


【PDFCreatorによる請求書のPDF出力】

PDF Creator を使った PDF 出力


PDFCreatorは『売上猫くん Standard R5』とかFileMakerランタイムとかに関係なく、印刷コマンドを実行するソフトで利用可能(な筈)です。



(亀澤)

2013-05-14

ポータル行を削除しないバグを回避する

FileMaker にはポータル行を削除できないというバグがあり、米国のFM公式サイトではかなり以前から問題になっており、今現在もこの問題は解決されていない。


本家のスレッド
Delete portal row issue


そこで一子相伝の回避策。


  1. ポータル行となっているテーブルをピックアップ
  2. 上記でピックアップしたテーブルがレイアウト設定の[レコード表示(H):]に指定されているレイアウトを作成する。例えば、システムに売上明細、見積明細、受注明細というテーブルがあり、これらがポータルとして使用されていれば、ポータルがあるレイアウトとは別に、売上明細、見積明細、受注明細というレイアウトを用意し、その[レイアウト設定]―[レコード表示(H):]でそれぞれのテーブルを指定する。
  3. システムのスタートアップスクリプトで、上記で作成したレイアウトを開くようにする(開いた後は即刻閉じて良い)。
これによりシステムファイルを閉じなければ削除できなかったポータル行が、普通に削除できるようになる。
「言うとおりにやったが、削除できないじゃねーか!」とお怒り方がおられれば、ご一報のほど。

(土屋)

分離モデルにおけるSUM/ExecuteSQL関数の問題と対策

FileMakerの分離モデルにおいてSUMなどの集計関数を使用すると、計算結果が正しく表示されないことがある。

例:
App.fmp12(アプリファイル)とData.fmp12(データファイル、売上/売上明細テーブルを保持)があり、App側でDataにある2のテーブルを以下のようにリレートする。


◇売上テーブルの計算フィールド
SUM売上:SUM(売上明細::金額)、
SQL売上:ExecuteSQL("SELECT SUM(\"金額\") FROM \"売上明細\" WHERE " & 売上::Id & "=\"fk\"";"";"")


◇レイアウト



上図は新規の売上レコードを作成し、売上明細(ポータル)に入力しているところだが、[SUM売上]と[SQL売上]には本来「40」と表示されるべきところ、誤った値が表示される。

一方、データビューアで、上記の2つの計算フィールドで設定した式を入れてみると、ExecuteSQL側は(恐らく)常に正しい値 40 を表示するが、Sum(売上明細::金額)は正しい値を表示しない。

次にレコードをコミット(保存)してみると、下図のようにすべての4つの項目で正しい値 40 が表示される。


ということで、分離モデルでは上記に関する対策を講じなければならないが、考えられる対策は以下の通り。

  1. レコードをコミット(保存)するようにユーザを教育する。
  2. 数量、単価を変更したときには、コミットを求めるメッセージを画面に表示する。
  3. 計算フィールドの使用を避け、数値型の売上フィールドを用意。ユーザが数値、単価を変更したときには売上フィールドの値が適正に更新されるように設計を行う(スクリプトとスクリプトトリガを利用。このとき、EcecuteSQLの使用が有効と思われる)。
上記1は開発者には一番楽であるが、寛大なユーザばかりとは限らない。
上記2は実装は簡単だが、Webアプリならまだしも、デスクトップアプリ/LANアプリでユーザに操作負担を求めるのはどうか、というのはある。
最後の3の実装はかなり面倒となる。

また、数量や単価を変更したときに、毎回自動コミットするように設計するというのはあり得るが、あまりに美しくない。

ちなみに、小社でリリースしている『FMEasy在庫 R1.0』は上記2を、『売上猫くん Standard R1.0』と『売上猫くん on MySQL R5β』では上記3を採用している。



(土屋)

【関連リンク】
FileMaker の分離モデル
FileMaker の分離モデル - 2


土屋企画の講習 ― 分離モデルに基づく請求書システムを作る(対象者:中級、4時間×2日)




2013-05-12

「レコード/検索条件を開く」ステップとレコードロック


スクリプトステップの一つ、「レコード/検索条件を開く」はどういう時に使うのか?

本スクリプトステップを実行すると現在選択しているレコードをロックできる。FileMaker Ver6以前ではフィールドにカーソルを入れるだけとそのレコードはロックされ、他ユーザは更新不可となったが、7以降では仕様が変わり、フィールド値を変更するか、このステップを実行しない限り、レコードはロックされない。逆にこのステップを実行して301のエラーが返るならば、このレコードは他のユーザが既に編集していることになる。

わかりやすい用例としては、請求書印刷スクリプトの先頭部でこのステップを入れ、他のユーザが当該レコードを編集中している(エラー301が返る)のであればメッセージを表示し印刷を中止する、というのがある。
請求書印刷に限らず、レコードが他ユーザに編集されている状況でなんらかの処理を実行してしまうと不味いという状況は業務アプリではよくあるわけで、本ステップを入れた「g(eneric)競合時処理強制終了」スクリプトを用意しておき、そうした不味い状況が発生しうるすべてのスクリプトの先頭部分に g競合時処理強制終了スクリプト をかましておくことが重要となる。

また、大量のレコードをバッチ更新する場合、FileMakerでは複数行ロックやテーブルロックを行う方法がないので、「レコード/検索条件を開く」ステップを対象レコード間でループ実行させ、301が一度も返らなかった場合にのみ、実際の処理をループさせる(例えば売掛残高更新ループ)というのは一考に値すると思われる。


(土屋)

2013-05-07

売上猫くん Standard R5.0 リリースしました!

2013年5月7日、「売上猫くん Standard R5.0」をリリースしました。

売上猫くん Standard R5 のサイト

【お知らせ】
カスタマイズに関する情報をプレリリースサイトに追加しました(2013/3/22)。
iPhone 機能情報をプレリースサイトに追加しました(2013/3/11)。



土屋

2013-02-19

突然名前解決できなくなる(次回対策用私的メモ)

今朝、自分のPCを起動して社内の他のPCにアクセスしようとるすと、失敗する。
昨日まで全く問題なかったのに。

  > ping his_pc

とやると、

Ping request could not find host his_pc. Please check the name and try again.

とか返ってくる。以前も同じようなことが数回発生した記憶があるが、解決方法については明確な記憶はなく、記録もとらなかったので、例によって後悔しきり。 よって、今回は本稿に記すことにした。

で、次に

> nslookup his_pc

とやると、


Server:  internal_dns.company.jp
Address:  192.168.0.254

Name:    his_pc
Address:  192.168.0.100


と返ってくる。で、

> ping 192.168.0.100

をやると、正常に応答がある。
よって内部DNSは正しく動作しているようだ。が、前回、内部DNSのレコードが誤って記録されていて、それを修正することにより治ったような記憶が微かにあるので、念のため内部DNSを調べてみる。やはりhis_pc のレコードの内部IPは正しく登録されている。次に第3のPCから

> ping his_pc

をやると正しく応答するので、小生のPCのDNSキャッシュ(DNSリゾルバ・キャッシュ)がおかしいようだ。そこで 

> ipconfig /displaydns

をやってみると、予想に反し、his_pc に関する情報が表示されない。予想では his_pc レコードに誤った値が登録されている筈だったのだが… 本来、ipconfig /displaydns についてちゃんと調べるべきなんだろうが、今日は時間切れ、つか面倒になってきたので、エイヤ!と

> ipconfig /dnsflush

 を実行。 すると、名前解決できるようになった。
1年後、同様の現象が起こったら、その時は /displaydns やDNSリゾルバ・キャッシュをちゃんと調べようと誓うのだった。


(土屋)


参考リンク
TCP/IPの設定を確認する「ipconfig」
WindowsのDNSキャッシュをクリアする方法 ‐ CClener の新バージョンではキャッシュが見れるらしい