|
PEXA Serviceについて
チュートリアル
テストツール
定義ファイル
基本プロセス
拡張プロセス
Condition
セッション
モデル
リファレンス
環境設定
|
|
はじめに
|
このドキュメントは、PEXAサービスフレームワークで使用するService定義ファイルについて解説するものです。
サービス定義ファイルは、サービスフレームワークの核となる定義ファイルです。
この定義ファイル中にSVOステートメントで定義されたデータモデルの操作を行う処理を記述し、PEXAのサービス実行エンジンに読み込ませることで動作させることができます。
この定義ファイルでは、ステレオタイプ化されて分類された数種類の実行命令(サービスプロセス)を並べていくことで実際の処理を記述します。
モデルの編集、検索、印刷、イベント送信や、それらの繰り返し、条件判定、他サービスの呼出といったことができるようになっています。
記述形式はPEXA独自のプロパティ形式となります。このプロパティ形式の書式については、リファレンスを参照して下さい。
|
|
|
ServiceSessionについて
|
ServiceSessionとは、サービスの呼出元と呼び出されたサービスが共有するメモリ空間を表すオブジェクトです。
ServiceSessionにはセッションキーを指定してセッション値を格納します。
このセッション値はそのサービスが実行されている間は保持されます。サービスの実行が終わればServiceSessionの内容は破棄されます。
呼出元はこのServiceSessionに対して値を設定することで、サービスに対してパラメータを渡すことが出来ます。
サービスは呼出元から渡されたServiceSessionを使って処理を行います。検索結果や編集結果などは全てこのServiceSession上に格納されます。
呼出元に返される出力パラメータもServiceSession経由で渡されます。この際に返されるパラメータはサービス側で特定のKeyの物だけに限定することもできますし、全てを返すこともできます。
このServiceSession上の値を扱うための書式は、以下のセッションについての各リファレンスを参照して下さい。
|
|
|
Directiveについて
|
Service定義ファイル内で処理を記述する際、Directiveを多用することになります。
Directiveとは、細かい操作命令、動的な値などを表す指示子の総称です。
Directiveは必ず先頭が"&"で始まります。
一例として、
- 現在の時刻を表す日付値 : &Date
- 処理をスキップする命令 : &Skip
といった物があり、これらをプロセス内や条件判定のセクション内などで多用します。
Directiveの詳細については、こちらを参照して下さい。
|
|
|
実行locationについて
|
サービスはClientの実行環境内およびServerの実行環境内の双方で実行することが出来ます。
それぞれ以下のような特徴があります。
|
種別
|
概要
|
長所
|
短所
|
|
client
|
ClientFrameworkの実行JVM内でサービスが実行される。
|
サービス呼出時にRMI等の通信を伴わないので動作が軽い。
|
サービス内で実行される処理にトランザクションを保証できない。
またClientPC上での動作となるので重たい処理には向かない。
|
|
server
|
サーバーサイド(JBoss等)の実行JVM内でサービスが実行される。
|
サービス内で実行される処理全体に対してトランザクションが保証される
(サービス内での処理全体をロールバック可能)。
サーバーサイドでの実行なので重たい処理を行える。
|
呼出に必ずRMI等のサーバーサイドとの通信処理が発生する。
|
このようにそれぞれの特徴がありますので、要件に合わせて適切に指定して下さい。
一般的な基準としては、サービス内に以下のプロセスが１つでも含まれている場合はserverとなります。
- DBを検索するsearchプロセス
- commit=trueのmappingプロセス
- printプロセス
- sendプロセス
上記のプロセスが１つも含まれない場合はclientで特に問題ありません。
以下で解説するService定義ファイル中に、service_location属性という設定がありますので、
実行locationはそこで指定して下さい。
|
|
|
Service定義の内容
|
Service定義の内容に含まれる情報には、主に以下の物があります。
|
Serviceの識別情報
|
Serviceはシステム内でユニークに特定できる必要があります。
そのために、Serviceを識別するための名称を必ず定義する必要があります。
また、サービス実行環境や呼出元へのリターン値などを指定することが出来ます。
詳細はserviceセクションを参照してください。
|
|
|
Service実行の前提条件
|
呼び出されたサービスは、呼出元からServiceSession経由で渡されたパラメータ値を見て自身が実行可能であるかを判定することが出来ます。
必須パラメータの有無や、パラメータの内容によってサービスの実行可否をここで判断し、問題があればエラーを返したりそのままリターンすることができます。
詳細はbefore_conditionセクションを参照してください。
|
|
|
処理プロセス
|
前提条件をパスした場合に、このサービス内で実行する処理内容をこのセクションで記述します。
ここでは、ステレオタイプ化された処理命令であるプロセスを列挙していくことで処理内容を定義します。
モデルの編集、検索、印刷、イベント送信や、それらの繰り返し、条件判定、他サービスの呼出といったことができるようになっています。
詳しくはprocessセクションを参照してください。
|
|
|
Serviceの終了条件
|
処理プロセスのセクションで記述された処理が全て終了した後に、このサービスが正常に処理完了したかを最後に判定することが出来ます。
これにより、全ての処理が終わった後のServiceSession中のパラメータ値を判定して何か問題があればエラーを呼出元に返すことが出来ます。
詳しくはafter_conditionセクションを参照してください。
|
|
|
|
|
Service定義ファイルの全体構成
|
Service定義ファイルの全体構成について、以下に示します。
serviceセクション及びprocessセクションは必須で、before_conditionとafter_conditionは任意となります。
それぞれのセクションの詳細については、以降で解説します。
記述イメージ
;---------------------------------------------------------------
; Release-Date: $Date:: 2016-01-06 13:14:29 #$
; Release-Version: $Revision: 8375 $
; Author: $Author: tann $
; First-Created-On: 2007/04/03
; First-Created-By: Daisuke Morishita
; ---------------------------------------------------------------
;-----------------------------
; serviceセクション(必須)
;-----------------------------
(service
service_name 操作ログを登録する
service_location server
return_keys ""
;-------------------------------------
; before_conditionセクション(非必須)
;-------------------------------------
(before_condition
:
:
)
;-----------------------------
; processセクション(必須)
;-----------------------------
{process
:
:
:
}
;-------------------------------------
; after_conditionセクション(非必須)
;-------------------------------------
(after_condition
:
:
)
)
|
|
|
serviceセクション
|
全体書式 :
(service
service_name宣言部(1)
service_location属性(0|1)
return_keys宣言部(0|1)
service宣言部(0|1)
before_conditionセクション(0|1)
processセクション(1)
after_conditionセクション(0|1)
)
記述注：
属性 あらかじめ決められた値を選択する(true/falseなど)
宣言部 値または、値のリストを設定する
セクション 入れ子で他の属性、宣言部、セクションを保持する可能性がある
(値又は、値のリストが設定される場合もある)
(1)：必須
(0|1)：オプション
(1以上):一個以上必須
(0以上)：0個以上(オプション)
記述例 :
(service
service_name 操作ログを登録する
service_location server
return_keys ""
:
:
:
)
説明 :
serviceセクションは、サービスの識別名や実行環境などのサービス自身の情報を記述するセクションです。
内部の各セクションの詳細については別項で解説します。
このセクションは必須です。
注意：
service_locationの指定に注意して下さい。これは、サービスをどこのVM上で実行するかを決める属性値です。
サービスで実行する処理にはトランザクションをかける(ロールバックを保証する)場合とかけない場合がありますが、
トランザクションをかけたい場合は必ず"server"を指定するようにして下さい。serverを指定すればアプリケーションサーバー上の
SessionBean内の実行エンジンによって処理が実行されますので、サービスの内容全体に対してトランザクションをかけることが出来ます。
属性値 :
serviceセクションの属性値は以下の通り。
|
service_name宣言部
|
記述例 :
service_name 操作ログを登録する
説明 :
必須です。
システム内でユニークになるサービスの識別名を指定します。
|
|
|
service_location属性
|
記述例 :
service_location server
説明 :
省略可能です。
サービスの実行環境の指定です。
以下の３つを指定することが出来ます。
- client：PEXA ClientFrameworkの実行VM上でサービスが実行されます。
- server：デフォルト。アプリケーションサーバーの実行VM上でサービスが実行されます。
- both：呼出元と同一の実行VM上でサービスが実行されます。
|
|
|
return_keys宣言部
|
記述例 : SessionキーAを返す
return_keys "A"
記述例 : SessionキーA,B,Cを返す
return_keys "A,B,C"
記述例 : 返さない場合
return_keys ""
説明 :
省略可能です。
呼出元に返すパラメータのServiceSessionキー名をカンマ区切りで指定します。
何も返したくない場合は、ダブルクオートで空文字を指定して下さい。
省略時はサービスの処理終了時点でServiceSession上に残っている全ての内容が呼出元に返されます。
|
|
|
service宣言部
|
記述例 :
service !xxx.share.service.AAAServiceImple
説明 :
省略可能です。また、ほとんど使用されることはありません。
サービスを丸ごとHelperクラスなどの外部モジュールで実装するような場合にのみ指定します。
service宣言部を記述した場合、processセクションなどが記述されていてもその内容は無視されます。
外部Helper名の記述内容は、Key・値形式での記述を参照。
ここで指定できるHelperクラスはpexa.share.service.ServiceHelperの実装クラスになります。
|
|
|
|
|
before_conditionセクション
|
記述例 : 判定条件が一つの場合
(before_condition
filter "A is not null"
error "Aが設定されていません"
)
記述例 : 判定条件が複数の場合
[before_condition
filter "A is not null"
error "Aが設定されていません"
,
filter "B is not null"
error "Bが設定されていません"
,
filter "C is not null"
error "Cが設定されていません"
]
説明 :
before_conditionセクションは、サービス実行の前提条件を定義するセクションです。
このセクションで定義した前提条件に合致しなかった場合は、サービスの実行自体をスキップしたり、エラーを呼出元に返したりすることが出来ます。
セクションを記述する際の括弧の種類は、判定条件が１つか複数かによって違います。
一つなら"()"を使用し、複数なら"[]"を使用して下さい。
このセクションの記述形式は、プロセス内で記述できるbefore_conditionと全く同じものになります。
詳細は以降に記述されているconditionセクション書式を参照して下さい。
このセクションは省略可能です。必要な場合のみ記述して下さい。
|
|
|
processセクション
|
記述例 : ２つの処理プロセスを持つ場合
{process
;--------------------------------------------------------
; プロセス１：モデルに設定する値を取得
;--------------------------------------------------------
(現在時刻を取得
format_type session
(session
(session_keys
現在日付 &Today
現在時刻 &Now
)
)
)
;--------------------------------------------------------
; プロセス２：操作ログモデルを生成
;--------------------------------------------------------
(操作ログモデルを登録する
format_type mapping
(mapping
commit true
create force
(@操作ログ:OperationLog
PatientNo @PEXA_ModelEventModel/PatientNo
;;OperationModelID ""
OperationModelName @PEXA_ModelEventModel/EntityName
ModelOperationCategory @PEXA_ModelEventOperationCategory
Operator @PEXA_ModelEventModel/LastUpdator
OperationDatetime @PEXA_ModelEventModel/LastUpdateDatetime
Creator @PEXA_ModelEventModel/LastUpdator
CreateDate @現在日付
CreateDatetime @現在時刻
LastUpdator @PEXA_ModelEventModel/LastUpdator
LastUpdateDatetime @現在時刻
)
)
)
}
説明 :
サービスで実行する処理内容を定義するセクションです。
processセクションを囲む括弧の種類は"{}"です。
このセクションでは、処理プロセスを羅列することで実行内容を記述します。
サービス定義ファイル内でユニークとなるプロセス名を任意で付けて、
それぞれに対してプロセスのステレオタイプ(format_type)を指定し、
それぞれのformat_type毎の書式に従って詳細を記述します。
必要な分のプロセスをprocessセクション内に記述して下さい。
プロセスの記述書式についてはこちらを参照して下さい。
|
|
|
after_conditionセクション
|
記述例 : 判定条件が一つの場合
(after_condition
filter "A is not null"
error "Aが設定されていません"
)
記述例 : 判定条件が複数の場合
[after_condition
filter "A is not null"
error "Aが設定されていません"
,
filter "B is not null"
error "Bが設定されていません"
,
filter "C is not null"
error "Cが設定されていません"
]
説明 :
after_conditionセクションは、サービスの終了条件を定義するセクションです。
processセクションで記述された処理が全て終了した後に、このセクションで記述された条件判定が行われます。
このセクションで定義した終了条件に合致しなかった場合は、エラーを呼出元に返すことが出来ます。
セクションを記述する際の括弧の種類は、判定条件が１つか複数かによって違います。
一つなら"()"を使用し、複数なら"[]"を使用して下さい。
このセクションの記述形式は、プロセス内で記述できるafter_conditionと全く同じです。
詳細は以降に記述されているconditionセクション書式を参照して下さい。
このセクションは省略可能です。必要な場合のみ記述して下さい。
|
|
|
conditionセクション書式
|
サービス実行時の前提条件、終了条件をbefore_condition, after_conditionというセクションに記述することができます。
この前提条件、終了条件には以下の種類があります。
- サービス自体の前提条件／終了条件
- 各プロセス毎の前提条件／終了条件
これらはどちらも同じ書式による記述となります。以下でその書式について解説します。
なお、先頭の「※Key・値形式での記述」についてはこちらを参照して下さい。
※Key・値形式での記述
before_condition 条件指定
※マップ形式での記述(条件が一つの場合)
ただし、exist,filter,class,constraintは排他かつ、少なくとも一つが指定される必要がある
(before_condition
exist宣言部(0|1)
filter宣言部(0|1)
class宣言部(0|1)
constraintセクション(0|1)
continue属性(0|1)
assert属性(0|1)
no_check属性(0|1)
error宣言部(0|1)
)
※リスト形式(条件が複数の場合)
必須、非必須については、マップ形式に同じ
[before_condition
exist宣言部(0|1)
filter宣言部(0|1)
class宣言部(0|1)
constraintセクション(0|1)
continue属性(0|1)
assert属性(0|1)
no_check属性(0|1)
error宣言部(0|1)
,
exist宣言部(0|1)
filter宣言部(0|1)
class宣言部(0|1)
constraintセクション(0|1)
continue属性(0|1)
assert属性(0|1)
no_check属性(0|1)
error宣言部(0|1)
,
...
]
記述注：
属性 あらかじめ決められた値を選択する(true/falseなど)
宣言部 値または、値のリストを設定する
セクション 入れ子で他の属性、宣言部、セクションを保持する可能性がある
(値又は、値のリストが設定される場合もある)
(1)：必須
(0|1)：オプション
(1以上):一個以上必須
(0以上)：0個以上(オプション)
以下でそれぞれの詳細について記述します。
|
判定条件の内容指定
|
conditionセクションで判定したい条件については、以下の宣言部やセクションにて指定します。
以下の宣言部、セクションはどれか一つが必ず指定されている必要があります。
|
|
|
判定結果に対する動作指定
|
判定結果に対する動作は以下の属性や宣言部で指定します。
なお、ここでの動作指定は判定結果がfalseとなった場合の指定となります。
判定結果がtrueの場合はチェックOKとなりそのままサービスやプロセスの実行が継続されることになります。
|
動作指定
|
概要
|
|
continue属性
|
条件が偽になった場合、次の条件の真偽についてもチェックを行うかどうかを指定する。
|
|
assert属性
|
サーバーがassertionモードで動作している場合のみ、該当の前提条件のチェックを行う場合に設定する。
|
|
no_check宣言部
|
前提条件のチェックを行うかどうかを判定するServiceSessionキー名を指定する。
|
|
error宣言部
|
条件が偽の場合の処理内容を記述する。
マップ形式による指定を行う場合はerrorセクション書式を参照してください。
|
|
|
|
exist宣言部
|
概要：
ServiceSessionキーの値の存在、非存在条件を指定する。
class宣言、filter宣言、constraintセクションとは排他。
ただし、exist宣言部、class宣言部、filter宣言部、constraintセクションのいずれか一つが存在する必要がある。
キー：「exist」(固定|オプション)
形式：Key・値または、Key・値のリスト
記述１：ひとつのServiceSessionキーの値の存在条件
exist ServiceSessionキー
記述２：ひとつのServiceSessionキーの値の非存在条件
exist ~ServiceSessionキー
記述３：複数のServiceSessionキーに対する存在、非存在条件(","の間に空白などを入れないこと)
exist ServiceSessionキー１,ServiceSessionキー２,...,ServiceSessionキーｎ
|
|
|
filter宣言部
|
概要：
ServiceSessionに対するフィルター条件を指定する。
class宣言、exist宣言、constraintセクションとは排他。
ただし、exist宣言部、class宣言部、filter宣言部、constraintセクションのいずれか一つが存在する必要がある。
キー：「filter」(固定|オプション)
形式：Key・値
記述：
filter ServiceSession条件式
記述の詳細については、別途ServiceSession条件式を参照
|
|
|
class宣言部
|
概要：
外部Helperクラス又は、HelperSessionBeanを指定する。
filter宣言部、exist宣言部、constraintセクションとは排他
ただし、exist宣言部、class宣言部、filter宣言部、constraintセクションのいずれか一つが存在する必要がある。
キー：「class」(固定|オプション)
形式：Key・値
記述：
class 外部Helper名
外部Helper名の記述内容は、Key・値形式での記述を参照。
ここで指定できるHelperクラスは以下の２種類です。
|
|
|
constraintセクション
|
PEXA3以降の機能です。
概要：
データモデルの一意性制約チェック条件を指定する。
filter宣言部、exist宣言部、class宣言部とは排他。
ただし、exist宣言部、class宣言部、filter宣言部、constraintセクションのいずれか一つが存在する必要がある。
従来はsearchプロセスで実際に検索処理を実行し、その結果をafter_conditionでチェックする必要があったが、
この機能によりプロセスではなくconditionとして一意性制約チェックを記述できるようになった。
記述
※マップ形式での記述(条件が一つの場合)
(before_condition
(constraintセクション
model宣言部(1) 対象モデルリソース名
(ptype_namesセクション(1)
ptypeA sessionキーまたはsession式
ptypeB sessionキーまたはsession式
ptypeC sessionキーまたはsession式
:
:
)
filter宣言部(0|1) modelの抽出条件フィルタ式
)
)
単独であれば、単一の業務項目に対する確認になります。
また、ptype_namesに複数の業務項目をしていすれば、その組での一意制約チェックになります。
それぞれ複数の単一の制約条件を記述したい場合は、下記のようにbefore_conditionをリスト化して記述してください。
※リスト形式(条件が複数の場合)
[before_condition
(constraintセクション
model宣言部(1) 対象モデルリソース名
(ptype_namesセクション(1)
ptypeA sessionキーまたはsession式
ptypeB sessionキーまたはsession式
ptypeC sessionキーまたはsession式
:
:
)
filter宣言部(0|1) modelの抽出条件フィルタ式
)
,
(constraintセクション
model model_name宣言部(1) 対象モデルリソース名
(ptype_namesセクション(1)
ptypeA sessionキーまたはsession式
ptypeB sessionキーまたはsession式
ptypeC sessionキーまたはsession式
:
:
)
filter宣言部(0|1) modelの抽出条件フィルタ式
)
,
:
:
]
上記の場合は、ptypeAとptypeBがそれぞれ一意制約チェックされます。
複数の項目を一度にチェックしたい場合は、continue属性にtrueを設定してください。
その場合は、一度に制約エラーがないかチェックされます。
※複数の一意性制約チェックを同時に行う場合
[boefre_condition
(constraintセクション
model宣言部(1) 対象モデルリソース名
(ptype_namesセクション(1)
ptypeA sessionキーまたはsession式
)
filter宣言部(0|1) modelの抽出条件フィルタ式
)
continue true
error "ptypeAの一意制約エラーです。"
,
(constraintセクション
model宣言部(1) 対象モデルリソース名
(ptype_namesセクション(1)
ptypeB sessionキーまたはsession式
)
filter宣言部(0|1) modelの抽出条件フィルタ式
)
continue true
error "ptypeBの一意制約エラーです。"
]
記述例：
例1：WardMasterをWardCodeで一意性制約チェック(新規登録時)
新規登録時に、WardCodeが重複していないかチェックする。
(before_condition
(constraint
model WardMaster
(ptype_names
WardCode @InputModel/WardCode
)
)
error "WardCodeが重複しています。"
)
例2：WardMasterをWardCodeで一意性制約チェック(更新時)
更新時に、WardCodeが重複していないかチェックする。
ただし、DB上に既に存在する自分自身を除外するためにfilterにて自身のProxyを対象外としている。
(before_condition
(constraint
model WardMaster
(ptype_names
WardCode @InputModel/WardCode
)
filter WardNo != @InputModel/WardNo
)
error "WardCodeが重複しています。"
)
|
|
|
continue属性
|
概要：
条件が偽になった場合、次の条件の真偽についてもチェックを行うかどうかを指定する。
マップ形式においては、記述の有無および、記述内容にかかわらず動作は同じ。
省略時は「false」が設定されたと見なされる。
キー：「continue」(固定|オプション)
形式：Key・値
記述１：偽の場合でも次の条件をチェックする
continue true
記述２：偽の場合次の条件をチェックしない
continue false
|
|
|
assert属性
|
概要：
サーバーがassertionモードで動作している場合のみ、該当の前提条件のチェックを行う場合に設定する。
具体的には、アプリケーションサーバーのＪＶＭオプション"-Dpexa_assert=true"が設定されている場合のみ評価対象になる。
assert属性は、サービスを呼び出す側との間の契約に関する条件(必須パラメータの有無など)をチェックする条件を設定する場合に利用する。
これにより、テスト時にはチェックを行い、リリース時にはそのチェックを外すという動作をサービスの記述の変更なしに行うことが可能になる。
assert属性省略時にはfalseが設定されたと見なされる。
記述１：assertionモード時のみにチェックを行う
assert true
記述２：assertionモード時以外でもチェックを行う(通常の前提条件)
assert false
|
|
|
no_check宣言部
|
概要：
前提条件のチェックを行うかどうかを判定するServiceSessionキー名を指定する。
no_check宣言で指定したServiceSessionキーに値が存在した場合、前提条件の評価は行わない。
no_check宣言を利用することで、何らかのWarrningが存在したが、ユーザー指定で強行する場合などの動作が可能になる。
省略時はno_checkに関する処理が行われない。
キー：「no_check」(固定|オプション)
形式：Key・値
記述：
no_check ServiceSessionキー名
|
|
|
error宣言部
|
概要：
条件が偽の場合の処理内容を記述する。
キー：「error」(固定|オプション)
形式：Key・値、またはKey・値のリスト、またはマップ形式
省略時は、固定のメッセージ,エラーコードを含む下記の例外(ServiceException)を送信する。
- エラーコード：-401
- エラーメッセージ：「Service前提条件または終了条件評価エラーが発生しました」
なお、省略時のエラーメッセージは、アプリケーションサーバー起動時に下記のＪＶＭオプションを指定することで変更することができる。
JVMオプション名：「serviceErrorMessage」
記述例：
-DserviceErrorMessage="Service condition error."
※記述１：エラーメッセージを指定
error エラーメッセージ
例外に設定するエラーメッセージを指定する。
エラーメッセージ内に空白を含む場合は""でクオートする
※記述２：エラーメッセージと例外コードを指定
error エラーメッセージ,エラーコード
例外に設定するエラーメッセージ並びにエラーコードを指定する。
エラーメッセージ内に空白を含む場合は""でクオートする
記述例： error "前提条件ＸＸの評価で偽になりました。",10
※記述３：Directiveを指定する
error &Directive
特定の振る舞いを指定する。
Directiveには下記の内容を指定することができる。
&Return
処理をその時点で終了(正常終了)する。
&Skip
Serviceに対しては&Returnに同じ。
ServiceProcessに対しては該当プロセスをスキップして次のプロセスを実行する。
※記述４：外部例外ハンドラを指定する
error !外部エラーハンドラ名
外部エラーハンドラ名の記述内容は、Key・値形式での記述を参照。
ここで指定できるHelperクラスは以下の２種類です。
※記述５：マップ形式による詳細指定
マップ形式で詳細指定することで、エラーコードのみ指定したり、ServiceExceptionに乗せて呼び出し元に送信するセッション値などを指定することが出来ます。
詳しくはerrorセクション書式を参照してください。
記述例１：エラーコード12345, エラー時Sesssion値「パラメータA」を例外で送信
(before_condition
filter "@パラメータA is not null"
(error
code 12345
session パラメータA
)
)
記述例２：エラーコード56789, エラー時Sesssion値「パラメータA」「エラー発生日時」を例外で送信
(before_condition
filter "@パラメータA is not null"
(error
code 56789
(session
パラメータA @パラメータA
エラー発生日時 &Now
)
)
)
|
|
|
Key・値形式での記述
|
条件判定の内容が、値の存在有無チェックのみの場合は、以下のような省略形式で記述が可能です。
※記述１：単一の存在条件(ServiceSessionキー名 is not null)
ServiceSessoinキー名を記述する
before_condition ServieSessionキー名
偽になった場合は、下記の固定のメッセージ及びエラー番号を含む「pexa.share.service.ServiceException」を送信する。
- エラー番号：-401
- エラーメッセージ：必須項目[ServiceSessionキー名]が存在しません。
※記述２：単一の非存在条件(ServiceSessoinキー名 is null)
"~"に続けてServiceSessionキー名を指定する
before_condition ~ServiceSessionキー名
偽になった場合は、下記の固定メッセージ及びエラー番号を含む「pexa.share.service.ServiceException」を送信する。
- エラー番号：-401
- エラーメッセージ：非存在条件項目[ServiceSessionキー名]が存在します。
※記述３：複数の存在・非存在条件の記述
","に続けて複数のServiceSessionキー名を記述する(","の前後に空白を入れてはいけない)。
非存在を条件を記述する場合は、"~"に続けてServiceSessionキー名を指定する
before_condition ServiceSessionキー名1,~ServiceSessionキー名2,...,ServiceSessionキー名n
偽になった場合、指定したキーで偽になった物に関するエラーメッセージの配列を返す。
注意：","形式で指定した場合、最初の条件で偽になっても、２番目の条件移行も真偽の確認が行われます。
- エラー番号：-401
- エラーメッセージ：必須項目[ServiceSessionキー名]が存在しません。
または ：非存在条件項目[ServiceSessionキー名]が存在します。
※記述４：外部Helperクラスの呼び出し
"!"に続けて外部Helperヘルパークラス名(パッケージ名を含む)を指定する。
before_condition !javaクラス名
Service前提条件の記述の場合
JavaHelperクラスは、下記のインタフェースを実装する必要がある。
pexa.share.service.ServiceCondition
また、ステートを持たないように実装する必要がある。
(複数のサービスから共通のインスタンスが呼び出されるため。よって、原則static以外のクラスメンバーは持たないようにする必要がある。)
Service実行時に、ServiceConditionの下記のメソッドが呼び出される。
判定結果が偽の場合で処理をAbortもしくはReturnする必要があればServiceExceptionをthrowすること。
/**
* 条件評価を行う。
* @param service 前提条件の対象となったService
* @param session 実行時サービスセッション
* @return 処理のAbortやReturnの必要が無い場合に判定結果を格納したセッションを返す。
* @throws ServiceException 判定結果が偽の場合でAbortまたはReturnする必要がある場合
*/
public ServiceSession evaluate(Service service, ServiceSession session) throws ServiceException, FatalException;
ServiceProcess前提条件の場合
pexa.share.service.process.ServiceProcessCondition
Service実行時に、ServiceProcessConditionの下記のメソッドが呼び出される。
判定結果が偽の場合で処理をAbort,Skip,Returnする必要があればServiceProcessExceptionをthrowすること。
/**
* 条件評価を行う。
* @param service 前提条件の対象となったServiceProcess
* @param session 実行時サービスセッション
* @return 処理のAbortやSkipやReturnの必要が無い場合に判定結果を格納したセッションを返す。
* @throws ServiceException 判定結果が偽の場合でAbort,Skip,Returnする必要がある場合
*/
public ServiceSession evaluate(ServiceProcess process, ServiceSession session) throws ServiceProcessException, FatalException;
なお、pexaは外部Helperクラスオブジェクトを取得するに当たって、下記の順番でメソッド、コンストラクタを検索する
- staticなgetInstance(pexa.share.util.res.Resource)
- staticなgetInstance()
- pexa.share.util.res.Resourceを引数に持つコンストラクタ
※記述５：外部HelperSessionBeanの呼び出し
"!"に続けて外部HelperSessionBeanのJNDI名を指定する。
ただし、JNDI名の中に":"を含んでいる必要がある。(":"が無い場合、内部ではJavaヘルパークラスだと判断している)
before_condition !JNDI名
Service前提条件の記述の場合
SessionBeanによるHelperは下記のインタフェースを実装する必要がある。
pexa.share.service.ServiceConditionFacade
Service実行時に、ServiceConditionFacadeの下記のメソッドが呼び出される。
判定結果が偽の場合で処理をAbortもしくはReturnする必要があればServiceExceptionをthrowすること。
/**
* 条件評価を行う。
* @param service 前提条件の対象となったService
* @param session 実行時サービスセッション
* @return 処理のAbortやReturnの必要が無い場合に判定結果を格納したセッションを返す。
* @throws ServiceException 判定結果が偽の場合でAbortまたはReturnする必要がある場合
*/
public ServiceSession evaluate(Service service, ServiceSession session) throws RemoteException, ServiceException, FatalException;
ServiceProcess前提条件の記述の場合
SessionBeanによるHelperは下記のインタフェースを実装する必要がある。
pexa.share.service.ServiceProcessConditionFacade
Service実行時に、ServiceProcessConditionFacadeの下記のメソッドが呼び出される。
判定結果が偽の場合で処理をAbort,Skip,Returnする必要があればServiceProcessExceptionをthrowすること。
/**
* 条件評価を行う。
* @param service 前提条件の対象となったServiceProcess
* @param session 実行時サービスセッション
* @return 処理のAbortやSkipやReturnの必要が無い場合に判定結果を格納したセッションを返す。
* @throws ServiceException 判定結果が偽の場合でAbort,Skip,Returnする必要がある場合
*/
public ServiceSession evaluate(ServiceProcess process, ServiceSession session) throws ServiceProcessException, FatalException, RemoteException;
|
|
|
|
|
errorセクション書式
|
before_condition, after_conditionセクションで記述した判定条件の結果が偽だった場合の処理内容をマップ形式で記述する場合の書式です。
この書式を使う場合は、必ずサービス実行をAbortする(ServiceExceptionを呼び出し元にthrowする)という動作になります。
マップ形式以外での指定方法については、error宣言部の書式を参照してください。
※記述１：session部をKey・値形式で記述する場合
呼び出し元にthrowするServiceExceptionに格納するセッション値のキーを羅列する形式です。
ここで指定したセッション値は呼び出し元が読み込んでエラーメッセージ表示のパラメータに使用することができます。
(before_condition
filter宣言部 判定条件
(error
code宣言部 エラーコード(正の整数値)
message宣言部 エラーメッセージを直接記述
session宣言部 セッションキー１,セッションキー２,セッションキー３,....セッションキーN
)
)
※記述２：session部をマップ形式で記述する場合
呼び出し元にthrowするServiceExceptionに格納するパラメータのキーと値を自由に指定できる形式です。
sessionプロセスとほぼ同じ形で記述することが出来るので、判定時のセッション値だけではなくDirective等を指定してその場で値を設定することが可能です。
(before_condition
filter宣言部 判定条件
(error
code宣言部 エラーコード(正の整数値)
message宣言部 エラーメッセージを直接記述
(session
セッションキー１ 任意の値１(文字列、セッション値、Directive等)
セッションキー２ 任意の値２(文字列、セッション値、Directive等)
セッションキー３ 任意の値３(文字列、セッション値、Directive等)
セッションキーN 任意の値N(文字列、セッション値、Directive等)
)
)
)
|
code宣言部
|
エラーコード値を指定します。
ここでは正の整数値を指定してください。負の値はPEXAエンジンが送信するエラーとして予約されています。
指定は任意です。指定されなかった場合は固定で-401となります。
|
|
|
message宣言部
|
エラーメッセージを直接記述することが出来ます。
エラーを受け取った側がエラーコードに対応する表示メッセージを持っていない場合などに使用されます。
指定は任意です。指定されなかった場合は固定で「Service前提条件または終了条件評価エラーが発生しました」となります。
|
|
|
session宣言部
|
ServiceExceptionに格納するエラー時セッション値を指定します。
指定方法はセッションキーを羅列する方法と、sessionプロセスと同じようにその場で任意のキー・値を指定する方法があります。
この宣言部を記述した場合、呼び出し元にはこの宣言部で定義したsessionキーのみで戻る。
サービス上で、メモリを大量に使用しているときは、必ず指定してください。
記述１：セッションキーの羅列
ServiceExceptionに格納したいセッション値のキーをカンマ区切りで羅列します。
記述例
(before_condition
filter "@ParamA is not null and @ParamB is not null"
(error
code 12345
message "A or B is null."
session ParamA,ParamB
)
)
このようにすると、サービスの呼び出し元はServiceExceptionから@ParamAと@ParamBの値を受け取ることが出来ます。
記述２：マップ形式による指定
ServiceExceptionに格納したいパラメータのキーと値をsessionプロセスと同じような形で指定します。
記述例
(before_condition
filter "@ParamA is not null and @ParamB is not null"
(error
code 12345
message "A or B is null."
(session
ParamA @ParamA
ParamB @ParamB
エラー時時刻 &Now
)
)
)
このようにすると、サービスの呼び出し元はServiceExceptionから@ParamA,@ParamBの値およびエラー発生時の時刻をjava.util.Dateで受け取ることが出来ます。
|
|
|
記述例：condition自体がマップ形式(単数)の場合
|
判定条件自体が単数の場合の記述例です。
(before_condition
filter "@ParamA is not null and @ParamB is not null"
(error
code 12345
message "A or B is null."
(session
ParamA @ParamA
ParamB @ParamB
エラー時時刻 &Now
)
)
)
上記の判定結果が偽だった場合、以下のようなエラーが格納されたServiceExceptionが呼び出し元にthrowされます。
エラーコード:12345
エラーパラメータ:ParamA="xxx",ParamB=null,エラー時時刻="2009/01/09:14:20:21"
|
|
|
記述例：condition自体がリスト形式(複数)の場合
|
判定条件自体が複数の場合の記述例です。
必須チェックを項目数分おこなうような形にしています。
[before_condition
filter "@ParamA is not null"
continue true
(error
code 56789
message "A is null."
(session
NullItemName "ParamA"
エラー時時刻 &Now
)
)
,
filter "@ParamB is not null"
continue true
(error
code 56789
message "B is null."
(session
NullItemName "ParamB"
エラー時時刻 &Now
)
)
,
filter "@ParamC is not null"
continue true
(error
code 90123
message "C is null."
(session
NullItemName "ParamC"
エラー時時刻 &Now
)
)
]
このような場合、判定条件が偽になった件数だけエラーコード及びエラーパラメータの組が作成されます。
たとえば上記の全ての判定結果が偽になった場合、
エラーコード:56789
エラーパラメータ:NullItemName="ParamA",エラー時時刻="2009/01/09:14:16:01"
エラーコード:56789
エラーパラメータ:NullItemName="ParamB",エラー時時刻="2009/01/09:14:16:02"
エラーコード:90123
エラーパラメータ:NullItemName="ParamC",エラー時時刻="2009/01/09:14:16:03"
というような３つのエラー内容を格納したServiceExceptionがthrowされることになります。
|
|
|
|
|
Service定義全体のサンプル
|
;---------------------------------------------------------------
; Release-Date: $LastChangedDate:: 2016-01-06 13:14:29 #$
; Release-Version: $LastChangedRevision: 8375 $
; Author: $LastChangedBy: tann $
; First-Created-On: 2007/03/18
; First-Created-By: kimura
; ---------------------------------------------------------------
;Alert及びReminderの一覧を検索して返すサービスです。
(service
service_name Reminder一覧を取得する
service_location server
;return_keys PersonalReminder一覧
{process
(検索対象区分
(before_condition
filter "@検索対象区分 = 選択患者"
error &Skip
)
format_type session
(session
(session_keys
PatientNo @患者情報/PatientNo
)
)
)
(PersonalReminderの検索条件を作成する
format_type session
(session
[session_keys
SF検索条件 "AlertUserNo =",'@ログイン利用者情報/UserNo'
SF検索条件1 "PatientNo =",'@PatientNo'
SF検索条件2 "PersonalReminderConfirmFlag =",'@表示絞込み区分'
]
)
)
(PersonalReminder検索の実行
format_type search
(search
source PersonalReminder
session_value PersonalReminder一覧
filter !quips_demo.share.service.search.base.SearchFilterHelper
sort LastUpdateDatetime
zero_is_null true
)
(after_condition
exist PersonalReminder一覧
error &Return
)
)
(Alertのみに絞り込む
(before_condition
filter "アラート表示状態 = 表示 and リマインダ表示状態 is null"
error &Skip
)
format_type search
(search
source @PersonalReminder一覧
session_value PersonalReminder一覧
filter "CurrentAlertNo is not null"
zero_is_null true
)
)
(Remainderのみに絞り込む
(before_condition
filter "アラート表示状態 is null and リマインダ表示状態 = 表示"
error &Skip
)
format_type search
(search
source @PersonalReminder一覧
session_value PersonalReminder一覧
filter "CurrentAlertNo is null"
zero_is_null true
)
)
}
)
|
|
|
更新情報
|
- 最終更新者 : $Author: tann $
- 最終更新日時 : $Date:: 2016-01-06 13:14:29 #$
- バージョン : $Revision: 8375 $
|
|
|
