Você está vendo a documentação do Apigee Edge.
Acesse a
documentação da Apigee X. informações
Na terça-feira, 29 de abril de 2014, lançamos uma nova versão do Apigee Edge para a nuvem.
Novos recursos e melhorias
Veja a seguir os novos recursos e melhorias desta versão.
- Painéis de análise
O Edge agora oferece novos relatórios de desempenho do endpoint, desempenho do proxy da API e análise de desempenho do cache para ajudar você a monitorar o desempenho.
Consulte "Os painéis de operações" em Painéis do Analytics. - Agregação de métricas personalizadas para performance
Esse recurso não está mais disponível.
Um novo recurso de agregação personalizado melhora o desempenho de 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ê vê os relatórios, o Edge acessa as métricas agregadas já disponíveis em vez de buscá-las em tempo real. - OAuth 2.0 pré-configurado em proxies de API
Ao criar um proxy de API, uma nova opção "Seguro com tokens de acesso do OAuth v2.0" configura automaticamente o proxy de API com políticas compatíveis com OAuth.
Consulte OAuth. - Mascaramento de dados no trace
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 de dados do usuário durante o desenvolvimento da API.
Caso:810723
Consulte Mascaramento e ocultação de dados. - Política de autenticação básica
Ela permite adicionar a autenticação básica leve a um proxy de API, fornecendo a codificação Base64 automática de credenciais do usuário e o preenchimento do cabeçalhoAuthorization: Basic
HTTP.
Consulte Política básica de autenticação. - 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 de 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 dos relatórios personalizados para proibir o uso de caracteres especiais. |
Informar problemas com o detalhamento de developer_app | Apps de desenvolvedor incorretos estavam sendo retornados nos relatórios personalizados que usavam o detalhamento developer_app. Esse problema foi corrigido. |
Período que não está funcionando em relatórios personalizados | Em relatórios personalizados com filtros com várias expressões entre parênteses (por exemplo, (request_verb eq 'POST') or (request_verb eq
'GET') ), alterar o período do relatório não afeta os resultados. Esse problema
foi corrigido.Caso: 810753 |
Gráficos não exibidos nos relatórios personalizados | Corrigimos um problema com gráficos que não apareciam nos 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 só está disponível 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 da página "Desenvolvedores" na IU de gerenciamento do Edge. No momento, este recurso não está disponível para organizações
que ativaram a monetização. Caso: 747159 |
Janela de apps do desenvolvedor travando | Depois que um desenvolvedor exclui um app no Portal do desenvolvedor do Edge, clicar nele na IU de gerenciamento do Edge faria com que a janela travava. 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 aparecem 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 | Antes, a interface de gerenciamento de borda permitia a criação de proxies de API com nomes
que continham caracteres especiais incompatíveis, o que resultava 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. Apenas caracteres alfanuméricos, "-" e
"_" são permitidos. Caso: 550390 |
Diferenciação entre maiúsculas e minúsculas na nomenclatura do proxy da API | O Edge estava criando proxies de API com nomes em letras minúsculas, independentemente das letras maiúsculas e minúsculas. O Edge agora respeita o caso do nome inserido para o proxy de API. |
Aviso ao salvar o proxy de API | Quando você salva um proxy de API no editor de proxy de API, o Edge o implanta em todos os ambientes em que a revisão está implantada no momento, incluindo os ambientes de produção. A interface de gerenciamento de borda agora exibe um aviso antes de salvar o proxy. |
Papel personalizado sem permissões salvando no ambiente de produção | Quando uma revisão de API implantada é atualizada, ela aciona um cancelamento interno e a implantação em
ambientes implantados. Foi possível implantar um papel personalizado sem as permissões de implantação adequadas 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 atual e retornou um status 201. Esse problema foi resolvido com a geração de um erro 409 e não substituir o servidor de destino atual. |
Não foi possível criar sessões de rastreamento para proxies de API | As sessões de rastreamento não estavam sendo criadas para ambientes com processadores de mensagens inacessíveis. Esse problema foi resolvido ao anexar sessões de rastreamento 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 processe o envio da resposta para a fila JMSReplyTo em vez do Edge, adicione o cabeçalho X-Apigee-Ignore-JMSResponse à resposta do proxy de API em qualquer fluxo e defina-o como "true":<Header name="X-Apigee-Ignore-JMSResponse">true</Header> |
Altos erros de CLOSE_WAIT e 502 de gateway inválidos | Um problema que causava métricas CLOSE_WAIT altas e 502 erros de gateway inválido 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, os.tmpdir retorna um nome de diretório como /tmp ou /var/tmp, que não existia no sandbox do Node.js de borda, causando falhas em alguns scripts. O sandbox do Edge Node.js agora inclui um diretório /tmp para uso de 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 enquanto
o Edge tentava capturar o código de resposta para métricas. Esse problema foi corrigido. Caso: 815595 |