Alfresco Process Services入門
こちらは原文(下記)の翻訳となります。内容に齟齬がある場合、原文の内容が優先されます。
目次
- 1 はじめに
- 2 Activitiとは
- 3 BPMN 2.0とは
- 3.1 BPMNグラフィカルモデリング要素
- 3.2 BPMNプロセスのXMLシリアル化
- 3.2.1 名前空間、リソース、コラボレーションの定義
- 3.2.2 プロセス定義の開始
- 3.2.3 開始イベント
- 3.2.4 コネクタオブジェクト
- 3.2.5 ユーザータスクの定義
- 3.2.6 排他ゲートウェイ
- 3.2.7 並列ゲートウェイ
- 3.2.8 包含ゲートウェイ
- 3.2.9 サービスタスク
- 3.2.10 タイマー
- 3.2.11 マルチインスタンス
- 3.3 Activiti BPMN拡張機能
- 3.3.1 ユーザーの割り当て
- 3.3.2 サービスタスクの実装
- 3.3.3 タスクリスナーと実行リスナー
- 3.3.4 式
- 3.3.5 フォーム
- 3.3.6 まとめ
- 4 Alfresco Process Servicesのインストール
- 5 Alfresco Process Servicesのアーキテクチャ
- 6 Alfresco Process Servicesアプリケーションについて
- 7 ビジネスプロセスの実装
- 7.1 初期設計
- 7.2 設計と実装
- 7.2.1 カスタムステンシルの作成
- 7.2.2 プロセスモデルの作成
- 7.2.3 開始イベント
- 7.2.4 Approve Invoiceユーザータスク
- 7.2.5 承認結果の 排他ゲートウェイ
- 7.2.6 Clarify Invoiceユーザータスク
- 7.2.7 確認結果の 排他ゲートウェイ
- 7.2.8 説明メッセージ付きApprove Invoiceユーザータスク
- 7.2.9 Prepare Paymentユーザータスク
- 7.2.10 Prepare Paymentタスクタイマー
- 7.2.11 File Invoiceサービスタスク
- 7.2.12 Send Approved Emailタスク
- 7.2.13 プロセスモデル用のBPMN 2.0 XMLの生成
- 8 ビジネスプロセス用アプリケーションの生成
- 9 ビジネスプロセスの実行
- 9.1 Approved Invoiceフローの実行
- 9.1.1 プロセスインスタンスの開始
- 9.1.2 Approve Invoiceタスクの完了
- 9.1.3 REST APIを用いたプロセスインスタンスの確認
- 9.1.4 Prepare Paymentタスクの完了
- 9.2 Rejected Invoiceフローの実行
- 9.1 Approved Invoiceフローの実行
- 10 ビジネスプロセスの改善
- 11 まとめ
![]()
Alfresco社員
2017年3月31日2:23 PM
はじめに
ご存じのように、AlfrescoではAlfresco Content ServicesとAlfresco Process Services(Activiti搭載)の2つの主力製品を取り扱っています。どちらの製品にも、無料版のCommunityバージョンと有料版のEnterpriseバージョンがあります。Enterpriseバージョンは、通常のサポートパッケージに加え、保証、追加の拡張機能、管理、 モデリングなどを装備し、ほとんどの本番環境に求められる必要な要素を網羅しています。
Activitiとは
Activitiは、Javaで実装されたオープンソースのBPMNプロセスエンジンで、設計、実装、デプロイ、ワークフローの実行に使用できます。これらのワークフローは、通常、組織におけるビジネスプロセスの管理と自動化に使用されます。
Activitiは、2010年にTom BaeyensとJoram Barrezによって作成されました。2人は以前所属していたJBossでjBPMワークフローエンジンを開発した開発者でもあります。jBPMはApacheライセンスを使っておらず、BPMN 2.0という新しいワークフロー定義の規格をサポートしていないという問題がありました。当時、AlfrescoのECM製品は、jBPMエンジンを組み込むことで、かなり前からワークフローをサポートしていました。AlfrescoのオープンソースワークフローエンジンであるActivitiを構築するためにAlfrescoがTomとJoramの雇用を決めたことは当然のことでした。
成功しているすべてのオープンソースプロジェクトと同様、より大規模な組織で採用されることにより、サポート、拡張性に関する主な機能、管理、レポート作成、高度な設計ツールなどが求められるようになりました。これが、2014年にAlfresco Process Servicesが誕生した経緯です。
Alfresco Process Servicesのコアワークフローエンジンは、BPMN 2.0ワークフロー定義を実行するApache認定のオープンソース製品です。以下は、Alfresco Process Services製品で利用できる追加機能の一例です(機能はこれに限定されず、新機能も高い頻度でリリースされます)。
ユーザータスク管理 - グループタスクのリスト、動的なフォームの添付、MS Officeドキュメントのプレビュー、UIのローカライズ
フォーム設計 - フォームライブラリ、マルチタブフォーム、豊富なフォームコントロール、データ駆動型コントロール(REST)、条件付き表示のサポート
プロセスデザイナー - ステップベースのエンドユーザー向けプロセスデザイナー、DMN準拠のデシジョンテーブル、アプリケーション/モデル/ステンシルセットの共有、アプリケーション/フォーム/モデル/ステンシルセットのエクスポートとインポート、自動文書生成
プロセス分析(Communityバージョンでは一切サポートなし) - プロセスヒートマップ、プロセス概要レポート、タスクのパフォーマンスレポート、SLAレポート
システム管理 - プロセスエンジン設定用の管理UIおよびクラスタファーム構成、LDAPおよびAD同期、マルチテナントサポート
アプリケーション統合 - Alfresco One ECM、BoxおよびGoogleドライブ、SharePoint
ご覧のとおり、大規模なビジネスプロセスプロジェクトに着手しようとしている場合に有用な機能や必要な機能が豊富に搭載されています。商用サポートやリリースプログラムの管理は言うまでもありません。
BPMN 2.0とは
ビジネスプロセスモデリング表記法バージョン2.0は、Object Management Group(OMG)が管理するワークフロー定義の規格です。グラフィカルな表現(図形と図のXMLシリアル化)とプロセスの実行に使用されるプロセス定義(XMLシリアル化)の両方をカバーしています。プロセスを視覚的に表現することは、エンドユーザーからプロセスの実装を行う開発者まで、プロジェクトのすべての関係者が話し合うことができるため、非常に有用です。
BPMNグラフィカルモデリング要素
BPMN要素には、フローオブジェクト、データ、接続オブジェクト、スイムレーン、アーティファクトの5つの基本的なカテゴリがあります。
フローオブジェクトは、ビジネスプロセスの挙動の定義に使用される主なグラフィカル要素です。
イベント-
アクティビティ-
ゲートウェイ-
データは、以下の4つの要素で表されます。
データオブジェクト
データ入力
データ出力
データストア
フローオブジェクトを互いに接続したり、他の情報に接続したりする方法は4つあります。以下は、4つの接続オブジェクトです。
シーケンスフロー -
メッセージフロー -
アソシエーション -
データアソシエーション -
アーティファクトは、プロセスに関する追加情報の提供に使用されます。
グループ -
テキスト注釈 -
下図はプロセスのグラフィカルモデルの例です。
プロセスモデルは左側から解釈または解読します(より具体的には、通常図表の左側にある開始オブジェクト(の記号)を探します)。開始オブジェクトの次に最初のアクティビティがあり、注文フォーム内のデータを受け取ります。次に 排他ゲートウェイがあり(つまり、フローは一方向にのみ遷移可能)、注文を受け付けるか却下するかのいずれかを決定します。注文を却下すると、注文はクローズされ、プロセスは終了します。
注文を受け付けると、注文が処理されます。フローは並列実行に分かれて、注文の発送と請求書処理を同時に行うことができます。 次に進むのが並列ゲートウェイです。プロセスエンジンは、並列ゲートウェイで並列実行パスが両方とも完了するまで待機します。これが完了すると、注文はクローズし、プロセスは終了します。
このようにプロセスをグラフィカルに表現すると、プロジェクトの関係者全員が理解できるため、非常に有用です。また、グラフィカルモデルに変更を加える場合、XMLを変更してエンジンにデプロイし、問題を発見してやり直すのに比べ、コストがかかりません。グラフィカルモデリングツールは、通常、プロセス検証機能を備えているため、つじつまが合わないことがあると直ちに確認できます。また、グラフィカルモデリングツールでは一般的にプロセスのXML表現も可能なので、好みに応じてXMLで作業できます。
BPMNプロセスのXMLシリアル化
ここまでに、グラフィカルな記号でプロセスをモデリングする方法を学習しました。ここからは、実際にプロセスエンジンが実行できる表現へと変換する方法について掘り下げる必要があります。BPMNの場合、それがXMLです。後でBPMNグラフィカルエディタを使用すると、ここで説明するXMLの詳細がわかるようになります。手作業でXMLをコーディングするよりもグラフィカルビューを使って作業する方が容易であり、エラーも発生しにくくなります。しかし、スクリプトを書く場合などの一部のケースでは、XMLで直接作業した方が簡単な場合があります。
Alfrescoをある程度使用していた経験があり、jBPMを用いて数多くのjPDL(XML)プロセスの設計と実装を行ってきた場合、jPDLとBPMN 2.0の2つのプロセス定義言語間の違いについても確認してみる価値があるでしょう。
確認するすべてのBPMN 2.0の構文について、対応するjPDLの構文がある場合は併せて確認します。jPDLの知識があれば、これによりBPMN 2.0への移行がスピードアップする可能性があります。これは、古いjBPMワークフローをどのように新しいActivitiエンジンで動作するかについて理解するうえでも有用です。
名前空間、リソース、コラボレーションの定義
XML 名前空間などを定義するファイル冒頭の構文です。
BPMN 2.0
jPDL
プロセス定義の開始
実際のプロセス定義の開始を定義する構文です。
BPMN 2.0
jPDL
開始イベント
プロセスの最初のイベントです。
記号:
注:開始イベントには複数の種類があります。上記は 開始イベントといい、エンドユーザーが手動でプロセスを開始する場合や、スクリプトがプロセスを開始する場合があるなど、何がプロセスをトリガーするのかがわからない場合に使用します。他に、プロセスが受信メッセージによってトリガーされる場合に使用されるメッセージ開始イベント、タイマーの終了時にプロセスをトリガーするタイマー開始イベントなど、さまざまな開始イベントがありますが、ここでは割愛します。
BPMN 2.0
jPDL
コネクタオブジェクト
コネクタオブジェクトはワークフローの異なるノード間に設定される遷移を表し、プロセス中に取ることができるルートを設定します。
記号:
注:XMLによるプロセスの定義では、要素の順序は重要ではありません。シーケンスフロー要素とタスク要素の順序は不規則でも構いません。つまり、シーケンスフロー要素は自己完結型であり、どのステップ(sourceRef)からどのステップ(targetRef)へ遷移するかを順序に依存せず、コネクタで明示的に指定する必要があります。
BPMN 2.0
jPDL
ユーザータスクの定義
プロセスを続行する前に、実際のユーザーが何らかの作業を行う必要があるアクティビティです。
記号:
BPMN 2.0
jPDL
排他ゲートウェイ
プロセスには判断ノードがあり、フローはここで可能な遷移先の1つを選択します。
記号:
BPMN 2.0
jPDL
並列ゲートウェイ
プロセスが複数の並列実行パスに分岐する、または複数の並列実行パスが1つに合流するノードです。
記号:
BPMN 2.0
jPDL
包含ゲートウェイ
プロセスが 排他ゲートウェイと並列ゲートウェイの組み合わせとして機能するノードです。
排他ゲートウェイのように送信シーケンスフローの条件を定義することが可能で、 包含ゲートウェイによってこれを評価します。評価結果が「true」になるものについてフローが並列して進められ、各シーケンスフローに対して並列実行を1つ作成します。
並列シーケンスフローの合流時、 包含ゲートウェイは並列ゲートウェイと同じように動作し、各受信シーケンスフローを待機します。ただし、 包含ゲートウェイはすべての並列実行パスを待機せず、評価結果が「true」になり、選択されたパスのみを待機することが並列ゲートウェイと主に異なります。
記号:
BPMN 2.0
jPDL
サポートされていません。
サービスタスク
ユーザーの介入なく処理を実行することが想定されるノードです。データをフェッチするための外部アプリケーションの呼び出し、データベースへの格納、電子メールの送信などがあります。
記号:
BPMN 2.0
jPDL
タイマー
特定の時間、実行を待機し、その後実行を継続するプロセスノードです。
記号:
以下の例では、何かを発行する前に少しの間待機することを決断できます。
BPMN 2.0
jPDL
マルチインスタンス
複数のアクティビティを並列して、または順次に、発生させることが可能なノードです。
記号:
注:マルチインスタンスノードの目的は、判断ゲートウェイを使用してフローをプロセスの1つ前のポイントに戻すなど、複数の要素を用いて手動でループ挙動を定義しなければならない状況を回避することにあります。代わりに、ユーザータスクなどのアクティビティにおけるループ特性を定義し、Activitiを呼び出す回数(つまり、渡されたコレクションのサイズ)と、完了したと判断するタイミングをプロセスエンジンにより把握します。
BPMN 2.0
以下のマルチインスタンスの定義の例では、reviewerList変数に含まれる各ユーザーに対してユーザータスクを開始します。
jPDL
foreach要素を用いて、jPDLで同様のマルチインスタンスの挙動を実現できます。
Activiti BPMN拡張機能
他の規格と同様に、規格から少し逸脱して優れた新機能を実装し、ユーザーの手間を軽減したいと考える状況があります。規格から逸脱する場合、使用しているプロセス定義は言うまでもなく別のBPMN 2.0準拠のエンジンでは動作しなくなります。
規格は一般的に、異なる企業間の妥協策であるため、必ず違う方法でやりたいことがでてきます。BPMN 2.0の仕様を読んでいると、実際に構成が少し面倒に見えることがあります。物事をできるだけ簡単にするため、ActivitiではActiviti BPMN拡張機能を導入しました。これらの拡張機能は、BPMN 2.0の仕様には含まれない新しい構成または構成を簡略化する方法です。
Activiti拡張機能は、プロセスの特定の要素を定義する明瞭でわかりやすい方法として、BPMN規格の将来のバージョンに組み込むことができるように定義されています。BPMN 2.0 規格はアプリケーションプログラミングインターフェイス(API)、ルールモデリング、データモデリングなどに対応していないため、実際にこれらの拡張機能が最終的なシステム実装に必要になると予測しています。
Activiti拡張機能は、activiti: 名前空間で明示されます。これらの拡張機能の一部は、標準のBPMN 2.0に簡単に変換することができます。Activiti 名前空間は、プロセス定義ファイルで次のように追加されます。
ユーザーの割り当て
ユーザーのタスクへの割り当ては、繰り返し行う必要がある作業です。そのため、本当に簡単でわかりやすいことが望ましいといえます。
Activiti拡張機能では、以下の新しい構成が採用されています。
activiti:assignee - 単一ユーザーをタスクに割り当てる
activiti:candidateUsers - ユーザープールからユーザーを割り当てる
activiti:candidateGroups - グループプールからグループを割り当てる
以下に例を示します。
これを標準のBPMN 2.0構文と組み合わせると、以下のようになります。
サービスタスクの実装
このActiviti拡張機能は、特定のサービスタスクと実行するコードをリンクするのに使用します。
Activiti拡張機能では、以下の新しい構成が採用されています。
activiti:class - クラスが指すコードを実行する
例:
タスクリスナーと実行リスナー
このActiviti拡張機能により、タスクの実行時、または遷移の発生時に、簡単にコードを実行できます。
Activiti拡張機能では、以下の新しい構成が採用されています。
activiti:taskListener - タスクの作成時、割り当て時、または完了時にコードを実行する
activiti:executionListener - 遷移の実行時にコードを実行する
タスクリスナーの例:
実行リスナーの例:
式
SpringのBeanとして実装されているJavaDelegateの呼び出しを可能にします。Unified Expression Language(UEL)式をサポートし、プロセス定義がSpringのバッキングBeanと通信できるようにします。
Activiti拡張機能では、以下の新しい構成が採用されています。
activiti:delegateExpression - 一致するSpringのBean IDを見つけ、JavaDelegateを実行する
activiti:expression - UEL式を評価し、SpringのBeanメソッドを呼び出す
Delegateの例:
UEL式の例:
フォーム
ユーザータスクと特定のフォーム定義を連携します。
Activiti拡張機能では、以下の新しい構成が採用されています。
activiti:formKey - フォーム定義を指す
例:
Alfresco Oneが組み込まれたActivitiの例:
まとめ
Activiti BPMN拡張機能はいたるところで使用されるので、拡張機能の意味を理解しておくのに越したことはありません。ここでは主な拡張機能のみを見てきましたが、他にもさまざまな拡張機能があります。詳しくはこちらを参照してください。
Alfresco Process Servicesのインストール
Alfresco Process Servicesのアーキテクチャ
下図は、Alfresco Process Servicesプラットフォームのアーキテクチャを示したものです。
このように、すべてJavaベースであり、Apache Tomcatなどの標準のJava Webコンテナで動作します。ユーザーインターフェイスは、数多くのいわゆるActivitiアプリケーションで構成されています。開発者や設計者向けの中心的なアプリケーションはKickstart Appで、ビジネスプロセスの設計や実装に使用します。
Task Appは、ビジネスプロセスのエンドユーザーがタスクの完了やワークフローインスタンスの管理に使用するアプリケーションです。Identity Managementアプリケーションは、ユーザープロファイルの管理に使用します。管理者の場合、グループや権限の管理にこのアプリケーションを使用します。
ビジネスプロセスを実装する際、ビジネスプロセス用のカスタムアプリケーションを作成します。アプリケーションには、ビジネスプロセスモデルが使用するあらゆるフォーム、デシジョンテーブル、データモデルが含まれます。
各種Activitiエンジンは、BPMN 2.0で定義された実行中のワークフロー、フォームの実行、DMN規格に準じたルール処理、検索などを実装します。すべて、Java仮想マシン(JVM)で動作します。
Alfresco Process Servicesアプリケーションについて
サーバー起動中、作業する主なアプリケーションを試すことができるようになりました。http://localhost:8080/activiti-appにアクセスすると、次のログイン画面が開きます。
admin@app.activiti.com/adminでログインします。ログインに成功すると、次のようなトップページが開きます。
トップページには、ユーザーが利用可能な数多くのアプリケーションを表示したダッシュボードが表示されます。Administrator(管理者)としてログインすると、利用できるすべてのアプリケーションが表示されます。各種アプリケーションは、特定のユーザーやグループに限定することができます。以下のタスクを実行するために、既成のアプリケーションを使用します。
Kickstart App - 基本的には、プロセスを設計してある程度実行し、アプリケーションとして他のユーザーと共有するワークベンチ
Task App - プロセスインスタンスが実行されると、ログインユーザー(この場合はAdministrator)に割り当てられたすべてのタスクを表示
Identity Management - グループ、テナント、ユーザーなどのセットアップに使用するアプリケーション
Analytics App - パフォーマンスやスループット統計データを伴う各種プロセスレポート
ビジネスプロセスの実装
以降のセクションでは、Alfresco Process Servicesを用いたビジネスプロセスの実装について説明します。シンプルな請求書支払い承認プロセスを構築してみましょう。
初期設計
ビジネスプロセスを設計する場合、スイムレーン図から始めると効果的な場合があります。スイムレーン図により、どの関係者(ユーザー、グループ、システム)がワークフローで何を行うかを簡単に把握できるためです。また、開発者、設計者、ビジネスアナリスト、エンドユーザーといったさまざまな関係者がいる場合、スイムレーン図を用いることで話し合いが行いやすくなります。
この段階でのActivitiの使用は任意です。スイムレーン図はさまざまなダイアグラムツールで作成できます。ただし、ワークフローエンジンの観点では、スイムレーン図には明示的な実行の意図がないことに留意してください。
以下に、シンプルな請求書支払い承認プロセスのスイムレーン図を示します。
ご覧のとおり、このワークフローはTeam Assistant(チームアシスタント)が請求書を受け取るところから始まります。ワークフローを開始すると同時に、Approver(承認者)となる担当者を割り当てます。金額に応じて承認を行う担当者が異なる場合があるため、手動による割り当てが必要になります。
次に、Approve Invoice (請求書承認)タスクが選択したApproverに割り当てられ、Approverは請求書を承認するか、請求書の目的をさらに明確にすることを要求します。請求書の詳細が要求される場合、Clarify Invoice(請求書の詳細)タスクが開始者、つまりTeam Assistantに割り当てられます。請求書の詳細を説明できない場合、プロセスは終了します。
請求書の支払いが承認されると、プールされた新しいタスクであるPrepare Payment(支払い準備)がAccounting(経理)グループに割り当てられます。同時にEscalate Timer(エスカレートタイマー)が起動します。仮にこれを15日後に期限切れになるように設定していると、15日後までに何も実行しない場合、エスカレートされたPrepare Paymentタスクが再度送られます。通常、請求書には支払い期限が記載されているため、Prepare Paymentタスクを未処理のままにすることはできません。
Prepare Paymentタスクが完了すると、プロセス実行は、File Invoice(請求書の保管)タスクに遷移し、その後Send Payment Approved Email(支払い承認メールの送信)タスクに進みます。Eメール送信サービスのタスクでは、プロセス開始時に開始者と請求書送信元企業の両方のEメールアドレスが提供されていた場合、両者にEメールを送信します。これでプロセスは終了となります。
設計と実装
実装したいプロセスがレイアウトされたスイムレーン図が用意できました。スイムレーン図は、クライアントの組織の誰でも作成することができます。プロセスの実装にActivitiを使用することを知っている必要もありません。
この時点で行う必要があるのは、設計に目を通し、あいまいな点を修正することです。プロセス設計のつじつまがあっており、やり残しがないことを確認する必要があります。初期設計を行う担当者は、ワークフロー定義のすべての要素や、BPMN 2.0によって何が可能かについて知らない可能性があります。そのため、BPMN 2.0に直接変換できるよう、スイムレーン図の矛盾を解消するまでには、複数のバージョンが発生する可能性があります。
BPMNエディタを使用している場合、多くのユーザーはプロセスのモデリングにスイムレーンを使用しません。これは単純に、スイムレーンがエディタ領域のスペースを占めてしまい、すべてをスイムレーンに一致させる作業が増えることになるためです。
BPMNエディタとフォームエディタは非常に強力なツールなので、設計はもちろん、作業しながら実際にワークフローを実装できます。これらのエディタ外で設定する必要があるのは、Javaサービスタスク、リスナー、カスタムRESTエンドポイントなどを実装する必要がある場合のみです。
カスタムステンシルの作成
ステンシルとは、Activitiプラットフォーム全体で使用するもので、基本的にドメイン固有の要素を再利用する1つの手段です。非技術系のユーザーでも、コンポーネントのAPIの知識を使わずにカスタムコンポーネントを自身のワークフローに組み込むことができます。
ステンシルには以下の3種類があります。
プロセスエディタステンシル - BPMNエディタのカスタマイズに使用
フォームエディタステンシル - フォームエディタのカスタマイズに使用
ステップエディタステンシル - ステップエディタのカスタマイズに使用
入門ガイドでステンシルについて説明する必要があるのかと考えるかもしれませんが、説明は必要です。一度プロセスモデルとフォームモデルを作成すると、BPMNエディタとフォームエディタ用に使用したステンシルの切り替えができなくなります。
そのため、カスタムプロセスステンシルとカスタムフォームステンシルを作成し、それらに使用するエディタをベースとすることをお勧めします。その結果、カスタムエディタステンシルを利用する際に、プロセス全体を作り直したり、フォームをゼロから再設計したりすることなく、エディタにカスタムコンポーネントを組み込むことができます。
では、カスタムステンシルとは何でしょうか。以下の例でステンシルの用途について説明しますが、ステンシルとは基本的にカスタムエディタを作成する手段の1つです。
エンタープライズREST APIを呼び出してユーザー情報をフェッチするのに使用できるサービスタスクがあると仮定します。サービスタスクは、com.mycompany.activiti.service.UserProfileServiceImplで、Javaで実装されます。そして、userId、endpointURLなどを渡す必要があります。基本的に、このサービスを使用したいビジネスユーザーは、多くのビジネスユーザーが知る必要のない詳細をかなり知っておく必要があります。サービスタスク、サービスタスク実装クラス名、パラメータ名などの使い方を知っている必要があります。
BPMNエディタで以下のようにビジネスユーザーが既製のコンポーネントを使用できれば、とても便利ではないでしょうか。
ここで、ユーザーはどのフィールドが呼び出されているか、クラス名は何かなどについて知る必要はありません。このカスタムサービスタスクをキャンバスにドラッグ&ドロップするだけで、カスタムプロパティを設定できます。エンドユーザーにわかりやすくするため、サービスタスクのデフォルトプロパティの多くも削除されています。BPMNエディタのカスタムステンシルを使用することで、これがすべて可能です。
カスタムコントロールを追加することで、同様の方法でフォームエディタをカスタマイズできます。デフォルトのフォームエディタには存在しないImage Hyperlinkコントロールを追加したいと仮定します。フォームエディタのカスタムステンシルを作成することで、以下のようにフォームエディタで利用できるようになります。
コントロールに必要な特定のデータを収集するため、次のようにコントロールに新しいプロパティタブを設けることも可能です。
このように、ステンシルは非常に有用であるため、プロセスやフォームのベースとなるベーシックなカスタムステンシルをいくつか作成してみましょう。カスタムステンシルは空になりますが、カスタムコンポーネントをエディタに追加する必要が考えられる場合に備えることができます。
ステンシルはApp Designerを用いて作成します(既製のステンシルをインポートする場合、こちらからZIPをダウンロード)。
このアプリケーションをクリックすると、次のページが表示されます。
画面上部のStencilsメニューアイテムをクリックし、次にCreate a new Stencil now!ボタンをクリックします。
ステンシルの名前を「My Company Process Editor」に指定し、Create new stencilボタンをクリックします。エディタの種類はデフォルトで「BPMN editor」に設定されているため、変更の必要はありません。
これにより、デフォルトのBPMNエディタが表示されます。画面右上のStencil Editorボタンをクリックすると、エディタをカスタマイズできます。今回はカスタマイズを行わず、この記事ではデフォルトのエディタレイアウトを維持します。ただし、将来必要になる場合に備えて、新しいコンポーネントを追加する用意はできています。
同じように、フォームエディタステンシルを追加します。
ここでは、Editor typeドロップダウンから「Form editor」を選択します。これで以下のように2つのステンシルが作成されました。
プロセスモデルの作成
エディタのベースとなるカスタムステンシルの作成が完了し、顧客のビジネスプロセスも明確になりました。次に、Activitiでプロセスを作成します。プロセスの作成にはApp Designerを使用します(この手順を簡単に確認したい場合は、こちらから入手可能なZIPファイル経由でインポートできます)。
このアプリケーションをクリックすると、次のページが表示されます。
ここでプロセスの設計、ユーザータスク用フォームの作成、デシジョンテーブル、データモデル、これをすべて含む新しいアプリケーションの定義を行うことができます。ほとんどの場合、プロセス定義から開始することをお勧めします。フォームが必要な場合は、 Kickstart Appページを使用して作成することができます。
画面右上のCreate Processボタンをクリックして、Web版のBPMN 2.0デザイナーを起動します。最初に開くダイアログで、プロセスの名前と説明の入力が求められます。
上図のように名前と説明を入力します。「BPMN editor」を選択したままにするので、馴染みのあるBPMN 2.0の図形を使用してプロセスを設計します。「Step Editor」を選択する場合は、より簡略化されたステップベースのアプローチでビジネスプロセスを設計することになります。
ステンシルには、先ほど定義したプロセスエディタのカスタムステンシルを選択することが重要です。Stencilドロップダウンから「My Company Process Editor」を選択します。将来的に役に立つことが見込まれるため、カスタムコンポーネントをこのステンシルに追加し、今後のプロセス定義で使用します。
Create new modelボタンをクリックして新しいプロセスモデルを作成します。BPMNエディタが次のように表示されます。
最初は開始イベントのみで、多くは表示されていません。BPMNエディタの左側に、自由に作業に使用できるBPMN要素がすべて表示されています。基本的な要素についてはこの記事で既に説明していますが、ご覧のとおり、他にも数多くの要素を使用できます。画面中央は、プロセスを作成するメイン領域です。先ほどお話したとおり、この時点では開始イベントのみが表示されています。
画面下部には、要素やノードに関連する情報が表示されます。いずれかの要素の外側をクリックすると、プロセス全体に関連する情報やプロパティが表示されます。
これは、リスナー、信号、変数、フォーム、IDなど、何かをセットアップする際に使用する場所です。実際に、一切XMLに触ることなく、BPMNエディタから多くのことを実行できます。
開始イベント
開始イベントなど(実際にその他にクリック可能な要素がない場合)、プロセス定義の要素をクリックすると、次のようにプロパティセクションにその要素が表示されます(Activitiオンラインユーザーガイドの「Start Events」)。
追加する各要素に対して、IDを設定しておくと便利です。これを行わない場合、ActivitiがIDを生成しますが、それでも問題はありません。ただし、要素により読みやすいIDを設定すると、生成されたプロセス定義XMLがより読みやすくなります。開始イベント要素のIDプロパティをクリックし、startInvoiceProcessというIDを設定します。画面は次のように表示されます。
このケースでは、開始イベントに一貫性のある対応する名前を設定しました。
使用可能なプロパティは、クリックした要素によって異なります。開始イベントは関連するフォームを持つことができるため、Referenced formなど、フォームに関連する新しいプロパティが表示されます。Approverを選択できる開始イベントに実際にフォームを連携し、請求書送付元の会社のEメールアドレスを指定して、請求書ファイルをアップロードします。Referenced formプロパティをクリックします。
これにより次のダイアログが表示されます。
複数のフォームの定義を開始した場合、ここでフォームが開かれます。この時点では、まだフォームは定義されていません。そのため、New formボタンをクリックして、新しいフォームを作成します。
名前を入力します。このワークフロー定義をベースにしたワークフローインスタンスを開始すると表示される最初のフォームであるため、ここでは「Start Invoice Approval Form」と設定します。次に役に立つ説明を入力します。
一番下にStencilドロップダウンが表示されます。先ほど作成した「My Company Form Editor」というフォームのカスタムステンシルが選択されていることを確認します。これでカスタムコントロールを追加して、将来使用することができます。
Create formボタンをクリックして、フォームの定義を開始します。
BPMNエディタではなく、フォームエディタが表示されます。フォームエディタでは、デフォルトでDesignモードが開くので、画面中央のキャンバスにコントロールの追加を開始できます。それでは、ユーザー選択、会社Eメールアドレスのテキストフィールド、さらに、承認を受ける請求書をアップロードできるように添付フィールドを追加してみましょう。
ここでは、基本的にフォームキャンバスへのコンロトールのドラッグ&ドロップのみを行いました。次にコントロールにラベルを設定します。これを行うには、コントロールにカーソルを置き、ペンをクリックします。このケースでは、デフォルトの1列複数行のレイアウトを使用しました。列数と各列の行数はカスタマイズ可能です。列幅やタブなども指定できます。
以下はApproverのラベルとIDです。
ラベルを入力すると、IDが自動的に生成されます。使用されたIDを覚えておくと、後にプロセスで参照できるので便利です。Company Emailのテキストコントロールは次のようになります。
以下は添付コントロールの請求書ファイルプロパティです。
フォームが完成したら、画面左上の検証ボタンをクリックします。
すべて緑であれば、フォームは有効です。検証ボタン横のディスクのアイコンをクリックして、フォームを保存します。
フォームを保存してフォームエディタを閉じ、BPMNエディタに戻るため、Save and close editorボタンをクリックします。開始イベントをクリックすると、作成したフォームがイベントに連携されます。
Activiti Web環境を離れることなく、フォームを作成し、プロセスモデルの要素に連携できました。今のところXMLには一切触っていません。
Approve Invoiceユーザータスク
ワークフロー定義の次のノードはApprove Invoiceユーザータスクです(Activitiオンラインユーザーガイドの「User Task」)。画面左側にあるナビゲータで Activitiesセクションを開くと、User Taskをプロセス定義キャンバスにドラッグ&ドロップできます。
次に、開始イベントをクリックし、遷移を表す矢印を選択して、開始イベントと新しいユーザータスクを接続します。
次に、ユーザータスクをダブルクリックして、「Approve Invoice」という名前を入力します。次の図が完成します。
この時点で、プロセスモデルを検証して保存します。
画面左上の検証ボタンをクリックし、次にその左にある保存ボタンをクリックします。検証前に承認タスクでやるべきことがあるため、検証は実際に失敗することになります。以下は検証エラーが表示された状態です。
検証に失敗しても、プロセスを保存できます。保存すると、プロセスはMy processes下に表示されます。
BPMNエディタに戻るには、単純にプロセスモデルをクリックします。
次に、右上にあるVisual Editorボタンをクリックします。Approve Invoiceタスクのプロパティを更新する必要があるので、タスクをクリックします。次に、タスクのIDとして「approveInvoice」と記入します。次のように表示されます。
このユーザータスクでは、Approverが作業内容に関する情報を参照し、確認のために請求書ファイルをダウンロードできるフォームが必要になります。Referenced formプロパティをクリックします。
「Approve Invoice」フォームという新しいフォームを作成します。
Create formボタンをクリックしてから、フォームエディタで次のようにフォームを設計します。
最初の情報であるDisplay textフィールドには、次のプロパティが表示されます。
ここでは、まずテキスト表示フィールドのNameを入力しました。これにより、IDが生成されました。次に、Text to displayへの入力を行いましたが、1か所で下にあるForm fieldドロップダウンからCompany Emailのフォームフィールド値を選択して挿入しています。${companyemail}変数には、開始フォームで入力したCompany Emailの値が代入されます。
変数名を覚えている場合は、テキストに${...}変数/フィールドプレースホルダを明示的に入力し、ドロップダウンリストから選択するのと同じ最終効果を持たせることも可能です。ドロップダウンからの選択は、変数を素早く正しい構文で挿入する手段にすぎません。
表示値フィールドには次のプロパティが表示されます。
フィールドにラベルを設定しておいたので、開始フォームでアップロードした請求書ファイルとして表示されるフォームフィールド値を選択しました。
最後は複数行のCommentsフィールドです。Approverが、請求書が却下され、請求書の詳細を説明する必要があるなどのメッセージを開始者に伝えたり、経理部に請求書の支払いに関するメッセージを伝えたりする際にこのフィールドを使用します。
ユーザータスクには、タスクの完了時にユーザーがクリックするCompleteボタンがデフォルトで表示されます。今回はこのボタンは不要なので、代わりにApprove(承認)ボタンとReject(却下)ボタンの2つを表示します。これらのボタンは、請求書を支払うかどうかについてのApproverによる決定を示します。これらの決定をタスク結果と呼びます。フォームエディタには、これらを設定するための専用のタブがあります。
Use custom outcomes for this formラジオボタンをクリックします。
上図のように、 2つのタスク結果が標準フィールドで指定されます。これらのボタンには任意の名前を付けることが可能で、BPMNエディタにより、関連する条件に正しい変数名が付いていることが確認されます。なお、必要に応じてボタンを増やすこともできます。
これでApprove Invoiceフォームが完成しました。フォームを保存して、BPMNエディタに戻ります。
すべてのユーザータスクは、ユーザーまたはユーザーのグループに割り当てる必要があります。上図のとおり、Approve Invoiceタスクはまだ誰にも割り当てられていません。何も行わないと、BPMNエディタによって、デフォルトでプロセスの開始者に割り当てられます。
これを修正するには、Assignmentプロパティをクリックします。
このダイアログは、これまで見てきたものよりも少々扱いにくくなっています。行うことは基本的に、最初の開始フォームでApproverとして選んだユーザーを担当者に設定することです。これを行うには、まずIdentity storeタブ(1)をクリックします。次に、AssignmentドロップダウンでAssign to single userを選択します(2)。次に、Form fieldタブ(3)をクリックします。最後に、Form fieldドロップダウンからApproverを選択します(4)。
BPMNエディタでは、プロセスの他のフォームで使用されているすべての担当者フォームフィールドの識別と選択が可能です。さらにFixed valuesセクションでは、フォームフィールドだけでなく、権限に対応する変数プレースホルダを利用することもできます。
ここで割り当て構成を保存します。プロパティセクションが次のように表示されます。
これでApprove Invoiceユーザータスクが完成しました。ワークフローの次の要素に進むことができます。
承認結果の 排他ゲートウェイ
2つの結果(承認または却下)を設定したため、Approve Invoiceタスクに続いて排他ゲートウェイが必要になります(Activitiオンラインユーザーガイドの「Exclusive Gateway」)。 排他ゲートウェイを次のように追加します。
ゲートウェイの後は、請求書却下または請求書承認のいずれかに進みます。それぞれの実行パスには、後に続くユーザータスクが1つあります。
Clarify Invoiceユーザータスク
リックソフト株式会社 は、日本でトップレベルのAtlassian Platinum Solution Partnerです。
大規模ユーザーへの対応実績が認められたEnterpriseの認定をうけ、高度なトレーニング要件をクリアし、小規模から大規模のお客様まで対応可能な実績を示したパートナー企業です。
Copyright © Ricksoft Co., Ltd. プライバシーポリシー お問い合わせ