1. はじめに
2. Service Frameworkとの関係
3. AET Frameworkの実行
4. 実行時のログ出力
5. AETモデル構成
   1. TransactionとTransactionMetaとの紐付け
   2. TransactionとAccountの紐付け
   3. TransactionとEntryの紐付け
6. AETスキーマ構成
7. AETスキーマ処理の流れ
   1. TransactionSourceモデルインスタンスの取得
   2. AET処理とTransactionSourceモデルとのマッチング
   3. Transactionモデルインスタンスの取得
8. AET Frameworkの機能
   1. Commonモードとオリジナルモード
   2. Transactionの単位とコミット単位の違いへの対応
   3. 残数制約
   4. Transactionインスタンスの削除とロールバック処理
   5. Transactionの移動量変更に対する取り扱い
   6. Transactionの移動量以外の内容変更に対する取り扱い
   7. Accountの引当
   8. 生成型Transactionへの対応
   9. AET処理実行順番制御（展開型Transactionへの対応）
   10. Transactionおよび、TransactionSourceへのフィードバック制御
   11. AccountInitialBalanceに対するamendment
   12. Entryへのトランザクション基準日の設定
   13. 基準日または基準日時を指定したBalance値及びInEntryとOutEntryの総和の取得
   14. Account生成基準日及びAccountが0になった基準日の管理
   15. AETが内部で利用するSessionKey一覧
   16. 例外処理

このドキュメントは、AET Frameworkのアーキテクチャについて解説するものです。

AET FrameworkはServiceFrameworkを補完するサブフレームワークであり、他には無い特徴がいくつかあります。
ここで解説する特徴を把握した上で使用して下さい。

AET Frameworkは、Service Frameworkのエンジン機能を利用して動作します。

通常のService Frameworkと異なる点は、AET FrameworkはServiceスキーマとは異なる独自のAETスキーマを持つことです。
AET Frameworkを構成するクラス群がAETスキーマを直接読み込んで、クラスのレベルでService Frameworkを利用してAET処理を実行します。

AET Frameworkの呼び出しは、Service FrameworkからAET Framework呼び出し用のformat_typeである「aet」を指定して行います。

Serviceプロセス記述例：

(AET_Frameworkの呼び出し
    format_type aet
    (aet
        role    RoleのSessionKeyを指定(省略時は"Role"が選択された物と見なす)
        source  TransactionSourceのSessionKeyを指定(省略時は"TransactionSource"が選択された物と見なす）
    )
)

Transactionを生成する各サービスから呼び出すことも可能ですが、ModelEvent Frameworkにおいて、Transactionになり得るモデルに対するイベントサービスとして扱うことを想定しています。 その場合、各Transaction側のサービスから、ModelEvent Frameworkの呼び出し(format_type=send)を経由して呼び出すことになります。 また、呼び出し時に同期で実行するのか、非同期で実行するのかを指定します。 バッチ型の処理を随時実行する場合は非同期を指定しても問題ありませんが、エラー発生時のロールバックが通知されないので、残数不足などにより業務上ロールバックが発生する可能性がある場合の処理は同期呼び出しか、直接呼び出しで利用する必要があります。

AETフレームワークに対して、Transactionモデルを引き渡すには、sourceで指定したSessionキーにTransaction元になるモデルのインスタンスを設定します。

モデルがヘッダ明細構造を取り、明細側がトランザクション元である場合でもヘッダ側を「source」に設定する事も可能です。その場合、AETスキーマ内で、TransactionSourceに設定されたインスタンスから実際のTransaction元になるModelインスタンス(例えば明細部など）を取得する為のパス式を記述することで対応可能です。ただし、「TransactionSource」そのものに複数のモデルインスタンス（Listや、配列）を設定することは現状できません(需要があれば将来のリリースにおいてサポートする可能性はありません）。

また、AETが内部で処理した際に、Creator,Remover等を設定するためのRole情報（Observable)を取得するためのSessionキーをroleで指定します。 省略した場合は"Role"が指定されたものと見なされます。Roleからは現象型「OperatorNo」が取得できる必要があります。

記述例：
(AET_Frameworkの呼び出し
    format_type aet
    (aet
        role    @LoginUserInfo
        source  @発注     ; 発注明細が処理対象のTransactionとなる
    )
)

AETスキーマによって定義したAET処理の動作を確認するために、実行時ログを出力することが出来ます。
アプリケーションサーバーのJavaVMの起動時オプションに以下を含めることで、サーバーサイドのコンソールログに出力されるようになります。

	-Daet_logging=ON

AET Frameworkは、以下のモデルによって構成されます

• Transaction:AETの起点
• TransactionMeta:一つのAET処理毎にTransactionを管理するために生成。
• Account:残数を管理また、Entryをその明細として保持
• In-Entry:Accountに対する一つのTransactionによる残数のIn(積み上げ)を保持
• Out-Entry:Accountに対する一つのTransactionによる残数のOut(積み卸しを保持)

AET_CommonAccountおよび、AET_CommonEntryは、Commonモードで処理を行う場合のモデルです。
Commonモード/オリジナルモードについてはこちらを参照してください。

TransactionMetaは、Commonモード、Originalモードにかかわらず常に利用されます。
よって、AET_Frameworkを利用するに当たって、データベースにAET_TransactoinMetaモデルに対応するテーブルがあらかじめ作成されている必要がある。作成されていない場合、テーブルが存在しない旨の実行時例外が発生します。

TransactionとTransactionMetaとの紐付け

TransactionMetaは、各Transactionおよび、AET処理単位毎に生成されます。 よって、TransactionとTransactionMetaとの関係は1:N(OperationName数)になります。 TransactionMetaは、Transactionのプライマリキー現象型の値を特定の現象型「AET_TransactionMetaProxyString」に文字列として保持します。 TransactionからTransactionMetaの有無を検索する際にはこの「AET_TransactionMetaProxyString」とAET処理名「AET_OperationName」をキーにTransactionMetaを検索します。文字列に変換されているため、TransactionMetaからはTransaction側を直接には取得することができません。 後述の「Transactionの残数変更に対する取り扱い」やロールバック処理の要不要などの判断の際にTransactionからTransactionMetaへの検索が実行されます。

TransactionとAccountの紐付け

AETスキーマ内において、Transactionに対応するAccountを検索するためのフィルタを指定する必要がある。 AET FrameworkはこのフィルタをつかってAccountの検索および、有無の確認を行う。 Commonモードにおいては、Transactionの指定された現象型の値を、AET_CommonAccountの特定の現象型「AET_AccountProxyString」に文字列に変換して保持しておいて、Transactionから取得した値でAET_AccountProxyStringに対してAET処理名と合わせてフィルタをかけることでAccountインスタンスを特定しています。 AET_AccountProxyStringに設定される現象型は、通常Transactionが保持する各種ソースマスタのプライマリキーに相当する現象型などが用いられる(例：受注明細の商品マスタNo等)。 オリジナルモードにおいては、Accountモデルに対して、Transaction側が保持するマスタの通番などを設定し、その通番で一意に特定するようなフィルタを独自に記述する必要がある。また、生成型のトランザクションにおいては、Account生成時に一意キーに相当する現象型の設定も合わせて記述する必要がある。

TransactionとEntryの紐付け

一般的にEntryはAccountの明細として取り扱われる必要がある。Commonモードにおいては、TransactoinMetaとEntryとの紐付けのためにEntryは、必ず（オリジナルのEntryであっても）TransactionMetaのプライマリキー「AET_TransactionMetaNo」を持ちます。

AET Frameworkのスキーマは、一つのTransactionSource・Transaction単位による、一つのAccountに対する積み上げ(in)又は積み卸し(out)処理単位に記述します。

よって、同一Transactionでも対象のAccountが別であれば、別のAET処理として管理され、同一Transactionまたは同一Accountであってもin,outが別であれば別のAET処理として管理されます。なお、スキーマ内においてin,outの連続性が保証されているかどうかは関知しません（基本的に積み上げ、積み卸しだけのTransactionも存在するため）。各AET処理にはそれぞれユニークな名前とIDをつける必要があります。AET Frameworkは、このAET処理名(aet_name)を一意キーとして動作します。

各AET処理単位毎に、起点となるTransactionの指定、対象のAccountモデルに対する指定、Accountの残数に関する制約、Entryモデル対する処理および、Transactionモデル対するAET処理後のフィードバック処理等を記述します。なお、詳細については、スキーマリファレンスを参照してください。

AETスキーマは、以下の流れで実行されます。

TransactionSourceモデルインスタンスの取得

Sessionキー「AET_TransactionSource」から値を取得。 なお、AET_TransactionSourceの値がnullの場合は、ServiceProcessExceptionを送信します。 もし、TransactionSourceが存在しない場合は、処理をスキップしたい場合は、ServiceProcessのbefore_conditionにおいて存在チェックおよび、存在しない場合のスキップ処理を記述します。

AET処理とTransactionSourceモデルとのマッチング

TransactionSourceのモデル名(Modelスキーマのresourceキーに指定されている名前)をキーに対応するAET処理名を検索します。 存在しない場合は、そのまま処理を終了。複数のAET処理が存在する場合は、以下の処理をAET処理単位に繰り返し実行します。

Transactionモデルインスタンスの取得

TransactionSourceから実際のTransactionの元になるモデルの取得方法が指定されている場合、Transactionモデルを取得。 取得方法が指定されていない場合は、TransactionSourceそのものをTransactionとして取り扱います。 Transactionが複数(Listまたは、配列）の場合、以下の処理をTransactionの数分だけ繰り返します。

AET Frameworkは単純な残数管理の記録以外にもいくつかの特徴的な機能があります。
以下でそれらについて説明します。

Commonモードとオリジナルモード

AET Frameworkは二つの動作モードを持っています。Commonモードとオリジナルモードです。 CommonモードはAET Frameworkがあらかじめ用意したAccount、Entryモデルを利用してAET処理を管理するモードであり、オリジナルモードは独自のAccount,Entryを指定して動作するモードです。 Common処理を利用した場合、AET処理を追加するに当たってAccount,Entryのモデルを用意することなくAETスキーマの追加だけでAET処理を追加することができます。 ただし、基本的にはAccountの残数および、EntryによるIn,Out数のみが管理され、Accountや、Entryに独自の属性を持たせることはできません。そのため、Entryや、AccountをTransactionから切り離してそれぞれ独自に集計したい場合などには利用することができません。 一方オリジナル処理の場合は、AET Frameworkに対してAccountおよび、Entryとして利用するモデルを指定して動作するモードです。この場合、Accountおよび、Entryに対するマッピング処理をAETスキーマ内部に記述することができるので、独自に属性項目などを持たせることが可能です。また一つのAccountモデルで複数の残数を制御する(非推奨）事も可能である。ただし、当然Account,Entryに対する生成、更新の際のmapping処理を記述する必要があるため、AETスキーマに記述する必要がある情報量もCommon処理に比べると多くなります。 モード 追加 記述量 Common スキーマのみ 最小限 オリジナル スキーマ＋モデル マッピング情報を含む

Transactionの単位とコミット単位の違いへの対応

Transactionの単位と呼び出しもとServiceのコミット単位が異なる場合があります。例えば、ヘッダ・明細関係のモデルの場合、明細がTransaction単位であるが、コミット（Serviceの処理）としては、ヘッダ側になる場合があります。 例：受注->受注ヘッダ・受注明細（こちらがTransaction単位)。 Transaction処理側(呼び出しもと)側がCommit単位で扱えるように、AET Frameworkへは、コミット単位のインスタンス（上記の例で言うと受注ヘッダ）で引き渡しが可能になっています。 具体的には、AET処理内でTransactinSource(AET Frameworkへ引き合わされたインスタンス)からTransaction単位のインスタンス（上記の例で言うと受注明細)を取り出し方を指定可能になっています。取り出したTransaction単位が複数(Listまたは、Updatableの配列）の場合、AET処理は、Transaction単位のインスタンス数分だけ繰り返して実行されます。 ただし、AET処理とのマッチングは、TransactionSourceのモデル名に対して行われる(上記例で言うと受注ヘッダ)側になります。Transaction単位の取得方法が指定されていない場合は、TransactionSourceをTransaction単位として扱います。なお、AET FrameworkへのTransactionSourceの引き渡しは一インスタンス毎で複数は引き渡せません。 また、TransactionSourceおよび、Transactionに対してそれぞれ独自にフィルタを設定可能です。フィルタが設定されている場合は、フィルタにマッチしたTransactionSourceおよび、TransactionだけがAET処理の対象になります。なお、フィルタの記述方法はServiceのsearchプロセスにおけるfilterセクションの記述方法に同じです。

残数制約

AET Frameworkは、Accountの残数の状態に対する制約を設定することが可能です。残数の制約は常時存在する制約とロールバック時に追加で発生する制約の2種類があります。つまり、ロールバック時は、常時制約にロールバック時制約を加えて残数制約をかけることができます。残数制約違反が発生すると、ServiceProcessExceptionが送信されAET処理自体がロールバックされます。 常時の残数制約は、大きく二つが存在します マイナスを許すか否か リミット値 リミット値が設定されているとリミット値を超えた残数を保持することができません。ロールバック時については、さらに以下の二つを追加して設定することが可能になっています。 ロールバック後にプラスである（これは、常時とは独立に設定できるようになっている） Account生成時の残数と同じである 特にAccount生成時の残数と同じであるは、誰も使っていない場合のみロールバックできる場合などの指定に便利です。

Transactionインスタンスの削除とロールバック処理

すでにAET処理が実行されているTransaction（Transactionに対応するTransactionMetaが有効)が削除(RemovedFlag=REMOVED)になった場合、AET Frameworkは自動的にロールバック処理を実行します。 ただし、ヘッダ・明細関係かつ明細側がTransactionになっている場合、明細を削除してCommit後にAET Frameworkを呼び出すと削除された明細のインスタンスそのものがヘッダから取得できなくなってしまうため、削除されたことがAET Frameworkから認識されません。 これを避けるためには、以下の３つの手段の内いずれかで対応を行います。 Commitする前にAET Frameworkを呼び出す Commitを実行しているService内のmappingプロセスにおいて、no_trim=trueを指定する 削除(RemovedFlag=REMOVED)、AET_RollbackedFlag=ROLLBACKEDを利用する Transactionインスタンスが、AET_RollbackedFlagを持ち、AET_RollbackedFlag=ROLLBACKEDが指定されている場合、AET Frameworkは、RemovedFlagの状態にかかわらず、ロールバック処理を実行します。 なお、Transactionが削除されてもTransactoinMetaは、AET_RollbackedFlag=ROLLBACKEDが指定されるだけで、削除(RemovedFlag=REMOVED)はされません。よって、Transactionが削除されてもTransactionMetaを検索することでTransactionの存在の痕跡(履歴)を確認することは可能になっています。 ロールバックしても、AET_TransactionMetaは、AET_RollbackedFlag=ROLLBACKEDが設定されるだけで、特に削除は行われません。 よって、Transaction側がRemovedFlag=REMOVEDで削除されてもAET_TransactionMetaは履歴を確認することができます。ただしこの場合、原則Transaction側は削除されてしまっているので、AET_TransactionMeta側からTransactionを引くことはできません(TransactionがMasterとして宣言されている場合は可)。 ロールバック後もTransactionをAET_TransactionMetaから参照する場合は、RemovedFlagではなく、AET_RollbackedFlagによるロールバック制御を行う必要があります。 Entryについては、特に何も指定しない場合、ロールバック時にEntryの削除(RemovedFlag=REMOVED)が行われます。 ただし、Commonモード時においては、entryセクションのrollbacked_onlyキーに値「true」を設定することで、削除(RemovedFlag=REMOVED)するかわりに、RollbackedFlag=ROLLBACKEDを設定するのみにとどめます。 rollbacked_only=falseまたは、省略した場合は、RemovedFlag=REMOVEDおよび、RollbackedFlag=ROLLBACKED両方が設定されます。 オリジナルモード時においては、entryセクションにセクション「rollbacked_mapping」を設定することで、ロールバック実行時にEntryの変更内容を自由に設定することができます。また、rollbacked_only=trueのみを設定した場合は、Entryモデルに対してAET_RollbackedFlagおよび、AET_RollbackOperator,AET_RollbackDatetimeの３つの現象型に対して以下の値を設定します。 AET_RollbackedFlag=ROLLBACKED AET_RollbackOperator=@AET_Role/OperatorNo AET_RollbackDatetime=&Now オリジナルモード時においても何も設定しない場合は、削除(RemovedFlag=REMOVED)が設定されます。 なお、削除処理時は、RemovedFlagだけでなく、Remover,RemoveDatetime,RemoveDateも合わせて値の設定が自動的に行われます。

Transactionの移動量変更に対する取り扱い

Transactionの移動量が変更になった場合の処理として、二つのモード「Amendモード」と「ロールバックモード」という二つの処理モードを選択可能です。 「Amendモード」はTransactionの移動量が変更になった場合、前回のTransactionの移動量との差分分だけ追加のInまたは、OutのEntryを生成するというモードである。この場合、移動量が減少した場合は、Entryにはマイナスの移動量を保持するEntryが生成されます。それに対してロールバック処理は一度Transactionがロールバックされてから、新規に更新された移動量によるTransactionが実行されます。 「Amendモード」を利用するべきか「ロールバックモード」を利用すべきかは、純粋に業務上の仕様に基づきます。 次のトランザクションが実行されていても修正が発生する可能性がある（許容すべき）場合は、「Amendモード」を使うことで、一連のTransactionを後ろから一度ロールバックをして再入力をするという手間を省くことができますが、修正に対するAET Frameworkとしての制約は特に存在しません。 「ロールバックモード」を利用した場合、残数がマイナスにならない制約を同時につけておけば、次のトランザクションがすでに行われている場合は残数がマイナスになるので、AET Frameworkレベルでロールバックができない旨の例外を送信し修正をブロックすることができる。 なお、生成型のトランザクション(Accountが存在しない場合は、Transactionの実行と同時にAccountを生成する）場合、Accountに生成時のバランス値を保持するように指定することができるので、ロールバックの例外によるブロックではなく、Transaction処理側で、初期バランス値と現在のバランス値を比較してTransactionのロールバックが実行可能かどうかを判断することも可能であり、オリジナルモードで処理を行っている場合ではこちらの方がパフォーマンス的には負荷が小さく仕様的にも明確です。 ただし、「Commonモード」を利用している場合、Transaction側に特定のCommonモードのインスタンスに関する判断処理が入るのを避け、AET Frameworkからの例外に基づき処理すべきです。

Transactionの移動量以外の内容変更に対する取り扱い

Transactionの移動量以外で内容変更が発生した場合に、AET処理をやりなおしたい場合があります。 例えば、在庫引き当て処理において、引き当て数量はそのままで、別の在庫から引き当てし直したようなケースです。 このような場合、引き当て元のAccount自体が変更になるため、数量の調整だけでは対応できません。 一度ロールバックしてからAET処理を改めてやり直す必要があります。 しかし、AETエンジン側だけではこのAET処理のやり直しを行うべきかを検出することはできないため、 AETエンジンの呼び出し元側で指示する必要があります。この指示を行うために以下の現象型が用意されています。 AET_TransactionRedoFlag AET処理のやり直しを行いたいTransactionに該当するデータモデルに対して、このAET_TransactionRedoFlagに値として"REDO"を設定してからAETエンジンを呼び出すと、 AETエンジンでは強制的にロールバックしてからAET処理を新規に行います。 ※注意※ このAET_TransactionRedoFlagはDBに値を保存したくない項目なので、モデル定義には記載しないでください。 DBに状態が保存されてしまうと、そのTransactionをAET処理にかけると常にAET処理のやり直しが発生してしまいます。 この項目は実行時にメモリ上で一時的にモデルに設定されて、コミットされたら消去される揮発性項目として扱います。

Accountの引当

一つのTransactionに対して複数のAccountが対象になる場合、手動による引当と自動による引当の2種類の動作を選択することが可能です。 自動の場合は、ソート順番による引当指定および、案分ロジックによる引当指定を選択することが可能です。ソート順番による引当を行う場合は、account/assignment/orderセクションにおいて、accountのソート順番を指定することで、このソート順にトランザクションの引当を行います。2010/05時点においては、案分ロジックによる自動案分については未実装です。将来的には、TransactionおよびAccountの属性情報から引当結果を生成を可能にする予定です。 Transactionから現象型「AET_AssignmentList」が取得できた場合、手動での引当になります。「AET_AssignmentList」は、以下の３つの項目からなるCombination型かつMultipleの現象型です。 AET_OperationName AET_Account AET_AccountAssignAmount AET_OperationNameが実行中のAET処理におけるAET_OperationNameと一致した場合のみ手動引当が実行されます。よって、あるTransactionが複数のAccountに対するTransaction処理を実行する場合、AET_OperationNameを設定することによって、どのTransaction処理に対する手動引当なのかを認識することができます。またこれにより、複数のTransactionに対する手動引当を定義することが可能になっています。 引当の方法は、「AET_Account」に引当対象のAccountモデルインスタンス(Updatable)を設定し、「AET_AccountAssignAmount」にBigDecimalで引当数を設定する。「AET_Account」に設定するのは、モデルインスタンス(Updatable)であり、Proxyではないことに注意が必要である。つまり、手動引当を行う場合は、他のプロセスにおいてすでにAccountのインスタンスが取得できている必用がある。また、手動引当の際には「AET_AccountAssignAmount」の合計がTransactionの移動量に一致しているかどうかは、AET_Framework側でチェックしており一致しなかった場合はServiceProcessExceptionを送信します。

生成型Transactionへの対応

accout/careateセクションを記述することで、Transaction実行時に対象のAccountが存在しない場合は、それを生成するという処理（生成型トランザクション）を記述することが可能です。また、Accountを生成したTransactionがロールバックされた際にそれを削除するかどうかを選択することが可能です。削除をするを選択した場合、生成したTransactionのロールバックが可能な場合(ロールバック後の残数が0である)、Accountの削除も同時に実行されます。 削除時点でAccountの残数が0に一致していない場合は、エラー番号「900306」、エラーメッセージ「ロールバック処理および、アカウントの削除に失敗しました。アカウント生成トランザクションがロールバックされた際にアカウントの削除が指定されていますが、ロールバック後のアカウントのバランス値が0になりません。生成時のトランザクション以外にのトランザクションによりバランスが変更されている可能性があります。」のFatalReasonを含むServiceProcess例外が送信されます。

AET処理実行順番制御（展開型Transactionへの対応）

AET Frameworkは、一つのTransactionに対してAET_OperationName単位かつ単位に積み上げ(Accountに対するIn-Entry生成処理)と積み卸し(Accountに対するOut-Entry生成処理)毎に独立かつ順不同で実行します。 これは、原則同一Transactionが同一AccountのIn,Out両方に出てくることがないという前提に基づきます。つまり、一つのTransactionについては、どのAET_OperationNameから実行しても原則同じ結果になる前提です。 しかし、一部のTransactionについては、一つのAccountのIn側Out側両方に同一Transactionが来ます。このようなケースをPEXAのAETビジネステンプレートにおいて展開Transactionと呼んでいます。 展開Transactionの場合は、Out側が先に実行された場合、本来は成功すべきTransactionが残数制約に（まだIn側が実行されていないので、残数が不足している）より失敗する可能性があります。 AET_Frameworkでは、「before_aet_name」にこのOperationを実行する前に実行すべきAET_OperationNameを記述することで、 まだbefore_aet_nameに指定されたOperationが未実行の場合、こちらを先に実行してから該当のOperationを実行する機能を提供することで、 展開Transaction時におけるOperationの順次実行をサポートする。

Transactionおよび、TransactionSourceへのフィードバック制御

Operationまたは、ロールバック時にTransactionおよび、TransactionSourceに対するフィードバック更新を実行する機能をサポートしている。 基本的にServiceのmapping相当の記述が可能であり、そのmapping中において、SessionKeyとして以下を利用することが可能です。

AccountInitialBalanceに対するamendment

AETスキーマのaccount/amountセクションに以下の設定を記述することで、 amend_initial_amount "true" InitialAmountを設定したtransactionのAmountが変更になった場合にAccountデータモデルのAccountInitialBalanceの値も自動的に更新するようになりました。 設定がない場合のデフォルトはfalseです。ただし、InitialAmountを設定したtransactionがロールバックされた場合は、特に変更はしません。 なお、この仕組みを利用するには、Accountのデータモデルが項目として「AET_AccountInitialTransactionMetaNo」を持っている必要があります。

Entryへのトランザクション基準日の設定

Entryに対する新しい共通項目として下記の現象型を追加しました。 AET_EntryBasisDate AET_EntryBasisDatetime 上記は、以降で説明するAccountから指定した日付、時間のBalance値を取得するための仕組みを提供するためのものです。 AETスキーマのtransactionセクションに以下が設定されている場合、 tran_basis_date_ptype_name="Transactionにおいて基準日を保持している現象型名" tran_basis_datetime_ptype_name="Transactionにおいて基準日時を保持している現象型名" AETフレームワークは、上記の基準日、基準日時をtransactionから取得してAET_EntryBasisDate、AET_EntryBasisDatetimeに設定します。

基準日または基準日時を指定したBalance値及びInEntryとOutEntryの総和の取得

Accountから任意の日付におけるBalance値や、InEntryのAmount総和およびOutEntryのAmount総和を取得できる仕組みを追加しました。 この仕組みを利用するためには、Accountデータモデルが下記の現象型を持つ必要があります。 AET_InEntryList AET_OutEntryList それぞれ、Accountの全てのInEtryのリスト、OutEntryのリストを取得可能にするものです。 ModelConvert機能、独自のProcedure、Alias機能などを使ってAccountから取得可能にして下さい。 上記を実現するための簡易実装のProcedureがPEXA標準で提供されています。 AET_InEntryListProcedure AET_OutEntryListProcedure 上記は、Accountから現象型名としてXXInEntryList,XXOutEntryListを持つすべての現象型の取得を試みてそれをマージするものです。 決して効率がいいものではありませんし、この実装がEntryのリストを取り出すにあたっては各InEntry, OutEntryの現象型名が命名規則に従う必要があります。 一時的な実装としてのみ利用してください。 また、「Entryへのトランザクション基準日の設定」が提供する機能により、EntryにAET_EntryBasisDateが設定されている必要があります。 つまり、そのAccoutに対するtransactionにおいてAETスキーマ内のtransactionセクションにtran_basis_date_ptype_nameが設定されている必要があります。 任意の日付、または日時のBalance値およびInEntry,OutEntryの総和を取得するにあたって、PEXAに以下の現象型とProcedureを追加されています。 現象型 対応するProcedure(Rule) AET_AccountRealBalanceOfDay AET_AccountRealBalanceOfDayProcedure AET_AmountOfInEntry AET_AmountOfInEntryProcedure AET_AmountOfOutEntry AET_AmountOfOutEntryProcedure また、現時点におけるInEntryの総和とOutEntryの総和を取得するための現象型とProcedure(Rule)も用意してあります。 現象型 対応するProcedure(Rule) AET_CurrentAmountOfInEntry AET_CurrentAmountOfInEntryProcedure AET_CurrentAmountOfOutEntry AET_CurrentAmountOfOutEntryProcedure これらの現象型、ルールをAccountデータモデルに持たせる事で、任意の日付ベースでのBalance値または、InEntyおよび、OutEntryの総和を求めることが可能になります。 実際に任意の日付のBalance,InEntry,OutEntryの総和の取得に当たっては、値を取得する際に、以下の現象型で取得したい日付をConditionに設定する必要があります。 AET_AccountBalanceEvaluateDate 実際にService内で取得する際には、無名モデルを生成して、そこにAET_AccountBalanceEvaluateDateを設定して、 ディレクティブの&GetObservationを利用してCondition(無名モデル)を指定した値の取得を行う必要があります。 これらの値を取得するService定義での記述例は以下のとおりです。 (condition準備 format_type mapping (mapping commit false create force (@condition AET_AccountBalanceEvaluateDate @evaluateDate ) ) : : (結果確認 format_type session (session acctualBalance "&GetObservation:{ @AET_Account }{ AET_AccountRealBalanceOfDay }{ @condition }" selectOut "&GetObservation:{ @AET_Account }{ AET_AmountOfOutEntry }{ @condition }" selectIn "&GetObservation:{ @AET_Account }{ AET_AmountOfInEntry }{ @condition }" ) )

Account生成基準日及びAccountが0になった基準日の管理

いつからいつまでAccountが実質的に存在していたかを管理可能にする仕組みとそれを保持するための標準の現象型が用意されています。 この仕組みを実現するにあたって、AETスキーマのaccountセクションに以下の設定項目があります。 設定キー名 説明 initial_basis_date Accountに生成時の基準日を設定するか否かを指定するフラグ(true|false)。 設定しない場合はfalseが設定されたものとみなす。 そのトランザクションがロールバックされても変更されません。 initial_basis_date_ptype_name Accountの生成時の基準日を設定する現象型を指定。 設定しない場合は、「AET_AccountInitialDate」が指定されたものとみなす。 initial_basis_datetime Accountに生成時の基準日時を設定するか否かを指定するフラグ(true|false)。 設定しない場合は、falseが設定されたものとみなす。 そのトランザクションがロールバックされても変更されません。 initial_basis_datetime_ptype_name Account生成時の基準日時を設定する現象型を指定。 設定しない場合は、「AET_AccountInitialDatetime」が指定されたものとみなす。 empty_basis_date AccountのBalanceが0になった時点での基準日を設定するか否かを指定するフラグ(true|false）。 設定しない場合は、falseが設定されたものとみなす。 もしバランスが0のものが更新、ロールバックで0以外になった場合、日付または、日時はクリアされます。 empty_basis_date_ptype_name AccountのBalanceが0になった時点の基準日を設定する現象型を指定。 設定しない場合は、「AET_AccountEmptyDate」が設定されたものとみなす。 empty_basis_datetime AccountのBalanceが0になった時点での基準日時を設定するか否かを表すフラグ(true|false)。 設定しない場合は、falseが設定されたものとみなす。 もしバランスが0のものが更新、ロールバックで0以外になった場合、日付または、日時はクリアされます。 empty_basis_datetime_ptype_name AccountのBalanceが0になった時点の基準日時を設定する現象型を指定。 設定しない場合は、「AET_AccountEmptyDatetime」が設定されたものとみなす。 なお、上記の機能を使うにあたって、AETスキーマのtransactionセクションに 基準日を扱う場合 "tran_basis_date_ptype_name"="Transactionにおいて基準日を保持している現象型名" 基準日時を扱う場合 "tran_basis_datetime_ptype_name"="Transactionにおいて基準日時を保持している現象型名" が必ず設定されている必要があります。 もし、フラグにtrueが設定されていながら、 tran_basis_date_ptype_name tran_basis_datetime_ptype_name のどちらかが設定されていない場合は、AETスキーマのパース時点(AETSchemaFactoryCreator実行時）に例外が送信されます。 標準現象型については、特にそれを利用しなければならない理由はありませんが、可能であれば利用するようにお願いします。

AETが内部で利用するSessionKey一覧

aet_error_list AET_Transaction AET_TransactionSource AET_TransactionMeta AET_TransactionMetaAmount AET_TransactionAmount AET_AetName AET_Account(※) AET_EntryAmount(※) AET_AccountNewBalance(※) AET_Entry(※) AET_Role (※)現状この項目については、一つのTransactionで複数のAccountが引当てられた場合、最後に引当てられた際のAccount,Entryに関する情報のみが取得可能です。

例外処理

Operation単位に残数制約などでトランザクションまたはロールバックが失敗した場合、以下の内容のSessionインスタンスを含むUserServiceFatalReasonインスタンスを作成、エラーリストに追加する。 AET_ErrorCode AET_ErrorMessage AET_Transaction AET_TransactionMeta AET_Entry AET_Account ただし、エラーの発生状況においては、AET_TransactionMeta以下のSessionKeyに対応した値は常に存在するとは限りません。 基本的に一つのOperationで残数制約などでエラーが発生しても全てのAET_Operationに対する処理は継続します。ただし、一つでもエラーが会った場合は、SessionKey「aet_error_list」にUserServiceFatalReasonのリストを設定し、UserServiceFatalReasonのリストを含むServiceProcessExceptionを送信する。ただし、SessionKeyに「aet_no_exception」に文字列"true"が設定されていた場合は、例外の送信を行わず、処理が成功したOperationについてはそのまま処理を継続することが可能になっている。

• 最終更新者 : $Author: morishita $
• 最終更新日時 : $Date:: 2011-05-23 13:21:47 #$
• バージョン : $Revision: 6445 $