16.08.17 - Apigee Edge for Public Cloud リリースノート

Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントをご確認ください
情報

2016 年 8 月 30 日(火)、Apigee Edge for Public Cloud の新しいバージョンをリリースしました。

新機能とアップデート

このリリースにおける新機能とアップデートは次のとおりです。

Assign Message と Raise Fault での JSON ペイロード

Assign Message ポリシーや Raise Fault ポリシーを使用して JSON ペイロードを設定する場合、実行時に JSON メッセージが適切にフォーマットされるようにする回避策が必要になることがあります。たとえば、メッセージ内で変数が使用されていない場合でも、バックスラッシュ「\」でペイロードを開始する、Payload 要素で variablePrefix と variableSuffix を指定するなど、回避策が必要です。

この機能強化により、適切な JSON メッセージ形式を確保するための回避策は必要なく、無効な JSON を作成することなく、中かっこを使用して変数を指定できます。たとえば、次のコマンドは JSON メッセージに message.content の値を挿入します。

<Payload contentType="application/json">{"message" : "{message.content}"}</Payload>

回避策を使用した場合、コードはそのまま機能します。変数を示すために、中かっこの代わりに variablePrefix と variableSuffix を使用することもできます。

Assign Message ポリシーRaise Fault ポリシーのリファレンス ドキュメントの <Set><Payload> 要素をご覧ください。(APIRT-1160)

XML to JSON ポリシーの拡張

XML to JSON ポリシーが強化され、次の機能が追加されました。このポリシーは次のように構成できます。

  • 一部の XML 要素は変換時に配列として扱います。その場合、JSON ドキュメントでは値が角かっこ「[ ]」で囲まれます。
  • 最終的な JSON ドキュメントで XML ドキュメント階層のレベルを削除または削除します。

詳細については、XML to JSON ポリシーをご覧ください。(APIRT-1144)

API プロダクトのリソースパスで複数のワイルドカードを使用する

API プロダクトでリソースパスを定義する場合、リソースパスの複数の場所にワイルドカードを含めることができます。たとえば、/team/*/invoices/** は、/team の後に任意の 1 つの値を持ち、invoices/ の後に任意のリソースパスを持つ API 呼び出しを許可します。API 呼び出しで許可される URI は proxyBasePath/team/finance/invoices/company/a です。

このリリース後に、既存の API プロダクトのリソースパスが想定どおりに機能しなくなった場合は、組織で次のプロパティを設定して、以前の動作に戻す必要があります。features.enableStandardWildCardMatchForAPIProductResources = true

(MGMT-3273)

JavaScript の暗号関数

新しい高性能 JavaScript crypto 関数セットを使用して、MD5、SHA-1、SHA256、SHA512 のオブジェクトを作成、取得、更新できるようになりました。また、crypto オブジェクトでもさまざまな形式で日付を取得できます。詳細については、JavaScript オブジェクト モデルをご覧ください。(APIRT-2886)

Java Callout JAR バージョン チェック

Java JAR リソースを API プロキシにアップロードすると、Java リソースのバージョンが、サポート対象のソフトウェアおよびサポート対象のバージョンに記載されている Edge のサポート対象バージョンの Java と互換性がない場合、(500 ではなく)HTTP 400 ステータス コードが返されます。(MGMT-3420)

API プロキシ リソースの検証

API プロキシ リソース ファイル(JavaScript や Java JAR など)が環境スコープまたは組織スコープに保存されている場合、検証フレームワークでは、検証に合格するためにそれらのリソースを API プロキシレベルのプロキシ バンドルに追加してインポートする必要がなくなりました。リソースの検証は、インポート時ではなくデプロイ時に行われるようになりました。(MGMT-1430)

個々の API プロキシのタイムアウトを構成する

指定した時間(ゲートウェイ タイムアウト ステータス 504)の経過後にタイムアウトするように API プロキシを構成できます。主なユースケースは、実行に時間がかかる API プロキシを使用している Private Cloud のお客様です。たとえば、3 分でタイムアウトするように特定のプロキシが必要だとします。API プロキシの構成で新しい api.timeout プロパティを使用できます。3 分間の例の場合は次のようになります。

  1. まず、3 分後にタイムアウトするようにロードバランサ、ルーター、Message Processor を構成します。
  2. 次に、関連するプロキシが 3 分でタイムアウトになるように構成します。値はミリ秒単位で指定します。次に例を示します。
    <ProxyEndpoint name="default">
      <HTTPProxyConnection>
        <BasePath>/v1/weather</BasePath> 
        <Properties> 
          <!-- api.timeout is in milliseconeds -->
          <Property name="api.timeout">180000</Property>
        </Properties>
        ...
    
  3. ただし、api.timeout を設定していないプロキシはすべて、新たに設定されたより高いロードバランサ、ルーター、Message Processor のタイムアウトを使用するため、システムのタイムアウト値を引き上げると、パフォーマンスの問題が発生する可能性があります。そのため、より長いタイムアウトを必要としない他の API プロキシを構成して、より短いタイムアウトを使用します。たとえば、次の例では 1 分後にタイムアウトするように API プロキシを設定します。
    <Property name="api.timeout">60000</Property>

Edge のタイムアウトを変更できない Cloud のお客様は、タイムアウトが標準の Edge Message Processor のタイムアウトである 57 秒より短くなれば、API プロキシのタイムアウトも構成できます。

値に変数を入力することはできません。このプロパティについては、エンドポイント プロパティのリファレンスをご覧ください。(APIRT-1778)

メッセージ ロギング ポリシーの TLS/SSL

<KeyStore><TrustStore> は、Message Logging ポリシーSSLInfo 構成で設定できます。これにより、ロギング サービスによる一方向および双方向の TLS/SSL が許可されます。Message Logging ポリシーの SSLInfo は、プロキシの TargetEndpoint の場合と同じように構成します。ただし、Message Logging の TLS/SSL は TCP プロトコルのみをサポートします。(APIRT-1858)

修正済みのバグ

このリリースでは以下のバグが修正されています。このリストは、サポート チケットの修正状況を確認するユーザーを主に対象としています。すべてのユーザーに詳細情報を提供することを目的としたものではありません。

問題 ID 説明
SECENG-609 関連するトラストストアの削除中、またはトラストストア内の有効な証明書が削除されても、ランタイム呼び出しが失敗しない
MGMT-3404 Node.js ログの表示と取得、プロキシのデプロイに非常に時間がかかる
MGMT-3400 /userroles management API の呼び出しが失敗すると、呼び出しを行うユーザーの名前に「+」記号が含まれていると失敗する
MGMT-3368 java.lang.ArrayIndexOutOfBoundsException: 1(resources/node/resources ディレクトリを含む API プロキシ バンドルをインポートする場合)
MGMT-3364 OAuthV2: redirect_uri チェック
MGMT-3319 いずれかのエントリに null 値を持つ Vault のエントリが組織(CPS と CPS 以外)で機能しない
MGMT-3226 組織/環境レベルでクエリを実行すると、API が失敗する原因となるデータがすべて pull されないようにする
Release_160302 には、リソースの累積サイズが 16 MB を超えると組織レベル/環境レベルでリソースを一覧表示できないバグがあり、この修正で対応します。
AXAPP-2429 response_status_code を使用する Analytics API がデータアクセス エラーを返す
AXAPP-2386 アナリティクスの日次メールレポートの空のレポート コンテンツを修正する
AXAPP-2347 日次分析のサマリー メールが届かない
APIRT-3141 コンストラクタが非公開になっているため、新しい ExecutionResult() を呼び出すと Java コールアウトが失敗する
APIRT-3140 HEAD API 呼び出しで ServiceCallout ポリシーが機能しない
APIRT-3131 外部認証プロバイダで収益化を使用する場合に、API プロキシで createdBy が正しく表示されない
APIRT-3121 組織のリソース ファイルの変更が 100% 有効ではない
APIRT-3117 MP が CPU 使用率 100% に達し、トラフィックの処理が停止した
APIRT-3016 デプロイ時にルーターの「Call timed out」エラーが表示される
APIRT-2975 証明書バンドルをアップロードできない
APIRT-2955 FHIR 苦情 Content-Type ヘッダー「application/json+fhir」の JSON レスポンス データの特定の属性をマスクできない
APIRT-2946 display を false に設定しても OAuthV2-RefreshToken ポリシーで属性が非表示にならない
APIRT-2908 仮想ホストの TLS1.2 アップデート後に、内部 API 呼び出しに TLS1.2 を適用する必要があります
APIRT-2901 キャッシュから返された Gzip 圧縮されたレスポンスは二重圧縮されている
APIRT-2873 プロダクト、デベロッパー、プロキシを削除した後、MP が VerifyAPIKey に関連する NullPointerException をスローする
APIRT-2871 Trace に IOIntensive ポリシーが 2 回表示される
APIRT-2825 accesstoken のエラー レスポンスの文法エラー
APIRT-2750 特定の組織でトラフィック障害が多い
APIRT-2685 不明なエラーがスローされてトラフィックが流れない
APIRT-2647 nonprod/dev で「基盤となる入力ストリームがゼロバイトを返しました」エラー
APIRT-2630 キャッシュから値を読み取ろうとすると断続的に発生する問題
APIRT-2620 一部のブロッキング ステップ用に個別のスレッドプール
APIRT-2610 Response Cache ポリシーを含む java.lang.ClassCastException
APIRT-2608 Response Cache ポリシーでの Last-Modified ヘッダーの解析エラー
APIRT-2605 「organization」および「environment」変数は、ポリシーによる上書きを許可すべきではない
APIRT-2566 OAuthV2 ポリシーで不正な形式の WWW-Authenticate ヘッダーが返される
APIRT-2491 管理と mps の間の RPC タイムアウトのため、TargetServer を更新できませんでした
APIRT-2386 許可された OAuth スコープが空の API プロダクトで、空の文字列スコープが作成される
APIRT-2383 エラー発生時に XSL Transformation ポリシーでデータがログに記録されていないように見える
APIRT-2364 エラー時に OAuth 障害フロー変数が更新されない
APIRT-2216 サーバー送信イベント - 本番環境で問題があるイベント ストリーム
APIRT-2079 作成したセッションのタイムアウト時間が経過しても DEBUG cURL 呼び出しが停止しない
APIRT-1495 XML Threat Protection が Content-Type をキャッチしない
APIRT-347 XSL ポリシーがインポート時に正しく検証されない(ドキュメントに記載されているように結果を出力変数に割り当てない)