REST APIログ収集の設定

Oracle Logging Analyticsでは、ログ・メッセージで応答するエンドポイントURLから継続的なREST APIベースのログ収集を設定できます。REST APIログ・ソースは、リクエストで指定された時間枠内に生成されたログ・メッセージで応答するAPIで構成する必要があります。

これは、環境、プラットフォーム、またはOCIサービス、Fusion Apps、ERPアプリケーションなどのアプリケーション、またはAPIを介してログを生成するその他のアプリケーションからの継続的なログ収集を自動化する場合に推奨される方法です。ソース定義でログ収集を開始するログ時間を指定したり、ログ・エンドポイントのページ結果に対してデータを反復および収集するオフセットを指定したり、コレクション・ウィンドウまたは時間枠にログを収集するために使用できるマクロがあります。

REST APIベースのソースを使用したログ収集の全体的なフロー

REST APIベースのソースを介してログ情報を収集するための概要タスクを次に示します。

REST APIソースの作成

Oracle Logging Analyticsには、REST APIログ収集用のOracle定義のログ・ソースがすでに用意されています。使用可能なOracle定義REST APIソースまたはOracle定義パーサーを使用できるかどうかを確認します。そうでない場合は、次のステップを使用して新しいログ・ソースを作成します。

開始する前に、ログに適した新しいパーサーを作成する必要がある場合は、完了します。パーサーの作成を参照してください。

  1. ナビゲーション・メニューを開き、「監視および管理」をクリックします。「ログ・アナリティクス」で、「管理」をクリックします。「管理の概要」ページが開きます。

    管理リソースが、左側のナビゲーション・ペインの「リソース」の下にリストされます。「ソース」をクリックします。

  2. 「ソース」ページが開きます。「ソースの作成」をクリックします。

    「ソースの作成」ダイアログ・ボックスが表示されます。

  3. 「Name」フィールドに、ログ・ソースの名前を入力します。

  4. 「ソース・タイプ」リストから、「REST API」を選択します。

  5. 「エンティティ・タイプ」をクリックし、アプリケーションを最も適切に識別するタイプを選択します。

  6. 「パーサー」をクリックし、収集するログのタイプに適したパーサーを選択します。

  7. 「エンドポイント」タブで、要件に応じて「ログ・エンドポイントの追加」または「複数のログのリスト・エンドポイントの追加」をクリックします:

    • ログを継続的に収集できる単一のログ・エンドポイントURLを指定するには、「ログ・エンドポイントの追加」をクリックします。「ログ・エンドポイントの追加」ダイアログ・ボックスが開きます。

      次の情報を入力します:

      1. 「ログ・エンドポイント名」を入力します。

      2. 「ログURL」を作成して、ログを定期的に収集します。「エンドポイントURLのタイプ」「ログ・エンドポイントURL」を参照してください。

      3. APIメソッドGETまたはPOSTを選択します。

        POSTを選択した場合は、メソッドのPOSTペイロードを入力し、JSONTextJavascriptHTMLおよびXMLからリクエスト・コンテンツのタイプを選択します。

      4. オプションで、「ログ・プロキシ・サーバーのURL」を指定します。

      5. オプションで、「リクエスト・ヘッダーの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」-「値」ペアの形式でリクエスト・ヘッダーを指定します。

      6. オプションで、「問合せパラメータの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」-「値」ペアの形式で問合せパラメータを指定します。

      7. 「資格証明」セクションで、「ログ資格証明タイプ」を選択します。REST APIログ収集の資格証明タイプの選択を参照してください。

      8. 入力した構成情報を検証するには、「検証」をクリックします。エラーがある場合は修正します。

        「変更の保存」をクリックします。

    • 複数のログを収集するためのログ・エンドポイントURLのリストを生成するために使用できる情報を含むJSONレスポンスを返すURLを指定するには、「複数のログのリスト・エンドポイントの追加」をクリックします。「複数のログのリストを追加」ダイアログ・ボックスが開きます。

      1. 「リスト・エンドポイントの構成」タブ:

        • 「ログ・リスト・エンドポイント名」を入力します。

        • 「ログ・リストURL」を作成して、ログ・ファイルに関する情報を取得します。「エンドポイントURLのタイプ」「ログ・リスト・エンドポイントURL」を参照してください。例:

          https://example.org/fetchlogfiles_data
        • オプションで、「ログ・プロキシ・サーバーのURL」を指定します。

        • APIメソッドGETまたはPOSTを選択します。

          POSTを選択した場合は、メソッドのPOSTペイロードを入力し、JSONTextJavascriptHTMLおよびXMLからリクエスト・コンテンツのタイプを選択します。

        • オプションで、「リクエスト・ヘッダーの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」-「値」ペアの形式でリクエスト・ヘッダーを指定します。

        • オプションで、「問合せパラメータの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」-「値」ペアの形式で問合せパラメータを指定します。

        • 「資格証明」セクションで、「ログ資格証明タイプ」を選択します。REST APIログ収集の資格証明タイプの選択を参照してください。

        • 「次」をクリックします。

      2. 「ログ・エンドポイントの構成」タブ:

        • ログ・リスト・エンドポイントのレスポンスの例を指定します。これは、前のタブで指定したログ・リスト・エンドポイントに対して取得するレスポンスの例です。例:

          { "totalSize": 4, "records": [ {"id": "firstId", "type": "firstType"}, {"id": "secondId", "type": "secondType"} ] }

          前述の例から、JSONパスrecords[*].idをエンドポイントURLで使用できます。JSONパス変数の詳細は、REST APIログ収集の変数を参照してください。

        • 「ログ・エンドポイント名」を入力します。

        • ログ・リスト・エンドポイントへのレスポンス例で識別されるJSONパス・キーを組み込むことで、「ログURL」を作成してログを定期的に収集します。「エンドポイントURLのタイプ」「ログ・エンドポイントURL」を参照してください。例:

          https://example.org/fetchLogs?time={START_TIME}&id={testLogListEP:$.records[*].id}
        • オプションで、「ログ・プロキシ・サーバーのURL」を指定します。

        • APIメソッドGETまたはPOSTを選択します。

          POSTを選択した場合は、メソッドのPOSTペイロードを入力し、JSONTextJavascriptHTMLおよびXMLからリクエスト・コンテンツのタイプを選択します。

        • オプションで、「ログ・プロキシ・サーバーのURL」を指定します。

        • オプションで、「リクエスト・ヘッダーの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」-「値」ペアの形式でリクエスト・ヘッダーを指定します。

        • オプションで、「問合せパラメータの表示」をクリックしてセクションを展開し、「追加」をクリックして、「名前」-「値」ペアの形式で問合せパラメータを指定します。

        • 「資格証明」セクションで、「ログ資格証明タイプ」を選択します。REST APIログ収集の資格証明タイプの選択を参照してください。

        • 「次」をクリックします。

      3. 「レビューおよび追加」タブ: 前のタブで提供された構成情報が検証されます。ログの収集元のURLのリストを確認します。

        エラーがある場合は修正します。

        「保存」をクリックします。

  8. 「ソースの作成」をクリックします。

エンドポイントURLのタイプ

ログ・リスト・エンドポイントURL: ログ・リスト・エンドポイントURLは、ログを収集するためのログ・エンドポイントURLのリストを作成するために使用できる情報を含むJSONレスポンスを返す必要があります。JSONレスポンスからログ・エンドポイントのリストを作成するために必要なJSONパス変数を指定します。さらに、マクロ{START_TIME}および{CURR_TIME}を使用して、対応する時間値をURLに動的に挿入できます。

ログ・エンドポイントURL: ログ・エンドポイントURLは、特定のREST APIエンドポイントから定期的にログを収集するために使用されます。マクロ{START_TIME}{CURR_TIME}および{TIME_WINDOW}を使用して、対応する時間値をURLに動的に挿入できます。{OFFSET}マクロを使用してページ区切りをサポートできます。ログ・リスト・エンドポイント・コールのレスポンスからJSONパス変数を使用して、特定のプロパティを置換することもできます。

  • {START_TIME}: ログを収集する必要がある時間を指定するには
  • {OFFSET}: ページ区切りのログ収集を処理するため
  • {CURR_TIME}: 現在の時間を指定します
  • {TIME_WINDOW}: 収集間隔または期間を指定するには

マクロの使用の詳細は、START_TIME MacroCURR_TIME MacroOFFSET MacroおよびTIME_WINDOW Macroを参照してください。

ログ・エンドポイントURLに指定できるログ・リスト・エンドポイント・レスポンスの変数、JSONパスの例および変数フィルタの使用の詳細は、REST APIログ収集の変数を参照してください。

START_TIMEマクロ

START_TIMEマクロを使用して、ログを収集する必要がある時間を指定します。START_TIMEマクロは、エンドポイントURL、フォーム・パラメータまたはPOSTペイロードで使用できます。

次の例は、START_TIMEマクロで指定されたタイムスタンプより大きいログを収集するエンドポイントURLを示しています:

https://example.org/fetchLogs?sortBy=timestamp&sortOrder=ascending&filter=timestamp+gt+{START_TIME:yyyy-MM-dd'T'HH:mm:ss.SSSZ}

構文:

{START_TIME<+nX>:<epoch | timestamp format supported by SimpleDateFormat java class>.TZ=<timezone name>}
  • nは、日付範囲の時間値です。Xは、日(D)、時間(h)、分(m)、月(M)、年(Y)で表されます。

  • +nXは、開始時間に追加する日数、時間数、分数、月数または年数です。これはオプションです。たとえば、+3Dです。

  • サポートされている時間書式は、javaクラスSimpleDateFormatと同じです。デフォルトの時間書式はyyyy-MM-dd'T'HH:mm:ss.SSSZです。例、 2001-07-04T12:08:56.235-0700

    epochまたは時間書式の指定はオプションです。エポックが指定されている場合、マクロはエポックミリ秒値で置換されます。

    SimpleDateFormatでサポートされているタイムスタンプ書式については、Java Platform Standard Ed. 8: Class SimpleDateFormatを参照してください。

  • TZは、タイムスタンプのタイムゾーンを指定します。エポックがすでに指定されている場合は適用されません。サポートされている形式は、javaクラスTimeZoneの3文字のID (UTCなど)と同じです。

  • このマクロの複数のインスタンスをURLに含めることができます。

  • 次に例を示します。

    1. {START_TIME:yyyy-MM-dd'T'HH:mm:ss.SSS.TZ=UTC}
    2. {START_TIME:epoch}

CURR_TIMEマクロ

CURR_TIMEマクロを使用して、REST APIエンドポイントURL、フォーム・パラメータおよびPOSTペイロードに現在の時間を挿入します。

次の例は、問合せパラメータでCURR_TIMEマクロを使用するエンドポイントURLを示しています:

https://example.org/fetchLogs?sortBy=timestamp&sortOrder=ascending&time={CURR_TIME:yyyy-MM-dd'T'HH:mm:ss.SSSZ}
  • このマクロを使用する書式は、START_TIMEマクロと同じです。

  • このマクロの複数のインスタンスをURLに含めることができます。

OFFSETマクロ

ページ区切りレスポンスを提供するエンドポイント、またはAPIレスポンスでオフセット動作を処理するエンドポイントには、OFFSETマクロを使用します。OFFSETマクロは、REST APIエンドポイントURL、フォーム・パラメータおよびPOSTペイロードで使用して、単一のログ収集サイクルで複数のページまたはチャンクをフェッチできます。

書式: {OFFSET(<start value>, <increment>)}

  • OFFSETマクロは、使用可能なすべてのレコードを取得するために、特定のログ・エンドポイントのページ区切り結果に関するデータを反復的にコールおよび収集するために使用されます。初期REST APIリクエスト・コールは開始値で始まり、後続の各コールでは増分の値によって増分されます。これ以上ログ・エントリが見つからない場合、これらの再帰的索引ベースのコールは停止されます。オフセットは、次の収集サイクルに繰り越されません。各収集サイクルのデフォルトまたは初期値から開始します。

  • 前述の形式では、開始値は索引の初期値であり、デフォルト値は0です。開始値を指定することはオプションです。

    使用可能な値: 0を含む正の整数

  • 前述の形式では、incrementは、後続のコールで開始値に追加する値を指定します。デフォルト値は1です。increment値を指定することはオプションです。

    使用可能な値: 正の整数のみ。除外0

  • このマクロのインスタンスは、URLに1つのみ含めることができます。

次の例は、OFFSETマクロのさまざまな使用方法を示しています。

  • {OFFSET}

    デフォルト値の開始値 = 0、増分 = 1を使用します。

  • {OFFSET(5)}

    start value = 5、increment = 1 (デフォルト)

  • {OFFSET(5,2)}

    start value = 5、increment = 2

次の例は、OFFSETマクロを使用するエンドポイントURLを示しています:

https://example.org/fetchLogs?startIndex={OFFSET(0,1000)}&count=1000

前述の例で、OFFSET(0,1000)は、最初のコールでは開始値が0、次のコールでは1000ずつ増分されることを示します。したがって、OFFSETマクロが解釈される場合、複数のコールのエンドポイントURLは次のようになります。

最初のコール: https://example.org/fetchLogs?startIndex=0&count=1000

2番目のコール: https://example.org/fetchLogs?startIndex=1000&count=1000

TIME_WINDOWマクロ

TIME_WINDOWマクロを使用して、ログを収集する収集間隔を指定します。REST APIエンドポイントURLで使用すると、エージェント収集間隔に関係なく、分、時間または日単位でログをフェッチできます。たとえば、時間ウィンドウが1d (1日)で、エージェント間隔が10分の場合、後続のログ収集は1日後にのみ実行されます。

次の例では、エンドポイントURLでTIME_WINDOW6hとして指定して、ログ収集間隔を6時間設定します。

https://example.org/fetchLogs?timewindow={TIME_WINDOW(6h)}

書式: {TIME_WINDOW(<number><timeunit>)}

前述のフォーマット:

  • number: ゼロより大きい数字。

  • timeunit: 時間の場合はh、日の場合はd、分の場合はm。デフォルト値はd (日)です。

エージェント収集間隔が、指定した時間ウィンドウより短いことを確認してください。TIME_WINDOWマクロは、エンドポイントで1回のみ使用できます。

REST APIログ収集の変数

変数を使用して、ログ・リスト・エンドポイントによるレスポンスの一部として提供された属性を、実行時にログ・エンドポイントのリクエストに動的に置換します。変数は、ログ・エンドポイントのURL、フォーム・パラメータ、POSTペイロードまたはHTTPリクエスト・ヘッダー値で使用できます。

ログ・リスト・エンドポイントへのコールが失敗した場合、依存関係のためにログ・エンドポイントからのログ・メッセージは収集されません。

ログ・エンドポイントの変数の形式:

{<log_list_endpoint_name>:<json path(<filter_field_name>='<value>')>}
  • 前述の形式では、log_list_endpoint_nameはログ・リスト・エンドポイントの名前です。

    フィルタ(<filter_field_name>=<value>)はオプションです。ログ・リスト・エンドポイントのJSONレスポンスからfilter_field_nameに一致する属性のみが取得され、ログ・エンドポイントで使用されます。例:

    https://www.example.com/log/{foo:$.items[*].links[*].href(rel='self')}

    フィルタの詳細な例は、フィルタの例を参照してください。

  • プロパティ値のフェッチがサポートされるのは、JSONコンテンツ・タイプのみです。

  • 同じ変数を複数回指定できます。

  • 変数は有効なリスト・エンドポイントのみを参照でき、ログ・エンドポイントは参照できません。

  • 次のJSONパス形式がサポートされています: 単純なJSONパス配列JSONパスおよび複数の配列JSONパス

単純なJSONパス

JSONレスポンスに複数のレベルのネストされた要素がある場合は、ノードとその後続の子ノードへの接続の特別な表記としてJSONパスを指定できます。

次の例では、JSONパス$.foo.abcを使用して、出力としてresultを取得します:

{
    "foo" : 
    {
        "abc" : "result"
    }
}

次の例では、JSONパス$.*.idを使用して["id1", "id3"]出力を取得するか、$.*.*を使用して出力["id1", "id2", "id3"]を取得します:

{
    "foo" : {
        "id" : "id1"
    },
    "foo2" : {
        "ID" : "id2",
        "id" : "id3"
    }
}

次の例では、JSONパス$.foo.*を使用して出力["id1", "value1"]を取得します:

{
    "foo" : {
        "id" : "id1",
        "abcd" : "value1"
    },
    "foo2" : {
        "id" : "id2"
    }
}

配列JSONパス

JSONレスポンスにデータの抽出元となるオブジェクトの配列がある場合は、配列オブジェクトの名前を指定し、[]を使用してその配列オブジェクト内の適切な要素を抽出します。たとえば、次のJSONレスポンスには、オブジェクトrecordsおよびitemの2つの配列があります:

{
     "records": [
         {"id": "firstId", "type":"firstType"},
         {"id":"secondId", "type":"secondType"}
     ],
     "items": [
         {"name":"firstName", "field":"value"},
         {"name":"secondName", "field":"value"},
         {"name":"thirdName", "field":"value"}
     ]
}
  • JSONパス$.records[0].idを指定してfirstIdを出力としてフェッチし、$.records[1].idを指定してsecondIdを出力としてフェッチするか、$.records[*].idを指定してすべてのJSONオブジェクトからidをフェッチします。最後のケースでは、出力は文字列["firstId", "secondId"]のリストです。

  • ()を使用して、JSONパスに条件を指定することもできます。前述の例では、typefirstTypeであるrecordsのみからidをフェッチするには、JSONパス$.records[*].id(type='firstType')を使用します。

複数の配列JSONパス

次の例を考えます:

ログ・リスト・エンドポイントURL getlistの場合:

https://www.example.com/url_list

ログ・リスト・エンドポイントへのJSONレスポンス:

{
  "records": [ { "id": "firstId", "type": "firstType" }, { "id": "secondId", "type": "secondType" } ],
  "items": [ { "name": "firstName", "field": "value" }, { "name": "secondName", "field": "value" }, { "name": "thirdName", "field": "value" } ]
}

ログ・エンドポイントURL (getlistの変数を参照):

https://www.example.com/{getlist:$.records[*].id}/{getlist:$.items[*].name}

変数{getlist:$.records[*].id}および{getlist:$.items[*].name}を使用すると、エージェントは、2つの配列フィールド["firstId", "secondId"]および["firstName", "secondName", "thirdName"]のすべての組合せを含む次のログ・エンドポイントを生成します:

  • https://www.example.com/firstId/firstName

  • https://www.example.com/secondId/firstName

  • https://www.example.com/firstId/secondName

  • https://www.example.com/secondId/secondName

  • https://www.example.com/firstId/thirdName

  • https://www.example.com/secondId/thirdName

フィルタの例

ログ・リスト・エンドポイントfooからの次のJSONレスポンスについて考えてみます:

{
    "items": [
        {
            "BusinessEventCode": "JournalBatchApproved",
            "CreationDate": "2019-07-27T17:19:19.261+00:00",
            "links": [
                {
                    "rel": "self",
                    "href": "/erpBusinessEvents/self/100100120766717"
                },
                {
                    "rel": "canonical",
                    "href": "/erpBusinessEvents/rel/100100120766717"
                }
            ]
        }
    ]
}

ここで、次のログ・エンドポイントの例を検討します:

https://www.example.com/log/{foo:$.items[*].links[*].href(rel='self')}

前述の例では、パス・パラメータは、ログ・リスト・エンドポイントfooのJSONレスポンスの配列要素$.items[*].links[*].hrefに置き換えられ、rel='self'のみを選択するための追加条件が指定されています。

前述のJSONレスポンスの場合、エージェントは次のログ・エンドポイントを生成します:

https://www.example.com/log/erpBusinessEvents/self/100100120766717

REST APIログ収集の資格証明タイプの選択

エージェントとREST APIソース間の接続を認可するには、最初にエージェントの資格証明ストアでAPI資格証明を構成します。エージェント側で管理エージェント・サービスでソース資格証明を構成した後、REST APIログ・ソースの作成時にこの情報を使用できます。

管理エージェントがログ出力ホストからデータを収集できるように、管理エージェント・サービスでソース資格証明を構成するには、管理エージェントのソース資格証明を参照してください。

ログ・エンドポイントまたはログ・リスト・エンドポイントを追加するときに、「ログ資格証明タイプ」を選択して、ワークフローに資格証明情報を指定します。次のいずれかのオプションを選択します。

  • なし
  • 基本認証: 管理エージェント・サービスで作成した資格証明のログ資格証明名を指定します。
  • 静的トークン: 管理エージェント・サービスで作成した資格証明のログ資格証明名を指定します。
  • 動的トークン(OAuth 2.0):

    管理エージェント・サービスで作成したトークンのトークン資格証明名を指定します。また、「トークン・エンドポイント名」「トークン・エンドポイントURL」「付与タイプ」、オプションで「スコープ」などのトークン情報を指定します。

    トークン・プロキシがログ・エンドポイントのものと同じ場合は、「ログ・エンドポイントと同じプロキシ」チェック・ボックスを有効にしたままにします。そうでない場合は、チェック・ボックスを無効にし、「トークン・プロキシ・サーバーURL」を指定します。

認証タイプへの資格証明タイプのマッピング:

認証タイプ 管理エージェントでの資格証明タイプ 資格証明プロパティ
Basic認証 HTTPSBasicAuthCreds HTTPSUserName, HTTPSPassword
HTTPSCreds HTTPSUserName、HTTPSPassword、sslトラストストアのプロパティ
静的トークン HTTPSTokenCreds HTTPSToken、HTTPSTokenType、sslトラストストア・プロパティ(オプション)
動的トークン HTTPSBasicAuthCreds HTTPSUserName, HTTPSPassword
HTTPSCreds HTTPSUserName、HTTPSPassword、sslトラストストアのプロパティ

ssl truststoreプロパティには、次の情報が含まれています。

  • "ssl_trustStoreType": ストアのタイプ。例: JKS

  • "ssl_trustStoreLocation": トラスト・ストアのパス

  • "ssl_trustStorePassword": トラスト・ストア・パスワード(オプション)

資格証明JSONの属性に関する次の側面に注意してください:

  • source: 値はlacollector.la_rest_apiである必要があります

  • name: 資格証明に適した名前

  • type: これは、前述の資格証明タイプ表の「管理エージェントでの資格証明タイプ」列で指定された値のいずれかである必要があります。

資格証明JSONの例を参照してください。

資格証明JSONの例

信頼できるホストを使用するHTTPSを介したユーザー名とパスワードを使用した基本認証の例:

{
  "source":"lacollector.la_rest_api",
  "name":"ExampleRestAPICreds",
  "type":"HTTPSBasicAuthCreds",
  "description":"These are HTTPS (BasicAuth) credentials.",
  "properties":
  [
    { "name":"HTTPSUserName", "value":"CLEAR[admin]" },
    { "name":"HTTPSPassword", "value":"CLEAR[myPassword]" }
  ]
}

証明書を明示的に指定することによるSSL証明書、ユーザー名およびHTTPSを介したパスワードを使用したBasic認証の例:

{
  "source":"lacollector.la_rest_api",
  "name":"ExampleRestAPICreds",
  "type":"HTTPSCreds",
  "description":"These are HTTPS (BasicAuth) credentials.",
  "properties":
  [
    { "name":"HTTPSUserName", "value":"CLEAR[admin]" },
    { "name":"HTTPSPassword", "value":"CLEAR[myPassword]" },
    { "name":"ssl_trustStoreType", "value":"JKS" },
    { "name":"ssl_trustStoreLocation", "value":"/scratch/certs/mycert.keystore" },
    { "name":"ssl_trustStorePassword", "value":"mySSLPassword" }
  ]
}

token over HTTPSとトラステッドホストの例:

{
  "source":"lacollector.la_rest_api",
  "name":"ExampleRestAPICreds",
  "type":"HTTPSTokenCreds",
  "description":"These are HTTPS (Token) credentials.",
  "properties":
  [
    { "name": "HTTPSToken", "value": "CLEAR[token value]" },
    {"name": "HTTPSTokenType", "value": "CLEAR[Bearer]" }
  ]
}

明示的に指定された証明書を使用したHTTPS経由のトークンの例:

{
  "source":"lacollector.la_rest_api",
  "name":"ExampleRestAPICreds",
  "type":"HTTPSTokenCreds",
  "description":"These are HTTPS (Token) credentials.",
  "properties":
  [
    { "name": "HTTPSToken", "value": "CLEAR[token value]" },
    {"name": "HTTPSTokenType", "value": "CLEAR[Bearer]" },
    { "name":"ssl_trustStoreType", "value":"JKS" },
    { "name":"ssl_trustStoreLocation", "value":"/scratch/certs/mycert.keystore" },
    { "name":"ssl_trustStorePassword", "value":"mySSLPassword" }
  ]
}