Você está visualizando a documentação do Apigee Edge.
Acesse a
documentação da
Apigee X. info
Na terça-feira, 29 de abril de 2014, lançamos uma nova versão na nuvem do Apigee Edge.
Novos recursos e melhorias
Confira a seguir os novos recursos e as melhorias desta versão.
- Painéis de análise
Agora, o Edge oferece novos relatórios de Análises de desempenho do endpoint, desempenho do proxy de API e desempenho do cache para ajudar a monitorar a performance.
Consulte "Os painéis de operações" em Painéis do Google Analytics. - Agregação de métricas personalizadas para performance
Este recurso não está mais disponível.
O novo recurso de agregação personalizada melhora a performance da análise, permitindo que você defina métricas personalizadas que o Edge coleta e armazena à medida que as chamadas de API são feitas. Quando você consulta relatórios, o Edge acessa as métricas agregadas já disponíveis em vez de buscá-las em tempo real. - OAuth 2.0 preconfigurado em proxies de API
Ao criar um proxy de API, uma nova opção "Proteger com tokens de acesso do OAuth v2.0" configura automaticamente o proxy de API com políticas que oferecem suporte ao OAuth.
Consulte OAuth. - Mascareamento de dados no rastreamento
O recurso da API /maskconfigs permite mascarar dados sensíveis, como informações de cartão de crédito, em sessões de rastreamento de proxy de API, ajudando a garantir a segurança dos dados do usuário durante o desenvolvimento da API.
Caso:810723
Consulte Como mascarar e ocultar dados. - Política de autenticação básica
A política de autenticação básica permite adicionar a autenticação básica leve a um proxy de API, fornecendo codificação Base64 automática das credenciais do usuário e preenchimento do cabeçalho HTTPAuthorization: Basic
.
Consulte a política de autenticação básica. - PostClientFlow
O PostClientFlow permite adicionar políticas do MessageLogging que são executadas depois que a resposta é enviada. Isso reduz a latência do proxy da API e disponibiliza informações para geração de registros que não são calculadas até que a resposta seja enviada, como client.sent.start.timestamp e client.sent.end.timestamp.
Caso: 814059
Bugs corrigidos
Os bugs abaixo foram corrigidos nesta versão.
Tópico | Descrição |
---|---|
Validação do nome do relatório personalizado | O Edge agora valida os nomes de relatórios personalizados para impedir o uso de caracteres especiais. |
Informar problemas com o detalhamento de developer_app | Apps de desenvolvedor incorretos estavam sendo retornados em relatórios personalizados que usavam o detalhamento de developer_app. Esse problema foi corrigido. |
O período não funciona em relatórios personalizados | Nos relatórios personalizados que continham filtros com várias expressões entre parênteses, como (request_verb eq 'POST') or (request_verb eq
'GET') , a alteração do período do relatório não afetava os resultados. Esse problema
foi corrigido.Caso: 810753 |
Gráficos não aparecem em relatórios personalizados | Correção de um problema com gráficos que não apareciam em relatórios personalizados. Caso: 814623 |
Importação de WSDL |
|
Configuração da política de limite de taxa simultânea | O seletor de endpoint de destino agora está disponível apenas ao adicionar uma política de limite de taxa simultânea a um proxy de API. O endpoint de destino não se aplica a outras políticas. |
Suporte da empresa para desenvolvedores | Para organizações com empresas ativadas, agora é possível especificar uma empresa ao
criar ou editar um desenvolvedor. Caso: 515246 |
Exportação de desenvolvedores, apps e produtos | Agora é possível exportar desenvolvedores, apps e produtos para um arquivo CSV na página
"Desenvolvedores" da interface de gerenciamento do Edge. No momento, esse recurso não está disponível para organizações
que têm a monetização ativada. Caso: 747159 |
A janela "Apps para desenvolvedores" trava. | Depois que um desenvolvedor excluiu um app no portal do desenvolvedor do Edge, clicar nesse app na IU de gerenciamento do Edge fazia com que a janela travasse. Esse problema foi corrigido. |
Comentários em uma configuração de proxy da API | Os comentários em uma configuração de proxy de API agora aparecem na visualização de código do editor de proxy da API e no Property Inspector. |
Proxies de API criados com nomes inválidos | A interface de gerenciamento do Edge permitia a criação de proxies de API com nomes que continham caracteres especiais sem suporte, resultando em proxies inválidos que não podiam ser excluídos. Os nomes de proxy de API agora são validados no momento da criação. Apenas caracteres alfanuméricos, "-" e
"_" são permitidos. Caso: 550390 |
Diferenciação entre maiúsculas e minúsculas na nomenclatura de proxy de API | O Edge estava criando proxies de API com nomes em letras minúsculas, independentemente do caso digitado. O Edge agora respeita a caixa do nome inserido para o proxy da API. |
Aviso sobre o salvamento do proxy de API | Quando você salva um proxy de API no editor, o Edge implanta o proxy em todos os ambientes em que a revisão está implantada, incluindo ambientes de produção. A interface de gerenciamento do Edge agora mostra um aviso antes de salvar o proxy. |
Papel personalizado sem permissões para salvar no ambiente de produção | Quando uma revisão de API implantada é atualizada, ela aciona uma desinstalação e implantação interna em
ambientes implantados. Um papel personalizado sem as permissões de implantação adequadas conseguiu implantar salvando um proxy de API. Esse problema foi resolvido com a aplicação de permissões de
implantação. Caso: 813084 |
Servidor de destino duplicado | Ao criar um servidor de destino duplicado, em vez de um erro HTTP 409, o Edge substituiu o servidor de destino existente e retornou um status 201. Esse problema foi resolvido com a geração de um erro 409 e a não substituição do servidor de destino atual. |
Não é possível criar sessões de trace para proxies de API | As sessões de rastreamento não estavam sendo criadas para ambientes com processadores de mensagens que
não podiam ser acessados. Esse problema foi resolvido anexando sessões de rastreamento apenas aos
processadores de mensagens acessíveis e disponíveis Caso: 812192 |
Comportamento atualizado de JMSReplyTo | Por padrão, o Edge envia a resposta para a fila especificada no cabeçalho JMSReplyTo.
No entanto, se você quiser que o serviço de back-end processe o envio da resposta para a fila JMSReplyTo
em vez do Edge, adicione o cabeçalho X-Apigee-Ignore-JMSResponse à resposta do proxy da API
em qualquer fluxo e defina-o como verdadeiro:<Header name="X-Apigee-Ignore-JMSResponse">true</Header> |
Erros de gateway incorreto CLOSE_WAIT e 502 altos | Um problema que causava métricas altas de CLOSE_WAIT e erros 502 de gateway incorretos foi
corrigido. Casos: 814656, 814664, 814670 |
Diretório temporário do Node.js | Quando um script Node.js é implantado no Edge, ele é executado em um sandbox que restringe o acesso do sistema de arquivos a um determinado diretório. No entanto, o os.tmpdir retorna um nome de diretório como /tmp ou /var/tmp, que não existia no sandbox do Node.js do Edge, fazendo com que alguns scripts fossem interrompidos. O sandbox do Node.js do Edge agora inclui um diretório /tmp para uso do os.tmpdir. |
Exceções de ponteiro nulo em chamadas de API | Na política Atribuir mensagem, um status de resposta nulo gerou uma exceção de ponteiro nulo, porque
o Edge tentou capturar o código de resposta para métricas. Esse problema foi corrigido. Caso: 815595 |