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 メッセージが実行時に適切にフォーマットされるように回避策を講じる必要が生じることがありました。たとえば、バックスラッシュ「\"」でペイロードを開始する、ペイロード要素で 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 コールアウト 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

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

修正済みのバグ

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

問題 ID 説明
SECENG-609 関連するトラストストアの削除時、またはトラストストア内の有効な証明書が削除されても、ランタイム呼び出しが失敗しない
MGMT-3404 Node.js ログの表示/取得とプロキシのデプロイが非常に遅い
MGMT-3400 /userroles の管理 API の呼び出しが失敗する(呼び出しを行うユーザーの名前に「+」記号が含まれている場合)
MGMT-3368 java.lang.ArrayIndexOutOfBoundsException: 1(resources/node/resources ディレクトリを含む API プロキシ バンドルをインポートする場合)
MGMT-3364 OAuthV2: redirect_uri チェック
MGMT-3319 Vault 内のエントリのいずれかに null 値が含まれているエントリが、組織(CPS と CPS 以外)で機能しない
MGMT-3226 組織/環境レベルでクエリを実行しても、すべてのデータを pull できず、API が失敗する
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 デプロイでのルーターの「通話タイムアウト」エラー
APIRT-2975 証明書バンドルのアップロード失敗
APIRT-2955 FHIR 申し立ての Content-Type ヘッダー「application/json+fhir」で JSON レスポンス データの特定の属性をマスクできない
APIRT-2946 display が false に設定されているにもかかわらず、OAuthV2-RefreshToken ポリシーで属性が非表示にならない
APIRT-2908 virtualhost での TLS1.2 更新後、内部 API 呼び出しに対して TLS1.2 の適用が必要
APIRT-2901 キャッシュから返された gzip により圧縮されたレスポンスが二重圧縮される
APIRT-2873 プロダクト、デベロッパー、プロキシを削除した後、MP が VerifyAPIKey に関連する NullPointerException をスローする
APIRT-2871 IOIntensive ポリシーが Trace に 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 変換ポリシーがデータをログに記録していないと思われる
APIRT-2364 OAuth 障害フロー変数がエラーで更新されない
APIRT-2216 サーバーから送信されたイベント - 本番環境でイベント ストリームに問題が発生した
APIRT-2079 作成されたセッションのタイムアウト時間が経過しても DEBUG cURL 呼び出しが停止しない
APIRT-1495 XML Threat Protection が Content-Type をキャッチしない
APIRT-347 インポート時に XSL ポリシーが適切に検証されない(ドキュメントに記載されているように、結果が出力変数に割り当てられない)