設計情報に関する詳細な技術情報をまとめました。(ここに記載した内容の詳細なお問い合わせは標準サポートの対象外となることがあります。詳細はサポート窓口へお尋ねください。)

DDLの作成ルール

Wagby はモデル定義から create table 文、drop table 文といった DDL を自動生成します。これは Hibernate の機能を用いています。具体的には Hibernate マッピングファイル (.hbm.xml) から生成されるものです。

DDL の項目の並びは、モデル定義の項目順ではありません。Hibernate マッピングファイルの記載順となります。

DDLの場所

自動生成されたDDLファイルは以下のフォルダに保存されています。

wagbydesigner/webapps/wagbydesigner/WEB-INF/env/work/dbschema/createddl/

制約名

"drop constraint FKXXXX" の、FKXXXXX に相当する部分は Hibernate が自動生成しています。Wagby では特に制御していません。

インデックス

検索条件に対応したインデックス指定は、次のファイルで確認できます。

wagbyapp/webapps/wagby/WEB-INF/export/conf/initdb.xml

テキストエディタでファイルの内容を確認することができます。次の DDL が含まれています。

CREATE INDEX "jfcidx_ModelID_ModelitemName" ON "ModelID"

文字エンコード

Wagby が生成する DDL の文字エンコードは、Wagby Designer を動作させている OS に依存します。

例えば Windows OS 環境では Shift JIS になります。そのためテーブル名やカラム名に日本語を指定するとエラーになります。

回避策

wagbydesigner/bin/setenv.bat に下記の行を追加することで、回避できます。DDLがUTF-8で出力されるようになります。

set CATALINA_OPTS=%CATALINA_OPTS% -Dfile.encoding=UTF-8

ただし、この設定を行うと、Tomcatのコンソール出力が文字化けします。

次に示す単語は予約語であるため、項目名として用いることはできません。

Javaの予約語

abstract
assert
boolean
break
byte
case
catch
char
class
const
continue
default
do
double
enum
else
extends
false
final
finally
float
for
goto
if
implements
import
instanceof
int
interface
long
native
new
null
package
page
private
protected
public
return
short
static
strictfp
super
switch
synchronized
this
throw
throws
transient
true
try
void
volatile
while
アルファベット大文字小文字を区別しません。abstractもAbstractもABSTRACTも予約語となります。
将来のJavaで、予約語が追加される可能性があります。予めご了承ください。

その他の予約語

action
and (JSTLで利用)
application
choose
content
css
customize
div (JSTLで利用)
empty (JSTLで利用)
error
errorcode
exception
eq (JSTLで利用)
ge (JSTLで利用)
gt (JSTLで利用)
help
hour_m
id
img
item
jpermission_m
jprincipal
jshparamを含む名前
juser
label
lt
minute_m
mod (JSTLで利用)
movestep_m
ne (JSTLで利用)
not (JSTLで利用)
now
out
or (JSTLで利用)
pageContext
request
response
session
system
xmlで始まる名前
WEB-INF

Windows OS で利用できない名前

Windows OS で Wagby Designer を利用する場合、次の名前を利用することができません。

con
aux
prn
com1
lpt1

Wagby ではリポジトリ(設計情報)は「名前.txt」というファイル名で管理されます。Windows OS では con という名前は予約されているため con.txt というファイル名がエラーとなります。

モデル名、モデルID は XML の要素名としても使用します。 このため、XMLの名前に使用できない文字を指定することはできません。

具体的には次のルールが適用されます。

  • 1文字目は半角英字、全角ひらがな、全角カタカナ、漢字、「_(アンダースコア)」などの文字を使用することができます。
  • 2文字目以降は1文字目で使える文字に加えて、半角数字などを使用することができます。
  • 半角カタカナや全角数字、全角英字、記号は使用できません。

XMLの名前として使用できる文字の詳細については、XML 1.0のW3C勧告(http://www.w3.org/TR/2004/REC-xml-20040204/#CharClasses)をご覧下さい。

「システム」タブに含まれているモデルの詳細を説明します。

システムモデル一覧

モデル名モデルID用途
バッチジョブ実行結果 jfcbatchjob_execution Spring Batch を利用した場合に有効です。ジョブの実行結果が格納されます。登録処理は Spring Batch フレームワークが行います。更新や削除を行うことは(Spring Batch が)想定していません。運用時は閲覧専用になります。
バッチジョブ実行詳細 jfcbatchjob_execution_context
バッチジョブ実行パラメータ jfcbatchjob_execution_params
バッチジョブインスタンス jfcbatchjob_instance
バッチステップ実行 jfcbatchjob_execution
バッチステップ実行詳細 jfcbatchjob_execution_context
共通設定プリファレンス jfccspreferenceitem 一覧表示グリッドの設定を複数の利用者で共通利用する場合に用います。共通設定を作成したタイミングでデータが登録されます。運用時は閲覧専用になります。更新や削除は行う場合は直接、データベースを操作してください。
フローパターン jfcflow_setting ワークフロー利用時に用いられます。フローパターンを格納します。運用時に独自のフローパターンを追加することもできます。
グラフ設定 jfcgraphsetting グラフ表示の設定を保存し、他の利用者が共通で利用することができます。共通設定を作成したタイミングでデータが登録されます。運用時は閲覧専用になります。更新や削除は行う場合は直接、データベースを操作してください。
ジョブマスタ jfcjob Wagby は Spring Batch とは別に、時間指定によるジョブを用意しています。そのジョブリストを格納しています。その内容は、Wagby インストール時にあらかじめ用意されています。
ジョブスケジュール jfcjobschedule jfcjob で用意されたジョブを実行するスケジュールが格納されます。運用者はジョブスケジュールを追加・編集することができます。
ライセンスファイル jfclicenseholder 本番運用ライセンスファイルに関する情報が格納されます。通常、1レコードを保持します。
メールテンプレート jfcmailtemplate メール送信設定が保存されます。設定した分だけレコードが追加されます。
定義モデル jfcmodel 定義済みのシステムモデルおよびユーザモデルの名称ならびにデータ量を保持しています。開発者や運用者が操作するモデルではなく、閲覧専用として用いられます。
定義モデル jfcmodel4dm
フロー参加者設定 jfcparticipant_setting ワークフロー利用時に用いられます。フローに参加するユーザまたはグループの情報を格納します。運用時に任意に追加することができます。
フロー参加者コンテナ jfcparticipant_setting_node
ポータル jfcportal ポータルを利用する場合に用いられます。ポータルを利用するかしないか、という1レコードのみを保持します。
ポートレット jfcportlet ポータルに表示できる部品情報を保持します。開発者が独自にポートレットを拡張して追加することもできます。
ポートレット(グラフ色) jfcportletGraphColor_m グラフポートレットで用います。インストール時に確定されており、拡張することはできません。
ポートレット(グラフ種類) jfcportletGraphType_m
プリファレンス jfcpreferenceitem 利用者(ログオンアカウント juser)毎に用意されます。一覧表示のソート情報や一覧表示グリッドの列並び情報など、ログオフしても値を保持すべき情報が格納されています。再ログオンすると、前回の情報を復元するために用意されています。登録済みアカウント数 x 保持する情報(key-valueのペア) の数だけレコードが追加されます。レコードの追加、編集、削除はシステム内部で自動的に行われます。
代理者設定 jfcproxy_setting ワークフロー利用時に用いられます。代理承認の設定を行なったときにレコードが追加されます。
帳票テンプレート jfcreporttemplate Excel/PDF帳票利用時に用いられます。設定した数だけレコードが追加されます。
開始フロー状態 jfcstartworkstate ワークフロー利用時に用いられます。自分が申請したワークフローが現在、誰の承認待ちになっているかを知るための管理情報です。システムによってレコードが用意されます。ワークフローが終了してもこのレコードは記録としてデータベースに保持されるため、運用に伴ってデータ量は増加します。管理者が手動で古いデータを削除することが可能です。(削除されたデータは検索対象外になります。)
保留フロー状態 jfcsuspendworkstate ワークフロー利用時に用いられます。自分が承認すべきワークフローを調べるための管理情報です。システムによってレコードが用意されます。ワークフローが終了してもこのレコードは記録としてデータベースに保持されるため、運用に伴ってデータ量は増加します。管理者が手動で古いデータを削除することが可能です。(削除されたデータは検索対象外になります。)
ワークフロー設定 jfcworkflow_setting ワークフロー利用時に用いられます。ワークフローを利用するモデルと、ワークフロー定義を結びつけます。設定した数だけレコードが作成されます。
フローイベント jfcworkstate ワークフロー利用時に用いられます。ワークフローに対するイベント(承認、差し戻し、決裁など)を記録します。システムによってレコードが用意されます。ワークフローが終了してもこのレコードは記録としてデータベースに保持されるため、運用に伴ってデータ量は増加します。管理者が手動で古いデータを削除することが可能です。(削除されたデータは検索対象外になります。)
グループ jgroup システム内部で利用するグループ情報です。登録したグループの数だけレコードが追加されます。
休日 jholiday システム内部で利用する休日情報です。初期値は日本の公休日情報 "JapanHolidays.ics" が登録されています。任意の休日を追加登録することもできます。
お知らせ jnews 利用者へのお知らせをポータル画面に表示することができます。お知らせポートレットを利用した場合にレコードが追加されます。
プリンシパル jprincipal 利用者(ログオンアカウント juser)毎に用意されます。Wagbyの認可機能を実現します。アカウントの登録と編集にあわせて、システム内部で自動的に管理されます。
アカウント juser 利用者(ログオンアカウント)です。登録したアカウントの数だけレコードが用意されます。
順序 seq モデル毎の順序(主キー)を保持します。OracleやPostgreSQLなど、データベースが sequence (順序) サービスを提供する場合には用意されません。MySQLなど、sequence を提供しないデータベースを利用した場合にのみ用意されます。システムが自動的に管理します。

システムモデルの制約

システムモデルには次の制約があります。

  • モデルIDを変更してはいけません。
  • モデルを削除してはいけません。
  • モデルに含まれるモデル項目はID、型を含めすべて変更してはいけません。

以下のモデルは、モデル項目の拡張ができます。

定義済み項目の変更は行えません。具体的には項目名の変更や、型の変更を行うことはできません。
モデル名モデルID用途
グループ jgroup グループ権限管理で用いる。アカウント(juser)と連携している。
アカウント juser ログオンアカウント。
お知らせ jnews 利用者へのお知らせを行うことができるモデル。

ここに記載している以外のモデルは変更することはできません。インストール時の状態でお使いください。 Wagbyのバージョンアップでは、移行ツール適用時に(上記モデル以外の「システム」に属するモデルは)最新版のモデルが適用されます。

テーブル定義

主キーが複合キー形式となっている「商品」モデルを用意します。

図1 商品モデル(主キーが複合キー形式)

「売上伝票」モデルの「明細」部(繰り返しコンテナ)で、商品モデルを参照します。

図2 売上伝票モデル

Wagbyの設計情報の「商品」項目は、「売上伝票」モデルのテーブル定義においては二つの列が用意されます。

図3 売上伝票モデルのテーブル定義

生成される列の命名規則は次のとおりです。

(Wagbyの)項目名_参照先モデルの主キー項目名

Webフォームのパラメータ

複合キーを利用した場合、Wagbyが生成するWebフォームでは次のような形式でデータを扱います。

value1$SEP$value2$SEP$...

ここで value1, value2 はそれぞれ主キー1の値、主キー2の値です。"$SEP$" が値の区切り文字となります。

楽観ロックの実装

Wagbyが利用する Hibernate というミドルウェアが提供する機能を用いています。ただしタイムスタンプ方式ではなく、バージョン方式のみを採用しています。(タイムスタンプ方式は厳密性に欠けると判断しました。)

悲観ロックの実装

Wagby独自のロックマネージャを用います。ロック取得時のキーはメモリに保持されています。特別な内部テーブル jfclockobject でロックキーを管理させることもできます。この場合、外部システムから「どのレコードがロックされているか」を知ることができます。[詳細は次節で説明します。]

データベースの SELECT FOR UPDATE 構文について

いくつかのデータベースには "SELECT ... FOR UPDATE" 構文が提供されています。しかし Wagby のロックは、この機能を使っていません。その理由を説明します。

"SELECT ... FOR UPDATE" はトランザクション内でのみ有効なロックです。 しかし本節で説明しているロック処理は、ユーザの操作を伴うもので、次のような動作が求められるものです。

  1. 更新画面を開く。(ここでデータを SELECT する。)
  2. ユーザがデータを編集する。
  3. 保存ボタン押下でデータを更新する。(データを UPDATE する。)

ここで 1. と 3. ではトランザクションが異なります。このように複数のトランザクションをまたがるような処理は一般に「ロングトランザクション」として扱います。

データベースのトランザクションとは異なるものです。

ロングトランザクションでは、"SELECT ... FOR UPDATE" を使うことができません。 この構文は画面処理ではなく、ある完結した業務処理ロジックの中で使うことを想定したものです。

「保存ボタンを押下した直後に "SELECT ... FOR UPDATE" を実行して...」という考え方ではロストアップデートを防ぐことができず、厳密な悲観ロックとはいえません。

Wagbyではこのようなロングトランザクションでも一貫性を保つため、楽観ロックならびに(独自のロックマネージャを使った)悲観ロックの両方に対応しています。

Wagbyの「悲観ロック」は内部でロックマネージャをもっています。このロックマネージャはメモリ内にロックを保持します。この情報は外部から知ることはできません。

このロック情報を(リレーショナルデータベースの)テーブルに書き込むオプションを用意しています。これによって、外部プログラムから「どのデータがロックされているか」を知ることができるため、ロックされているデータは更新しないといった制御を行うことができます。

さらに、外部プログラム側からロックをかけることで、Wagby側からも更新ができないように制御することもできます。

定義方法

「環境 > カスタマイズ > 詳細 > ロック情報をデータベースのテーブルに格納する」を有効にします。

図4 ロック情報をデータベースのテーブルに格納する

ロック情報を検索する

システム管理者でログオンし、管理処理タブにある「ロック情報検索」画面を開くと、図5のように現在、ロックされているデータが表示されます。

図5 ロック情報を検索する

jfclockobjectテーブル

設定を有効にすると、利用するリレーショナルデータベース内に jfclockobject テーブルが用意されます。

項目名 主キー 説明
modelname ロック対象のモデル名(英語)
pkey ロック対象データの主キーの値。複合キーの場合は"$SEP$"を区切り文字として値を連結する。
lockForAll 数値型。"1" が個別データのロック。"2" がモデル全体のロックを意味する。
userid ロックを取得した(juserアカウントの)userid値。
username ロックを取得した(juserアカウントの)username値。
sessionid ロックを取得したユーザのセッションID値。

あるデータの更新画面を開くタイミングで、jfclockobject テーブルを検索し、該当データに関するロックが存在するかどうかを確認します。すでにロックが存在していた場合、更新画面を開くことができません。存在しなかった場合、同テーブルにロック情報を書き込みます。更新処理が終了したタイミングで、ロック情報を削除します。

外部からロックを取得する

外部プログラムから jfclockobject テーブルにロック情報(レコード)を追加することで、Wagbyの画面から編集できないようにすることができます。

事前に同テーブルにロック対象データがないか確認してからレコードを追加するようにしてください。

jfclockobject テーブルに用意されたすべての列を埋める必要があります。いずれか一つでも、未設定 (null) であった場合、ロックは取得されません。

項目 modelname, pkey, lockForAll は対象データを指し示すために必要です。
項目 userid, username, sessionid は「誰がロックを取得したか」という情報を記録するために必要です。

なお項目 sessionid は Web アプリケーションサーバが発行するセッションIDが格納されます。しかし外部プログラムからこの値を設定する場合、セッションID を生成することは困難です。例えば Web アプリケーションサーバに Tomcat を利用した場合、セッションIDは32文字のランダム文字列です。原則として、ユニークな文字列であれば動作します。

外部プログラムから値を設定する場合は、何らかのルールを決めると良いでしょう。例えばこの値を次のようにします。

$HOSTNAME$APPLICATIONNAME$SEQUENCEVALUE

このようなルールに基づいて擬似的なセッションID文字列をセットすることで、ユニーク性を保ちつつ、誰がロックしたかも視認しやすくなります。

文字列型

データベースに格納される文字列型の標準サイズは次のとおりです。

データベース 定義
Oracle varchar2(255 char)
SQL Server nvarchar(255)
DB2 varchar(255)
MySQL varchar(255) (*1)
PostgreSQL varchar(255)
HSQLDB (内蔵DB) varchar(255)
1. varchar 型で指定する数は MySQL のバージョンによって変わります。4.1 以前は「バイト」単位ですが、それ以降は「文字」単位です。詳細はMySQLのマニュアルでご確認ください。

数値

データベースに格納される数値型の標準サイズは次のとおりです。

データベース 定義
Oracle 整数 number(10,0)
1バイト整数 number(3,0)
2バイト整数 number(5,0)
4バイト整数 number(10,0)
8バイト整数 number(19,0)
4バイト浮動小数 float
8バイト浮動小数 double precision
SQL Server 整数 int
1バイト整数 tinyint
2バイト整数 smallint
4バイト整数 int
8バイト整数 numeric(19,0)
4バイト浮動小数 float
8バイト浮動小数 double precision
DB 2 整数 integer
1バイト整数 smallint
2バイト整数 smallint
4バイト整数 integer
8バイト整数 bigint
4バイト浮動小数 float
8バイト浮動小数 double
MySQL 整数 integer
1バイト整数 tinyint
2バイト整数 smallint
4バイト整数 integer
8バイト整数 bigint
4バイト浮動小数 float
8バイト浮動小数 double precision
PostgreSQL 整数 int4
1バイト整数 int2
2バイト整数 int2
4バイト整数 int4
8バイト整数 int8
4バイト浮動小数 float4
8バイト浮動小数 float8
HSQLDB (内蔵DB) 整数 int4
1バイト整数 int2
2バイト整数 int2
4バイト整数 int4
8バイト整数 int8
4バイト浮動小数 float4
8バイト浮動小数 float8

テキストエリア

文字列型の項目をテキストエリアに変更した場合(またはその逆に、テキストエリア指定を解除した場合)Wagby は関連するモデルのテーブル定義を変更することがあります。例えば外部データベースに MySQL を用いている場合、通常の文字列型は varchar 型を適用しますが、テキストエリアの場合は text 型を用いるようになります。

テキストエリアを指定した項目には「格納できる文字数」の上限があります。これはデータベースによって変動します。 これを変更する場合は"テーブル定義の型"を直接、指定してください。

データベース文字列文字列(テキストエリア)
HSQLDB(組み込みDB)varchar(4000)varchar(4000)
PostgreSQLvarchar(255)text (*1)
Oraclevarchar2(255)varchar2(4000)
SQL Servernvarchar(255)nvarchar(1000)
DB 2varchar(255)varchar(4000)
MySQLvarchar(255)text (*2)
1. PostgreSQL の text 型は 1G バイトです。
2. MySQL の text 型は 65,535 バイトです。

選択肢モデル/リストボックス/ラジオボタン

モデルを参照する側(参照元モデル)の項目では、参照先モデルのID値を保持します。内容部ではありません。

データベース上のテーブルを確認すると、ID値が格納されていることがわかります。

チェックボックス

図6は、標準で用意されているアカウントモデル(juser)のテーブル構成を抜粋したものです。「所属グループ(jgroupid)」項目はグループモデル(jgroup)をチェックボックスとしてモデル参照しています。この項目は juser テーブルには存在しません。代わって「juser$jgroup」という名前のテーブルが作成されます。

図6 テーブルイメージ
  • テーブル名は「モデル名$項目名」です。
  • 所属先となるjuserテーブルの主キーを持ちます。
  • 「項目名jshid」という列が自動的に付加されます。これも主キーの一部になります。これは内部管理上、インデックス列として用意されるものです。
  • 「項目名jshid」の値は 0 から開始されます。また飛び番号はありません。

一つも選択していない状態は、別テーブルに一件もデータがないという状態になります。実際に保持する値(上の例では jgroupid 列の値)は、参照先モデル(jgroup)の主キーになります。

データベースを直接操作する場合、「項目名jshid」は 0 から開始かつ飛び番号なしというルールを遵守してください。不整合が生じた場合、チェックボックス項目は機能しなくなります。

繰り返し項目

繰り返し属性を指定した項目は、別テーブルに分割されます。(1:Nの関係になります。)そのため登録できるデータ数の上限はありません。

厳密には採用する外部データベースの、1テーブルに保持できるレコード数が理論的な上限となります。よって実運用での制約は、なしとみなすことができます。

生成されるテーブルは「モデル名$項目名」となります。

繰り返しコンテナ

繰り返しコンテナは、別テーブルに分割されます。(1:Nの関係になります。)そのため登録できるデータ数の上限はありません。

厳密には採用する外部データベースの、1テーブルに保持できるレコード数が理論的な上限となります。実運用での制約は、なしとみなすことができます。

生成されるテーブル名は「モデル名$(繰り返しコンテナ)項目名」となります。このテーブルの命名規則は固定です。

繰り返しコンテナ項目は、物理カラムを指定しても無視されます。

繰り返しコンテナID

「繰り返しコンテナID」は、標準では "<コンテナ名>jshid" という名前のカラムが用意されます。型は整数型です。

  • 「繰り返しコンテナID」はデータベースに保存する必要があります。データベース非保存とすると正しく動作しません。
  • 「繰り返しコンテナID」はデータベースには "0" から開始される連番として値が保存されています。nullは許容しません。また、飛び番号も認められません。

この「繰り返しコンテナID」の物理カラムを指定することができます。

図7 「繰り返しコンテナID」の物理カラムを指定する

株式会社アイビス様が提供する郵便番号データと、日本郵政公社が提供する事業所の個別郵便番号データを用いて、zipcode.dat を作成する方法を説明します。

  1. 株式会社アイビス様が提供する「zipcloud」にアクセスし、「ダウンロード」リンクをクリックします。同データは無償で公開されています。
    図8 zipcloud
  2. ダウンロードした "ken_allYYYYMM.zip" (YYYYは年号,MMは月) を "ken_all.zip" に改名し、wagbyapp/webapps/wagby/WEB-INF/jmaster に保存します。
  3. 日本郵政公社の郵便番号検索サイト http://www.post.japanpost.jp/zipcode/index.html にアクセスし、「郵便番号データのダウンロード」リンクをクリックします。(毎月一回、月末に更新されます。)
    図9 郵便番号検索サイト
  4. 事業所の個別郵便番号をダウンロードするためのリンクをクリックします。
    図10 事業所の個別郵便番号ダウンロード (1)
  5. zip形式でのダウンロードへのリンクをクリックします。
    図11 事業所の個別郵便番号ダウンロード (2)
  6. 最新データのダウンロードリンクをクリックすると、"jigyosyo.zip" というファイルがダウンロードされます。(ファイルサイズは年月によって異なります。)
    図12 事業所の個別郵便番号ダウンロード (3)
  7. ダウンロードした "jigyosyo.zip" も、wagbyapp/webapps/wagby/WEB-INF/jmaster に保存します。
    図13 jmasterフォルダ
  8. Wagbyアプリケーションを停止します。
  9. コマンドプロンプトを起動し、wagbyapp/webapps/wagby/WEB-INF フォルダに移動します。
    次のコマンドを入力し、実行します。
    java -cp lib/j_util.jar;lib/commons-lang.jar jp.jasminesoft.util.address.GenerateMasterData
    javaコマンドが動作しない場合、「Javaのインストール」手順に従って、Java本体のインストールを行ってください。

    次のように出力されます。

    C:\Wagby-8.x.x\wagbyapp\webapps\wagby\WEB-INF>java -cp lib/j_util.jar;lib/commons-lang.jar jp.jasminesoft.util.address.GenerateMasterData
    Generate Master Data Program. compaction=true
    Reading postal file...done.
    Creating zip file...done.
    
    図14 コマンド実行
  10. wagbyapp/webapps/wagby/WEB-INF/jmaster/zipcode.dat が更新されたことを確認します。
  11. コマンドプロンプトを終了します。
  12. Wagbyアプリケーションを再起動します。
このあとにビルド処理を行った場合は、ここで作成した zipcode.dat を再度、wagbyapp/webapps/wagby/WEB-INF/jmasterフォルダに保存してください。

住所正規化コンバータサーバモジュールは、Wagby販売パートナーからお求めください。

ここでは住所正規化コンバータR6を例に説明します。

Apache Tomcat の設定

Apache Tomcat のサイトから最新の Tomcat を入手します。

ダウンロードして展開した apache-tomcat フォルダを "AnormR6Tomcat" に改名しました。

webappsフォルダの設定

標準で添付されている webapps フォルダ以下のファイルを削除します。

図15 webapps フォルダ以下の標準ファイルを削除する
図16 空になった webapps フォルダ

入手した住所正規化コンバータサーバモジュールを webapps フォルダに展開します。

図17 webappsフォルダにanormが展開された

展開後のwebappsフォルダを示します。

図18 展開後のwebappsフォルダ

web.xmlの編集

anorm/WEB-INF/web.xml を編集します。(Windows OS 付属のメモ帳は使えません。TeraPadなど別のテキストエディタを使ってください。)

"jmasterDirPath" を適切に編集します。住所正規化コンバータが提供する住所マスタである jmaster のパスを指定してください。(Windows OS では、フォルダの区切り文字は円マークを二つ入力します。)

図19 jmasterのパスを指定する

catalina.batの編集

binフォルダに含まれているcatalina.batファイルを編集します。

図20 catalina.batファイル

コメントが終わった部分に、メモリサイズを指定します。

set JAVA_OPTS=-Xmx1024m -Xms1024m

住所正規化コンバータR6は、標準で1Gバイトのヒープメモリが必要のため、これを指定しています。

図21 メモリサイズの設定

server.xmlの編集

住所正規化コンバータサーバとWagbyの開発機が「別である」場合は、この手順をスキップすることができます。

ここでは同一マシンで住所正規化コンバータのサーバとWagbyDesignerを動作させている場合を想定し、住所正規化コンバータサーバのTomcatのポート番号を変更する方法を説明します。

ポート番号が重複していると、サーバの起動に失敗します。
図22 server.xmlを開く

ポート番号 "8005" の部分を、"18005" に変更した例です。

図23 8005番ポートの変更

ポート番号 "8443" の部分を、"18443" に変更した例です。

図24 8443番ポートの変更

ポート番号 "8009" の部分を、"18009" に変更した例です。

図25 8009番ポートの変更

住所正規化コンバータサーバ(Tomcat)の起動

binフォルダのstartup.batを実行します。

図26 startup.batファイル

起動後、住所マスタの読み込みが開始されます。コンソールにはマスタの読み込みに関する表示があります。"Server startup in XXX ms" という表示が出たところで、起動に成功しています。

図27 起動に成功した
住所マスタの読み込みメッセージがないまま起動した場合、住所正規化コンバータは正しく動作しません。web.xmlの設定(住所マスタフォルダの位置)を見直してください。

動作テスト

Webブラウザから住所正規化コンバータサーバを開きます。

http://localhost:8080/anorm/
図28 テスト用画面を開く

住所文字列を入力し、「正規化処理を開始」ボタンを押下します。正規化が行われているかどうか確認してください。

図29 動作テスト(1)
図30 動作テスト(2)

続いてREST APIのテストを行います。アドレスバーに直接、次のように入力します。(入力パラメータは郵便番号です。)

http://localhost:8080/anorm/v1/anorm?zipcode=1030027

結果がJSON表記で返されれば動作テストは終了です。

図31 REST APIのテスト
Wagbyから住所正規化コンバータを利用する場合、この REST API 機能を使います。

内部の構造

Wagby でファイル型の項目を定義するとテーブルには二つのカラムが用意されます。

  • 一つ目のカラムには、オリジナルのファイル名を保存する。
  • もう一つのカラムには、upload_dir フォルダ内の物理的なファイル名を記録する。

ファイル本体はデータベースに格納されません。upload_dirというフォルダ内にモデルIDのフォルダが用意され、その中に一時ファイル名が付与されて保存されます。

図32 upload_dirフォルダ

ファイル型項目を作成すると、対応する(データベースの)テーブルには二つの項目が用意されます。例を示します。

モデル product にファイル型項目 photo を用意したとします。このとき、テーブル product が作成されますが、項目は次のように二つ用意されます。

項目名 説明
photo ファイル名が格納されます。 duke3D.jpg
photo_jshfilename ファイルの存在するパスを示します。起点は wagbyapp/bin となっています。 ../../upload_dir/product/__multi1869501174086226700.tmp
この例では upload_dir に保存される実際のファイルは一時ファイル名(拡張子tmp)となっています。これをアップロードしたファイル名自身を使うようにすることもできます。次の節で説明します。

オリジナルファイル名をそのまま使う

「オリジナルファイル名をそのまま使う」設定時の upload_dir フォルダを図33に示します。アップロード時のファイル名で格納されています。

図33 オリジナルファイル名をそのまま使う設定にした場合のupload_dirフォルダの内容

「オリジナルファイル名をそのまま使う」設定の注意点

運用途中でファイル名の扱いを「オリジナルファイル名を残す」方式に変更する場合

運用後に「ファイル名にオリジナルファイル名をそのまま使う」ように設定を変更して再ビルドし、アプリケーションを入れ替えた場合は次のようになります。

  • その前まで登録されたファイルは拡張子が .tmp のファイル名のまま。
  • アプリケーション入れ替え後に登録したファイルはオリジナルファイル名として保存される。

過去に登録された .tmp ファイル名を、オリジナルファイル名に戻すためのツールを提供しています。 詳細は"ファイル名の扱いをオリジナルファイル名を残す方式に変更する"をお読みください。

ファイルの実体の扱い

ファイルの削除処理を行なった場合、データベースからファイル名の情報は削除されますが、ファイルの実体は残っています。

ファイルの実体を upload_dir フォルダに残す理由は次のとおりです。

  • コピー登録機能を用いた場合、コピー元のデータを削除したときにコピーされたデータからファイルの実体が存在しなくなった、ということを防ぐ必要がある。
  • ファイル型項目の参照連動・自モデル保存の場合、連動元と連動先でファイルの二重管理を行う必要がある。連動元をコピーしても連動先から参照するファイルの実体は残っている必要がある。

物理的なファイルを定期的に削除する

残っているファイル(の実体)を定期的に削除するジョブが用意されています。 "サポート > 管理者ガイド(R8) > 参照されていないファイルの削除ジョブ"をお読みください。

物理的なファイルを同時に削除する

データ削除のタイミングでファイルの実体を削除する方法も用意されています。この方法は上述した「ファイルの実体を upload_dir フォルダに残す理由」に該当しない場合にのみ行なってください。

カスタマイズフォルダ customize/resources に myapplication.properties ファイルを用意し、次の行を加えます。

server.context-parameters.file_delete_mode=UnsavedFile

上記設定を追加後、ビルドを行なってください。この設定はアプリケーション全体に適用されます。

運用途中に直接 application.properteis ファイルを変更することもできます。変更(し、再起動した)後の操作で、ファイルの削除処理が機能します。ただし、変更前のファイルは upload_dir フォルダに残ったままとなります。過去データについては、テーブルに格納されているファイル型項目を直接、SQL で検索し、参照されていないファイルを手動で削除してください。

制約

一覧更新、アップロード更新、一括更新、メール受信、メール送信でのファイル削除には未対応です。また、カスタマイズコードで Dao/Service を使った場合も未対応です。これらは将来の Wagby で対応する計画です。

保存先フォルダの変更

自動生成された WEB-INF\classes\savedir.properties.UTF8 ファイルをテキストエディタで開きます。 次のように記載されています。

# ライセンスファイル
savedir.jfclicenseholder=../../upload_dir/jfclicenseholder
# メールテンプレート
savedir.jfcmailtemplate=../../upload_dir/jfcmailtemplate
# 帳票テンプレート
savedir.jfcreporttemplate=../../upload_dir/jfcreporttemplate
# 顧客
savedir.customer=../../upload_dir/customer

標準では、起点ディレクトリ (wagbyapp\bin) からの相対パスとなっています。保存先はモデル毎に指定できるようになっています。

ここで、変更したいモデルのみエントリを残して編集します。変更が不要なモデルは、もともとのファイルから記述を削除します。 例えば「顧客」モデルのみ保存先を変更したい場合は、次のようになります。

# 顧客
savedir.customer=C://Users//YOURNAME//Desktop//newfolder

編集したファイルを customize\resources フォルダに、mysavedir.properties.UTF8 というファイル名で保存します。

運用開始後に変更した場合

運用途中に mysavedir.properties.UTF8 ファイルを作成した場合、次のルールとなります。

  • 変更前に登録したファイルは、変更前に指定されていたフォルダを参照します。
  • 変更後に登録したファイルは、新しく指定されたフォルダを参照します。
このため、変更前に指定されていたフォルダは消さないようにご注意ください。

その他の情報

"サポート > Wagby Developer Network(R8) > Javaを用いたカスタマイズ > リソースファイル"をお読みください。

データベースによる挙動の違い

一意制約設定を行った項目の一部を未入力(null)として保存した場合の動作は、データベースによって異なります。

項目A, B, Cに一意制約を定義します。ここで A:aaa, B:null, C:ccc というデータを登録します。 その後、A:aaa, B:null, C:ccc のデータを再び登録しようとすると、次のようになります。

内蔵データベース(HSQLDB)、PostgreSQL
登録可能。
SQLServer
一意制約違反で登録に失敗する。

詳細は、ご利用のデータベースのマニュアルをお読みください。

生成されるDDL

ここで指定した一意制約の設定は、次のファイルで確認できます。

wagbydesigner/webapps/wagbydesigner/WEB-INF/env/work/dbschema/createddl/モデルID.ddl

テキストエディタでファイルの内容を確認することができます。次の DDL が含まれています。

alter table "モデルID"
   add constraint jfcuk_モデルID_設定した名前 unique ("項目名");

init_db.bat を実行すると、この alter 文も同時に実行されます。

一意制約名の自動調整

一意制約名は、利用するデータベースが許可する制約名の最大長に合わせて調整されます。

具体的には最大長を超える名前の場合、短縮されます。(短縮の結果、重複する場合には、これを重複しないように一意な名前を割り当てます。これはテーブル名や項目名でも同様です。)

project_filter.xls を変更することで、標準のフィルタルールをカスタマイズすることができます。

図34 project_filter.xls

ダウンロード

ダウンロードしたファイルを解凍し、customize/resources フォルダに保存します。下記の仕様にあわせて、標準のフィルタルールを変更することができます。ビルドを行うと、カスタマイズしたフィルタルールが適用されます。

project_filter.xls 仕様

  • 新しいフィルタを定義することはできません。既存のフィルタ(「フィルタ名」に含まれるもの)の適用ルールを変更することができます。
  • 各数値は、適用の順番を意味します。この数値を変えることで、ルールが変わります。
  • 数値を消去すると、当該フィルタルールは使われなくなります。このとき、数字の並びが順序よく整列されるようにしてください。

インデックスファイルの格納場所

全文検索のために利用する検索用インデックスファイルは次の場所に格納されます。

wagbyapp\webapps\wagby\WEB-INF\idxdir\モデル名

インデックスファイルが変更されるタイミング

インデックスファイルは次のタイミングで変更されます。

  • データの変更(新規登録、更新、削除)
  • インポート処理
  • インデックスの最適化処理

インデックスのサイズ

データをインデックスに登録すると、データ1件に使用されるサイズは、登録対象サイズの最大約7.2倍になります。 このことから、1モデルで使用するインデックスサイズは次のように見積りできます。

インデックスサイズ(バイト) = データ件数 × 平均登録対象サイズ × 7.2

平均登録対象サイズは、全文検索の対象となる項目に格納される文字列数および添付文書に含まれるテキスト文字列数からおおよその数値を出してください。

インデックスファイルのサイズは、扱うデータのサイズより大きくなります。 特に添付ファイルの全文検索機能を有効にするとインデックスのサイズは巨大になります。 データペース用のディスク領域とあわせてインデックス用のディスク領域も十分確保されているかを確認してください。

インデックスの生成ルール

全文検索で利用するインデックスファイルと、サジェストで利用するインデックスファイルは別に用意されています。

全文検索

N-gram インデックス方式を採用しています。N の値は 2 (bigram) を用いています。
これは、文字列の先頭から1文字ずつずらしながら、2文字ずつ抜き出したものを検索語として登録するものです。

例えば "東京都" という文字列の場合「東京」「京都」が検索語になります。具体的な検索動作は次のようになります。

  • "東" ではヒットしない。
  • "東京" ではヒットする。
  • "京" ではヒットしない。
  • "京都" ではヒットする。
  • "東京都" ではヒットする。

ただし半角アルファベット文字についてはスペース等の区切り文字で分割したものを登録します。
例えば "orange pineapple banana" の場合、"orange", "pineapple", "banana" に分割し、それぞれを検索語として登録します。このため検索語に "apple" を入力した場合はヒットしませんが、"pine" はヒットします。

サジェスト

文字列を分割せずにそのまま検索語として登録します。 なお、文字列が 64 文字を超える場合は、先頭から64 文字を登録します。

サジェストの場合は先頭からの一致検索になります。例えば "北九州" という文字列に対して "北" はヒットしますが、"九州" はヒットしません。

インデックスの最適化処理

インデックスファイルは定期的に最適化処理を行うことで、検索スピードを一定に保つことができます。 Wagbyは次のタイミングで最適化処理を行います。

アプリケーションを無停止で稼働させる場合は、インデックス最適化ジョブを設定してください。

手動によるインデックスファイルの再作成

何らかの理由でインデックスファイルが破損した場合、次の手順で再作成することができます。

インデックスファイルは検索用のファイルですので、破損してもデータがおかしくなることはありません。
  1. Webアプリケーションを停止します。
  2. インデックスファイルを削除します。

    特定モデルのインデックスを最適化する場合、例えばsampleモデルのインデックスを最適化する場合には、次のフォルダを削除します。

    wagbyapp\webapps\wagby\WEB-INF\idxdir\sample

    またインデックス全体を最適化する場合には次のフォルダ全体を削除します。

    wagbyapp\webapps\wagby\WEB-INF\idxdir
  3. Webアプリケーションを起動します。初期化処理時にインデックスの作成の後、インデックスの最適化が行われます。

運用時の注意R8.0.5

全文検索を有効にしたとき、Wagbyアプリケーション起動時に検索用インデックスファイルを作成するようになります。この処理が終わらないうちに(全文検索を使った)モデルの登録・更新・削除を行うと、検索用インデックスファイルが作成完了するまで待機します。

このような動作のため、全文検索を有効とした場合は Wagby アプリケーションをメンテナンスモードで起動させ、ログ(system.log)に"インデックス作成完了"と出力されるまで待つという運用を推奨します。

具体的にはインデックスファイルの作成が完了すると次のようなログが出力されます。

 [INFO jp.jasminesoft.jfc.textsearch.servlet.MakeTextIndexThread run] (admin@localhost) finished making textsearch index.

このログを確認後、メンテナンスモードを終了させ、一般利用者に解放するとよいでしょう。

juser モデルのサブモデルは、Designer では作成できません。次のいずれかの対応が必要です。

  • 新規作成したモデルで juser モデルと同じ定義を行なう。
  • juser のリポジトリファイルを手動でコピーしてサブモデルを作成する。[後述]

いずれの場合も、以下に記載する制約にしたがって(サブモデルを)修正する必要があります。

juser サブモデルの制約

juserのサブモデル側に次の項目を含めることはできません。

  • 現在のパスワード(passwdNow)
  • 新規パスワード(passwd) (*1)
  • 新規パスワード(確認用)(passwd2)
  • パスワード更新日 (passwdChangeDate)
  • パスワード更新フラグ (passwdChangeFlag)
  • パスワード入力エラー数 (passwdErrCount)
  • 過去のパスワード (oldPasswds)
  • パスワード強制変更 (compulsoryChange)

このため、サブモデル側でアカウントを作成した場合、パスワードが空白となるため、メインモデル側でパスワードを設定するという運用になります。(またはパスワードの初期値を設定し、初期パスワードを決めておきます。)

passwd項目は初期値が設定されていれば(juserの)サブモデルに含めることができます。

リポジトリをコピーしてサブモデルを作成する

juser のリポジトリファイルを手動でコピーしてサブモデルを作成する方法を説明します。例として「アカウント(juser)」のサブモデルのモデルID を「juser_sub」とします。適切に読み替えてください。

  1. repository\trunk\common-juser フォルダをコピーして repository\trunk\common-juser_sub フォルダを作成します。
  2. 重複している以下のファイルとフォルダを削除します。
    • repository\trunk\common-juser_sub\compulsoryChange.txt
    • repository\trunk\common-juser_sub\compulsoryChange_m
  3. ファイル名をサブモデルのモデルIDに合わせて変更します。
    • repository\trunk\common-juser_sub\juser_sub.txt
    • repository\trunk\common-juser_sub\juser_sub
  4. ファイル repository\trunk\common-juser_sub\juser_sub.txt 内のモデルIDを変更します。
    acl/@id=juser_sub
    action/@descriptionSelect=アカウントサブモデル検索
    displayaction/@id=juser_sub
    model/@description=アカウントサブモデル
    model/@id=juser_sub
    model/@srcfilename=common-juser_sub.xls
    model/displayitemgroup/@id=juser_sub
    modelId=juser_sub
    sendmail/@id=juser_sub
    
  5. リポジトリの再読み込みを行ないます。
  6. 作成したサブモデルに、上記「juser サブモデルの制約」を適用します。
  7. 画面 > その他 > モデルの関連性、のメインモデル名に"アカウント(juser)"を選択します。
  8. アカウントサブモデル検索メニューの表示が必要な場合は、WagbyDesigner のメニュー画面で追加してください。

URLを指定する

外部システムから直接、Wagby 上の画面を開くことができます。URL に次の情報を含めます。

キー 説明
forwardUrl 遷移先画面に関する情報

例えば顧客モデル(customer)の一覧表示画面を開く場合、次のようになります。ホスト名は適切に読み替えてください。

http://localhost:8921/wagby/logon.do?forwardUrl=showListCustomer

最初にログオン画面が表示されます。ログオン後、メニュー画面をスキップして顧客モデル(customer)の一覧表示画面が開きます。

  • パラメータ forwardUrl は「画面名」を記載してください。ここで、画面名とはログオン後のメニュー選択時に URL に表示される部分に相当します。
  • 遷移先画面用の追加パラメータを指定しない場合、末尾の ".do" は不要です。
  • forwardUrl パラメータを省略した場合は、メインメニュー画面へ遷移します。
  • パラメータにログオンアカウントおよびパスワードを指定することはできません。

例:新規登録画面を開く

URL に action_New パラメータを加えます。値部分も同じく "New" とします。

http://localhost:8921/wagby/logon.do?forwardUrl=insertCustomer.do?action_New=New

接頭語 "action_" のあとに続く文字列は「イベント」として扱われます。 詳細は"画面遷移パラメータまとめ"をお読みください。

例:検索条件を付与する

forwardUrl パラメータ内に含める&は、"%26" に置換してください。これは forwardUrl パラメータ以降の文字列をひとまとまりとして扱えるようにするためです。

http://localhost:8921/wagby/logon.do?forwardUrl=showListCustomer.do?action_Search_Condition=Search_Condition%26customer_cp$002f整数型項目1jshparam=整数値%26customer_cp$002f整数型項目2jshparam=整数値
  • 上例で、検索条件を格納するモデル名は customer_cp と表現しています。詳細は「コンディションモデル」をお読みください。
  • 上例の「整数型項目」は適切に読み替えてください。Wagbyでは整数型項目は範囲を指定することができます。開始と終了を、それぞれ接尾語 "1jshparam", "2jshparam" を付与することで区別します。
  • コンディションモデル名と項目名の間は "$002f" で区切ります。これは '/' 文字を utf-8 でエンコードした表現となっています。

例:日本語文字を含む検索条件を付与する

遷移先を showListStaff.do とします。また、検索条件部を次のようにします。

?action_Search_Condition=Search_Condition&staff_cp$002fname=鈴木 一郎

まずパラメータのマルチバイト文字列「鈴木 一郎」のみをURLエンコードします。文字エンコーディングは utf-8 としてください。

?action_Search_Condition=Search_Condition&staff_cp$002fname=%E9%88%B4%E6%9C%A8%20%E4%B8%80%E9%83%8E

次に「画面URL」と「パラメータ」を連結します。

showListStaffSub.do?action_Search_Condition=Search_Condition&staff_cp$002fname=%E9%88%B4%E6%9C%A8%20%E4%B8%80%E9%83%8E

この文字列をもう一回URLエンコードします。

showListStaffSub.do%3Faction_Search_Condition%3DSearch_Condition%26amp%3Bstaff_cp%24002fname%3D%25E9%2588%25B4%25E6%259C%25A8%2520%25E4%25B8%2580%25E9%2583%258E

このようにして作成された文字列を logon.do の forwardURL のパラメータ値として指定します。

http://localhost:8921/wagby/logon.do?forwardUrl=showListStaffSub.do%3Faction_Search_Condition%3DSearch_Condition%26amp%3Bstaff_cp%24002fname%3D%25E9%2588%25B4%25E6%259C%25A8%2520%25E4%25B8%2580%25E9%2583%258E
forwardUrl に指定するパラメータ値のうち「=」「$」「?」「.」はURLエンコードしなくても動作します。つまりURLエンコードが必要な文字は「&」「%」及びマルチバイト文字となります。

まとめますと、日本語文字(マルチバイト文字)は、2回URLエンコードした値に置換してください。

スマートフォンからの操作

スマートフォンの場合は forwardUrl 指定は無効となります。つまりログオン認証後、指定画面へリダイレクトされず、メニュー画面が表示されます。