※この記事は SAP Advent Calendar 2020 の12月23日分の記事として執筆しています。
ソリューション構築の背景
……！？！？
毎日クラウドソリューションの研究に明け暮れる私たちは、どういうわけかいつの間にやら大正時代に迷い込んでしまったようです。
しかもこの世界に暮らす人々は、どうやら凶暴な人喰い鬼に悩まされているらしい。
……！？！？！！！！
というわけで今回の記事では、SAP Cloud Platform Workflow Managementを活用して効率よく鬼滅の豆（とは、、？？？）を撒き、クラウド時代のおしゃれさで鬼をがんがん討伐していこうと思います！！！
とりわけ、先日行われたばかりのSAP TechEd 2020にてアップデートのあった機能に着目して鬼を滅多斬りにしていきます。
SAP Cloud Platform Workflow Managementとは
Workflow Managementサービス概要
SAP Cloud Platform Workflow Management は、その名の通りワークフローを構築、実行、管理することができるSAP Cloud Platformのサービスです。
SAP Cloud Platformのサービスとして以前からSAP Cloud Platform Workflow Serviceがあったので違いがわかりにくいのですが、基本的には新Workflow Managementの方が旧Workflow Serviceの機能を含み込んでいて、それに加えてProcess VisibilityやBusiness Rulesなどの関連サービスをまとめて提供するものになります。
Workflow Managementの全体感をイメージするには、例えばSAP TechEd 2020の[DEV207]Digital Process Automation with SAP Cloud Platform Workflow Managementの資料に掲載されているダイアグラムがわかりやすいです。
この図が示すように、Workflow Managementの機能はWorkflow, Business Rules, Process Visibility, Inboxの機能から主に構成されているのですが、この中でもProcess Visibilityがとりわけ新しく、TechEdのハンズオンセッションでもたびたび取り上げられていました。
Process Visibilityとは
Process Visibilityはその名の通り、プロセスの様々な側面を可視化することのできるサービスです。
プロセスと言うと抽象的ですし、実際いろいろなサービスのプロセスを連携することができるのですが、その中でも最もプロセス連携が簡単なのがSAP Cloud Platform Workflow Serviceで定義したワークフロープロセスです。
環境にデプロイされたワークフローを指定し、GUIベースでフェーズや計算項目を定義していくだけで、下記のようなグラフィカルな確認画面を作成できます（詳細は後述しますが、この画面のアイテムをクリックすることでプロセスの詳細も見ていくことができます）。
▼ Process Visibility - "Process Workspace"アプリ画面イメージ
Process Visibilityはプロセスの進行状況がおしゃれに確認できるばかりではありません。
Workflow Serviceそれ自体はエラーハンドリングがちょっと苦手で、例えば外部連携処理などでシステムエラーになるとインスタンスがストップしてしまうので、リカバリ用のフローをWorkflowの内部で定義することができません。システムエラーが発生した場合、モニターアプリを管理者が能動的にチェックすることでしか検知できないという状況でした。
そこにProcess Visibilityを併用することで、定期的にプロセスのステータスを所定の条件にしたがってチェックし、例えばエラーとなっているものを拾ってきて、あらかじめフローとして構築しておいたAction（例えば管理者への通知や、必要であればワークフローインスタンスのリスタートなど）を実行することができます。
ソリューションイメージ
##人物相関図
設定が少々特殊なので、よろしければ最初に人物相関図をご覧ください。
彼らは鬼殺隊の組織上では次のような関係にあるようです。
ソリューションイメージ
というわけで、
- 戦闘の現場で鬼たちと戦う担当者・竈門のり治郎と我妻かなめんが、SAP Cloud Platform Workflowで、戦闘に必要な「鬼滅の豆」の調達の承認を申請する
- 上長の煉獄すみ寿郎がProcess Visibilityで全体の戦況（※調達状況）を確認しつつ、SAP Cloud Platform WorkflowのMy Inboxで「鬼滅の豆」の調達を承認する
という基本的なワークフローを構築し、さらには
- もしもワークフローのプロセスに異常があればProcess Visibilityがそれを検知し、IT管理者・もなねずこに通知が届き、必要であれば後続のリカバリフローを起動できる
- もしも承認期限を超過していたらProcess Visibilityがそれを検知し、上長の煉獄すみ寿郎に通知が届く
という素敵な運用フローまで合わせて構築していきましょう。
本ブログでの紹介内容
本ブログでご紹介する内容はSAP TechEdの下記のハンズオンセッションの内容とほぼ同じものとなっています。
詳細なステップはセッション資料として紹介されているため、重複する内容は割愛し、構築イメージが掴めるように内容をご紹介します。
（本ブログをお読みいただいた後でハンズオンセッションを実施いただければ、きっとかなりわかりやすいと思います！）
DEV264 - Deep dive into SAP Cloud Platform Workflow Management
また、Workflowの構築方法に関しては以前のブログにてご紹介したことがありますので、こちらをぜひご確認ください。
「だいじょぶだぁ」と言うとSAP CP Workflow Serviceで購買依頼登録が承認されるiOSアプリを実装する
以下では構築ステップを概要レベルでご紹介しつつ、特にProcess Visibilityの構築イメージ・使い方イメージが伝わるように書き進めていきます。
開発・実行環境
本ブログに記載の内容はSAP Cloud Platformトライアル環境（無料）で実施することができます。
ソリューション構築
環境の設定
Boosterによるセッティング
SAP Cloud PlatformのCockpitにて"Booster"と呼ばれる環境設定タスクセットが用意されており、"Set up for Workflow Management"というメニューを実行するだけで必要なQuota, Space, Subscription, Instance, Destination, Rolle Collectionなど、ちょっと面倒な準備を自動的に実行してくれます。
これを手動でやるとかなり手間だし、抜け漏れも多くなりがちだと思うのですが、ボタン一つで環境をセットアップできるので嬉しいです。
Workflow Managementアプリケーションの確認
この設定が完了すると、それだけで下記のWorkflow Managementの関連アプリが登録されたLaunchpad画面が開けるようになります。
（従来は、環境の設定に加え、関連アプリを設定したLaunchpadモジュールやApplication Routerなどを自分でデプロイしなければ関連アプリにアクセスできなかったのですが、今ではサービスをSubscribeするだけでManagedのLaunchpadにアクセスすることができるようです）
今回利用するアプリケーションのタイルに印を付けてみました。
緑色で囲った分が、今回利用するワークフロー関連のタイルです。従来のワークフローを触ったことある方なら見慣れているアプリだと思います。
- My Inbox: ワークフローのタスクをユーザが受信する
- Monitor Workflows - Workflow Definitions: ワークフローのテストインスタンスを開始できる
- Monitor Workflows - Workflow Instances: ワークフローのインスタンスを監視する
オレンジ色で囲った分が、今回利用するProcesss Visibility関連のタイルです。
- Process Workplace: プロセスを可視化したシナリオを確認し、必要であればユーザがユーザアクションを起動できる
- Configure Visibility Scenario: 2.のシナリオを作成する
- Monitor Visibility Scenario: シナリオのイベントを監視し、システムアクションを定期起動（またはマニュアル実行）する
ワークフロー構築
まずはワークフローを構築していきます（ワークフローはSAP Cloud Platform Business Application Studioを利用して実装します）。
今回は3つのワークフローを構築します。
- 「鬼滅の豆」調達承認フロー
- 通知フロー
- リカバリフロー
1. 「鬼滅の豆」調達承認フロー
ワークフローの作成
こちらは非常にシンプルなワークフローです。
担当者・竈門のり治郎または我妻かなめんが「鬼滅の豆」の調達の承認を申請し、上長の煉獄すみ寿郎が調達を承認または差戻、差し戻しされた場合は担当者が取下げか再申請をするというもの。
このワークフローを起動すると、各種処理者の「My Inbox」アプリにタスクが追加され、それを処理することができるようになります。
今回はワークフロー起動部分は実装せず、テスト用のインスタンスを作成することで挙動を確認します。
★この記事の内容と直接の関係はないのですが、Workflowの起動オプションの一つとしてABAPから起動するというものがあります。同じSAPアドベントカレンダーの記事としてtamiさんが下記の超実践的な記事を書かれていますので是非ご参照ください。
もちろんABAPのみならず、カスタムFioriアプリやその他の外部システムなどさまざまな場所から起動することが可能です。
ワークフローAttributeの設定（重要！）
このとき、後続の作業との関連で重要になるのがWorkflowのAttributeの設定です。
ワークフローは内部にContextと呼ばれる処理用データを持っているのですが、このContextの内容をAttributeとして外部から参照可能なようにマッピングしてあげます。
こうすることで、Process Visibilityでのシナリオ設定時に、これらのワークフローの値を利用することができるようになります。
2. 通知フロー
2.と3.は、異常発生時にProcess VisibilityがActionとして起動するために構築するものです。
「2. 通知フロー」は、連携されたエラー情報をMy Inboxにタスクとして通知します。
（※今回は簡単に実装できるようMy Inboxへの通知として実装していますが、メールサーバを設定すれば、メール送信による通知として実装することも可能です）
3. リカバリフロー
「3. リカバリフロー」は、エラーとなって止まっているワークフローの申請データを元に、ワークフローAPIによって新しいワークフローを再作成するためのワークフローです。
Workflowのビルド・デプロイ
上記のワークフローは、SAP Business Application Studioで作成されたMTAプロジェクト（Multi-target Application）の内部に構築しました。
こちらをビルド・デプロイすることで、上記の3つのワークフローが利用可能となります。
Workflowのテストインスタンスの作成
- "Monitor Workflows - Workflow Definitions"アプリを用いて、適当なテストインスタンスを作成しておきます。
- 煉獄すみ寿郎になりきって、"My Inbox"でいくつかの申請を承認しておきます。
- "Monitor Workflows - Workflow Instances"アプリを用いて、いくつかのテストインスタンスをわざと"Suspended"にしておきます（後続のProcess Visibilityで、このインスタンスを異常の発生したインスタンスとして認識させます）。
Process Visibility Scenarioの設定
それではいよいよ、Visibility Scenarioの設定を実施していきましょう！
シナリオの作成
"Configure Visibility Scenarios"を開きます。
新規シナリオを追加します。
先ほど作成した「鬼滅の刃 調達承認フロー」をシナリオに追加します。
するとこのように、EventsとContextが読み込まれます。
Eventsは、今回は各種ユーザタスクの開始や終了などから成っています。
また、ここで読み込まれたContextが、先ほど「ワークフローAttributeの設定」の手順で設定したAttributeと対応していることがわかると思います。
試しに、この状態でシナリオをActivateし、"Process Workplace"で何ができているか見てみましょう。
なんと、すでにカードがいくつか表示されています！
すでに表示されているカードはどこで定義されているのでしょうか。"Configure Visibility Scenarios"アプリに戻って確認してみましょう。
どうやら下記のように、"Performance Indicator"のタブで自動的にいくつかのPerformance Indicatorが最初から定義されており、その内容がカードとして表示されているようです。
つまり、表示するカードを新しく作っていくためには、このタブに設定を追加していく必要があります。
そして、その前準備として、その他のタブで、Performance Indicatorの設定に必要なもろもろの要素を予め設定しておく必要があるみたいです。
シナリオの編集 - Indicatorの設定
最初にインポートされたEventsとContextsを元に、追加のPerformance Indicatorを定義するためのPhase/Status/Attributeなどを定義していきます。
Phase
Phaseのタブでは、Eventsを元に、EventとEventの間のPhaseを自由に定義することができます。
例えば下記では、煉獄すみ寿郎の承認フェーズ（タスクが届いてから承認が完了するまでのフェーズ）を定義しました。
State
Stateのタブでは、OPEN/Completed/Endedという3つのStateの条件を指定することができます。
下記の内容はワークフローを追加した時にすでに自動的に定義されており、今回は内容を変更していません。
Status (Target/Sub-Status)
Targetのサイクル時間を設定し、それに対する条件でSub-Statusを定義することができます。
いろいろな設定ができそうなのですが、例えばすでに定義されているSub-Statusとしては下記のものがありました。
- Overdue：インスタンスがOpenだが、経過時間がTargetのサイクル時間を超えている状態。
- Threshold：インスタンスがOpenだが、経過時間がTargetのサイクル時間に対する閾値（%）を超えている状態。
Attributes
ActionやPerformance Indicatorとして利用したい項目、計算項目、データ構造を、これまでに読み込んだContextや作成したAttributesなどを元に定義します。
Performance Indicator
これまでに定義した要素を使って、画面に表示したいPerformance Indicatorのカードの内容を設定します。
今回は例えば線グラフを使ってみましたが、他にもいろいろな種類のUIがありそうです。
シナリオの確認 - Performance Indicatorの確認
上記のもろもろの設定を終えてシナリオをActivateし、"Process Workplace"を確認すると……
眺めているといろいろ見えてきます！
- 承認された豆の量がちょっとえぐいな、、どうやら激戦のようですね。。。
- 煉獄すみ寿郎がまだ承認していない依頼が27件！
- StatusがCriticalになっている依頼が13件も。。。
なにはともあれ、
シナリオの編集 - Actionの設定
シナリオに対してActionを設定していきます。
先ほど実装した「2. 通知フロー」「3. リカバリフロー」をシナリオの条件に紐づけていきます。
「2. 通知フロー」を呼び出すAction
"Configure Visibility Scenarios"アプリの画面に戻り、「2. 通知フロー」をActionとして設定します。
Trigger Type: Systemとなっているので、こちらは自動的に（定期的に）起動してもらえます。
ここのConditionのところに注目すると、先ほど確認したSub-Statusが下記の条件を満たす場合にこのアクションが起動されるという設定となっています。
上記がおよそ意味しているのは、システムエラーの場合または期限超過の場合にこのフローが起動されるというものです。
ここで最初に定義したフローを思い返していただきたいのですが、システムエラーの場合の場合はIT管理者に、期限超過の場合は承認者に通知がいくようになっています。
「3. リカバリフロー」を呼び出すAction
次に 「3. リカバリフロー」をActionとして設定します。
Trigger Type: Userとなっているので、こちらはユーザが能動的に起動するActionです。
Conditionは先ほどと同様で、システムエラーの場合または期限超過の場合にこのActionが使用可能となります。
このフローについても改めて思い返してみると、ワークフローのインスタンス情報を取得して、その情報を元に新しいワークフローを再申請できるというものでした。
シナリオの確認 - Actionの確認
ダミーのエラーを発生させる
エラー発生時の挙動を見てみるため、"Monitor Workflow"アプリを使用し、試しにわざとワークフローインスタンスを"Suspended"にしてみます。
「2. 通知フロー」の起動を確認
"Monitor Visibility Scenarios"アプリを開きます。
エラー（または期限超過）となっているインスタンスが5分に1度検知され、「2. 通知フロー」のアクションが起動されているのがわかります。
IT管理者・もなねずこの気持ちになってMy Inboxをみてみるとこのようにエラー通知がきていることがわかります。
（※前述の通り、メールサーバがあれば、My Inboxではなくメールでの通知を実装することも可能です。）
この通知がきたら、IT管理者はワークフローの管理画面などを使ってエラー情報の詳細を確認すれば良いということになります。
これまでのワークフロー機能だけでは管理者にエラー通知を出すことはほぼ不可能だった思うので、これは嬉しい機能だと思います。
「3. リカバリフロー」の起動を確認
今度は"Process Workspace"アプリの画面に戻ってみましょう。
"Open Instances"の"Critical"部分をクリックします。
すると、エラーとなっているインスタンスが一覧表示されるので、データ行をクリックしてみましょう。
（ちなみに、どのカードをクリックしても、こんな風に一覧表示画面・詳細画面に潜っていくことができます）
下記のようにインスタンスの詳細を確認することができます。
そして、右下に見えている「承認プロセスのリスタート」を押します。すると「3. リカバリフロー」が開始され、新しいインスタンスが作成されているはずです。
"Monitor Workflow"アプリで確認してみると、確かに新しいインスタンスがスタートされています。
非常にシンプルなフローですが、それでも、例えば別システムとの疎通ができなくなっているせいでエラーになったワークフローを、障害復旧後にボタン一つで再作成できるのだとしたら結構いい感じに使いこなせる気がします。
終わりに
というわけで、鬼滅の豆をめちゃくちゃいっぱい投げつけられて大打撃を受けた鬼たちは今回のところはひとまず無事退治されたようです（そういう話だったっけ？）。
でも、現場のメンバーからはちょっとした不満が……
というわけで、とりあえず今回のところはめでたしめでたし！！！！！