Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info
Во вторник, 29 апреля 2014 года, мы выпустили новую облачную версию Apigee Edge.
Новые функции и улучшения
Ниже перечислены новые функции и улучшения в этом выпуске.
- Панели мониторинга аналитики
Теперь Edge предоставляет новые аналитические отчеты по производительности конечных точек, производительности API-прокси и производительности кэша, которые помогут вам отслеживать производительность.
См. раздел «Панели мониторинга операционной деятельности» в панели мониторинга аналитики . - Агрегация пользовательских метрик для оценки производительности
Эта функция больше недоступна.
Новая функция пользовательской агрегации повышает производительность аналитики, позволяя определять собственные метрики, которые Edge собирает и сохраняет при выполнении вызовов API. При просмотре отчетов Edge обращается к уже имеющимся агрегированным метрикам, а не получает их на лету. - Предварительно настроенный OAuth 2.0 в API-прокси
При создании API-прокси новая опция «Защищено с помощью токенов доступа OAuth v2.0» автоматически настраивает API-прокси с политиками, поддерживающими OAuth.
См. OAuth . - Маскирование данных в трассировке
Ресурс API /maskconfigs позволяет маскировать конфиденциальные данные, такие как информация о кредитных картах, в сеансах трассировки API-прокси, что помогает обеспечить безопасность пользовательских данных во время разработки API.
Дело: 810723
См. раздел «Маскирование и скрытие данных» . - Политика базовой аутентификации
Политика базовой аутентификации позволяет добавить упрощенную базовую аутентификацию к API-прокси, обеспечивая автоматическое кодирование учетных данных пользователя в формате Base64 и заполнение заголовка HTTPAuthorization: Basic.
См. политику базовой аутентификации . - PostClientFlow
Компонент PostClientFlow позволяет добавлять политики MessageLogging, которые выполняются после отправки ответа. Это уменьшает задержку API-прокси и делает доступной для логирования информацию, которая вычисляется только после отправки ответа, например, client.sent.start.timestamp и client.sent.end.timestamp.
Дело: 814059
Исправлены ошибки
В этом релизе исправлены следующие ошибки.
| Тема | Описание |
|---|---|
| Проверка пользовательских названий отчетов | Теперь Edge проверяет названия пользовательских отчетов, чтобы исключить использование специальных символов. |
| Сообщайте о проблемах с детализацией в приложении разработчика. | В пользовательских отчетах, использующих детализацию developer_app, отображались некорректные приложения разработчиков. Эта проблема исправлена. |
| Временной период не работает в пользовательских отчетах. | В пользовательских отчетах, содержащих фильтры с несколькими выражениями в скобках — например, (request_verb eq 'POST') or (request_verb eq 'GET') — изменение временного периода отчета не влияло на результаты. Эта проблема исправлена.Дело: 810753 |
| Диаграммы не отображаются в пользовательских отчетах. | Исправлена ошибка, из-за которой диаграммы не отображались в пользовательских отчетах. Дело: 814623 |
| импорт WSDL |
|
| Настройка политики ограничения количества одновременных запросов | Теперь селектор целевой конечной точки доступен только при добавлении политики ограничения количества одновременных запросов к API-прокси. Целевая конечная точка не применяется к другим политикам. |
| Поддержка разработчиков со стороны компании | Для организаций, в которых включена возможность указания компаний, теперь можно указывать компанию при создании или редактировании данных разработчика. Дело: 515246 |
| Экспорт разработчиков, приложений и продуктов | Теперь вы можете экспортировать разработчиков, приложения и продукты в CSV-файл со страницы «Разработчики» в пользовательском интерфейсе управления Edge. В настоящее время эта функция недоступна для организаций, у которых включена монетизация. Дело: 747159 |
| Окно приложений разработчика зависает | После удаления приложения разработчиком на портале разработчиков Edge, щелчок по этому приложению в пользовательском интерфейсе управления Edge приводил к зависанию окна. Эта проблема исправлена. |
| Комментарии в конфигурации API-прокси | Комментарии в конфигурации API-прокси теперь отображаются в режиме просмотра кода редактора API-прокси и в инспекторе свойств. |
| API-прокси созданы с недопустимыми именами | Ранее пользовательский интерфейс управления Edge позволял создавать API-прокси, имена которых содержали неподдерживаемые специальные символы, что приводило к созданию недействительных API-прокси, которые невозможно было удалить. Теперь имена API-прокси проверяются при создании. Допускаются только буквенно-цифровые символы, символы «-» и «_». Дело: 550390 |
| Учет регистра при именовании API-прокси | Ранее Edge создавал API-прокси с именами в нижнем регистре, независимо от регистра введенного имени. Теперь Edge учитывает регистр имени, введенного для API-прокси. |
| Предупреждение о сохранении через API-прокси | При сохранении API-прокси в редакторе API-прокси Edge развертывает API-прокси во всех средах, где в данный момент развернута данная версия, включая производственные среды. Теперь пользовательский интерфейс управления Edge выдает предупреждение перед сохранением прокси. |
| Пользовательская роль без разрешений сохраняется в производственной среде. | При обновлении развернутой версии API происходит внутреннее удаление и повторное развертывание в развернутых средах. Пользовательская роль без надлежащих разрешений на развертывание могла быть развернута путем сохранения прокси-сервера API. Эта проблема была решена путем принудительного применения разрешений на развертывание. Дело: 813084 |
| Дубликат целевого сервера | При создании дубликата целевого сервера вместо ошибки HTTP 409 Edge перезаписывал существующий целевой сервер и возвращал статус 201. Эта проблема была решена путем генерации ошибки 409 вместо перезаписи существующего целевого сервера. |
| Не удалось создать трассировочные сессии для API-прокси. | Трассировочные сессии не создавались для сред с недоступными обработчиками сообщений. Эта проблема решена путем прикрепления трассировочных сессий только к доступным и работоспособным обработчикам сообщений. Дело: 812192 |
| JMSReplyTo обновил поведение | По умолчанию Edge отправляет ответ в очередь, указанную в заголовке JMSReplyTo. Однако, если вы хотите, чтобы отправка ответа в очередь JMSReplyTo осуществлялась бэкэнд-сервисом, а не Edge, добавьте заголовок X-Apigee-Ignore-JMSResponse к ответу API-прокси в любом потоке и установите для него значение true:<Header name="X-Apigee-Ignore-JMSResponse">true</Header> |
| Высокий уровень ошибок CLOSE_WAIT и 502 (неверный шлюз). | Исправлена ошибка, вызывавшая высокие значения метрики CLOSE_WAIT и ошибки 502 Bad Gateway. Дела: 814656, 814664, 814670 |
| Временная директория Node.js | Когда скрипт Node.js развертывается в Edge, он запускается в песочнице, которая ограничивает доступ к файловой системе определенным каталогом. Однако os.tmpdir возвращает имя каталога, например, /tmp или /var/tmp, которого не существовало в песочнице Edge Node.js, что приводило к сбоям в работе некоторых скриптов. Теперь песочница Edge Node.js включает каталог /tmp, который может использоваться os.tmpdir. |
| Исключения NullPointerException при вызовах API | В политике назначения сообщений (Assign Message) нулевой статус ответа вызывал исключение NullPointerException, поскольку Edge пытался получить код ответа для метрик. Эта проблема исправлена. Дело: 815595 |