2010-03-30

タスクの種類

XPDL BPMN

XPDLでは、タスクに複数の種類があります。ひとまず仕様書を抜粋して、一覧にしました。ちょっと違いの分からないものがいくつかあります。

TaskService: A Service Task is a Task that provides some sort of service, which could be a Web service or an automated application.
TaskSend: A TaskType of Send MUST NOT have an incoming Message Flow. A Send Task is a simple Task that is designed to send a message to an external participant (relative to the Business Process). Once the message has been sent, the Task is completed.
TaskReceive: A TaskType of Receive MUST NOT have an outgoing Message Flow. A Receive Task is a simple Task that is designed to wait for a message to arrive from an external participant (relative to the Business Process). Once the message has been received, the Task is completed.
TaskUser: A User Task is a typical workflow task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort.
TaskManual: A TaskType of Manual MUST NOT have an incoming or an outgoing Message Flow.
TaskApplication: The Activity is implemented by (one or more) tools. A tool may be an application program (link to entity Application); which may be invoked via Interface 3 (WfMC) - see the Workflow Client Application API (WAPI - Interface 2).
TaskScript: A Task Type of Script MUST NOT have an incoming or an outgoing Message Flow. A Script Task is executed by a business process engine. The modeler or implementer defines a script in a language that the engine can interpret. When the Task is ready to start, the engine will execute the script. When the script is completed, the Task will also be completed.
TaskReference: There may be times where a modeler may want to reference another activity that has been defined.

BPMNでも、タスクに複数の種類があるので、同じく一覧にします。

Service Task: A Service Task is a Task that uses some sort of service, which could be a Web service or an automated application.
Send Task: A Send Task is a simple Task that is designed to send a Message to an external Participant (relative to the Process). Once the Message has been sent, the Task is completed.
Receive Task: Receive Task is a simple Task that is designed to wait for a Message to arrive from an external Participant (relative to the Process). Once the Message has been received, the Task is completed.
User Task: A User Task is a typical “workflow” Task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort.
Manual Task: A Manual Task is a Task that is expected to be performed without the aid of any business process execution engine or any application. An example of this could be a telephone technician installing a telephone at a customer location.
Business Rule Task: A Business Rule Task provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide.
Script Task: A Script Task is executed by a business process engine. The modeler or implementer defines a script in a language that the engine can interpret. When the Task is ready to start, the engine will execute the script. When the script is completed, the Task will also be completed.

XPDL と BPMN は相互参照しながら仕様を策定していると思われるので、まず似ていると思うのですが、この部分はまったく一緒といっても良さそうですね。文章もコピーしたと思われます。
以下に一覧としてまとめました。

BPMN	XPDL	説明
Service Task	TaskService	サービス（典型的にはWebサービス）によって実行されるタスク
Send Task	TaskSend	プロセスに関係している外部のParticipant（人や組織とは限らない）にメッセージを送るタスク
Receive Task	TaskReceive	プロセスに関係している外部のParticipant（人や組織とは限らない）からメッセージを受け取るタスク
User Task	TaskUser	ソフトウェアを使って、人によって処理されるタスク。いわゆるワークフローシステムにおけるタスク
Manual Task	TaskManual	ソフトウェアの助けを借りずに、人によって処理されるタスク。
Business Rule Task	-	Business Rule Engine によって処理されるタスク。Service Task の特別なものと考えるべきか。
-	TaskApplication	何らかのアプリケーションによって処理されるタスク。Workflow Client Application API (WAPI) を介して実行される想定。
Script Task	TaskScript	BusinessProcessEngine 自信によって、自動処理されるタスク。処理内容はスクリプトによって記述される。
-	TaskReference	他のタスク定義を参照する。複数同じ定義を行う場合に使用する。

XPDL における TaskApplication の位置づけが正直よく解らないのですが、それ以外は解りやすいです。何らかのソフトウェアによって自動処理されるものが、Service Task, Business Rule Task, Script Task の3種類で、人によって処理されるものが User Task と Manual Taskの2種類。人かソフトウェアか、プロセスの外部にメッセージを送信 or 受信するだけのものが、Send Task, Receive Task になります。

2010-03-29

web.xml のの指定は、エラーページのファイルサイズに注意

プログラミング

web.xml で HTTP 404 エラーの場合に、同時のエラーページを指定することができます。
たとえば以下のようになります。

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
    <error-page>
        <error-code>404</error-code>
        <location>/error/404.html</location>
    </error-page>
</web-app>

ただしこの指定には注意が必要です。指定したエラーページのファイルサイズが小さいと、ブラウザで表示されません。
IEだけの話かと思いましたが、Firefox や Chrome でも同様の症状が発生します。

ちょっと試しに設定を書いて簡単なファイルを置いてとすると、ファイルサイズの件にハマってしまいます。注意してください。

2010-03-18

ExtJSのComboBoxで、HTML escape が必要な選択肢を表示する方法

プログラミング

ExtJSのExt.form.ComboBoxは、デフォルトでは選択肢のHTMLエスケープを実行してくれません。
たとえば

という選択肢を用意すると、右の図のようになります。

選択するときちんと表示されますが、選択肢の一覧のところではとが欠けているのが見て取れます。'<'と'>'がHTMLエスケープされていないようです。

バグのような気もするのですが、これに対応するには Template の仕組みを使用します。

var combo = new Ext.form.ComboBox( {
	store : xs,
	displayField : 'display',
	valueField : 'value',
	tpl : '<tpl for="."><div class="x-combo-list-item">{[fm.htmlEncode(values.display)]}</div></tpl>',
});

tpl で指定しているのが、選択肢一覧での表示テンプレートになります。
valuesは値を格納しているハッシュです。表示するプロパティ(displayFieldで指定している値）の名前が display なので、values.display と指定しています。
fmは Ext.util.Format クラスを表しています。それの htmlEncode メソッドを使用して、HTMLエスケープします。

2010-03-12

XPDL と Questetra BPM Suiteのデータ形式の比較（続き）

BPMN XPDL

先日の簡単なプロセスモデルを、今度はXPDLで表現します。

概略は以下の通りです。
（XPDL2.1に対応した手頃な XPDL エディタを見つけれていないので、仕様書等を参考に手書きしています）

<Activities>
  <Activity Id="1">
    <Event>
      <StartEvent Trigger="None" Implementation="Other" />
    </Event>
  </Activity>
  <Activity Id="2" Name="Compose Acceptance Message">
    <Implementation>
      <Task>
        <TaskUser>
          <Performers>
            <Performer>社員</Performer>
          </Performers>
        </TaskUser>
      </Task>
    </Implementation>
  </Activity>
  <Activity Id="3">
    <Event>
      <EndEvent Result="None" Implementation="Other" />
    </Event>
  </Activity>
</Activities>
<Transitions>
  <Transition Id="101" Name="" From="1" To="2">
  </Transition>
  <Transition Id="102" Name="" From="2" To="3">
  </Transition>
</Transitions>

タスクおよびイベントは、の子要素で表現。タスクは複雑で、子要素にがあり、その子要素にがあります。
の子要素には他になどがあります。の子要素にもがありますが、これはタスクの種類を表現するものです。

イベントはの子要素で開始／終了／中間イベントの区別が表され、さらにその属性で細かいタイプが区別されます。

シーケンスフローはで表現されます。どこからどこに接続されているかは、From属性とTo属性で表現されます。

2010-03-10

XPDL と Questetra BPM Suiteのデータ形式の比較

BPMN XPDL

簡単なプロセスモデルを用いて、XPDLとQuestetra BPM Suiteのデータ形式を比較します。

以下のように、開始イベントとタスク・終了イベントが直列に並んだだけのプロセスモデルを考えます。

このプロセスモデルをQuestetra BPM Suiteのデータ形式で表現した場合の概略は以下の通りです。
細かい部分は省略しています。

<nodes>
  <node id="100509" number="-100609">
    <swimlane-id>100508</swimlane-id>
    <name>タスク</name>
    <nodeType>0</nodeType>
    <activity id="100510">
    </activity>
  </node>
  <node id="100511" number="-100611">
    <swimlane-id>100508</swimlane-id>
    <name/>
    <nodeType>1</nodeType>
    <event id="100512">
      <eventType>2</eventType>
    </event>
  </node>
  <node id="100513" number="-100613">
    <swimlane-id>100508</swimlane-id>
    <name/>
    <nodeType>1</nodeType>
    <event id="100514">
      <eventType>3</eventType>
    </event>
  </node>
</nodes>
<flows>
  <flow id="100516">
    <name/>
    <from-node-id>100509</from-node-id>
    <to-node-id>100513</to-node-id>
  </flow>
  <flow id="100515">
    <name/>
    <from-node-id>100511</from-node-id>
    <to-node-id>100509</to-node-id>
  </flow>
</flows>

Questetra BPM Suite では、イベントもタスクもの子要素として表現されます。ゲートウェイもです。
の子要素でイベントは、タスクはで表現されます。はイベント、タスク、ゲートウェイを判別する要素。はイベントの種類を表す要素です。

は所属するレーン（スイムレーン）を表します。ここでは省略していますが、スイムレーンの要素内にはプロセスの参加者に関する定義が含まれています。

はシーケンスフローを表します。どこからどこにシーケンスフローが接続されているかは、およびで表現されます。
参照するアイテムは、すべてidで識別されます。

次は XPDL で同じプロセスモデルを表現した場合にどうなるか、近々説明したいと思います。

2010-03-08

Questetra BPM Suite のプロセスモデルをXPDLで表現する（まだまだXPDLの勉強中）

XPDL BPMN

TaskもEventもGatewayも。子要素で区別される。
Flowは。FromとToでどこからどこに接続されているか表現される。
XPDLのTaskには８種類あるが、Questetra BPM Suiteのタスクはか。
描画情報はで表現される。

2010-03-04

エンジンがどう動作すべきかにも言及している BPMN 2.0

BPMN

先日、BPMN 2.0 では Intermediate Boundary Events は大きく2種類に分かれると書きました。例外フローに移行した場合、タスクやサブプロセスがキャンセルされるかどうかで、2種類に分かれます。

同じことを BPMN 1.2 で表現できるのかどうか調べてみました。結論から言うと、BPMN 1.2 で例外フローに移行した場合、もとのタスクやサブプロセスがどうなるかは「解りません」でした。

BPMN 2.0 では、Intermediate Boundary Events は共通属性として cancelActivity が定義されています。同様の属性は、BPMN 1.2 にはありません。また BPMN 1.2 では Intermediate Boundary Events について、指定した条件が満たされると例外フローに移行するとありますが、元のタスクやサブプロセスをキャンセルするかどうかについては、厳密な記載がありません。ただしキャンセルすることを期待しているのだろう、と思います。

仕様書全般的な話として、BPMN 2.0 では Execution Semantics という章があり、エンジンにおける動作についての言及があります。また WS-BPEL へのマッピングが付録から独立した章へ格上げされているところからも、より動作に関する意識が強まっていると考えられます。

おそらく解釈の違いによって、同じプロセス図なのに、エンジンでの動きがまったく異なるという事態が発生したのでしょう。同じプロセス図でもベンダーや人によって、どう動くか解釈が大きく異なるというのは BPM 業界全般として大きな問題と考えます。良い方向に向かっていると思います。