Você está lendo 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
O Edge agora oferece novos relatórios de performance de endpoint, performance de proxy de API e análise de performance de cache para ajudar você a monitorar a performance.
Consulte "Os painéis de operações" em Painéis de análise. - Agregação de métricas personalizadas para performance
Esse recurso não está mais disponível.
Um 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. Ao visualizar relatórios, o Edge acessa as métricas agregadas já disponíveis em vez de buscá-las na hora. - OAuth 2.0 pré-configurado 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. - Mascaramento de dados no trace
O recurso de API /maskconfigs permite mascarar dados sensíveis, como informações de cartão de crédito, em sessões de trace de proxy de API, ajudando a garantir a segurança dos dados do usuário durante o desenvolvimento de APIs.
Caso:810723
Consulte Mascaramento e ocultação de 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 de credenciais do usuário e preenchimento do cabeçalho HTTPAuthorization: Basicheader.
Consulte Política de autenticação básica. - PostClientFlow
O PostClientFlow permite adicionar políticas MessageLogging que são executadas após o envio da resposta. Isso reduz a latência do proxy de API e disponibiliza informações para a 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 caracteres. |
| Problemas de relatório com detalhamento de developer_app | Apps de desenvolvedores 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 | Em relatórios personalizados que continham filtros com várias expressões entre parênteses
—por exemplo, (request_verb eq 'POST') or (request_verb eq
'GET')—a mudança 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 | Um problema com gráficos que não apareciam em relatórios personalizados foi corrigido. 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 que têm 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. Esse recurso não está disponível no momento para organizações que
têm a monetização ativada. Caso: 747159 |
| Janela de apps de desenvolvedores travada | Depois que um desenvolvedor excluiu um app no portal do desenvolvedor do Edge, clicar nesse app na interface de gerenciamento do Edge fazia com que a janela travasse. Esse problema foi corrigido. |
| Comentários em uma configuração de proxy de API | Os comentários em uma configuração de proxy de API agora estão visíveis na visualização de código do editor de proxy de API e no inspetor de propriedades. |
| Proxies de API criados com nomes inválidos | A interface de gerenciamento do Edge permitia anteriormente a criação de proxies de API cujos nomes
continham caracteres especiais não aceitos, resultando em proxies de API inválidos que não podiam ser
excluídos. Os nomes de proxy de API agora são validados no momento da criação. Somente 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 inserido. O Edge agora respeita o caso do nome inserido para o proxy de API. |
| Aviso ao salvar o proxy de API | Ao salvar um proxy de API no editor de proxy de API, o Edge implanta o proxy de API em todos os ambientes em que a revisão está implantada no momento, 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 salvas no ambiente de produção | Quando uma revisão de API implantada é atualizada, ela aciona um cancelamento e uma implantação internos em
ambientes implantados. Um papel personalizado sem permissões de implantação adequadas podia ser
implantado salvando um proxy de API. Esse problema foi resolvido aplicando 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 substituía o servidor de destino atual e retornava um status 201. Esse problema foi resolvido com a exibição de um erro 409 e não substituindo o servidor de destino atual. |
| Não é possível criar sessões de trace para proxies de API | As sessões de trace não estavam sendo criadas para ambientes com processadores de mensagens que
estavam inacessíveis. Esse problema foi resolvido anexando sessões de trace apenas aos
processadores de mensagens acessíveis e disponíveis Caso: 812192 |
| Comportamento atualizado do 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 envie a resposta para a fila JMSReplyTo
em vez do Edge, adicione o cabeçalho X-Apigee-Ignore-JMSResponse ao proxy de API
resposta em qualquer fluxo e defina-o como verdadeiro:<Header name="X-Apigee-Ignore-JMSResponse">true</Header> |
| Erros de gateway inválido 502 e CLOSE_WAIT altos | Um problema que causava métricas CLOSE_WAIT altas e erros de gateway inválido 502 foi
corrigido. Casos: 814656, 814664, 814670 |
| Diretório temporário do Node.js | Quando um script do Node.js é implantado no Edge, ele é executado em uma sandbox que restringe o acesso ao sistema de arquivos a um determinado diretório. No entanto, os.tmpdir retorna um nome de diretório como /tmp ou /var/tmp, que não existia na sandbox do Node.js do Edge, fazendo com que alguns scripts fossem interrompidos. A 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 de atribuição de mensagens, um status de resposta nulo gerava uma exceção de ponteiro nulo à medida que
Edge tentava capturar o código de resposta para métricas. Esse problema foi corrigido. Caso: 815595 |