DCWorkFlowとは

　CMF 1.4より、標準配布物に DCWorkFlowが含まれるようになりました。DCWorkFlowは、CMF サイトの中の portal_content のワークフローを定義するものです。

　ここでは、ワークフローの概念自体は説明しませんので、別のところで学習してください。

http://www.atransia.co.jp/home/ZenKai/Members/kafka/News/1036669673/view

また、DCWorkFlowは、 CMF の枠組みの中でうまく定義、動作できるようにデザインされているものですので、Zopeの Roleの概念や、CMFの構成要素 （skin や portal_content、permission） に対する理解が必要ですが、それもここでは説明しません。
　あらかじめ CMFDefault Site（もしくは、Ploneサイト） を Addして、コンテンツを published の状態にするまでの操作をして、CMF自体が大体どんなものかを理解してから以下を読んでください。

　CMFDefault の中で portal_workflow を開くと、最初に workflows のタブが開いていて、どの content_type には、どのワークフローを使うかが書いてあります。（初期状態では、すべて (default) = "default_workflow" となるようになっています）

その画面から contents タブを開いて、AddWorkflow ボタンを押すと、 workflow 追加画面になり、そこで DCWorkFlowを追加することができます。

　

 Type の中でカッコ内に Web-configureable workflow とあるものが、DCWorkFlowのインスタンスが作成されるもので、あとで定義を追加・変更できるものです。 Simple Review / Publish Policy は、デフォルト状態で登録されている default_workflowと同じで、定義不可能なものです。
　定義可能な WorkFlowの中で、[Classic][Review 2]は、CMFDefault の中で使えるように定義済みになっているものですので、ためしに両者を Add して、その定義がどうなっているかを見るのは、新たに workflowを定義するためにも有用だと思います。
　かくいう私も、両者の定義がどう違うかよく見ていませんが、大体、CMFDefaultで最初に存在する default_workflow と同じ動きをするもののようです。

　以下が、Classic と Revision 2を追加した portal_workflowの画面。

DCWorkFlowの定義画面を開いて見ると、普段見慣れた

のほかに、DCWorkFlow特有のタブがあります。これについて以下にざっと説明します。

タブ名 概要
Status portal_contentの状態を定義します。具体的には
  • 現在の Statusから、どの Trasition に移動することができるのか
  • 現在の Statusの時の portal_contentの Permission
  • 現在の Statusに移動してきたときに、どのVariable にどういう値を設定するか

が定義できます。

初期状態（portal_contentが作成された時）に設定される status には '*' が付いて表示されます。
Trasitions 状態遷移図の矢印に相当する部分です。具体的には
  • どの Statusに移動するか
  • どういう条件でトリガされるか
  • 起動の前後に実行するスクリプト
  • どの　条件（Permissionなど）の時に、このTrasisionを起動できるか
  • Action Box の表示内容
  • Trasision が起動されたときに、どのVariableにどういう値を設定するか
Variables WorkFlowの遷移中に変化する portal_content のプロパティとその定義
Worklists 特定の条件が揃った portal_contentが存在するときに、画面に表示するための定義。

うまく説明できませんが、CMFDefaultで、Pendingのものがあるときに Reviewerの Action Box　"Pending 1" と知らせるための定義は、ここに書いてある。
Scripts Transisionから呼ばれるスクリプトの定義
Permissions WorkFlowを移動中に変化する Permissionを選択しておく

　と偉そうに書いておきながら、Status や Trasionsにある Variables と、DCWorkFlowの中の Variables は、どうやって使い分ければよいのだろう？とか、疑問点は多々あります。（だれか、もっと突っ込んだ解説をしてください）　

雑感

　DCWorkFlowは、CMFの枠組みの中でうまく動作するように設計されているので、CMFを使いこなしている方には DCWorkFlowでワークフローが定義できるのは便利でしょう。

　しかし、市販されているワークフローシステム（めちゃ高いやつ）と比較すると、あまり複雑なことはできません。特に、ワークフローのオブジェクト (portal_content) が分割や再結合するようなことができないので、そのような業務に使おうとするのは大変でしょう。また、複数のドキュメントや画像の複合物のようなものを、ワークフローさせたいような場合、portal_contentを定義しないといけないので、厄介です。

　オブジェクトの状態によって、自動的に異なる Statusに移動するようなワークフローは、Trasions の Trigger type で Automatic Triger を選択するとできるそうですが、見通しが悪くなってしまうと思います。

　そうしてみると、稟議書や、支払い伝票の類（めっちゃ高いワークフロー製品で扱うようなもの）を DCWorkFlowを使って処理するのは難しいでしょう。やはり、サイトのコンテンツを公開するまでのそれほど複雑でないワークフローのための定義ツールの範囲で使うだけにしたほうがよいと思いました。
　めっちゃ高いワークフロー製品でやっているようなことをどうしても Zope でやりたい場合は、OpenWorkFlowを試してみるとよいでしょう。

参考 URL

　

ある nakagami のメモ