経験したハードルを一通り集めてみる
前回はプロジェクトマネジメント編の目次でしたが、今回はアプリケーション編の目次を作成しました。本書の中心となる章です。
intra-martを使い始めた技術者が行き当たる問題は、「標準機能は一見便利そうに見えるのにあと一歩のところが届かないためにスクラッチ開発したくなる」ではないでしょうか1。私もプロジェクトの途中で何度も挫折(要件を満たせずにバーター交渉をしなければならない)しかけました。その中で出てきたアイディア達なので、これから開発を始める人や今まさに開発している人たちにもお役に立つのではないかと思います。
書きたいと思っている内容は次の節です。
アプリケーション編目次
- 物足りなく感じる標準機能に一工夫をすればまだまだ戦える
- ストアドファンクションの活用で輝くIM-LogicDesigner
- 共通マスタの不足を補うIM-FormaDesigner
- 複雑すぎる社内ルールを動的展開で表現できるIM-BIS
- 参照範囲を絞込めば意外と便利なViewCreator
- 例で見るintra-mart実装パターン
- テーブルを持つまでもない設定情報を保持するストアドファンクション
- コード体系が決まっているなら入力サポートを行うテキストボックス
- コードでの一本引きも検索からの選択も使えるテキストボックス
- 「その他」の時だけ入力できるテキストボックス
- ラジオボタンやセレクトボックスの外部連携に注意
- 確認ダイアログがユーザーに優しい「戻るボタン」
- 活性や表示の切替を統括するイベントボタン
- 外部連携でNULLオブジェクトに対処するためのダミー値
- 行選択による子画面への遷移
- 明細テーブルやグリッドを使う場合は表示順と行番号の不一致に注意
- 締め日を持たせて防止する業績改竄
- 業務間連携や複雑な処理を行う案件完了処理
- システム連携
- 直接DB連携が許容されるならFDWが最短
- intra-mart側処理によるファイル連携
- PostgreSQL側処理によるファイル連携
- バリデーション
- 関数フィールドを使った組合せバリデーション
- 隠しフィールドを使った業務的バリデーション
- ノード後処理を使った排他的バリデーション
- テンプレート
- テンプレート機能を使って高めるUI変更の安全性
- 共通ヘッダー/フッターはテンプレートで管理
- 画面の複雑性が高いならノード毎に画面を作った方が安全
- 紙がなくせない職場なら参照画面と合わせて印刷画面も作成
- 画面遷移
- 申請処理後の遷移先を指定
- 遷移時に処理が完了していないならリダイレクト画面でポーリング
- 一覧画面
- 同一部内の隣の課の作った申請も表示できる一覧画面
- 一覧画面からフロー画面を参照
- 一覧画面から履歴画面を参照
- 複雑なワークフロー
- 案件番号から案件情報を取得
- 案件の完了判定
- 動的承認ノードよりも横配置ノードよりも縦配置ノード
- ランクで判定する承認対象者
- 申請組織の階層構造に基づく再起処理
- 特定条件を満たすときのみ発動する例外承認ルート
- 強制差戻し
- 親子関係を持つワークフロー
- (1)子から親の参照
- (2)親から子の起票
- (3)子から親を選択して起票
- (4)同じ親を持つ子の重複防止
- (5)兄弟の順序や累計の利用
- 修正や削除を行うワークフロー
- (1)完了したワークフローに対する変更の意味
- (2)削除前情報を残さない削除
- (3)削除前情報を残す削除
- (4)変更前情報を残さない修正
- (5)変更前情報を残す修正
- データローディング
- (1)リプレースプロジェクトの鬼門
- (2)IM-BISのバージョニング機能をフル活用
- (3)DBスキーマを確定させるだけの画面
- (4)IM-LogicDesignerのルーティング定義
- (5)対象データのクレンジング
- (6)投入プログラムサンプル(C#)
- (7)運用開始までにAPIを閉じる
-
「そもそも機能が多過ぎてどう使えばいいのか分からない」の段階を乗り越えた人の話です。 ↩