OpsRamp 承認機能付きProcess Workflowを作成してみた。

#概要
今回は皆さん大好き承認機能付きのProcess Workflowを作成したので、そちらをご紹介します。
まずWorkflowの説明をします。
1, Windows Agentからサービスを監視し、Downを検知
2, サービスの再起動スクリプトの実行承認を依頼する
3, 承認された場合Workflowでサービス再起動が自動で実施される
4, 自動対応内容がアラート/チケットにコメントされる

皆さんの環境でこのWorkflowを再現したい場合、以下の説明から作成もできますが、
後日、APIPOSTでサクッと作成出来る方法を投稿しますので、そちらのほうが簡単かもしれません。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342082/9a2938a6-c798-94f8-b38e-44eb646081fe.png" width=100%>

#各タスクの説明
画像の各タスクをWorkflowの流れと一緒に順に説明します。
※原則記載の無い設定項目はデフォルト値です。

###startevent(アラート発生)
アラートのcomponentのフィールドの文字列が”Print Spooler”であった場合、
このWorkflowを開始する。

| 項目 | 値 |
|:-|:-|
|  Name | ServiceAlert  |
| ID  | 自動入力  |
|  Configuration | Alert  |
| Configuration2  | Created  |
| Filter Criteria  | $component = "Print Spooler"  |

###User Task(承認申請)
タスクチケットを作成します。
言い換えますと、承認申請がタスクという種類のチケットで作成されます。

| 項目 | 値 |
|:-|:-|
|  Name | ObtainApproval|
| ID  | 自動入力  |
|  Subject| サービス再起動承認依頼  |
| Description  | 下記サービスが停止中です、再起動のためワークフローの承認をお願いします。<code>$ServiceAlert.alert.resource.hostName</code>, <code>$ServiceAlert.alert.component</code> |
| Priority  | high  |
| Assignee | 任意(承認者にするのがいいと思います。)　|

※ここにない項目はデフォルトで構いません。

###(Taskチケット)
予めCustom Formで承認対応用のフィールドを用意しておきましょう。
(Custom Formの詳細はこれだけでとても長くなるため省略します。)

Setup＞Service Desk＞Custom Forms＞Task

| 項目 | 値 |
|:-|:-|
| Formの種類  | Drop-down list|
| Display Label  | Actions  |
|  Is editable?| 有効  |
| Dropdown Options 1| Deny(※横のボックスも同じ内容を入力) |
| Dropdown Options 2| Approve(※横のボックスも同じ内容を入力) |

###(承認作業)
承認者が内容を確認し、承認します。

要件
「承認する = Workflowを先にすすめる」という事になるのですが、
その条件として、**この作成されたTaskチケットのステータスを「Resolved」にする必要があります。**
これはOpsRampのドキュメントに書いていないので要注意です。(2021/12/03現在)
合わせて、事前に作成した「Action」のフィールドは「Approved」を選択しましょう。

![0024.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342082/31bb1d9b-cb72-60db-1310-e2aa1d668fbd.png)

###Exclusive Gateway(承認された場合のみ次のタスクを実行する)
Taskチケットを更新したことにより、先に進むことが出来るようになりました。
次に待ち構えているのは条件分岐です。
下記の設定で、Taskチケットの「Action」のフィールドは「Approved」の時だけ
関所を通す設定を入れていきます。
これ勘違いしやすいのですが、分岐のFunctionであるExclusive Gatewayには
分岐の条件を入れる項目はありません。分岐の条件を入れるのはそこから伸びている
棒線矢印の中に入れていきます。

1, Exclusive Gateway

| 項目 | 値 |
|:-|:-|
| Name  | Get Responce|
| ID  | 自動入力|

2, Global Connect その1(矢印の棒線)

| 項目 | 値 |
|:-|:-|
| Name  | Deny|
| ID  | 自動入力|

3, Global Connect その2(矢印の棒線)

| 項目 | 値 |
|:-|:-|
| Name  | Approve|
| ID  | 自動入力|
| Condition  | $ObtainApproval.task.Actions = "Approve"|

###Script Task(プロセスを再起動する)
承認が通っているため、Downしたプロセスをスクリプトで起動させます。
これによって対象のアラートは復旧します。
今回はOpsRamp上で用意したスクリプトを動かします。

| 項目 | 値 |
|:-|:-|
| Name  | RestartService|
| ID  | 自動入力|
| Configuration| Agent|
| Script Category| 任意|
| Script Name| 任意|
| Resource Id| $ServiceAlert.alert.resource.uuid|
| Imputs-Service Name| $ServiceAlert.alert.component|

※このスクリプトはOpsRamp内で作成し、スクリプトのImputのパラメータを
仕込んであります。ですので、通常はパラメータなければImput入力項目は
出てきません。

###Service Task(アラート/インシデントチケットに自動対応実施のログを残す)
最後にスクリプトを実行したということをアラートとインシデントにコメントして残します。
このService TaskはOpsRampUIから取れるアクションの一部を自動で実施してくれます。
ドロップダウンから選択するだけなので、スクリプト等がなくても簡単に実行できるので楽ちんです。

1, アラート

| 項目 | 値 |
|:-|:-|
| Name  | AddAlertComment|
| ID  | 自動入力|
| Service| Platform Service|
| Task| Post Alert Comment|
| AlertID| $ServiceAlert.alert.uuid|
| Comments| 自動化ワークフローによりサービスの再起動を実施しました。承認者: $ObtainApproval.task.assignedTo.loginName|

2, インシデント

| 項目 | 値 |
|:-|:-|
| Name  | UpdateIncident|
| ID  | 自動入力|
| Service| Platform Service|
| Task| Update Incident|
| Response| 自動化ワークフローによりサービスの再起動を実施しました。承認者: $ObtainApproval.task.assignedTo.loginName|

それぞれこの様にポストされました。
アラート
![0025.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342082/42e83e0d-788a-2c33-4e7e-ca2027008e12.png)
インシデントチケット
![0026.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2342082/0668ad31-d8cd-68b0-24c8-dfb37dd004b6.png)

以上です。