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 melhorias desta versão.
- Painéis de análise
O Edge agora oferece novos relatórios de desempenho do endpoint, do proxy de API e do cache para ajudar você 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
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 rastreamento
O recurso de 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 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 autenticação básica leve a um proxy de API, fornecendo codificação Base64 automática de credenciais de usuário e preenchimento do cabeçalhoAuthorization: BasicHTTP.
Consulte a política de autenticação básica. - PostClientFlow
O PostClientFlow permite adicionar políticas MessageLogging que são executadas depois que a resposta é enviada. Isso reduz a latência do proxy de API e disponibiliza informações para registro em log que não são calculadas até depois que a resposta é 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 impedir o uso de caracteres especiais. |
| Denunciar problemas com o detalhamento do developer_app | Apps de desenvolvedores incorretos estavam sendo retornados em relatórios personalizados que usavam o detalhamento "developer_app". Esse problema foi corrigido. |
| O período não está funcionando nos 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'), mudar o 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 | Foi corrigido um problema que impedia a exibição de gráficos em relatórios personalizados. Caso: 814623 |
| Importação de WSDL |
|
| Configuração da política de limite de taxa simultânea | O seletor "Endpoint de destino" agora está disponível apenas ao adicionar uma política de limite de taxa simultâneo 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. No momento, esse recurso não está disponível para organizações que ativaram a monetização. Caso: 747159 |
| A janela "Apps do desenvolvedor" não responde | Depois que um desenvolvedor excluía um app no portal de desenvolvedores do Edge, clicar no app dele 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 a criação de proxies de API com nomes que
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. 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 minúsculas, independente do caso inserido. O Edge agora respeita o uso de maiúsculas e minúsculas 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 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 salvas no ambiente de produção | Quando uma revisão de API implantada é atualizada, ela aciona uma remoção e implantação internas 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 sobrescreveu o servidor de destino existente e retornou um status 201. Esse problema foi resolvido gerando 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 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 envie a 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 como "true": <Header name="X-Apigee-Ignore-JMSResponse">true</Header> |
| Muitos erros CLOSE_WAIT e 502 (gateway incorreto) | Corrigimos um problema que causava métricas CLOSE_WAIT altas e erros 502 bad gateway. Casos: 814656, 814664, 814670 |
| Diretório temporário do Node.js | Quando um script Node.js é implantado na borda, ele é executado em uma 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 na sandbox do Node.js do Edge, fazendo com que alguns scripts falhassem. O sandbox do Node.js do Edge agora inclui um diretório /tmp para uso de os.tmpdir. |
| Exceções de ponteiro nulo em chamadas de API | Na política Assign Message, um status de resposta nulo gerava uma exceção de ponteiro nulo quando
o Edge tentava capturar o código de resposta para métricas. Esse problema foi corrigido. Caso: 815595 |