環境構築手順と実装方法についておさらいしておきます。(Buri-1.0.0を基準とします)気合いが入ってることが大前提です。中途半端な気持ちではBuriを役立てることはできません。DBFluteのBuri連携機能のExampleプロジェクト「dbflute-buri-example」を参考にするようにして下さい。DBFluteのBuri連携の概要#Buriはステータス実装のための便利な機能を持っています。その機能を有効利用するためにDBFluteがBuriと連携します。ディベロッパーBuriの内部構造を意識させない「A」は言うまでもないですね。DBFluteのポリシーです。Buri内部で例外が発生したりするととてもやっかいです。トラブルが発生しないようにします。純粋に業務的なステータス実装に集中する」ということです。便利な機能を使うためにその他の煩雑な知識が必要になっては意味がありません。その代わりアーキテクトはできるだけトラブルがないように、環境構築やアプリへの微調整など頑張ることが大事です。DBユーザと空のDBスキーマを作成>まずはDB環境です。後の手順でReplaceSchemaを実行しますので、とりあえずは「DBユーザ」と「空のDBスキーマ」を作成して下さい。EMechaで普通にDBFlute環境>こちらは、DBFluteのドキュメント「EMechaによるセットアップ」をご覧下さい。buriDefinitionMap.dfpropの作成・設定>DBFluteクライアント/dfprop配下に「buriDefinitionMap.dfprop」という名前のファイルを配置します。手動で作成するよりかは、dbflute-buri-exampleのburiDefinitionMap.dfpropをコピーして持って来るようにして下さい。activityDefinitionMapにXPDL上のアクティビティを定義します。「status」にはステータスになりえるアクティビティを定義します。基本的にはXPDL上のFinishModeがManualのアクティビティがそれです。「action」にはそのプロセスで利用する全てのアクションを定義します。tableProcessMapに実際の業務テーブルとプロセスとの関連を定義します。一つのテーブルに複数のプロセスが関連付けられるようになっています。一つのテーブルに一つのプロセスであれば、list:{}の中に一つだけプロセスを指定して下さい。playsql配下にBuriの内部テーブルのDDL>Buriの内部テーブルのDDLを配置します。「replace-schema-01-buri-internal.sql」Oracleであれば、dbflute-buri-exampleのreplace-schema-01-buri-internal.sqlをそのまま持って来てもOKです。playsql配下にDBFluteのBuri用VIEWのDDL>DBFluteが利用するBuriの内部テーブルを参照するためのVIEWのDDLを配置します。「replace-schema-02-dbflute-buri.sql」どのDBを使っていようが、dbflute-buri-exampleのreplace-schema-02-dbflute-buri.sqlをそのまま持って来て下さい。Oracleでないなら、VIEWのSQLの「LOCALTIMESTAMP」の部分を利用するDBに合わせて適切に調節して下さい。(INDEXの利用対象となるか確認)この件は、こちらの記事が参考になります。playsql配下に業務テーブルのDDL>業務テーブルのDDLを配置します。業務テーブルのDDLを実行するためにReplaceSchemaタスクを実行します。実行前にDBFluteクライアント/playsql/data配下に準備したデータを配置するようにして下さい。JDBC/Doc/Generate実行>JDBCタスク、Docタスク、Generateタスクを実行します。DBFluteのBuri連携のためのクラスが生成されます。allcommon.plugin.buriパッケージ配下のクラスがそれです。BasicParticipantProviderBehaviorToDataAccessRuleは、buri-share.diconに指定します。buri-share.diconはBuri本体からコピーしてきて修正します。dbflute-buri-exampleのburi-share.diconを参考に配置・修正して下さい。(Buri-1.0.1以降の場合は、buri-user.diconで指定できるようです)FixedBuriDataAccessScriptFactoryImplは、buri-extension.diconに指定します。buri-extension.diconはBuri本体からコピーしてきて修正します。dbflute-buri-exampleのburi-extension.diconを参考に配置・修正して下さい。BasicBuriUserDataProviderおよびBasicParticipantProviderは、buri-user.diconに指定します。dbflute-buri-exampleのburi-user.diconを参考に配置・修正して下さい。DBFluteの共通カラムの自動設定で利用するAccessContextの設定をして下さい。DBFluteの共通カラムのページを参考に。これは、ステータス更新ユーザ(の履歴)を保持するための設定です。AccessContextとBuriのステータス更新を関連付けて保持します。業務的に「誰がこのステータスを変更したのか」を保持することはほとんどの場合において必須かと思われます。ここではこの機能を利用することを前提として説明をしています。Buriの権限機能の仕組みを利用して実現しています。権限チェックを行いたい場合は、このあたりを独自に拡張して下さい。dbflute-buri-exampleが利用しているBuriのバージョンと実際に利用しようとしているBuriのバージョンが同じであれば、Exampleのdiconを持って来て、パッケージ名の調整などをするだけでもOKです。タイプセーフなtoNextStatus()>Buriのプロセスに関連付けられた業務テーブルのBehaviorにtoNextStatus_[プロセス]()メソッドが生成されています。プロセスの指定はメソッドで解決されタイプセーフです。アクションの指定はENUMによるタイプセーフです。指定されたステータスによる絞り込み条件での検索>Buriのプロセスに関連付けられた業務テーブルのBehaviorにgetEntities()メソッドが生成されています。ステータスを指定して該当する業務テーブルを検索できます。ステータスの指定はENUMによるタイプセーフです。第二引数:検索したいステータス(可変長引数で複数指定可)検索された業務テーブルのEntityリストは、Buriが保持する情報を取得するためのVIEWのEntityを保持しています。(内部的にsetupSelect_[ViewEntity]をしています)「Buriが保持する情報へのスムーズなアクセス」にて説明します。第二引数(可変長引数)を指定しなかった場合は、ステータス条件無しの検索となります。state.getStatusUpdateUser();}さらにステータス更新履歴のVIEWをLoadReferrerで取得することができます。番外編#履歴に対してExistsSubQueryができます。「とあるステータスになったことがある」という条件で絞り込みができます。このときのステータスの指定もタイプセーフです。});DBFluteが提供するViewはカスタマイズが可能です。基本構造を崩さなければ、カラムを追加などはアプリの自由です。おまけ#履歴に関してですが「ステータス変更時のコメント」のような業務的に結構重要な値を保持することができません。画面でステータス変更履歴を表示するときにBuriの履歴と一緒に合わせてどうのこうのってやらなければなりません。「ステータス変更履歴はBuriに任せることができる」っていうのが無いとBuri利用の説得力が半減するので、DBFluteで拡張してどうにかできないかなぁと考えたり...(でもさすがに簡単な拡張じゃないので無理かも)インターフェース的には、toNextStatus()に引数を増やして、コメントを一緒に(内部的に)登録できるようにできるといいかな。コメントに限らず設定次第で独自の値を第三引数で指定できると一番良いのかも。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。