この演習では、NeedIt API のスクリプト化された Web サービスで GET リソースを作成します。このリソースはユーザーとエンコードクエリに渡されます。

GET リソースの作成

1. 前の演習で開いていない場合は、Studio で NeedIt アプリケーションを編集用に開きます。
   1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [システムアプリケーション] > [Studio] を開きます。
   2. [アプリケーションを選択] ダイアログで、NeedIt アプリケーションをクリックします。
2. 前の演習で開いていない場合は、アプリケーションエクスプローラーを使用して [受信データ連携 (Inbound Integrations)] > [Scripted REST APIs] > [NeedIt API] を開きます。
3. [リソース] 関連リストに切り替え、[新規] ボタンをクリックします。
4. リソースの構成：
   名前： no_getinfo
   HTTP メソッド： GET
   相対パス： /nigetinfo/{user_name}
5. [送信] ボタンをクリックします。

クエリパラメーターの関連性

1. [クエリパラメーターの関連性] 関連リストまでスクロールし、[新規] ボタンをクリックします。
2. API クエリパラメーターの関連性の構成：
   API クエリパラメーター： ni_query
3. [送信] ボタンをクリックします。
4. Studio で [ni_getinfo スクリプト化された REST リソース (ni_getinfo Scripted REST Resource)] タブに戻ります。
5. [他のアクション] メニュー () をクリックして、[フォームの再ロード] メニューアイテムを選択します。
6. [クエリパラメーターの関連性] 関連リストまでスクロールします。ni_query クエリパラメーターをリソースに関連付ける必要があります。
7. ni_query パラメーターを必須にします。
   1. [クエリパラメーターの関連性] 関連リストにある ni_query クエリパラメーターの [必須] 列で <値> をダブルクリックします。
   2. [必須] の値を [true] に設定します。
   3. [保存 (Enter)] ボタン () をクリックします。
8. [更新] ボタンをクリックします。

ドキュメント

1. [ドキュメント] セクション (タブ) までスクロールします。
2. [ドキュメント] セクション (タブ) を構成します。
   簡単な説明： ユーザーのアクティブな NeedIt レコードを検索します。[必要なもの] でグループ化します。
3. [更新] ボタンをクリックします。

リソーススクリプトは、応答オブジェクトのプロパティを作成して設定するサーバーサイド JavaScript です。応答オブジェクトは、リソースを呼び出したアプリケーションに返されます。

リソースの [スクリプト] フィールドには、スクリプトテンプレートが含まれています。自己呼び出し型関数式または即時呼び出し型関数式と呼ばれるテンプレートの process 関数は、リソースにアクセスすると自動的に呼び出されます。process 関数に渡される要求および応答オブジェクトは、自動的に作成されます。

開発者は、テンプレートのコメントの後にサーバーサイド JavaScript を追加します。

RESTAPIRequest API を使用すると、開発者は要求からデータにアクセスできます。request オブジェクトは RESTAPIRequest クラスから自動的にインスタンス化され、Scripted REST API スクリプトの process 関数に渡されます。

要求オブジェクトのプロパティは次のとおりです。

• body
• pathParams
• queryParams
• queryString
• URI
• URL
• headers
• getHeader()
• getSupportedResponseContentTypes()

本文

body オブジェクトは、要求本文へのアクセスを提供します。

//get instance of RESTAPIRequestBody var requestBody = request.body;

pathParams

pathParams オブジェクトを使用すると、要求 URL で渡されたパスパラメーターにスクリプトでアクセスできます。使用可能なパスパラメーターは、スクリプト化された REST サービスのリソースによって決まります。デモサービスからの userinfo リソースの URL は次のとおりです。

https://<instance>/api/<namespace>/demo_service/userinfo/{user_id} 

パスパラメーターは、サービスが呼び出されたときに渡されます。

//get pathParams object var pathparams = request.pathParams; //get user_id property value from pathparams object var userID = pathparams.user_id;

サンプルスクリプトが実行された後の pathparams.user_id プロパティの値は、URL で渡された値と同じです。

queryParams

queryParams オブジェクトを使用すると、Web サービス要求からクエリパラメーターにスクリプトでアクセスできます。デモサービスのクエリパラメーターは demo_query です。デモサービスの URL は次のとおりです。

https://<instance_rest_endpoint>/?demo_query=active%3Dtrue 

demo_query パラメーター値は、サービスが呼び出されたときに渡されます。

//get queryParams object var queryparams = request.queryParams; //value of myQueryParam is active=true var myQueryParam = queryparams.demo_query;

サンプルスクリプトが実行された後の myQueryParam 変数の値は active=true です。

queryString

queryString 文字列は、エンドポイント URI に追加されるクエリ全体を含みます。デモサービスの URL は次のとおりです。

https://<instance>/api/<namespace>/demo_service/userinfo/5137153cc611227c000bbd1bd8cd2005d?demo_query=active%3Dtrue 

クエリ文字列は URL の一部です。

//get the query string //value of query is demo_query=active%3Dtrue var query = request.queryString;

サンプルスクリプトが実行された後の query 変数の値は demo_query=active%3Dtrue です。

URI

uri 文字列は、ドメイン情報を除いた要求 URI を含みます。デモサービスからの userinfo リソースの URL は次のとおりです。

https://<instance>/api/<namespace>/demo_service/userinfo/{user_id} 

URI にはクエリパラメーターが含まれていません。

//get the uri string //value of query is /api/<namespace>/demo_service/userinfo/5137153cc611227c000bbd1bd8cd2005d var query = request.uri;

サンプルスクリプトが実行された後の query 変数の値は /api/187049/demo_service/userinfo/5137153cc611227c000bbd1bd8cd2005d です。

URL

url 文字列には要求 URL 全体が含まれています。

//get the url string //returns https://instance/api/<namespace>/demo_service/userinfo/5137153cc611227c000bbd1bd8cd2005d var query = request.url;

スクリプトの実行後の query 変数の値は URL 全体です。

headers

headers オブジェクトには、要求のすべての headers プロパティ値のペアが含まれています。

//get the headers from the request var headers = request.headers; //get the value of the Accept property var acceptHeader = headers.accept;

request.headers オブジェクトのプロパティは、API ごとに異なる場合があります。デモサービス API の request.headers プロパティには、accept、from、content-type が含まれます。API で大文字を使用して定義されている場合でも、すべての request.headers プロパティ名は小文字であることに注意してください。request.headers プロパティをログに記録するために使用されるスクリプトは、データタイプもログに記録しました。すべてのプロパティが文字列であることに注意してください。

getHeader()

getHeader メソッドは、Web サービス要求から特定のヘッダーの値を含む文字列を返します。

//get the headers from the request var headers = request.headers; //get the value of the from header var fromHeader = headers.getHeader('from');

スクリプトの実行後、変数 fromHeader の値は Abel Tuter になります。

開発者向けのヒント：API で大文字を使用して定義されている場合でも、ヘッダープロパティの名前は小文字になります。

getSupportedResponseContentTypes()

getSupportedResponseContentTypes() メソッドは、各文字列が application/json などのコンテンツタイプである文字列値のアレイを返します。

var contentTypes = []; contentTypes = request.getSupportedResponseContentTypes(); for(i=0;i<contentTypes.length;i++){ gs.info("content type [" + i + "] = " + contentTypes[i]); }

contentTypes アレイには、デモサービス用の要素が 1 つあります。

RESTAPIRequestBody API を使用すると、開発者は Scripted REST API 要求の本文コンテンツにアクセスできます。request.body オブジェクトは自動的にインスタンス化されます。

request.body オブジェクトのプロパティを確認するには、リソースの [スクリプト] フィールドに「request.body」と入力します。

プロパティが自動的に表示されます。キーボードの上下矢印キーを使用して、強調表示されたプロパティの説明を確認します。

プロパティリストのアイコンは、プロパティのデータタイプを示します。

• O：オブジェクト
• S：文字列
• F：関数

RESTAPIRequestBody API には次のものが含まれます。

• data：単一のオブジェクトまたはオブジェクトのアレイとしての要求本文の内容。
• dataStream：ストリームとしての要求本文の内容。
• dataString：文字列としての要求本文の内容。
• hasNext()：要求本文に別のエントリが含まれている場合は true を返します。
• nextEntry()：要求本文からスクリプトオブジェクトとして 1 つのエントリを取得します。

RESTAPIRequestBody API ドキュメントのサンプル要求本文を参照してください。

ServiceNow は、既存のテーブルと列のデータに関する集計統計を計算するために使用する集計 API を提供しています。このモジュールで示すユースケースでは、次の 3 つの集計が必要です。

• user_id が問い合わせユーザーであるインシデントテーブルレコード。
• user_id が要求元である変更要求テーブルレコード。
• user_id がオープン者である問題テーブルレコード。

Scripted REST API は、集計 API を 3 回呼び出す代わりに、集計を実行して、単一の response オブジェクトに集計を返します。

(function process(/*RESTAPIRequest*/ request, /*RESTAPIResponse*/ response) { // implement resource here // Get value from the user_id path parameter passed in the URL var requestUser = request.pathParams.user_id; // Get value of the demo_query query parameter passed in the URL var requestDemoQuery = request.queryParams.demo_query; // Query the sys_user table to get the user record for the user passed in // the user_id path parameter var requestUserName = new GlideRecord('sys_user'); requestUserName.get(requestUser); // Aggregation 1: Incident table // Get the count of Incident table records where the user from the user_id path // parameter is the Caller. var userIncidentCount = new GlideAggregate('incident'); userIncidentCount.addAggregate('COUNT'); userIncidentCount.addQuery('caller_id',requestUser); userIncidentCount.addEncodedQuery(requestDemoQuery); userIncidentCount.query(); var incidents = 0; if (userIncidentCount.next()) { incidents = userIncidentCount.getAggregate('COUNT'); } // Aggregation 2: Change request table // Get the count of Change request table records where the user from the user_id path // parameter is the Requested by. var userChangeCount = new GlideAggregate('change_request'); userChangeCount.addAggregate('COUNT'); userChangeCount.addQuery('requested_by',requestUser); userChangeCount.addEncodedQuery(requestDemoQuery); userChangeCount.query(); var changes = 0; if (userChangeCount.next()) { changes = userChangeCount.getAggregate('COUNT'); } // Aggregation 3: Problem table // Get the count of Problem table records where the user from the user_id path // parameter is the Opened by. var userProblemCount = new GlideAggregate('problem'); userProblemCount.addAggregate('COUNT'); userProblemCount.addQuery('opened_by',requestUser); userProblemCount.addEncodedQuery(requestDemoQuery); userProblemCount.query(); var problems = 0; if (userProblemCount.next()) { problems = userProblemCount.getAggregate('COUNT'); } //Create a body object. Add property value pairs to the body. var body = {}; body.numInc = incidents; body.numChg = changes; body.numPrb = problems; body.user = {"User name": requestUserName.user_name, "User ID": requestUser}; // Send the response object, which is returned to the requestor, to the body object. response.setBody(body); })(request, response);

応答本文には、インシデント、変更、問題の数に加えて、ユーザー名とユーザー ID が含まれています。

リソーススクリプトについて覚えておくべきポイント

• process 関数は自己呼び出し型です。
• request オブジェクトと response オブジェクトは自動的にインスタンス化されます。
• Scripted REST APIs にはアクセス制御が適用されます。API の認証を介して要求を行うユーザーは、要求された情報にアクセスできる必要があります。

この演習では、ni_getinfo リソースにスクリプトを追加します。このスクリプトは、パスパラメーターで渡されたユーザーのアクティブな NeedIt 要求の数を検出します。response オブジェクトは次の要素で構成されます。

• ユーザーのアクティブな NeedIt レコードの数 (整数)
• 要求タイプ (オブジェクトのアレイ) 別のユーザーのアクティブな NeedIt レコードの数
• ユーザー (オブジェクト) の名前と sys_id

REST API Explorer を使用して ni_getinfo リソースをテストします。

準備

1. ServiceNow ブラウザーのメインウィンドウ (Studio ではない) で、Application Navigator を使用して [NeedIt] > [開く] を開きます。
2. その時点でリストにない場合は、[要求先] 列と [要求タイプ] 列を追加します。
   1. [リストをカスタマイズ] アイコン () をクリックします。
   2. [利用可能] スラッシュバケットで、[要求先] フィールドをダブルクリックして [選択済み] スラッシュバケットに移動します。
   3. [上に移動] () ボタンと [下に移動] () ボタンを使用して、選択した場所に [要求先] フィールドを配置します。
   4. [要求タイプ] フィールドを [選択済み] スラッシュバケットの任意の位置に追加します。
   5. [OK] ボタンをクリックします。
3. Beth Anglin や Fred Luddy などのユーザーを選択します。要求タイプ (人事、 施設、 法務) ごとに、選択したユーザーが要求先であるレコードが少なくとも 1 つあることを確認します。必要に応じて、既存のレコードを変更するか、新しいレコードを作成します。
4. NeedIt レコードリストで、条件ビルダーを使用して、選択したユーザーおよび各要求タイプのアクティブなレコードの数を検索します。この例では Fred Luddy を検索します。必ず選択したユーザーを検索してください。
   
   
5. ユーザーが要求先であるアクティブな NeedIt レコードの数をメモします。

リソーススクリプト

1. ni_getinfo リソースを Studio で編集用に開いていない場合は、アプリケーションエクスプローラーを使用して [受信データ連携 (Inbound Integrations)] > [スクリプト化された REST リソース] > [NeedIt API/ni_getInfo[GET]] を開きます。

2. [スクリプト] フィールドの内容を次のスクリプトに置き換えます。

   (function process(/*RESTAPIRequest*/ request, /*RESTAPIResponse*/ response) { // implement resource here // Get value from the user_name path parameter passed in the URL var requestUser = request.pathParams.user_name; // Get value of the ni_query query parameter passed in the URL var requestNIQuery = request.queryParams.ni_query; // Query the sys_user table to get the user record for the user passed in // the user_id path parameter. var requestUserName = new GlideRecord('sys_user'); requestUserName.get('user_name',requestUser); // Get the count of active NeedIt table records where the user from the // user_name path parameter is the Requested for. エンコードクエリはクエリパラメーターの関連性からのものです。Group by category. var userNICount = new GlideAggregate('x_58872_needit_needit'); userNICount.addAggregate('COUNT'); userNICount.addQuery('u_requested_for',requestUserName.sys_id); userNICount.addEncodedQuery(requestNIQuery); userNICount.groupBy('u_request_type'); userNICount.query(); var needitRecs = 0; var niUserRecs = []; var needitRecsCount = 0; while (userNICount.next()) { needitRecs = userNICount.getAggregate('COUNT'); var reqType = userNICount.u_request_type.getDisplayValue(); niUserRecs.push({"requestType": reqType, "count": needitRecs}); needitRecsCount = parseInt(needitRecsCount) + parseInt(needitRecs); } //Create a body object. Add property value pairs to the body. var body = {}; body.totalUserNIRecs = needitRecsCount; body.catCounts = niUserRecs; body.user = {"User name": requestUserName.user_name, "User ID": requestUserName.sys_id}; // Send the response object, which is returned to the requestor, to the body object. response.setBody(body); })(request, response);

3. スクリプトを読んで、何をするスクリプトかを理解します。

4. [更新] ボタンをクリックします。

n_getinfo リソースのテスト

1. ServiceNow ブラウザーのメインウィンドウ (Studio ではない) で、Application Navigator を使用して [システム Web サービス] > [REST] > [REST API Explorer] を開きます。

2. REST API Explorer を構成して、NeedIt API の n_getinfo リソースをテストします。

   名前空間： x_58872_needit
   API 名： NeedIt API
   API バージョン： 最新

3. REST API Explorer でドキュメントを確認します。

   質問：テキスト「NeedIt アプリケーションレコードのデータへのアクセスを提供します」はどこで定義されましたか。？
   
   回答：このテキストは NeedIt API の [ドキュメント] セクション (タブ) にある [簡単な説明] フィールドで定義されました。
   

   
   
   

   質問：テキスト「ni_getinfo - ユーザーのアクティブな NeedIt レコードを検索します。[必要なもの] でグループ化します。」はどこで定義されましたか？
   
   回答：そのメソッド名は REST API Explorer が挿入しました。このテキストは NeedIt API ni_getinfo リソースの [ドキュメント] セクション (タブ) にある [簡単な説明] フィールドで定義されました。
   

   
   
   

4. API メニューを開き、[API ドキュメント] メニューアイテムを選択します。
   

   

   質問：API ドキュメントはどこで定義されましたか？
   
   回答：API ドキュメントは UI ページとして定義され、NeedIt API の [ドキュメント] セクション (タブ) にある [ドキュメントリンク] フィールドで参照されました。
   

   
   
   

5. 要求を準備します。

   user_name： <準備セクションのユーザーのユーザー名。たとえば、fred.luddy>
   ni_query： active = true

6. [要求ヘッダー] セクションまでスクロールします。

   1. 要求形式の選択リストを調べます。
   2. 応答形式の選択リストを調べます。

   質問：[要求形式] フィールドで application/json が唯一の選択肢となるのはなぜですか？
   
   回答：受け入れ可能な要求形式は、NeedIt API の [コンテンツネゴシエーション] セクションで設定されます。
   

7. [送信] ボタンをクリックします。

REST API Explorer でのテストの確認

1. [要求] セクションで、要求の形式を確認します。パスパラメーターとクエリパラメーターを特定できますか？
   

   

2. [応答] セクションまでスクロールし、ステータスコードとヘッダーを確認します。ステータスコードは 200 OK である必要があります。

3. 応答本文を確認します。次の例のようになります。ユーザーとカウントは異なる場合があります。

{ "result": { "totalUserNIRecs": 6, "catCounts": [ { "requestType": "Facilities", "count": "1" }, { "requestType": "Human Resources", "count": "2" }, { "requestType": "Legal", "count": "3" } ], "user": { "User name": "fred.luddy", "User ID": "5137153cc611227c000bbd1bd8cd2005" } } }

API ユーザーが問題をデバッグできるようにするには、error オブジェクトを使用して、エラーに関する情報を API のコンシューマーに報告します。ServiceNow には、エラーに対する 2 つの戦略があります。

• 事前定義された error オブジェクトを使用する
• カスタム error オブジェクトを作成する

どちらの場合も、error オブジェクトは sn_ws_err 名前空間からインスタンス化する必要があります。

事前定義されたエラーオブジェクト

事前定義された error オブジェクトは、標準の HTTP ステータスコードを使用してコンシューマーに情報を送信します。エラーメッセージを渡して、カスタムメッセージを送信します。

たとえば、NotFoundError オブジェクトをコンシューマーに送信します。

(function run(request, response) { // resource is not available return new sn_ws_err.NotFoundError('The resource you requested is not part of the API.'); })(request,response);

開発者向けのヒント：error オブジェクトを含むメッセージの送信は必須ではありませんが、送信した方が API のユーザーにとっては便利です。

事前定義されたエラーは応答本文に返されます。

カスタムエラーオブジェクト

ServiceError オブジェクトを使用して、カスタムエラーを定義します。ServiceError メソッドは次のとおりです。

(function run(request, response) { var myError = new sn_ws_err.ServiceError(); myError.setStatus(442); myError.setMessage('Invalid value in path parameter'); myError.setDetail('We recognized the path parameter you sent, but the value you requested does not exist in the database.'); return myError; })(request,response);

カスタムエラーは応答本文に返されます。

デフォルトでは、API バージョニングは無効になっています。バージョニングを有効にすると、開発者は Web サービスコンシューマーからの既存の統合に影響を与えることなく変更をテストして展開できます。

バージョニングの有効化

バージョニングは API レベルで有効になっており、すべての API リソースに適用されます。バージョニングを有効にするには、Scripted REST API で [バージョニングの有効化] 関連リンクをクリックします。

バージョニングが有効になっている場合、リソース URL にはバージョン番号が含まれます。バージョニングを有効にするときに既存のデータ連携の遮断を防ぐには、バージョン v1 をデフォルトにします。

[リソース] リストには [API バージョン] 列が含まれ、バージョン番号がリソースパスに追加されます。

注意：バージョニングを有効にすると、無効にすることはできません。

新規バージョンの作成

API に新しいバージョンを追加するには、[新規バージョンを追加] 関連リンクをクリックします。

[新規バージョンを追加] ダイアログが開きます。

新しいバージョンをデフォルトにするには、[このバージョンをデフォルトにする] チェックボックスをオンにします。ほとんどの場合、開発が完了して新しいバージョンが完全にテストされるまで、新しいバージョンをデフォルトにすべきではありません。

既存のバージョンからリソースをコピーするには、[次のバージョンから既存のリソースをコピー] 選択リストで該当するバージョンを選択します。

リソースを編集するときは、編集するバージョンを選択します。

REST API Explorer でテストする場合は、API バージョンをテストするバージョンに設定します。

開発者向けのヒント：カスタムの Scripted REST APIs のバージョン間の変更を文書化します。REST API Explorer のメニューからメソッド定義と完全なドキュメントアクセスを更新します。

この演習では、NeedIt API のバージョニングを有効にします。ユーザーから渡された user_name パスパラメーターが sys_user テーブルに見つからない場合に error オブジェクトを返す、新しいバージョンの ni_getinfo リソースを作成します。

バージョニングの有効化

1. NeedIt API を編集用に開いていない場合は、Studio でアプリケーションエクスプローラーを使用して [受信データ連携 (Inbound Integrations)] > [Scripted REST APIs] > [NeedIt API] を開きます。
2. バージョニングを有効にします。
   1. [バージョニングの有効化] 関連リンクをクリックします。
   2. [バージョニングの有効化] ダイアログで、[バージョン v1 をデフォルトにする] チェックボックスをオンにします。
   3. [OK] ボタンをクリックします。

新規バージョンの追加

1. [新規バージョンを追加] 関連リンクをクリックします。
2. 新しいバージョンを設定します。
   このバージョンをデフォルトにする： 未選択 (オフ)
   次のバージョンから既存のリソースをコピー： v1
3. [OK] ボタンをクリックします。

新規バージョンの編集

1. [リソース] 関連リストまでスクロールし、ni_getinfo(v2) のリンクをクリックします。
2. [リソースパス] フィールドを確認し、[リソースパス] のバージョン番号をメモします。
3. 要求でユーザーから渡された user_name パスパラメーターが sys_user テーブルに見つからない場合は、カスタム error オブジェクトを返すようにスクリプトを変更します。

   1. カスタムエラーロジックをコピーします。

      // If there is no user record for the user_name passed in the user_name path parameter, // return a custom error. Notice the error object is created from // sn_ws_err.ServiceError(); If no status value is set, the HTTP Status will // be 500. if(!requestUserName.user_name){ var apiError = new sn_ws_err.ServiceError(); apiError.setStatus(542); apiError.setMessage("User not found"); apiError.setDetail("No user record found for the user_name passed into the ni_info web service resource using the user_name path parameter."); response.setError(apiError); return; }

   2. カスタムエラーロジックをスクリプトの 15 行目に貼り付けます。行番号が多少異なる場合があります。erro オブジェクトロジックは、データベースからユーザーレコードを取得してから userNICount オブジェクトを作成するまでの間に入ります。
      

      

   3. error オブジェクトロジックを調べて、何をするロジックかを理解します。

4. [更新] ボタンをクリックします。

API ドキュメントの更新

1. Studio でアプリケーションエクスプローラーを使用して、[フォームと UI (Forms＆UI)] > [UI ページ] > [needit_api_documentation] を開きます。

2. HTML にリストアイテムを追加します。

   <li>GET ni_getinfo(v2)：v1 と同じ機能がすべて含まれていますが、要求が無効なユーザー名を渡した場合のカスタムエラーメッセージも含まれています。</li>

   

3. [更新] ボタンをクリックします。

ni_getinfo(v2) リソースのテスト

1. Studio の ni_getinfo (v2) リソースレコードで、[REST API の探索] 関連リンクをクリックします。

2. REST API Explorer が、名前空間、API 名、API バージョン、リソースが選択された状態で開くことに注意します。

3. API メニューを開き、[API ドキュメント] メニューアイテムを選択します。新しい v2 ドキュメントは API ドキュメントの一部ですか？
   

   

4. 要求を準備します。

   user_name： <無効なユーザー名をパスします。たとえば、hello.world>
   ni_query： active = true

5. [送信] ボタンをクリックします。

6. [応答] セクションまでスクロールし、ステータスコードを確認します。ステータスコードは 542 である必要があります。

7. 応答本文を確認します。カスタム error オブジェクトが含まれている必要があります。

{ "error": { "detail": "No user record found for the user_name passed into the ni_info web service resource using the user_name path parameter.", "message": "User not found" }, "status": "failure" }

[Web API の使用率] ダッシュボードには、API ごとに分析データが表示されます。開発者は以下を確認できます。

• リソース別の API 使用率 (過去 30 日間)
• メソッド別の API 使用率 (日次)
• バージョン別の REST API 使用率 (日次)
• API 使用率 (月次)

API のダッシュボードを表示するには、Application Navigator を使用して [Performance Analytics] > [ダッシュボード] を開きます。[すべて] を選択し、検索フィールドを使用して「Web API の使用率」を検索します。ダッシュボードを開き、選択リストから目的の API を選択します。

または、API レコードの [API Analytics] 関連リンクをクリックします。

ダッシュボードを使用して API への要求を監視します。

この演習では、NeedIt API のダッシュボードを開いて確認します。

ダッシュボードを開く

1. NeedIt API を編集用に開いていない場合は、Studio でアプリケーションエクスプローラーを使用して [受信データ連携 (Inbound Integrations)] > [Scripted REST APIs] > [NeedIt API] を開きます。
2. [API Analytics] 関連リンクをクリックします。

ダッシュボードの確認

NeedIt API とそのリソースには多くのトラフィックがないため、ダッシュボードには多くのデータがありません。

次の点を判断できるかどうか確認してください。

• 各リソースが呼び出された回数(ヒント：詳細については、ダッシュボードウィジェットのデータをクリックしてください)。
• 最もビジー状態だったリソース：
  • 過去 30 日間
  • 今日
  • 月次
• NeedIt API で最もビジーだった日はいつですか？
  
  

開発者は、GitHub のようなソースコントロールアプリケーションを使用して、個人開発者インスタンス (PDI) の外部で変更をコミット (完了した作業を保存) できます。アプリケーションに対する変更内容をコミットして、作業をソースコントロールに保存します。

この演習では、このモジュールで完了した作業を GitHub リポジトリに保存します。

注意：ServiceNow が開発者プログラムの学習コンテンツで GitHub を使用する方法の詳細と、作業を保存する方法に関するビデオを見るには、『GitHub ガイド』を参照してください。

変更をコミット (Commit Changes)

1. NeedIt アプリケーションが Studio で開かれていない場合は、ここで開きます。

   1. ServiceNow ブラウザーのメインウィンドウで、Application Navigator を使用して [システムアプリケーション] > [Studio] を開きます。

   2. [アプリケーションを選択] ダイアログで、このアプリケーションをクリックします。

2. [ソースコントロール] メニューを開き、[変更をコミット] メニューアイテムを選択します。

   

3. コミットする更新を選択します。

   1. [<アプリケーション> のソースコントロールにコミットするファイルを選択] ダイアログで、[すべての Update Sets] を選択します。
   2. コミットするアプリケーションファイルを確認します。
   3. [続行] ボタンをクリックします。
   

4. [NeedIt のソースコントロールにコミットするファイルを確認] ダイアログで、「Scripted REST APIs モジュール完了」などのコミットコメントを入力します。

5. [コミットファイル] ボタンをクリックします。

   

6. [変更をコミット] ダイアログが成功を報告したら、[閉じる] ボタンをクリックします。

   

   注意：変更のコミットに失敗した場合は、フォークしたリポジトリ URL ではなく ServiceNow のリポジトリ URL を [URL] フィールドに入力している可能性があります。GitHub 接続問題のトラブルシューティング方法については、『GitHub ガイド』の 「GitHub 問題のトラブルシューティング」 セクションを参照してください。

ここでは、Scripted REST APIs についての理解度を確認できます。自分の進行状況を評価するには、次の質問が役立ちます。質問ごとに回答を決定し、質問の任意の場所をクリックして回答を表示します。

質問：正誤問題？Scripted REST APIs は Studio で作成できます。

回答：正解は正しいです。

---

質問：[コンテンツネゴシエーション] セクションで構成されるものについて説明しているのは次のうちどれですか？複数の回答が正解の場合があります。

1. 利用可能な認証方法。
2. サポートされる要求形式。
3. API で利用可能なレコード。
4. サポートされる応答形式。
5. Web サービスプロバイダーとコンシューマーの間の契約。

回答：正解は 2 と 4 です。開発者は [コンテンツネゴシエーション] セクションを使用して、要求と応答に使用できる形式を構成します。

---

質問：正誤問題？Scripted REST API のドキュメントは UI ページとして作成する必要があります。

回答：正解は誤りです。REST API のドキュメントは、URL でアクセス可能な場所であればどこでもホストできます。UI ページを使用すると、ServiceNow インスタンスのドキュメントを簡単に管理できます。

---

質問：スクリプト化された REST リソースを作成すると、次のどれが作成されますか？複数の回答が正解の場合があります。

1. 応答本文
2. 要求ヘッダー
3. REST メソッド
4. パスパラメーター
5. クエリパラメータ

回答：正解は 3 と 4 です。

要求ヘッダーとクエリパラメーターをリソースに関連付けることができます。

---

質問：開発者が要求からデータにアクセスできるようにする API は次のうちどれですか？

1. RESTAPIRequestBody
2. RESTAPIRequestV2
3. RESTRequest
4. RESTRequestV2
5. RESTAPIRequest

回答：正解は 5 です。

---

質問：リソーススクリプトに応答本文を作成するのは次のどのメソッドですか？

1. setBody()
2. setContent()
3. setBodyContent()
4. getBody()
5. getContent()

回答：正解は 1 です。

---

質問：正誤問題？Scripted REST APIs を使用すると、開発者はカスタムエラーコードを作成できます。

回答：正解は正しいです。

---

質問：API のバージョニングの開始方法を説明する文は次のどれですか？

1. [バージョニングの有効化] ボタンをクリックします。
2. Scripted REST API レコードの [コピー] ボタンをクリックし、[バージョン] フィールドをインクリメントします。
3. Scripted REST API レコードの [バージョニングの有効化] 構成オプションを選択します。
4. [バージョニングの有効化] 関連リンクをクリックします。
5. [新規バージョンを追加] 関連リンクをクリックします。

回答：正解は 5 です。バージョニングを有効にした後、[新規バージョンを追加] 関連リンクを使用してバージョンを作成します。

---

質問：[Web API の使用率] ダッシュボードを開く方法を説明している文は次のどれですか？複数の回答が正解の場合があります。

1. [REST] > [ダッシュボード] を開き、「Web API の使用率」を検索します。
2. API レコードの [API Analytics] 関連リンクをクリックします。
3. [Performance Analytics] > [ダッシュボード] を開き、「Web API の使用率」を検索します。
4. リソースレコードの [API Analytics] ボタンをクリックします。
5. [REST] > [API Analytics] を開きます。

回答：正解は 2 と 3 です。

---

お疲れさまでした。「Scripted REST APIs」モジュールはこれで完了です。スクリプト化された REST への関心に基づいて、さらに次のことも学んでいただけます。

• 受信 REST データ連携：この開発者サイト学習モジュールでは、REST API Explorer を使用して ServiceNow API への要求を構築し、テストします。
• スクリプトのテクニカルベストプラクティス：この開発者サイトガイドでは、コードを読みやすくする、小さなモジュール式コンポーネントを作成する、データベースを操作するなど、スクリプティングに関するテクニカルベストプラクティスを提供します。
• REST API リファレンス：この開発者サイトの製品ドキュメントは、Web サービスで使用される各 REST APIs に関するドキュメントです。