このシリーズの最初のパートでは、データベース内のエンティティのライフサイクルを管理するためのいくつかの基本的な手順を紹介しました。 2番目の最後の部分では、追加の構成テーブルを使用して実際のワークフローを定義する方法を示します。これは、ユーザーが方法の各ステップで許容されるオプションを提示される場所です。また、部品表構造での「アセンブリ」と「サブアセンブリ」の厳密な再利用を回避するための手法についても説明します。
オプションの定義
第1部では、コアワークフローテーブルと、これらをデータベースに簡単に組み込む方法を紹介しました。ここで必要なのは、ユーザーが次の論理状態を選択できるようにするためのものです。これは、論理ワークフローを定義するものです。 。
次の図は、ワークフローデータベースモデルのすべてのコンポーネントを定義しています。
2つの構成テーブルworkflow_state_option およびworkflow_state_context 、モデルに追加されました。 許容される次の状態を定義するオプションテーブルから始めます。 。その機能を理解したら、コンテキストテーブルに戻り、その機能について説明します。
許容される次の状態
次の表は、構成表全体のSQLビューに似ています。ここでは、テーブルの結合を非表示にして、type_keysの組み合わせを確認しています。 。それでは、それぞれの STATE.OUTCOMEについて考えてみましょう。 オプションを組み合わせて定義します ユーザーが利用可能：
| STATE.OUTCOMEの組み合わせ（状態階層から） | 状態コンテキスト | 子供が無効 | オプション1 | オプション2 |
|---|---|---|---|---|
| APPLICATION_RECEIVED .ACCEPTED | STANDARD_JOB _APPLICATION | N | APPLICATION_REVIEW | |
| APPLICATION_RECEIVED .REJECTED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| APPLICATION_REVIEW .PASSED | STANDARD_JOB _APPLICATION | N | INVITED_TO_INTERVIEW | |
| APPLICATION_REVIEW .FAILED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| INVITED_TO_INTERVIEW .ACCEPTED | STANDARD_JOB _APPLICATION | N | インタビュー | |
| INVITED_TO_INTERVIEW .DECLINED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| インタビュー .PASSED | STANDARD_JOB _APPLICATION | N | MAKE_OFFER | SEEK_REFERENCES |
| INTERVIEW.FAILED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| インタビュー .CANDIDATE_CANCELLED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | INVITED_TO_INTERVIEW |
| インタビュー 。NO_SHOW | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| MAKE_OFFER.ACCEPTED | STANDARD_JOB _APPLICATION | N | SEEK_REFERENCES | |
| MAKE_OFFER.DECLINED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| SEEK_REFERENCES .PASSED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .HIRED | |
| SEEK_REFERENCES .FAILED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| APPLICATION_CLOSED .HIRED | STANDARD_JOB _APPLICATION | N | ||
| APPLICATION_CLOSED .NOT_HIRED | STANDARD_JOB _APPLICATION | N |
今のところコンテキストを無視しているため、状態コンテキスト および子供が無効ですか？ 灰色で表示されます。また、簡潔にするために、この例ではオプションの数を2つに制限しましたが、実際には制限はありません。
では、これはどのように機能しますか？
インタビューが行われたばかりで、インタビュアーが結果を記録していると想像してください。更新される基になるテーブルはmanaged_entity_stateです 。論理的な結果には、PASSEDとFAILEDの2つがあります。したがって、現在のmanaged_entity_state 選択した結果で更新されます（wf_state_type_outcome_id ）。サンプルモデルでは、インタビュアーはインタビューに関するメモを含めることもできます。
インタビュアーがPASSEDを選択すると、MAKE_OFFERとSEEK_REFERENCESの2つのオプションが表示されます。これらは次の状態です 私たちのワークフローで。 go toに似ています プログラミングのステートメント。どちらのオプションでも、新しい行がmanaged_entity_stateに挿入されます 、ワークフロープロセスの次の状態に求人応募を移動します。ユーザーは、due_dateを入力して、この期限を設定できます。 。
一方、インタビュアーがFAILEDを選択した場合、オプションはAPPLICATION_CLOSEDの1つだけです。したがって、新しいmanaged_entity_state 行は、APPLICATION_CLOSED状態（wf_state_type_state_id）を使用して挿入されます 。
APPLICATION_CLOSED状態に使用できるオプションがないことがわかります。これは、ワークフロープロセスの終わりに到達したことを意味します。
コンテキストテーブル
コンテキストテーブルの役割を確認するために、技術的な求人応募プロセスの構成を見てみましょう。 再生：
| STATE.OUTCOMEの組み合わせ（州の階層から） | 状態コンテキスト | 子供が無効 | オプション1 | オプション2 |
|---|---|---|---|---|
| APPLICATION_RECEIVED .ACCEPTED | TECHNICAL_JOB _APPLICATION | N | アプリケーション _REVIEW | |
| APPLICATION_RECEIVED .REJECTED | TECHNICAL_JOB _APPLICATION | N | アプリケーション _CLOSED | |
| APPLICATION_REVIEW .PASSED | TECHNICAL_JOB _APPLICATION | N | INVITED_TO _INTERVIEW | |
| APPLICATION_REVIEW .FAILED | TECHNICAL_JOB _APPLICATION | N | アプリケーション _CLOSED | |
| INVITED_TO_INTERVIEW .ACCEPTED | TECHNICAL_JOB _APPLICATION | N | TEST_APTITUDE | |
| INVITED_TO_INTERVIEW .DECLINED | TECHNICAL_JOB _APPLICATION | N | アプリケーション _CLOSED | |
| TEST_APTITUDE .PASSED | TECHNICAL_JOB _APPLICATION | N | インタビュー | SEEK _REFERENCES |
| TEST_APTITUDE .FAILED | TECHNICAL_JOB _APPLICATION | N | アプリケーション _CLOSED | |
| インタビュー .PASSED | TECHNICAL_JOB _APPLICATION | N | MAKE_OFFER | SEEK _REFERENCES |
| インタビュー .FAILED | TECHNICAL_JOB _APPLICATION | N | アプリケーション _CLOSED | |
| インタビュー .CANDIDATE_CANCELLED | TECHNICAL_JOB _APPLICATION | Y | - | - |
| インタビュー 。NO_SHOW | TECHNICAL_JOB _APPLICATION | N | アプリケーション _CLOSED | INVITED_TO _INTERVIEW |
| MAKE_OFFER .ACCEPTED | TECHNICAL_JOB _APPLICATION | N | SEEK _REFERENCES | |
| MAKE_OFFER .DECLINED | TECHNICAL_JOB _APPLICATION | N | アプリケーション _CLOSED | |
| SEEK_REFERENCES .PASSED | TECHNICAL_JOB _APPLICATION | N | アプリケーション _CLOSED.SUCCESS | |
| SEEK_REFERENCES .FAILED | TECHNICAL_JOB _APPLICATION | N | アプリケーション _CLOSED | |
| APPLICATION_CLOSED .HIRED | TECHNICAL_JOB _APPLICATION | N | ||
| APPLICATION_CLOSED .NOT_HIRED | TECHNICAL_JOB _APPLICATION | N | INSUFFICIENT _EXPERIENCE | OVER _QUALIFIED |
ここでのコンテキストはTECHNICAL_JOB_APPLICATIONです。何でこれが大切ですか？結果を上書きできるからです。以前、部品表（BOM）構造で「アセンブリ」と「サブアセンブリ」を再利用できると述べたことを思い出してください。これは、何かを一度定義して再利用するときに役立ちますが、硬すぎる場合もあります。すべてを再利用したくない場合はどうなりますか？
workflow_state_contextを挿入する workflow_state_hierarchyの間 およびworkflow_state_option 、結果の再利用とオーバーライドの両方が可能です。このモデルでは、さまざまなプロセスで結果を有効にするか無効にするかを定義できます。
上記の例では、INTERVIEW.CANDIDATE_CANCELLEDの組み合わせは無効になっています。言い換えれば、それは単に技術的な求人応募にとって許容できる結果ではないということです。したがって、面接官は、技術的な面接の結果を記録するときにそれを選択できません。これは、クエリがworkflow_state_context.child_disabled = ‘N’のオプションのみを選択するためです。 。
workflow_state_option workflow_state_hierarchyの直接の子ではありません 、状態が使用されるたびに、個別のオプションのセットを定義する必要があります。ただし、このトレードオフにより、各プロセスのオプションを微調整できます。
適格な結果
より詳細な修飾子を定義するオプションもあります 結果のために。これを行うには2つの方法があります：
- BOMに4番目のレベルを作成して、階層の結果の下に修飾子を定義できます。このアプローチでは、デューデリジェンスを行う必要があります。たとえば、FAILEDの結果はさまざまな状態で使用されます。異なるFAILED状態に対して同じ修飾子を使用しますか？多分そうではありません。
- 修飾子は
workflow_state_typeで定義できます ただし、それらを階層に結び付けないでください。それらは自立型です。次に、workflow_state_optionを使用します 特定の結果コンテキストの修飾子を一覧表示します。これは上記の構成が示すものであり、OVER_QUALIFIEDおよびINSUFFICIENT_EXPERIENCE修飾子がAPPLICATION_CLOSED.NOT_HIRED結果のオプションとしてリストされています。
いずれの場合も、アプリケーションは、状態や結果ではなく、修飾子が選択されたことを認識する必要があります– workflow_level_type これを示し、managed_entity_state.wf_state_type_qual_idを更新します 選択した値で。
いくつかのテーブル構成データ
基礎となる構成データをテーブルごとに確認したい場合があります。ここにidsがあります およびtype_keys それらは括弧内で参照します。簡潔にするために、記事に関連する値のみが示されています。
ワークフロー_レベル_タイプ
| id | type_key |
|---|---|
| 1 | プロセス |
| 2 | 状態 |
| 3 | 結果 |
| 4 | QUALIFIER |
ワークフロー_state_type
| id | type_key | ワークフロー_level_type_id |
|---|---|---|
| 1 | STANDARD_JOB_APPLICATION | 1（プロセス） |
| 2 | TECHNICAL_APPLICATION | 1（プロセス） |
| 3 | インタビュー | 2（状態） |
| 4 | 合格 | 3（結果） |
| 5 | 失敗 | 3（結果） |
| 6 | MAKE_OFFER | 2（状態） |
| 7 | SEEK_REFERENCES | 2（状態） |
| 8 | APPLICATION_CLOSED | 2（状態） |
| 9 | 採用 | 3（結果） |
| 10 | NOT_HIRED | 3（結果） |
| 11 | INSUFFICIENT_EXPERIENCE | 4（QUALIFIER） |
| 12 | OVER_QUALIFIED | 4（QUALIFIER） |
ワークフロー_state_hierarchy
| id | state_type_parent_id | state_type_child_id |
|---|---|---|
| 1 | 1（STANDARD_JOB_APPLICATION） | 3（インタビュー） |
| 2 | 2（TECHNICAL_JOB_APPLICATION） | 3（インタビュー） |
| 3 | 3（インタビュー） | 4（合格） |
| 4 | 3（インタビュー） | 5（失敗） |
| 5 | 1（STANDARD_JOB_APPLICATION） | 8（APPLICATION_CLOSED） |
| 6 | 2（TECHNICAL_JOB_APPLICATION） | 8（APPLICATION_CLOSED） |
| 7 | 8（APPLICATION_CLOSED） | 9（HIRED） |
| 8 | 8（APPLICATION_CLOSED） | 10（NOT_HIRED） |
ワークフロー_state_context
| id | state_type_id | state_hierarchy_id | child_disabled |
|---|---|---|---|
| 1 | 1（STANDARD_JOB_ APPLICATION） | 3（INTERVIEW.PASSED） | N |
| 2 | 1（STANDARD_JOB_ APPLICATION） | 4（INTERVIEW.FAILED） | N |
| 3 | 1（STANDARD_JOB_ APPLICATION） | 7（APPLICATION_CLOSED。HIRED） | N |
| 4 | 1（STANDARD_JOB_ APPLICATION） | 5（APPLICATION_CLOSED。NOT_HIRED） | N |
| 5 | 2（TECHNICAL_APPLICATION） | 6（APPLICATION_CLOSED。NOT_HIRED） | N |
ワークフロー_state_option
| id | state_context_id | state_type_id |
|---|---|---|
| 1 | 1（STANDARD_JOB_APPLICATION。INTERVIEW。PASSED） | 6（MAKE_OFFER） |
| 2 | 1（STANDARD_JOB_APPLICATION。INTERVIEW。PASSED） | 7（SEEK_REFERENCES） |
| 3 | 2（STANDARD_JOB_APPLICATION。INTERVIEW。FAILED） | 8（APPLICATION_CLOSED） |
| 4 | 5（TECHNICAL_JOB_APPLICATION。APPLICATION_CLOSED。NOT_HIRED） | 11（INSUFFICIENT_EXPERIENCE） |
| 5 | 5（TECHNICAL _JOB_APPLICATION。APPLICATION_CLOSED。NOT_HIRED） | 12（OVER_QUALIFIED） |
明らかに、これを設定するのは非常に難しいです。できれば、ユーザーフレンドリーなインターフェースを備えたアプリケーションを介して管理する必要があります。
代替シーケンス
多くのテーブルにalt_sequenceという列があることに注意してください。 。これは、ユーザーに提示されるさまざまな選択の値のリストを並べ替えるために使用されます。通常、これは使用状況に基づいて降順で表示され、最も頻繁に使用されるオプションが一番上に表示されます。
この記事ではジョブアプリケーションについて説明しましたが、このモデルは、エンティティの状態を長期にわたって管理する必要がある多くの種類のワークフローに使用できます。または、モデルをパターンとして使用して、特定の要件に合わせてカスタマイズすることもできます。