Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация
В среду, 29 января 2014 г., мы выпустили новую локальную версию Apigee Edge.
Если у вас есть вопросы, обратитесь в службу поддержки клиентов Apigee .
Этот выпуск содержит функции и исправления ошибок из следующих облачных выпусков:
Новые функции и улучшения
- OAuth 2.0 обновляет пользовательские атрибуты токенов
Новая политика «Установить информацию OAuth v2.0» позволяет обновлять пользовательские атрибуты токенов OAuth 2.0.
http://apigee.com/docs/api-services/content/set-oauth-tokens-attributes-using-setoauthv2info - Обновления политики OAuth 1.0a
Этот выпуск включает следующие обновления политики OAuth 1.0a:- Как и в случае с токенами OAuth 2.0, теперь вы можете устанавливать собственные атрибуты для токенов OAuth 1.0a.
- Новая операция GenerateVerifier позволяет генерировать и возвращать верификатор OAuth 1.0a (аналогично коду авторизации в OAuth 2.0).
- Информация SSL в переменных потока
Apigee Edge теперь позволяет распространять и получать доступ к информации SSL в переменных потока. Установив новое свойство propagate.additional.ssl.headers для ProxyEndpoint, вы получите доступ к той же информации SSL, что и на веб-сервере Apache.
http://apigee.com/docs/api-services/api/variables-reference - Заголовки JMS как заголовки HTTP
Все заголовки JMS теперь распространяются как заголовки HTTP для последующей обработки. - Обновление модуля Node.js
Встроенный модуль Node.js Apigee был обновлен и теперь включает следующие модули: argo 0.4.9, async 0.2.9, express 3.4.8, подчеркивание 1.5.2, usergrid 0.10.7, volos-cache-memory 0.0.3. , волос-oauth-apigee 0.0.2, волос-квота-apigee 0.0.2. - Пользовательские роли в пользовательском интерфейсе управления – БЕТА
В дополнение к существующим пользовательским ролям «Бизнес-пользователь», «Администратор операций», «Администратор организации» и «Пользователь» этот выпуск включает бета-функцию, которая позволяет создавать собственные роли в пользовательском интерфейсе управления. Вы можете контролировать доступ к различным функциям Edge, используя настраиваемые роли. - Установщик Advanced API Services (ранее App Services)
Службы API Apigee Edge Advanced API (ранее — Службы приложений) теперь доступны для локального использования. Существующий установщик Edge позволяет развертывать и настраивать расширенные службы API в вашей собственной локальной среде. - Установщик монетизации Developer Services (ранее Monetization Services)
Возможность монетизации является частью Edge Developer Services. Локальный установщик Edge теперь включает расширенный интегрированный установщик монетизации. Для монетизации необходима дополнительная платная лицензия. - Несколько процессоров сообщений на одном хосте – автоматическая установка
Это усовершенствование поддерживает топологию развертывания нескольких процессоров сообщений, установленных на одном хосте, что требует привязки каждого процессора сообщений к определенному IP-адресу. Теперь вы можете добавить параметр свойстваBIND_ON_ALL_INTERFACES=n
в файл конфигурации автоматической установки, который заставляет обработчик сообщений прослушивать определенный IP-адрес, указанный свойствомHOSTIP
в том же файле. Дополнительные сведения об этом свойстве и о настройке автоматической установки см. в Руководстве по установке и настройке Apigee On-premises Deployment Kit . - Обновления JMS
Этот выпуск включает в себя различные обновления поддержки Apigee JMS, в том числе:- Все заголовки JMS теперь распространяются как заголовки HTTP для последующей обработки.
- Теперь вы можете указать ExpiryTime и DeliveryMode для сообщений, помещенных в ResponseQueue, используемых прокси-сервером JMS. Все заголовки HTTP, соответствующие стандартным заголовкам JMS, устанавливаются «как есть», а другие заголовки HTTP устанавливаются как свойства JMS в ответном сообщении, используемом прокси-сервером JMS.
Исправлены ошибки
Тема | Описание |
---|---|
Разрешения настраиваемых ролей | Разрешения, установленные с использованием пользовательских ролей, теперь работают должным образом. |
Аналитика задержки API | В потоке прокси-сервера API, когда вызов целевой системы приводит к тайм-ауту (например, тайм-ауту чтения HTTP), целевое время задержки включается в аналитику API. |
Атрибут «тип» в политиках | Атрибут «type» теперь правильно работает во всех политиках Apigee. |
OAuth 2.0 делает недействительными токены | Функциональность аннулирования токенов для политик Apigee OAuth 2.0 теперь соответствует спецификации OAuth. Вам больше не требуется указывать «тип» при настройке параметра «токен». |
RBAC с картами ключ/значение | Управление доступом на основе ролей теперь работает для карт «ключ-значение», созданных на уровне среды. |
Формат ответа политики OAuth 1.0a | При отправке запросов к API с политикой OAuth 1.0a ответ теперь возвращается в формате заголовка Accept. |
Известные проблемы
Тема | Описание |
---|---|
HTTP-запрос 1.0, Ответ HTTP 1.1 | Эта проблема связана со сценарием, в котором клиент отправляет запрос с использованием HTTP 1.0 со свойством content-length в заголовке, но серверная служба настроена на использование HTTP 1.1 и вместо этого возвращает свойство transfer-encoding для фрагментированного кодирования. Чтобы успешно справиться с этим сценарием, вы можете удалить свойство transfer-encoding из ответа HTTP 1.1 с помощью политики AssignMessage. В следующей политике, которая будет прикреплена к потоку ответов прокси-сервера API, свойство transfer-encoding удаляется из заголовка HTTP, что позволяет клиенту получать ответ без фрагментов. <AssignMessage name="RemoveChunkedEncoding"> <AssignTo createNew="false" type="response"></AssignTo> <Удалить> <Заголовки> <Header name="Transfer-Encoding"/> <Header name="transfer-encoding"/> </Заголовки> </Удалить> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </AssignMessage> |