PEXA Modelについて

チュートリアル

定義ファイル

機能一覧

リファレンス

目次
  1. はじめに
  2. データモデル構成概要
  3. PEXAで用意される標準現象型
  4. Model定義の内容
  5. Model定義ファイルの全体書式


はじめに

モデル定義は、業務システムが取り扱う対象(Object)を表現する定義ファイルです。
データベースとのO/Rマッピング情報や、データモデルが提供する各種機能に関する定義情報がこの定義ファイルで宣言されます。

この定義ファイルはPEXAプロパティ形式で記述され、実行環境にてPEXAの実行エンジンによりそのまま直接読み込まれます。

プロパティ形式の書式については、リファレンスを参照して下さい。


データモデル構成概要

モデルフレームワークは、Model定義の内容に従って各メタ情報類、データベース、Procedure等の各要素をデータモデルという器にまとめ上げます。 各要素間の関連について、概要図を以下に示します。

                               Model                                     Database
┌─────┐          ┌───────┐                ┌─────┬─────┬─────┐
│          │          │ Proxy=1001   │                │  Proxy   │ カラムA  │ カラムB  │
│  Client  │reference │ Ptype1=AAAAA │    O/R Mapping ├─────┼─────┼─────┤
│          ├────→│ Ptype2=BBBBB │───────→│  1001    │  AAAAA   │  BBBBB   │
└─────┘          │ Ptype3 ───┼┐              ├─────┼─────┼─────┤
┌─────┐reference │              ││              │  1002    │  CCCCC   │  DDDDD   │
│          │update    │              ││              ├─────┼─────┼─────┤
│ Service  │commit    │              ││┌─────┐│  1003    │          │          │
│          ├────→│              │└│Procedure │├─────┼─────┼─────┤
└┬────┘          └───────┘  └─────┘│  1004    │          │          │
  │                             ↑                       ├─────┼─────┼─────┤
  │                             │                       │  1005    │          │          │
  │                             │instance               ├─────┼─────┼─────┤
  │                             │                       │  1006    │          │          │
  │ search            ┌────┴────────┐     └─────┴─────┴─────┘
  │ create            │                          │ SQL            ↑
  └────────→ │  PEXA Execution Engine   ├────────┘
                       │                          │
                       └──┬────────┬─┘
                             │ read           │ read
                             ↓                ↓
                 ┌─────────┐┌────────┐
                 │                  ││                │
                 │ Model Definition ││ Ptype MetaData │
                 │                  ││                │
                 └─────────┘└────────┘

データモデルに対する操作時の動作について、以下に概要を記述します。

データモデル検索

PEXA実行エンジンは、Serviceからの要求と検索条件に従ってデータベースに対してSQLを発行し、検索結果をモデル定義の内容に従ってデータモデルとしてメモリ上にインスタンス化します。
インスタンス化されたデータモデルが保持する値等はO/RマッピングされたDBのレコードの内容となります。


データモデル新規生成

PEXA実行エンジンは、Serviceからの要求に従ってモデル定義ファイルの内容を元に、新たなデータモデルをメモリ上にインスタンス化します。
新規生成されたデータは、データモデルがコミットされるまではデータベースに保存はされません。


データモデル編集

Serviceは、データモデルの内容をメモリ上で編集することが出来ます。
更新された内容は、データモデルがコミットされるまではデータベースに保存はされません。


データモデル編集内容の保存(コミット)

Serviceは、データモデルの編集内容をコミットすることが出来ます。
コミットすることにより、編集内容がデータベースに保存されます。


データモデルの削除

PEXAでは、データモデルをデータベースから削除するという操作は基本的に行いません。
その代わり、PEXAで標準で用意されている現象型である、RemovedFlagもしくはValidityFlagの値を設定することによりそのデータが削除された物であるという扱いにしています。



PEXAで用意される標準現象型

PEXAでは、以下のような現象型が標準で用意されています。
これらのうち、必須となっている現象型はPEXAの実行エンジンの内部でも参照している現象型となるので、全てのデータモデルに必ず含まれている必要があります。

現象型名 必須? 値の型 どこで設定? 説明
ValidityFlag 必須 pexa.share.util.business.ValidityFlag メンテナンス要員による手動設定 データモデルが有効状態であるか無効状態であるかを表す現象型です。
この現象型は基本的にデータメンテナンス用なので、アプリケーションから設定することはほとんどありません。
RemovedFlag 必須 pexa.share.util.business.RemovedFlag アプリケーション データモデルが削除状態であるか未削除状態であるかを表す現象型です。
この現象型はアプリケーションから必要に応じて設定します。
VersionNumber 必須 java.lang.Integer PEXA実行エンジン データモデルの更新バージョン番号です。
データモデルをコミットする度にPEXA実行エンジンによって自動的にインクリメントされます。
また、更新時に他のユーザーと競合していないかのチェックのためにPEXA実行エンジンによって参照されます。
アプリケーションから設定することはありません。
EntityName 必須 java.lang.String データモデルのstaticセクション データモデルの名称です。
データモデル毎に固定で決定するので、Model定義のstaticセクションで初期値を設定しておきます。
CreateDate 非必須 java.util.Date アプリケーション データが新規生成された日付です。
CreateDatetime 非必須 java.util.Date アプリケーション データが新規生成された時刻です。
LastUpdateDatetime 非必須 java.util.Date アプリケーション データが最後に更新された時刻です。


Model定義の内容

Model定義の内容に含まれる情報には、主に以下の物があります。
それぞれがModelフレームワークの提供機能を表現しています。

共通情報

データモデルのヘッダ情報的な定義を行う部分です。
データモデル名、コネクションプール、InitialContext情報などを定義します。

書式はModel定義ファイルの全体書式を参照してください。


O/Rマッピング

O/Rマッピングとは、"Object Relational Mapping"の略です。
データモデルとデータベースの間をマッピングする機能で、モデルフレームワークの中核となる機能です。

アプリケーション(クライアントフレームワーク、サービスフレームワーク)側は、 この機能によりデータモデル及び現象型と対話することでデータの読み込み、登録、更新などが全て可能になりますので、 データモデルの裏側に隠れているデータベースを全く意識する必要がありません。

この機能の設定情報には、以下の情報が含まれます。

  • プライマリキーの通番を取得するための採番機能情報
  • データモデルがリンクする、データベース上のテーブルの指定
  • プライマリキーとなる現象型とDBのカラム情報
  • 読み込み可能な現象型とDBのカラムとのマッピング
  • 生成可能な現象型とDBのカラムとのマッピング
  • 更新可能な現象型とDBのカラムとのマッピング
  • 削除可能な現象型とDBのカラムとのマッピング
書式はschemaセクションを参照してください。


StaticFilter

データモデルを検索する際に、検索条件中に静的に必ず含めたい条件がある場合に記述します。
RemovedFlagやValidityFlag等、PEXA側で標準で用意しているデータモデルの有効性を表す項目を指定することがよくありますが、 データモデル毎の固有の条件があれば、個々にそれを記述することも出来ます。

基本的には、トランザクション系データとマスタ系データでそれぞれ以下のように指定します。

トランザクション系データの場合:

static_filter	" RemovedFlag = NOT_REMOVED and ValidityFlag = VALID "
基本的には、RemovedFlag及びValidityFlagを固定フィルタに指定します。
このようにしておくことで、削除されているデータや無効になっているデータを検索結果から必ず除外することが出来ます。


マスタ系データの場合:
static_filter	" ValidityFlag = VALID "
これは、マスタデータの場合は過去のトランザクションデータが既に削除されている(RemovedFlag = REMOVED)ようなマスタデータを参照している場合があり、 RemovedFlagを条件に入れるとそういったデータを参照した際のエラー原因になるためです。

書式はstatic_filter宣言部を参照してください。


Procedure

現象型に対して、値を動的に導出するルールを実装した小プログラムやサービスをマッピングすることができます。
これは、参照する毎に値が動的に変わる可能性のあるような現象型に対応するための機能です。

単純な例としては、以下のような物が考えられます。

例:
顧客を表すデータモデルに、以下の現象型があるとします。

  • 生年月日
  • 現在年齢
上記のうち、「生年月日」は顧客毎に静的な値なのでそのままデータベースに保存されるため、素直にデータベースのカラムにマッピングされます。
それに対して「現在年齢」はデータベースに保存することが出来ません。その現象型が参照された瞬間の年齢を値として返す必要があるためです。

このような場合は、「現在年齢」の値を返す小さなプログラムを作成し、そのプログラムを「現在年齢」という現象型に割り当てます。 こうすることで、データベースに保存できないような動的な値もアプリケーションから見るとデータモデルの単純な一項目として参照することが出来ます。

     ┌────┐        ┌──────┐        DataBase
     │        │        │Model       │      ┌───┬──────→
     │Client  │ 参照   │            │      │Proxy │ 生年月日
     │Service ├───→│Proxy=1001  │      ├───┼──────→
     │        │        │生年月日 ────→ │1001  │1970/01/01
     └────┘        │現在年齢 ───┐   └───┴──────→
                         │            │ │             
                         └──────┘ │     ┌───────────────────┐
Modelを見ている側からは        ↑         └─→ │Procedure                             │
どちらも単純な項目に見える     │                │  データモデルの「生年月日」と        │
                               │                │  現在のシステム時刻から、その顧客の  │
                               └────────┤  現在年齢を求めて返すプログラム      │
                           「生年月日」を参照して└───────────────────┘
                           「現在年齢」の値を返す
大抵のアプリケーションでは、このような動的な値の取得は処理プロセス中に導出ロジックを混ぜ込むような形をとりますが、 ModelFrameworkのこの機能を使用するとそのような値の導出ルールが処理プロセスに混ざることが無くなるので、ルールとプロセスが分離できるようになります。

書式はprocedureセクションを参照してください。


Trigger

ある現象型に対して値が外部から設定された事を契機として、Triggerというプログラムモジュールを起動することが出来ます。
現象型Aに対して値がセットされた時に、連動して現象型B,C,Dを設定するというようなことができます。

┌────┐            ┌───────┐
│        │現象型Aに  │              │    call      ┌────────────┐
│Client  │値を設定    │Model         ├─────→  │Trigger                 │
│Service ├─────→│現象型A      │              │現象型Aを元に          │
│        │            │現象型B      │←──────┤現象型Bの値を決めて設定│
└────┘            │              │ 現象型Bに   └────────────┘
                        └───────┘ 値を設定
また、Triggerの実行タイミングを、値の設定前と設定後のどちらにするかも指定できます。
上記の例で言うと、以下のような実行タイミングとなります。

値の設定前を指定(before)
  1. 現象型Aに対する値設定を検出してTriggerが実行される
  2. Triggerの実行が完了してから現象型Aに実際に値が設定される
値の設定後を指定(after)
  1. 現象型Aに対して実際に値が設定される。
  2. 値の設定が完了後にTriggerが実行される

!!!注意!!!
このTriggerという機能は、使用方法を間違えると重大なバグを埋め込むことになりますので注意してください。
Triggerはプログラムモジュールなので、プログラム言語でできることは全てその内部で実装できてしまいますが、 トランザクション境界などについて考慮していないような処理を実装するとロールバック時に意図しない動作を引き起こします。
使用する際は必ず以下の点を守ってください。

「呼出元のモデル内の項目のみ処理対象にすること」
Trigger内で行う処理内容は、呼出元モデル内の項目操作のみとしてください。
別のデータモデルをTrigger内で取得して更新などを行った場合、ClientVM上でこのような処理が実行されると、エラー時のロールバック対象から外れてしまいます。

「循環が発生しないようにすること」
PEXA実行エンジンでは、Triggerによる処理が原因で循環が発生していることを検出できません。
Triggerが仕掛けられている現象型をTriggerから更新したりすると処理が循環してスタックオーバーフローを引き起こしますので注意してください。


書式はtriggerセクションを参照してください。


Alias

データモデルに含まれる現象型に対して別名を定義することができます。
これは、同じような意味の現象型が個々のモデル内で別々の現象型名で登録されているような場合に、 それらを残しつつ統一的な名称を割り当てたいといった場合に使用します。

┌────┐                   ┌─────────────┐
│        │                   │                          │
│Client  │現象型Aを参照     │Model                     │
│Service ├────────→ │現象型Aは現象型Bのalias───┐ 
│        │ ←────────┤                          │   │
│        │現象型Bの値の     │現象型B="AAAA"←───────┘
│        │AAAAが返される     │                          │
└────┘                   └─────────────┘
なお、別名現象型に割り当てる対象は、同じモデル内の現象型もしくはパス式を指定することが出来ます。 パス式を指定した場合、別データモデルの項目をあたかも自身の項目であるように見せることが可能です。 詳細はaliasセクションを参照してください。


Static

データモデルに含まれる現象型に対して固定的な初期値を定義することができます。
初期値が設定された現象型がデータベースのカラムとマッピングされている場合、 アプリケーションによって別の値が上書き設定されていなければ、 その初期値が初回コミット時にデータベースにも設定されます。

┌────┐                   ┌───────────┐            DataBase
│        │現象型Aを参照する │Model                 │       ┌───┬───→      
│Client  │と初期値"AAAA"が   │Proxy=1001            │       │Proxy │ A
│Service │返される           │現象型A              ├──→ ├───┼───→      
│        ├────────→ │(static               │       │1001  │AAAA
│        │上書き設定は可能   │    現象型A = "AAAA" │       └───┴───→      
│        │                   │)                     │  
└────┘                   └───────────┘  現象型Aが上書きされない限り、
                                                           初期値はそのままDBにも保存
詳細はstaticセクションを参照してください。


ModelMapping

データモデル中に他のデータモデルのProxy(主キー)を現象型として保持している場合に、 そのProxy現象型を経由して他モデルに自動接続する機能をModelMapping機能と呼んでいます。

この機能は、パス形式の記述と組み合わせて使用します。
例えば、以下のように"ModelA"と"ModelB"があるとします。

┌────┐       ┌───────────────┐    ┌──────┐
│        │       │ModelA                       │    │ModelB      │
│Client  │パスで │Proxy = 1001                  │    │Proxy = 2001│
│Service ├──→ │現象型X(Model BのProxy)=2001─┼─→│現象型Y=ZZZ │
│        │参照   │                              │    │            │
└────┘       └───────────────┘    └──────┘
この場合、現象型Xが"ModelB"のProxyなのでModelMappingによって自動接続が可能です。
ClientもしくはServiceが現象型パス形式で、
	"ModelA/現象型X/現象型Y"
といった形式で指定すると、ModelB側で保持している現象型Yの値"ZZZ"が取得できます。

なお、このModelMapping機能による接続先モデルはProxy定義の内容がデフォルト設定になります。
ObservableProxyであればfinderpathの指定で決まり、
IdentifiedObservableProxyであれば実行時に組み合わされたIdentifiedFlagによって決定されます。

ただし、Model定義ファイル内のmappingセクションにProxy現象型とモデル名の対応を記述することで、Proxy定義のデフォルト設定を上書き設定することが可能です。

詳細はmappingセクションを参照してください。


ModelConvert

親子関係を持つデータモデル間の関係を表現するための機能をModelConvert機能と呼んでいます。
この機能を使用すると、親データモデル中の現象型を経由して子データモデルをあたかも一項目のように取得できます。

                   ┌────────┐                              ┌─────────────┐
                   │親モデル        │                              │子モデル1                │
                   │Proxy=1001      │                              │Proxy=2001                │
                   │                │     ┌────────┐     │親モデルのProxy現象型=1001│
┌────┐       │                │     │ModelConvert    │検索 └─────────────┘
│        │参照   │                │┌→ │     Procedure  ├─→ ┌─────────────┐
│Client  ├──→ │子モデルのリスト││   └────────┘     │子モデル2                │
│Service │       │を表す現象型XXX ├┤   ┌────────┐     │Proxy=2002                │
│        │       │                ││   │Completion      │連動 │親モデルのProxy現象型=1001│
└────┘       │                │└→ │(before, after) ├─→ └─────────────┘
 現象型XXXを経由   │                │     └────────┘     ┌─────────────┐
 して子モデルの    │                │                              │子モデル3                │
 リストが取得可    │                │                              │Proxy=2003                │
     │            │                │                              │親モデルのProxy現象型=1001│
     │            └────────┘                              └─────────────┘
     │                                                                        ↑        
     │                                                                        │        
     └────────────────────────────────────┘
この機能は、ModelConvertProcedure及びCompletion設定の組み合わせで成り立っています。

ModelConvertProcedure:
ModelConvertProcedureは、子モデルのリストを親モデル側の一項目のように見せて取得するための機能です。
上記の図のように、親モデル側は子モデルを特定する情報を自分の内部には保持していません。
その代わり、子モデルの方で親モデルを特定するためのProxy現象型を保持しているので、 ModelConvertProcedureという仕組みがprocedureセクション内のmodelサブセクションの設定内容を参照して子データモデルを検索し、その一覧を返します。

Completion:
Completionは、親モデルの変更に合わせて子モデルも同時に連動するための機能です。
例えば、親子のデータモデル間では通常以下のような連動を行います。
  • 親モデルのRemovedFlagがREMOVEDになったら、全ての子モデルは同時にRemovedFlag=REMOVEDに更新される。
  • 親モデルのValidityFlagがINVALIDになったら、全ての子モデルは同時にValidityFlag=INVALIDに更新される。
  • 親モデルがcommit(DBへの内容保存)されたら、全ての子モデルは同時にcommitされる。
上記の設定はcompletionセクションで記述されます。



Model定義ファイルの全体書式

Model定義ファイルの全体構成について、以下に示します。
それぞれの属性、宣言部、セクションの詳細については、以降で解説します。

書式:

context_default属性(1)
check_value属性(1)
pool_name宣言部(1)
resource宣言部(1)
schemaセクション(1)
procedureセクション(0|1)
completionセクション(0|1)
cascadeセクション(0|1)
aliasセクション(0|1)
staticセクション(0|1)
static_filter宣言部(0|1)

	
記述注:
    属性        あらかじめ決められた値を選択する(true/falseなど)
    宣言部      値または、値のリストを設定する
    セクション  入れ子で他の属性、宣言部、セクションを保持する可能性がある
                (値又は、値のリストが設定される場合もある)

    (1):必須
    (0|1):オプション
    (1以上):一個以上必須
    (0以上):0個以上(オプション)
記述例:
;;--------------------------------------------------
;;Common Definition
;;--------------------------------------------------
context_default     true
check_value         false
pool_name           java:comp/env/jdbc/pexaPool
;;--------------------------------------------------
;; ModelName
;;--------------------------------------------------
resource        SampleIdentifiedModel
;;-------------------------------------
;; O/R mapping
;;-------------------------------------
(schema
    table SAMPLE_IDENTIFIED 
    (primary
        column			SAMPLE_PROXY2
        phenomenon_type	SampleProxy2
    )
    (column
        (load
            SampleProxy2         SAMPLE_PROXY2,SAMPLE_IDENT
            SampleIdentFlag      SAMPLE_IDENT
            VersionNumber        VERSION_NUMBER
            SampleMasterCode     SAMPLE_MASTER_CODE
            Comment              COMMENT
            RemovedFlag          REMOVED_FLAG
            ValidityFlag         VALIDITY_FLAG
            LastUpdateDatetime   LAST_UPDATE_DATETIME
            CreateDate           CREATE_DATE
        )
        (create
            SampleProxy2         SAMPLE_PROXY2,SAMPLE_IDENT
            VersionNumber        VERSION_NUMBER
            SampleMasterCode     SAMPLE_MASTER_CODE
            Comment              COMMENT
            RemovedFlag          REMOVED_FLAG
            ValidityFlag         VALIDITY_FLAG
            LastUpdateDatetime   LAST_UPDATE_DATETIME
            CreateDate           CREATE_DATE
        )
        (save
            SampleProxy2         SAMPLE_PROXY2,SAMPLE_IDENT
            VersionNumber        VERSION_NUMBER
            SampleMasterCode     SAMPLE_MASTER_CODE
            Comment              COMMENT
            RemovedFlag          REMOVED_FLAG
            ValidityFlag         VALIDITY_FLAG
            LastUpdateDatetime   LAST_UPDATE_DATETIME
            CreateDate           CREATE_DATE
        )
        (delete
        )
    )
)
;;-------------------------------------
;; procedure
;;-------------------------------------
(procedure
)
;;-------------------------------------
;; ptype alias
;;-------------------------------------
(alias
	PEXA_IdentifiedFlag  SampleIdentFlag
)
;;-------------------------------------
;; set static intial value
;;-------------------------------------
(static
    EntityName       SampleMaster
    SampleIdentFlag  SAMPLE1
    VersionNumber    1
    RemovedFlag	     NOT_REMOVED
    ValidityFlag     VALID
)
;;-------------------------------------
;; default search filter
;;-------------------------------------
static_filter	" ValidityFlag = VALID "

context_default属性

説明:
使用する接続Contextの設定です。
システムのデフォルト設定を使用するか、個別設定を使用するかを指定します。

必要がない限り基本的にtrueを指定してください。

区分値:

  • true:システムのデフォルト設定を使用する
  • false:個別設定を使用する


check_value属性

説明:
モデルに対して設定された現象型の値に対するチェック処理のON/OFF指定です。
ONにすると値の設定時に常にチェック処理が実行されるため、ONにするとパフォーマンスに影響が出ます。 デバッグ時に必要がない限り基本的にfalseを指定してください。

区分値:

  • true:値チェックON
  • false:値チェックOFF


pool_name宣言部

説明:
このデータモデルが使用するコネクションプールの指定です。
アプリケーションサーバー上にデプロイされているデータソースのJNDI名を指定します。

PEXAではコネクションプールのJNDI名をデフォルトで規定していますので、基本的にはそちらを固定で指定してください。

デフォルトはjava:comp/env/jdbc/pexaPoolです。

記述:

pool_name           java:comp/env/jdbc/pexaPool


resource宣言部

説明:
このデータモデルに与えるシステム内でユニークな名称です。
任意の文字列を指定できます。

記述:

resource        SampleIdentifiedModel


static_filter宣言部

説明:
データモデル検索時に、検索条件に必ず固定的に付与したい条件があればここで指定します。

ここで指定する検索条件は、モデル条件式となります。
この条件式の書式についてはこちらを参照してください。

記述:

static_filter	" ValidityFlag = VALID "



schemaセクション

書式:

(schema
    sequencerサブセクション(0|1)
    table宣言部(1)
    primaryサブセクション(1)
    columnサブセクション(1)
)
	
記述注:
    属性        あらかじめ決められた値を選択する(true/falseなど)
    宣言部      値または、値のリストを設定する
    セクション  入れ子で他の属性、宣言部、セクションを保持する可能性がある
                (値又は、値のリストが設定される場合もある)

    (1):必須
    (0|1):オプション
    (1以上):一個以上必須
    (0以上):0個以上(オプション)

記述例:

;;-------------------------------------
;; O/R mapping
;;-------------------------------------
(schema
    ;-------------------------------------------------
    ; sequencerは標準設定を使用する場合は省略可
    ;-------------------------------------------------
    ;(sequencer
    ;    table       SEQUENCER_TABLE
    ;    ident       IDENT
    ;    id          ID
    ;    ident_value SampleMaster
    ;    min         MIN_ID
    ;    max         MAX_ID
    ;    ;cached      100	;; only use cache
    ;    ;pool_name   java:comp/env/jdbc/seqPool ;; only use cache
    ;)
    table SAMPLE_IDENTIFIED 
    (primary
        column			SAMPLE_PROXY2
        phenomenon_type	SampleProxy2
    )
    (column
        (load
            SampleProxy2         SAMPLE_PROXY2,SAMPLE_IDENT
            SampleIdentFlag      SAMPLE_IDENT
            VersionNumber        VERSION_NUMBER
            SampleMasterCode     SAMPLE_MASTER_CODE
            Comment              COMMENT
            RemovedFlag          REMOVED_FLAG
            ValidityFlag         VALIDITY_FLAG
            LastUpdateDatetime   LAST_UPDATE_DATETIME
            CreateDate           CREATE_DATE
        )
        (create
            SampleProxy2         SAMPLE_PROXY2,SAMPLE_IDENT
            VersionNumber        VERSION_NUMBER
            SampleMasterCode     SAMPLE_MASTER_CODE
            Comment              COMMENT
            RemovedFlag          REMOVED_FLAG
            ValidityFlag         VALIDITY_FLAG
            LastUpdateDatetime   LAST_UPDATE_DATETIME
            CreateDate           CREATE_DATE
        )
        (save
            SampleProxy2         SAMPLE_PROXY2,SAMPLE_IDENT
            VersionNumber        VERSION_NUMBER
            SampleMasterCode     SAMPLE_MASTER_CODE
            Comment              COMMENT
            RemovedFlag          REMOVED_FLAG
            ValidityFlag         VALIDITY_FLAG
            LastUpdateDatetime   LAST_UPDATE_DATETIME
            CreateDate           CREATE_DATE
        )
        (delete
        )
    )
)

モデルフレームワークの中核機能である、O/Rマッピングに関する定義情報を記述するセクションです。
以下に関する情報を内部に記述します。

table宣言部

説明:
このデータモデルがマッピングされるデータベースのテーブル名を指定します。

記述:

table SAMPLE_IDENTIFIED



sequencerサブセクション

書式:

(schema
    (sequencer
        table宣言部(1)
        ident宣言部(1)
        id宣言部(1)
        ident_value宣言部(1)
        min宣言部(1)
        max宣言部(1)
        cached宣言部(0|1)
        pool_name宣言部(0|1)
    )
)	
記述注:
    属性        あらかじめ決められた値を選択する(true/falseなど)
    宣言部      値または、値のリストを設定する
    セクション  入れ子で他の属性、宣言部、セクションを保持する可能性がある
                (値又は、値のリストが設定される場合もある)

    (1):必須
    (0|1):オプション
    (1以上):一個以上必須
    (0以上):0個以上(オプション)

説明:
データモデルのプライマリキー(Proxy)のIDを採番するための設定情報セクションです。

このセクションは、採番のために特殊な設定が必要な場合にのみ記述してください。
ほとんどのケースではPEXAのデフォルトの動作で対応できるので、その場合は記述は不要です。

なお、デフォルトの動作の場合は、ID自動採番は以下と同等の設定で行われます。

[省略時のデフォルト設定]
table       SEQUENCER_TABLE
ident       IDENT
id          ID
ident_value データモデルの名称
min         MIN_ID
max         MAX_ID
cached      100	;; only use cache
pool_name   java:comp/env/jdbc/seqPool ;; only use cache

セクション内には以下の宣言部があります。

table宣言部

説明:
プライマリキーの採番を行うためのメタデータテーブル名称を指定します。

記述:

table SEQUENCER_TABLE


ident宣言部

説明:
データモデルが使用する採番テーブル内のレコードを特定するためのモデル識別カラム名をここで指定します。
ここで指定したカラムにident_value宣言部で指定した値が設定されます。

記述:

ident IDENT


id宣言部

説明:
採番された値が保存されるカラムの名前をここで指定します。
PEXA実行エンジンがこのカラムの値を参照し、データベースに新規登録されたデータに対して値を割り振った後、このカラムの値がインクリメントされます。

記述:

id ID


ident_value宣言部

説明:
ident宣言部で指定したカラムに設定される値の指定です。
基本的にはデータモデル名称を設定します。

記述:

ident_value PrescriptionOrderModel


min宣言部

説明:
採番される値の最小値を指定するためのカラムの名前をここで指定します。

記述:

min   MIN_ID


max宣言部

説明:
採番される値の最大値を指定するためのカラムの名前をここで指定します。

記述:

max   MAX_ID


cached宣言部

説明:
自動採番をいくつの単位でキャッシュしながら行うかの指定です。
ここで例えば"100"と指定すると、採番処理が行われた時点で一度にIDカラムの値が100増加し、その分の値がメモリ上にキャッシュされます。 その値をPEXA実行エンジンが使い切るまで、データベースの採番テーブルにアクセスされなくなるのでパフォーマンスアップを図ることが出来ます。

記述:

cached      100	;; only use cache


pool_name宣言部

説明:
採番テーブルに対してアクセスする際に使用するコネクションプールのJNDI名称の指定です。
採番をキャッシュする場合に、データモデルに直接マッピングされるテーブルと別のコネクションプールを指定することができます。

記述:

pool_name   java:comp/env/jdbc/seqPool ;; only use cache



primaryサブセクション

書式:

(schema
    (primary
        column宣言部(1)
        phenomenon_type宣言部(1)
    )
)	
記述注:
    属性        あらかじめ決められた値を選択する(true/falseなど)
    宣言部      値または、値のリストを設定する
    セクション  入れ子で他の属性、宣言部、セクションを保持する可能性がある
                (値又は、値のリストが設定される場合もある)

    (1):必須
    (0|1):オプション
    (1以上):一個以上必須
    (0以上):0個以上(オプション)

説明:
データモデルのプライマリキーを定義するためのセクションです。
Proxyを値にとる現象型と、それに対応するテーブルカラムをマッピングします。

ここで指定される現象型がObservableProxyになるかIdentifiedObservableProxyなるかで記述が変わります。

ObservableProxyの場合:
この場合、Proxyの現象型に対して通番のカラムのみを割り当てます。

(primary
    column             SAMPLE_PROXY
    phenomenon_type    SampleProxy
)

IdentifiedObservableProxyの場合:
この場合は、Proxyの現象型に対して通番と識別フラグのカラムを2つ割り当てます。

(primary
    column             SAMPLE_PROXY,SAMPLE_IDENT
    phenomenon_type    SampleProxy
)

セクション内には以下の宣言部があります。

column宣言部

説明:
Proxyの現象型に対して割り当てるテーブルカラム名を指定します。
Proxyが識別フラグを持つ場合は、カンマ区切りで通番と識別フラグのカラムを続けて二つ指定します。

記述:識別フラグ無し

column             SAMPLE_PROXY

記述:識別フラグ有り

column             SAMPLE_PROXY,SAMPLE_IDENT


phenomenon_type宣言部

説明:
データモデルのプライマリキーとなる、Proxyの現象型名を指定します。

記述:識別フラグ無し

phenomenon_type    SampleProxy



columnサブセクション

書式:

(schema
    (column
        (load
            現象型名    カラム名
            現象型名    カラム名
            現象型名    カラム名
                      :
                      :
                      :
        )
        (create
            現象型名    カラム名
            現象型名    カラム名
            現象型名    カラム名
                      :
                      :
                      :
        )
        (save
            現象型名    カラム名
            現象型名    カラム名
            現象型名    カラム名
                      :
                      :
                      :
        )
        (delete
        )
    )
)


記述注:
    属性        あらかじめ決められた値を選択する(true/falseなど)
    宣言部      値または、値のリストを設定する
    セクション  入れ子で他の属性、宣言部、セクションを保持する可能性がある
                (値又は、値のリストが設定される場合もある)

    (1):必須
    (0|1):オプション
    (1以上):一個以上必須
    (0以上):0個以上(オプション)

説明:
データモデルが持つ現象型(業務項目)とテーブルカラム名のマッピングを行うセクションです。
columnサブセクション内部にサブセクションがあり、それぞれ以下のように対応します。

  • loadセクション:参照可能な現象型のリスト
  • createセクション:新規登録可能な現象型のリスト
  • saveセクション:更新可能な現象型のリスト
  • deleteセクション:削除可能な現象型のリスト(現在使用されていません)
また、現象型が複数個の値を内部で保持するような値の場合(IdentifiedObservableProxy)は、 一つの現象型に対して複数個のカラムをカンマ区切りでマッピングします。

以下に記述例を挙げます。この場合は以下のような特徴があります。
  • Proxyが識別フラグ付き
  • 全ての現象型は参照可能
  • 全ての現象型は新規登録可能
  • Proxy、識別フラグ、CreateDate、EntityNameが更新不可(saveセクションからは除外)
  • deleteセクションは記述無し
(schema
    (column
        (load
            SampleProxy2        SAMPLE_PROXY2,SAMPLE_IDENT
            SampleIdentFlag     SAMPLE_IDENT
            VersionNumber       VERSION_NUMBER
            SampleMasterCode    SAMPLE_MASTER_CODE
            Comment             COMMENT
            EntityName          ENTITY_NAME
            RemovedFlag         REMOVED_FLAG
            ValidityFlag        VALIDITY_FLAG
            LastUpdateDatetime  LAST_UPDATE_DATETIME
            CreateDate          CREATE_DATE
        )
        (create
            SampleProxy2        SAMPLE_PROXY2,SAMPLE_IDENT
            SampleIdentFlag     SAMPLE_IDENT
            VersionNumber       VERSION_NUMBER
            SampleMasterCode    SAMPLE_MASTER_CODE
            Comment             COMMENT
            EntityName          ENTITY_NAME
            RemovedFlag         REMOVED_FLAG
            ValidityFlag        VALIDITY_FLAG
            LastUpdateDatetime  LAST_UPDATE_DATETIME
            CreateDate          CREATE_DATE
        )
        (save
            VersionNumber       VERSION_NUMBER
            SampleMasterCode    SAMPLE_MASTER_CODE
            Comment             COMMENT
            RemovedFlag         REMOVED_FLAG
            ValidityFlag        VALIDITY_FLAG
            LastUpdateDatetime  LAST_UPDATE_DATETIME
        )
        (delete
        )
    )
)


procedureセクション

書式:

(procedure
    modelセクション(0|1)
    procedureセクション(0|1)
)


記述注:
    属性        あらかじめ決められた値を選択する(true/falseなど)
    宣言部      値または、値のリストを設定する
    セクション  入れ子で他の属性、宣言部、セクションを保持する可能性がある
                (値又は、値のリストが設定される場合もある)

    (1):必須
    (0|1):オプション
    (1以上):一個以上必須
    (0以上):0個以上(オプション)

説明:
現象型に対して、Procedureという値を導出するルールの実装をマッピングするためのセクションです。
Procedureには以下の2タイプがあります。

  • ModelConvertProcedure
  • 任意の処理を実装したProcedure
前者をmodelサブセクションで、後者をprocedureサブセクションで記述します。

記述例

(procedure
    (model
        交通費精算書明細    ""
    )
    (procedure
        現年齢    xxxx.share.procedure.CurrentAgeProcedure
        在籍日数  xxxx.share.procedure.RegisterDateCountProcedure
    )
)


modelサブセクション

ModelConvert機能を実現するための特殊なProcedureを指定するためのセクションです。
子モデルが従属キーとして親モデルのProxyを現象型として保持していれば、親モデル側のモデル定義でこのセクションに設定を記述することでデータモデルの親子関係を定義できます。

ModelConvertProcedureの実装はPEXAによって提供されているのでクラス名の記述は不要です。
記述形式としては、省略形書式外部キー指定書式詳細指定書式の3パターンがあります。

省略形書式

書式:

(procedure
    (model
        Combinationの現象型    ""
        Combinationの現象型    ""
        Combinationの現象型    ""
                :
                :
                :
    )
)

説明:
もっとも省略した形式の書式です。
左辺に取得したい子モデルを表すCombinationの現象型を指定し、右辺は固定で「""」と記述します。

このようにすることで、PEXA実行エンジンはCombination現象型の定義からモデル名を取得し、そこから親モデルのProxyを保持する子モデルを自動で検索して返します。

記述例:

(procedure
    (model
        ;;--------------------------------------------------------
        ;; 左辺は子モデル(のリスト)を表す現象型名
        ;; 右辺は省略
        ;;--------------------------------------------------------
        交通費精算書明細一覧    ""
    )
)


外部キー指定書式

書式:

(procedure
    (model
        Combinationの現象型    外部キー現象型名
        Combinationの現象型    外部キー現象型名
        Combinationの現象型    外部キー現象型名
                :
                :
                :
    )
)

説明:
現象型が表す子モデルに対して、親モデルを特定するProxy現象型(外部キー)を指定する書式です。
左辺に取得したい子モデルを表すCombinationの現象型を指定し、右辺には子モデル側が保持している、親モデルを特定する外部キーとなるProxy現象型を指定します。

子モデル側で保持している、外部キーとなる現象型名が親モデル側と異なる場合に使用します。

記述例:

(procedure
    (model
        ;;--------------------------------------------------------
        ;; 左辺は子モデル(のリスト)を表す現象型名
        ;; 右辺は子モデル側で保持している親モデルProxyの現象型名
        ;;--------------------------------------------------------
        申請書明細    交通費精算書No
    )
)


詳細指定書式

書式

(procedure
    (model
        {Combinationの現象型1
            (検索対象のモデル名11
                key宣言部 (template宣言部と排他)
                static宣言部 (key宣言部がある場合に指定可)
                template宣言部 (key宣言部と排他)
            )
            (検索対象のモデル名12
                key宣言部 (template宣言部と排他)
                static宣言部 (key宣言部がある場合に指定可)
                template宣言部 (key宣言部と排他)
            )
                 :
                 :
            cache属性(0|1)
            unique属性(0|1)
        }
        {Combinationの現象型2
            (検索対象のモデル名21
                key宣言部 (template宣言部と排他)
                static宣言部 (key宣言部がある場合に指定可)
                template宣言部 (key宣言部と排他)
            )
            (検索対象のモデル名22
                key宣言部 (template宣言部と排他)
                static宣言部 (key宣言部がある場合に指定可)
                template宣言部 (key宣言部と排他)
            )
                 :
                 :
            cache属性(0|1)
            unique属性(0|1)
        }
                 :
                 :
    )
)

説明:
詳細な検索条件まで指定する形式です。
Combination現象型名のセクションを記述し、その内部に検索対象のモデル名セクションを記述します。
このモデル名セクションを複数個列挙すると、複数種類のデータモデルの検索結果をMultiple Combination現象型として返すことが可能です。

検索条件には、以下の2種類の形式で指定できます。

  • 外部キー指定(子モデルが保持している親モデルのProxy)
  • 親モデルが保持している現象型の値による任意検索条件
どちらの形式で指定するかによって、モデル名セクション内で記述するパラメータが変わります。

前者で指定する場合は、key宣言部(必須)及びstatic宣言部(option)を指定します。

記述例:外部キー指定の場合

(procedure
    (model
        ;;-------------------------------------
        ;; 現象型名は「申請書明細」
        ;; 検索対象モデルは「交通費精算書明細」
        ;; 検索条件の外部キーに申請書No,固定条件にRemovedFlagを指定
        ;; 検索結果はリストになる
        ;;-------------------------------------
        {申請書明細
            (交通費精算書明細
                key       申請書No
                static    RemovedFlag = NOT_REMOVED
            )
            unique    false
            cache     false
        }
    )
)

後者で指定する場合は、template宣言部(必須)を指定します。
template宣言部では、左辺側は子モデル側の現象型名を指定し、右辺側には固定値もしくは親モデル側の現象型の値を

${親モデル側の現象型名}
という形式で指定できます。下記の記述例では、検索条件として固定値でRemovedFlagを指定し、 さらに親モデル側で持っている「申請書No」と「乗り物種別」という現象型を指定しています。

記述例:任意検索条件の場合

(procedure
    (model
        ;;-------------------------------------
        ;; 現象型名は「申請書明細」
        ;; 検索対象モデルは「交通費精算書明細」
        ;; 検索条件に申請書No,乗り物種別,RemovedFlagを指定
        ;; 検索結果はリストになる
        ;;-------------------------------------
        {申請書明細
            (交通費精算書明細
                template    "申請書No = ${申請書No} and 乗り物種別 = ${乗り物種別} and RemovedFlag = NOT_REMOVED"
            )
            unique    false
            cache     false
        }
    )
)


key宣言部

説明:
検索条件として使用する外部キーの現象型を指定します。template宣言部と排他になります。
子モデル側で保持している、親モデルを指すProxy現象型名をここで指定します。

記述:

key    申請書No


static宣言部

説明:
key宣言部を記述した場合に、外部キー以外の固定検索条件をこの宣言部で追加指定できます。(Optional)

記述:

static    "RemovedFlag = NOT_REMOVED"


template宣言部

説明:
任意の検索条件の指定です。key宣言部と排他になります。
検索条件には、固定値の他に親モデル側で保持している現象型の値を含めることが出来ます。
左辺側は子モデル側の現象型名を指定し、右辺側には固定値もしくは親モデル側の現象型の値を

${親モデル側の現象型名}
という形式で指定できます。

記述:

filter    "RemovedFlag = NOT_REMOVED and 乗り物種別 = ${乗り物種別}"


unique属性

説明:
検索結果が複数件数になることがあるかの指定です。
ここでtrueを指定しているのに複数件の結果が返ってきた場合はエラーとなります。

区分値:

true    検索結果はnullもしくは単数
false   検索結果が複数になりうる(デフォルト値)


cache属性

説明:
検索結果をキャッシュするかの指定です。
ここでtrueを指定すると、一度参照された検索結果がキャッシュされてその後はデータベースの検索を行わなくなります。

区分値:

true    検索結果をキャッシュする(デフォルト値)
false   検索結果をキャッシュしない



procedureサブセクション

現象型に対して、その値を導出するためのルールを実装したProcedureをマッピングするためのセクションです。
単純な例で言えば、以下のような物が考えられます。

  • データモデル : 顧客モデル
  • 現象型 : 現在年齢
  • 導出ルール : 現在時刻(システム時刻) - 生年月日(顧客モデルの一項目)を年齢に換算する
この場合、以下のような記述ができます。

例:ProcedureをJavaで実装して直接マッピング
(procedure
    (procedure
        現在年齢    test.share.procedure.CurrentAgeProcedure
    )
)
このように、参照された時点(システム時刻)を元に動的に値が決まるような現象型の場合は、
データベースのカラムではなくProcedureという値の導出ルール実装をマッピングすることで対応できます。
このProcedureの指定方法には、以下の4パターンがあります。 上記の指定方法は混在できるので、一つのモデル定義内で各現象型に対してそれぞれ違う指定を行うことができます。
以下でそれぞれの指定方法について説明します。


Directiveで導出ルールを直接表現する指定

書式:

(procedure
    (procedure
        現象型    "Directive式"
    )
)

説明:
プログラムやサービスによる処理までは必要としないような、簡易な値導出ルールの場合に便利な指定方法です。

左辺に現象型、右辺にその値を導出するためのDirective式を記述してください。
ここで指定できるDirective式についてはこちらのリファレンスを参照してください。

なお、この機能はただいま実装中です。完了するまで今しばらくお待ち下さい。

記述例:親データにひも尽く子データの件数を返す

(procedure
    (procedure
        交通費精算書明細データ件数    "&Size:{交通費精算書明細}"
    )
)


Serviceとして作成されたProcedureの指定

ServiceFrameworkを使用して実装したProcedureを指定する場合の方法です。
この方法の利点は、プログラミングが必要ない(=Javaという言語に縛られない)事や、ServiceFrameworkの機能がそのまま利用できるところです。

この場合、対象の現象型が外部から参照されたタイミングで、指定されたサービスの呼出が行われます。
呼び出されたサービスは、呼出元モデルをあるセッションキーで入力パラメータとして受け取ります。
それを参照して何らかの値を導出して出力パラメータとしてあるセッションキーで呼出元モデルに返すという動作になります。

Procedureサービス呼出の指定方法には、以下の3通りがあります。

以下でそれぞれについて説明します。

Procedureサービス呼出の省略形書式

書式:

(procedure
    (procedure
        現象型    "&Service:{ serviceName }"
    )
)

説明:
サービス名のみを指定する場合の書式です。
この場合、サービスに対して渡される呼出元データモデルのSessionKeyと、 サービスが呼出元データモデルに返す値のSessionKeyは以下のデフォルトのキーとなります。

通常は、この書式が一番使用されます。

セッションキー
PEXA_Source 呼出元のデータモデルそのもの
PEXA_Return 呼出元のデータモデルに返す、サービスで導出した値

記述例:

(procedure
    (procedure
        現在年齢    "&Service:{現在年齢取得Procedure}"
    )
)


Procedureサービス呼出の入出力キー指定書式

書式:

(procedure
    (procedure
        現象型    "&Service:{ serviceName:sourceSessionNameKey:returnSessionNameKey }"
    )
)

説明:
サービス名および、サービスに対しての入出力キー名を指定する場合の書式です。
この場合、サービスに対して渡される呼出元データモデルのSessionKeyと、 サービスが呼出元データモデルに返す値のSessionKeyはここで指定されたキー名となります。

セッションキー
sourceSessionNameKeyで
指定されたキー名
呼出元のデータモデルそのもの。
なお、この指定が省略された場合はサービスの引数として呼出元データモデルを受け取らないことを表す。
returnSessionNameKeyで
指定されたキー名
呼出元のデータモデルに返す、サービスで導出した値。
なお、この指定が省略された場合は"PEXA_Return"が出力値キーとしてして採用される。

記述例1:
サービスに対して呼出元モデルを渡すための入力キーを"顧客モデル"として、
サービスが導出した値を呼出元データモデルに返すための出力キーを"現在年齢"とした場合。

(procedure
    (procedure
        現在年齢    "&Service:{現在年齢取得Procedure:顧客モデル:現在年齢}"
    )
)

記述例2:
サービスに対して呼出元モデルを渡すための入力キーを"顧客モデル"として、
サービスが導出した値を呼出元データモデルに返すための出力キーを省略してデフォルトの"PEXA_Return"とした場合。

(procedure
    (procedure
        現在年齢    "&Service:{現在年齢取得Procedure:顧客モデル:}"
    )
)

記述例3:
サービスに対して呼出元モデルを渡すための入力キーを省略して渡さないことにして、、
サービスが導出した値を呼出元データモデルに返すための出力キーを省略してデフォルトの"現在時刻"とした場合。

(procedure
    (procedure
        現在時刻    "&Service:{現在時刻取得Procedure::現在時刻}"
    )
)


Procedureサービス呼出の詳細指定書式

書式:

(procedure
    (procedure
        (現象型名
            service_name    serviceName             ;; 呼び出したいサービスの名前が設定される
            source          sourceSessionNameKey    ;; 呼出元データモデルが設定される
            return          returnSessionNameKey    ;; Serviceからの戻り値が設定される
            (session                                ;; ServiceSessionに設定する値(option)
                SessionKey1    Value1
                SessionKey2    Value2
                    ...
            )
        )
    )
)

説明:
一番詳細な形で記述するための書式です。
この書式を使用した場合は、今までの書式の情報に加えて任意のパラメータをサービスに対して渡すことができます。
ここで指定できるのは以下の項目になります。

パラメータ名
service_name宣言部 呼出したいサービスの名前
source宣言部 呼出元のデータモデルをサービスに渡すためのSessionKey名の指定。
指定されなかった場合はサービスに対して呼出元データモデルが渡されない。
return宣言部 サービスが導出した値を呼出元のデータモデルに返すためのSessionKey名の指定。
指定されなかった場合はデフォルトの"PEXA_Return"が採用される。
sessionセクション サービスに渡したい任意パラメータのSessionKey名及び値の指定。
任意パラメータ用なので指定しなくても良い。

記述例1:
service_name, source, returnを指定した場合。
これはProcedureサービス呼出の入出力キー指定書式と結果は全く同じ。

(procedure
    (procedure
        (現在年齢
            service_name    現在年齢取得Procedure
            source          顧客データ
            return          現在年齢
        )
    )
)

記述例2:
サービスに任意パラメータを指定した場合。

(procedure
    (procedure
        (現在年齢
            service_name    現在年齢取得Procedure
            source          顧客データ
            return          現在年齢
            (session
                現在時刻    &Today
                今日日付    &Now
            )
        )
    )
)



Javaプログラムとして作成されたProcedureの指定

JavaプログラムとしてProcedureを作成し、それを指定することが可能です。
この方法は、サービスによる実装ではパフォーマンスに問題がある場合や、サービス定義ファイルでの記述では実現が難しい場合などに使用します。

ただし、JavaプログラムとしてProcedureを作成するとJavaというプラットフォームに縛られるので、 可能な限りDirectiveサービスによる実装が推奨されます。

指定方法としては、以下の二通りがあります。

それぞれについて以下で説明します。

Procedureクラスを直接指定する場合

書式:

(procedure
    (procedure
        現象型    Procedureクラス名
    )
)

説明:
ユーザーによって任意の処理を実装した、Javaクラスとして作成したProcedureを現象型にマッピングするためのセクションです。

左辺に現象型、右辺に対応するProcedureクラス名を必要な数だけ列挙してください。
ここで指定するHelperクラスはpexa.share.concept.Procedureを実装したクラスです。

記述例

(procedure
    (procedure
        現年齢    xxxx.share.procedure.CurrentAgeProcedure
        在籍日数  xxxx.share.procedure.RegisterDateCountProcedure
    )
)


ProcedureSourceクラスとパラメータを指定する場合

書式:

(procedure
    (procedure
        現象型    ProcedureSourceクラス名%パラメータ文字列
    )
)

説明:
Javaクラスとして作成されたProcedureを使用するが、直接そのクラス名を指定せずに、 ProcedureSourceというクッションになるクラスとそれに対するパラメータを指定する方法です。

この方法で指定すると、以下のような流れでProcedureが呼び出されます。

  1. ProcedureSourceインスタンスが、パラメータ文字列を渡されてnewされる。
  2. Procedureインスタンスが、ProcedureSourceからパラメータ文字列をコンストラクタに渡されてnewされる。
  3. newされたProcedureインスタンスが呼び出される。
これにより、一つのProcedure実装で、複数のProcedure機能を有する場合などの固定的なパラメータによる処理の切り分けなどができます。
ここで指定するProcedureSourceのクラスはpexa.share.concept.ProcedureSourceを実装したクラスです。

記述例
パラメータで「満年齢」か「数え年」を指定して、現在年齢を取得するProcedureをProcedureSource経由で呼び出す。

(procedure
    (procedure
        現在年齢    xxxx.share.procedure.CurrentAgeProcedureSource%満年齢
    )
)



SessionBeanとして作成されたProcedureの指定

書式:

(procedure
    (procedure
        現象型    session:pathName
    )
)

説明:
呼び出すProcedureがSessionBeanである場合の指定です。
プロトコル指定がsessionである必要はありませんが":"が入るとJNDIのパス文字列が指定されたと見なされます。
これにより、Procedure呼び出しがネットワーク越しに他のサーバー呼び出しになる場合もサポートしています。

記述例

(procedure
    (procedure
        Validation    session:server.facade.ValidationFacade
    )
)


triggerセクション

書式:

(trigger
    (before(0|1)
        現象型    Triggerクラス名
        現象型    Triggerクラス名
        現象型    Triggerクラス名
                :
                :
                :
    )
    (after(0|1)
        現象型    Triggerクラス名
        現象型    Triggerクラス名
        現象型    Triggerクラス名
                :
                :
                :
    )
)


記述注:
    属性        あらかじめ決められた値を選択する(true/falseなど)
    宣言部      値または、値のリストを設定する
    セクション  入れ子で他の属性、宣言部、セクションを保持する可能性がある
                (値又は、値のリストが設定される場合もある)

    (1):必須
    (0|1):オプション
    (1以上):一個以上必須
    (0以上):0個以上(オプション)

説明:
ある現象型に対して値が設定された事を契機として起動される、Triggerというプログラムモジュールを設定するためのセクションです。

Triggerの実行タイミングは、値の設定前と設定後のどちらかを指定できます。
値の設定前に実行したいTriggerはbeforeサブセクション内に、
値の設定後に実行したいTriggerはafterサブセクション内に記述してください。

サブセクション内では、左辺にはTriggerを起動したい現象型名を指定し、右辺にはTriggerクラス名を指定してください。
ここで指定するHelperクラスはpexa.share.concept.Triggerを実装したクラスです。

記述例:

(trigger
    (after
        勘定科目No    xxxx.share.service.trigger.計上時仕訳貸借種別Trigger
    )
)


aliasセクション

書式:

(alias
    別名現象型    モデル内の現象型(パス式も可)
    別名現象型    モデル内の現象型(パス式も可)
    別名現象型    モデル内の現象型(パス式も可)
	           :
	           :
	           :
)


記述注:
    属性        あらかじめ決められた値を選択する(true/falseなど)
    宣言部      値または、値のリストを設定する
    セクション  入れ子で他の属性、宣言部、セクションを保持する可能性がある
                (値又は、値のリストが設定される場合もある)

    (1):必須
    (0|1):オプション
    (1以上):一個以上必須
    (0以上):0個以上(オプション)

説明:
ある現象型に対して別名の現象型を設定するためのセクションです。

左辺には別名現象型名を指定し、右辺にはマッピング対象の現象型を指定してください。
なお、右辺側にはパス式を記述することが可能なので、Proxyとパス式を組み合わせて別モデルの項目をあたかもそのモデルの項目として見せることが出来ます。

記述例:

(alias
    PEXA_IdentifiedFlag    OrderIdentifiedFlag
    CreatorName            Creator/UserName
    UpdatorName            Updator/UserName
)


staticセクション

書式:

(static
    初期値を設定する現象型    初期値の文字列表現または初期値を設定する項目名(パス式を含む)
    初期値を設定する現象型    初期値の文字列表現または初期値を設定する項目名(パス式を含む)
    初期値を設定する現象型    初期値の文字列表現または初期値を設定する項目名(パス式を含む)
	           :
	           :
	           :
)


記述注:
    属性        あらかじめ決められた値を選択する(true/falseなど)
    宣言部      値または、値のリストを設定する
    セクション  入れ子で他の属性、宣言部、セクションを保持する可能性がある
                (値又は、値のリストが設定される場合もある)

    (1):必須
    (0|1):オプション
    (1以上):一個以上必須
    (0以上):0個以上(オプション)

説明:
ある現象型に対して固定の初期値を設定するためのセクションです。

左辺には初期値を持たせたい現象型名を指定し、右辺には初期値の文字列表現または、現象型名またはパス式を指定してください。現象型名または、パス式を指定する場合は、先頭にアスタリスク"*"を設定する必要があります。アスタリスクが存在しない場合は、現象型の値が指定されたと見なされます。
初期値が設定された現象型がデータベースのカラムとマッピングされている場合、 アプリケーションによって別の値が上書き設定されていなければ、その初期値が初回コミット時にデータベースにも設定されます。

記述例:

(static
    EntityName      PrescriptionOrder
    VersionNumber   1
    RemovedFlag     NOT_REMOVED
    ValidityFlag    VALID
    CreateDate		*CreateDatetime	;; 項目を指定した場合
    MaterialName	*MaterialNo/MaterialName	;; パス式を指定した場合
)


mappingセクション

説明:
他のモデルを指すProxyの現象型名に対して、ModelMapping機能による自動接続先のモデル名を設定するためのセクションです。
なお、ModelMapping機能による接続先モデルはProxy定義によってデフォルト設定されているのが基本ですので、このセクションは必要がない限りは記述する必要はありません。 Proxy定義のデフォルト設定を上書き設定したい場合や、個別に詳細設定を行いたい場合にのみ記述してください。

このセクションは簡易形式詳細形式の2種類の指定方法があります。
以下でそれぞれについて解説します。

簡易形式

書式:

(mapping
    他モデルを指すProxy現象型    接続対象モデル名
    他モデルを指すProxy現象型    接続対象モデル名
    他モデルを指すProxy現象型    接続対象モデル名
	           :
	           :
	           :
)


記述注:
    属性        あらかじめ決められた値を選択する(true/falseなど)
    宣言部      値または、値のリストを設定する
    セクション  入れ子で他の属性、宣言部、セクションを保持する可能性がある
                (値又は、値のリストが設定される場合もある)

    (1):必須
    (0|1):オプション
    (1以上):一個以上必須
    (0以上):0個以上(オプション)

説明:
簡易形式の記述方法です。
左辺には他モデルを指すProxy現象型を指定し、右辺にはモデル名を指定してください。

記述例:

(mapping
    OrderNo      PrescriptionOrderModel
    PatientNo    PatientInfo
)


詳細形式

書式:

(mapping
    (他モデルを指すProxy現象型1
        path宣言部(1)
        cache属性(0|1)
        transient属性(0|1)
    )
    (他モデルを指すProxy現象型2
        path宣言部(1)
        cache属性(0|1)
        transient属性(0|1)
    )
        :
        :
)


記述注:
    属性        あらかじめ決められた値を選択する(true/falseなど)
    宣言部      値または、値のリストを設定する
    セクション  入れ子で他の属性、宣言部、セクションを保持する可能性がある
                (値又は、値のリストが設定される場合もある)

    (1):必須
    (0|1):オプション
    (1以上):一個以上必須
    (0以上):0個以上(オプション)

説明:
詳細形式の記述方法です。
他モデルを指すProxy現象型をセクション名のセクション内部に、マッピング先のデータモデル名やキャッシュオプションを指定します。

記述例:

(mapping
    (OrderNo
        path      PrescriptionOrderModel
        cache     instance
        transient true
    )
)


path宣言部

説明:
外部キーProxy現象型に対してマッピングするデータモデル名を指定します。

記述:

path    PrescriptionOrderModel


cache属性

説明:
検索結果のキャッシュ指定です。
データモデルインスタンス単位のキャッシュ、JavaVM単位のキャッシュ、キャッシュ無しを選択できます。

区分値:

instance    検索結果をデータモデルインスタンス内でキャッシュする
vm          検索結果をJavaVM内でキャッシュする
none        キャッシュしない(デフォルト)


transient属性

説明:
cache属性でinstanceもしくはvmを指定した場合に有効になる設定です。
データモデルがRMI通信によりClient/Server間で転送された場合にキャッシュ内容を保持するかが指定できます。
この指定がfalseの場合、転送時にキャッシュ内容もネットワークを通じて送信されるので、通信データ量が大きくなります。必要がない限りfalseのままにしておいてください。

区分値:

true    検索結果は転送時に破棄する(デフォルト値)
false   検索結果を転送時も保持する



completionセクション

書式:

(completion
    beforeセクション(0|1)
    afterセクション(0|1)
)


記述注:
    属性        あらかじめ決められた値を選択する(true/falseなど)
    宣言部      値または、値のリストを設定する
    セクション  入れ子で他の属性、宣言部、セクションを保持する可能性がある
                (値又は、値のリストが設定される場合もある)

    (1):必須
    (0|1):オプション
    (1以上):一個以上必須
    (0以上):0個以上(オプション)

説明:
親モデルのcommit実行前(beforeサブセクション)と実行後(afterサブセクション)に行う、
子モデルとの間の連動処理を定義するためのセクションです。
ModelConvert機能における子モデルとの連動処理の設定となります。

記述例:

(completion
    {before
        (cascade
            RemovedFlag:REMOVED         ""
            ValidityFlag:INVALID        ""
        )
    }
    {after
        DiseasePhaseModelList       ""
    }
)

以下の二つのサブセクションがあります。
ModelConvert機能による親子間の連動処理を行うには、この二つのサブセクションの設定内容がセットになります。
どちらか一方のみの設定というのは基本的にありません。


beforeサブセクション

書式:

(completion
    {before
        (cascade
            子モデルと連動させる現象型名:連動する値の文字列表現     ""
            子モデルと連動させる現象型名:連動する値の文字列表現     ""
            子モデルと連動させる現象型名:連動する値の文字列表現     ""
               :
               :
        )
    }
)


記述注:
    属性        あらかじめ決められた値を選択する(true/falseなど)
    宣言部      値または、値のリストを設定する
    セクション  入れ子で他の属性、宣言部、セクションを保持する可能性がある
                (値又は、値のリストが設定される場合もある)

    (1):必須
    (0|1):オプション
    (1以上):一個以上必須
    (0以上):0個以上(オプション)

説明:
親モデルのコミット完了前(before completion)に、子モデルに対して行う連動処理を定義するためのセクションです。
ここでは基本的に、項目レベルでの連動処理をcascadeセクション内部に記述します。

基本的な設定としては、以下の2項目についての連動が自動で行われるように記述します。

  • 親モデルのRemovedFlagがREMOVEDになったら子モデルのRemovedFlagもREMOVEDにする
  • 親モデルのValidityFlagがINVALIDになったら子モデルのValidityFlagもINVALIDにする


afterサブセクション

書式:

(completion
    {after
        連動してcommitする子モデルを表す現象型名       ""
        連動してcommitする子モデルを表す現象型名       ""
        連動してcommitする子モデルを表す現象型名       ""
             :
             :
    }
)


記述注:
    属性        あらかじめ決められた値を選択する(true/falseなど)
    宣言部      値または、値のリストを設定する
    セクション  入れ子で他の属性、宣言部、セクションを保持する可能性がある
                (値又は、値のリストが設定される場合もある)

    (1):必須
    (0|1):オプション
    (1以上):一個以上必須
    (0以上):0個以上(オプション)

説明:
親モデルのコミット完了後(after completion)に、子モデルに対して行う連動処理を定義するためのセクションです。
ここでは基本的に、連動してコミットする対象の子モデルを指定することになります。

このセクションの記述内容は、procedureセクションのmodelサブセクションと同一になります。
詳細はそちらを参照してください。


更新情報

  • 最終更新者 : $Author: namako $
  • 最終更新日時 : $Date:: 2012-04-16 14:36:27 #$
  • バージョン : $Revision: 6885 $



Copyright © 2006, Atrris Corporation