https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71030001/customer/tips/index.html Recent content in 4.5 その他運用設計Tips on JP1 Cloud Service 運用統合 利用ガイド Hugo -- gohugo.io ja https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71030001/customer/tips/tips_library/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71030001/customer/tips/tips_library/index.html Libraryの機能により、複数のユーザーから参照できる共有コンテナをマニフェストファイルで定義します。 共有コンテナへは任意のファイルを格納することができます。たとえば、申請時に画面上で添付するファイルのひな型をテンプレートとして共有コンテナに格納し、ユーザーにダウンロードして利用してもらうことやユーザーが入力した申請内容のファイルを複数のユーザーが確認できるよう共有のコンテナに格納するなど、さまざまな運用に活用できます。 マニフェストファイルを登録後、コンテナタブからアップロードする際、マニフェストファイルに記載した内容を指定することで共有コンテナとして使用することができます。 Libraryのマニフェストの詳細は「Library」を参照してください。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71030001/customer/tips/tips_application/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71030001/customer/tips/tips_application/index.html アプリケーションはドキュメントの1つで、ドキュメントテーブルから情報を取得することができます。 ここでのドキュメントとは、運用業務の中で使用する添付ファイルのことではなく、ワークフロー、サービスカタログおよびデータモデルなどを定義したマニフェストファイルのことを指します。 Ops Iの運用にあわせて、メニューエリアに顧客固有のアプリケーションを項目（操作アイコン）として追加することができます。追加した項目から、ドキュメントテーブルから取得した情報をコンテンツエリアに表示することができます。また、アプリケーションのメニューエリア内での表示順を指定することも可能です。 アプリケーションを表示するために、まずApplicationのマニフェストファイルにアプリケーションの表示内容を定義します。アプリケーションのマニフェストについては「Application」を参照してください。 次に、ACLとStatementのマニフェストファイルを作成し、アプリケーションのマニフェストファイルへのひもづけや、アプリケーションを表示させるユーザーやグループのカスタムロールに作成したカスタムACLを割り当てます。ACLとStatementの詳細については「ユーザーとACL」や「ACL、Statement」を参照してください。 カスタムロールにカスタムACLを割り当てるには、APIを実行する必要があります。詳細については「JP1 Cloud Service 運用統合 APIリファレンス」の「APIリファレンス概要＞APIの詳細と実行例＞ロールにカスタムACLを割り当てる、割り当てを解除する＞ロールにACLを割り当てる」を参照してください。 例えば、VM台帳管理を頻繁に活用する場合、メニューエリアに表示するアプリケーション名やアイコン、コンテンツエリアに表示するUIや関連するドキュメントなどをアプリケーションのマニフェストに定義することにより、メニューエリアに項目が追加され、その項目からVM台帳管理の一覧をコンテンツエリアに表示することができます。 （図）VM台帳管理の一覧をメニューエリアに追加した画面図の例 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71030001/customer/tips/tips_ticketcustom/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71030001/customer/tips/tips_ticketcustom/index.html タスクアプリケーションおよびリクエストアプリケーションのチケットタブから利用できるチケット機能は、お客様がチケットの画面をカスタムすることができます。 カスタムを実施する場合、「apps」リポジトリのファイルを編集します。「apps」リポジトリについては、「初期マニフェストファイルのカスタム」を参照してください。また、チケット画面の詳細については「チケット」を参照してください。 以下のカスタムが可能です。 【チケットのフィールド】 チケットのフィールド名の変更 チケットのフィールドの追加、削除 詳細は「チケットのフィールド」を参照してください。 【チケットのステータス】 チケットのステータス名の変更 チケットのステータスの初期状態、遷移順の変更 チケットのステータスの追加、削除 詳細は「チケットのステータス」を参照してください。 【チケットのタイプ】 チケットのタイプ名の変更 チケットタブから表示するタイプの追加、削除 詳細は「チケットのタイプ」を参照してください。 注意事項 以下の変更は、すべての顧客に反映されます。 フィールド名の変更 フィールドの追加、削除 ステータス名の変更 ステータスの初期状態、遷移順の変更 ステータスの追加、削除 タイプ名の変更 チケットタブから表示するタイプの追加、削除 項構成 4.5.3.1 チケットのフィールド 4.5.3.2 チケットのステータス 4.5.3.3 チケットのタイプ https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71030001/customer/tips/workflow_custom/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71030001/customer/tips/workflow_custom/index.html タスクアプリケーションおよびリクエストアプリケーションのワークフロータブでは、ワークフローの一覧が閲覧できます。ワークフロー一覧ではワークフローの内容を示すためにコンテキストID、担当者などのカラムがあらかじめ表示されています。 ワークフロー一覧画面では、お客様が案件名称や納期などのカラムを追加できます。カラムの値は、ワークフロー詳細画面などで編集できます。 さらに、ワークフロー一覧画面ではラベル名（カラムの表示名）を変更することができるほか、カラムを非表示または表示に切り替えたり、表示順を入れ替えたりすることができます。これにより、ワークフロー管理に必要な情報を整理しやすくなり、管理業務の効率化が期待できます。 カスタムを実施する場合、「apps」リポジトリのファイルを編集します。「apps」リポジトリについては、「初期マニフェストファイルのカスタム」を参照してください。また、ワークフロー一覧画面の詳細については「ワークフロー」を参照してください。 （1）ワークフロー一覧にカラムの追加 追加で表示可能なカラムはあらかじめ用意されていますが、初期設定では無効になっています。 ここでは追加できるカラムおよび編集対象のマニフェストファイルを説明します。 （表）追加で表示可能なカラム カラム名 データ形式 カラムの表示名※ 使用例 日本語 英語 description 文字列 varchar(256) 説明 Description 用途や申請内容の説明 category 文字列 varchar(256) 分類 Category 案件名称（案件A、案件Bなど） due_date 日時情報 timestamptz 期限 Due Date 2025-10-27 11:21:09 +09:00 note_1 文字列 varchar(4096) 備考 Note 作業ホスト名 note_2 文字列 varchar(4096) 備考2 Note 2 － note_2 文字列 varchar(4096) 備考3 Note 3 － ※カラムの表示名は用途に合わせて任意の名前に変更できます。 タスクアプリケーションとリクエストアプリケーションのワークフロー一覧に追加するカラムは、それぞれ次のマニフェストファイルで設定できます。 （表）編集対象のマニフェストファイルと変更箇所 マニフェストファイル 変更箇所 リクエストアプリケーションのワークフロー一覧画面 apps/ui/workflow_list_request manifest.yaml values.yaml workflow_filter_table.columns配下 タスクアプリケーションのワークフロー一覧画面 apps/ui/workflow_list_task manifest.yaml values.yaml workflow_filter_table. https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71030001/customer/tips/tips_yamlcustom/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71030001/customer/tips/tips_yamlcustom/index.html Ops IにはあらかじめOps IのUIやアプリケーションを定義しているマニフェストファイル「初期マニフェストファイル」が登録されています。初期マニフェストファイルの一部は編集をすることができ、チケット管理などの操作画面をカスタムできます。 編集することができる初期マニフェストファイルの登録場所ついて説明します。 Ops Iにはユーザーがアクセス可能な以下のグループとリポジトリがあり、初期マニフェストファイルは「Ops I System Engineers」グループの「apps」リポジトリに登録されています。 apps内はマニフェストファイルの種類別のディレクトリ構造となっています。 （表）Ops Iのグループとリポジトリ グループ リポジトリ 説明 Ops I System Engineers apps Ops IのUIやアプリケーションを定義している既存のマニフェストファイルの中で、ユーザーが編集可能なマニフェストファイルが登録されている。 編集をすることでOps Iの操作画面の一部をカスタムすることができる。 global global Library機能による共用コンテナの格納先リポジトリ、または添付ファイルの配布先のリポジトリとして利用できる。全ユーザーが所属するグループのため、globalリポジトリ内は全ユーザーに公開される。 ユーザー作成 ユーザー作成 Library機能による共用コンテナの格納先リポジトリ、または添付ファイルの配布先のリポジトリとして利用できる。サービスカタログ、ワークフロー、UI、Scriptなどの新規マニフェストファイルの登録先として利用できる。 ユーザーがアクセスするためには適切なグループに属している必要があります。また、使用目的にあわせて適切なGitロールを設定する必要があります。Gitロールの詳細は「（表）グループ追加時の関連するリソースエリアのタブ」を参照してください。 初期マニフェストファイルのカスタムにより操作画面の変更を行った例については、「チケット画面のカスタム」を参照してください。 注意事項 初期マニフェストファイルはOps Iのバージョンアップ時に更新が入る場合があります。 初期マニフェストファイルのカスタムをする際は、お客様がコードを保守する必要があります。 初期マニフェストファイルをカスタムした部分がOps Iのバージョンアップ時の変更と競合する場合、お客様が競合を解消する必要があります。Ops Iのバージョンアップ時には、カスタムした部分の動作確認を行ってください。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71030001/customer/tips/tips_businesslogictrigger/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71030001/customer/tips/tips_businesslogictrigger/index.html チケットの作成や更新などの操作を契機に、ユーザーが作成したスクリプト（JavaScriptファイル）をOps Iのサーバーサイドで実行できます。この機能を、ここでは「ビジネスロジックトリガー」と呼びます。またスクリプトが実行される契機となる操作を、ここでは「トリガー」と呼びます。スクリプトの詳細は「Script」を参照してください。 スクリプトは、トリガーの後に非同期で実行されます。 ビジネスロジックトリガーのマニフェストの詳細は「BusinessLogicTrigger」を参照してください。 ビジネスロジックトリガーを利用するユースケースを以下に示します。 チケット作成時に、チケットのカテゴリーなどから、担当者を自動で割り当てる。 チケットやナレッジ記事が作成・更新されたときに、外部システムが保有する情報を更新する。 【スクリプトの実行手順】 トリガーを設定しスクリプトを実行する手順は以下の通りです。 動作させるJavaScriptファイルを作成する。 BusinessLogicTriggerのマニフェストファイルを作成し、JavaScriptファイルとひもづける。 JavaScriptファイルとBusinessLogicTriggerマニフェストファイルをGitLabにpushし、Ops Iに登録する。 トリガーには、リソースと操作種別をそれぞれ指定できます。ただし、チケットの作成時には作業メモが作成されますが、作業メモの作成をトリガーとしたビジネスロジックトリガーは動作しません。トリガーの設定は、「BusinessLogicTrigger」の"resourceType"（リソース）と"(operation type)"（操作種別）を参照してください。 【スクリプトのログ】 スクリプトの実行結果をログで確認できます。ログを確認することで、ユーザーが作成したサーバーサイドスクリプトのデバッグや動作確認ができます。 ログを確認するには、Primitiveロール「script_logs_viewer」が割り当てられている必要があります。Primitiveロールの詳細は「Ops I上のロールとサポート機能の対応関係」を参照してください。 ログはダッシュボードアプリケーションで確認できます。詳細は「ダッシュボード」を参照してください。 また、ログはAPI「GET /api/v1/script-logs」でも取得できます。APIの詳細は「JP1 Cloud Service 運用統合 APIリファレンス」の「APIリファレンス詳細＞標準提供API＞標準提供API（v1）」のscript-logsを参照してください。 ログには以下の2種類があります。 サーバーサイドスクリプトの実行ログ： ユーザーが設定することで、OILogにより出力される。OILogについての詳細は「OILog」を参照。 ビジネスロジックトリガーの実行ログ： ユーザーが設定することなくデフォルトで出力される。 注意事項 複数のビジネスロジックトリガーが実行された場合、各スクリプトを実行する順序は保証されません。同一のレコードや外部システムのデータを更新する場合は、他の処理による更新を考慮して実装することを推奨します。 （例：同一のレコードや外部システムのデータを更新する処理は1つのスクリプトに集約し、複数のスクリプトから同じデータを更新しないように実装する） BusinessLogicTriggerのマニフェストファイルの"triggerType"に"async"が指定されている場合、スクリプトは非同期で実行されます。そのため、スクリプトが実行される時点では、対象レコードが他のユーザーや処理によって更新され、イベント発生時と異なっているおそれがあります。スクリプトでレコードを更新する場合は、スクリプト実行時の状態を確認し、他のユーザーや処理による更新内容を意図せず上書きしないように実装することを推奨します。 （例：スクリプトでチケットの担当者の値を設定する場合、担当者が未設定の場合のみ設定するなど、スクリプト実行時の状態に応じて更新の要否を判断するように実装する） ビジネスロジックトリガーのスクリプトを含むサーバーサイドスクリプトを定義する場合、複数のJavaScriptファイル利用について「サーバーサイドスクリプト定義時の注意点」を参照してください。 ビジネスロジックトリガーのスクリプトを定義する場合、再帰呼び出しについて「ビジネスロジックトリガー定義時の注意点」を参照してください。