現在、Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントをご確認ください。 情報
2016 年 8 月 30 日(火)、Apigee Edge for Public Cloud の新しいバージョンをリリースしました。
新機能とアップデート
このリリースにおける新機能とアップデートは次のとおりです。
Assign Message と Raise Fault での JSON ペイロード
この機能強化により、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 分間の例の場合は次のようになります。
- まず、3 分後にタイムアウトするようにロードバランサ、ルーター、Message Processor を構成します。
- 次に、3 分でタイムアウトするように関連するプロキシを構成します。値はミリ秒単位で指定します。次に例を示します。
<ProxyEndpoint name="default"> <HTTPProxyConnection> <BasePath>/v1/weather</BasePath> <Properties> <!-- api.timeout is in milliseconeds --> <Property name="api.timeout">180000</Property> </Properties> ...
- ただし、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 ポリシーが適切に検証されない(ドキュメントに記載されているように、結果が出力変数に割り当てられない) |