4.15.07.00 - Notas de lançamento do Apigee Edge para nuvem privada

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

Na terça-feira, 8 de setembro de 2015, lançamos uma versão importante de recurso do Apigee Edge para nuvem privada.

Desde o lançamento trimestral anterior do Edge para nuvem privada (4.15.04.00), as seguintes versões ocorreram e estão incluídas nesta versão trimestral:

• Nuvem: 15.04.15, 15.04.29, 15.05.27, 15.06.10 e 15.06.24
• Nuvem privada: 4.15.04.01

Quais versões do Edge podem ser atualizadas para 4.15.07.00

Dependendo da sua versão atual do Edge, você tem as seguintes opções:

• Fazer upgrade diretamente para a versão 4.15.07.00
• Upgrade incremental, o que significa que você precisa fazer upgrade da versão atual para outra versão do Edge e, em seguida, fazer upgrade para a versão 4.15.07.00.

Para mais informações, consulte Qual é o upgrade para a versão 4.15.07.00 do Edge para nuvem privada.

Antes de fazer upgrade da versão 4.15.01.x ou de uma versão anterior

1. Verifique a versão do SSTable no Cassandra:
   1. Mude o diretório para /<install-root>/apigee4/data/cassandra/data.
   2. Execute um comando de localização:
      > find . -name *-ic-*
      Os resultados retornarão um conjunto de arquivos .db se você estiver executando o Cassandra 1.2 SSTable.
   3. Execute este comando de localização:
      > find . -name *-hf-*
      Os resultados precisam estar vazios, o que significa que nenhum arquivo .db está no formato hf. Se não houver arquivos no formato hf, o upgrade para a versão 4.15.07.00 já estará concluído.
      
      O formato hf é para SSTables do Cassandra 1.0. Se você tiver arquivos *.db no formato hf, faça upgrade do SSTable conforme descrito no restante deste procedimento.
2. Se você encontrar arquivos *.db no formato hf, faça upgrade do SSTable executando o seguinte comando em cada nó do Cassandra até fazer upgrade de todos os nós do Cassandra:
   > /<install-root>/apigee4/share/apache-cassandra/bin/nodetool -h localhost upgradesstables -a
3. Repita a etapa 1 para verificar se todos os arquivos *.db estão no formato ic da versão 1.2 do Cassandra.
4. Repita as etapas de 1 a 3 em cada nó do Cassandra na instalação do Edge.
5. Faça upgrade para o Edge 4.15.07.00.
6. Após o upgrade para a versão 4.15.07.00, verifique os arquivos *.db para conferir se todos eles foram atualizados para o estilo C* 2.0 estável:
   > cd /<install-root>/apigee4/data/cassandra/data
   > find . -name *-template-*
   Esse comando retornará um conjunto de arquivos .db se você estiver executando o Cassandra 2.0.

Novos recursos e melhorias

Veja a seguir os novos recursos e melhorias desta versão.

Instalação e upgrade

Upgrade e desinstalação seletivos de componentes

Com os scripts apigee-upgrade.sh e apigee-Uninstall.sh agora permitem selecionar os componentes do Edge para upgrade ou desinstalação. Anteriormente, ele fez upgrade ou desinstalou todos os componentes do nó. (OPDK-1377 e OPDK-1175)

Reversão do upgrade

Se o apigee-upgrade.sh falhar durante um upgrade, você poderá usar o script apigee-rollback.sh para revertê-lo. Depois de corrigir os problemas, você pode tentar fazer o upgrade novamente. (OPDK-1275)

Opções de script do instalador reduzidas

Os scripts de instalação não assumem mais a forma longa de opções, como --help. Agora, elas aceitam apenas opções de letra, como -h. (OPDK-1356)

Instalação do SmartDocs

Ao instalar o SmartDocs com o script setup-smartdocs.sh, você precisa inserir a organização, o ambiente e o host virtual para garantir que o SmartDocs seja instalado no local esperado. Antes, esses valores eram codificados no script. (OPDK-1310)

Executar update-cass-pwd-in-config.sh sem prompts

Se você definir as variáveis de ambiente ENABLE_CASS_AUTH, CASS_USERNAME e CASS_PASSWORD, o script update-cass-pwd-in-config.sh poderá ser executado sem solicitações. (OPDK-1309)

Plataforma de borda

Confira abaixo os novos recursos da plataforma Edge incluídos nesta versão.

OpenJDK 1.7 compatível com a nuvem privada do Edge

Esta versão do Edge oferece suporte ao Oracle JDK 1.7 e ao OpenJDK 7. Além disso, a compatibilidade com o JDK 1.6 foi removida. (OPDK-1187)

Suporte a SO

O suporte do Apigee Edge para nuvem privada ampliou o suporte ao sistema operacional para incluir o Red Hat Enterprise Linux 6.6 e 7.0 (64 bits), o CentOS 6.5, 6.6 e 7.0 (64 bits) e o Oracle Linux 6.5.

Cassandra 2.0.15 incluído no OPDK 15.07

Esta versão instala o Cassandra 2.0.15. Se você estiver fazendo upgrade para uma versão anterior, a versão do Cassandra será atualizada. (OPDK-1197)

Suporte a SHA2 para hash de token OAuth

Para proteger melhor os tokens OAuth no caso de uma violação de segurança do banco de dados, o Edge oferece suporte a algoritmos SHA2 para gerar hash de tokens OAuth (além do SHA1). Com as novas propriedades de organização, é possível ativar e configurar o hash de novos tokens, bem como manter o hash legado em todos os tokens que existiam antes desse novo recurso. Antes, no Edge para nuvem privada, uma propriedade chamada hash.oauth.tokens.enabled no arquivo keymanagement.properties (no servidor de gerenciamento e processadores de mensagens) ativava o hash SHA1 automático de tokens OAuth. Essa propriedade foi descontinuada.

Se você já usou a propriedade hash.oauth.tokens.enabled para ativar o hash SHA1, o script de upgrade desta versão gera automaticamente as novas propriedades no nível da organização. Para verificar após o upgrade, faça um GET como administrador do sistema com esta API: https://{host}:{port}/v1/o/{your_org}.

• Para informações sobre como ativar o hash de token na sua organização com as novas propriedades, consulte "Tokens de hash no banco de dados" no tópico Como solicitar tokens de acesso.
• Para mais informações sobre como gerar hash em massa de tokens atuais, consulte o Guia de operações do Edge para nuvem privada (em inglês). (APIRT-1389)

Estrutura de diretórios simples para arquivos de registros

É possível configurar o Edge para armazenar arquivos de registros em uma estrutura de diretórios simples. Basta definir uma nova propriedade enable.flat.directory.structure como verdadeira no arquivo message-logging.properties. Para mais informações, consulte a Política de geração de registros de mensagens. (APIRT-1394)

Desempenho do cache do ambiente

Para melhorar o gerenciamento e a utilização do cache na memória, as configurações "Máximo de elementos na memória" em recursos de cache do ambiente foram descontinuadas. O total de elementos presentes em todos os recursos de cache (incluindo o cache padrão) depende da memória total alocada para o cache. Por padrão, a memória total alocada para armazenamento em cache na memória em um determinado processador de mensagens é 40% da memória total disponível, determinada pelas configurações de propriedade de cache no arquivo cache.properties do processador de mensagens. Os elementos serão removidos do cache na memória somente quando houver memória em cache insuficiente ou os elementos expirarem.

Para voltar ao comportamento antigo de usar a propriedade "Máximo de elementos na memória" para o gerenciamento de cache, defina a propriedade overrideMaxElementsInCacheResource=false no arquivo cache.properties. (APIRT-1140).

Serviços da API

Veja a seguir os novos recursos de serviços de API incluídos nesta versão.

Novo Proxy Editor como padrão

O novo editor de proxy de API é ativado por padrão na interface de gerenciamento. O novo editor inclui muitas melhorias de usabilidade, incluindo visualizações mais abrangentes de fluxos e endpoints condicionais na página "Visão geral", todas as configurações na página "Desenvolver", adição mais intuitiva de fluxos, endpoints e políticas condicionais, visualizações XML mais completas em vez de pequenos snippets, pesquisa que rastreia nomes de arquivos e textos e muito mais. (MGMT-2279)

Nova política de informações de exclusão do OAuth v2.0

Uma nova política "Excluir informações do OAuth v2.0" permite excluir códigos de autorização e tokens de acesso do OAuth v2. A política substitui a funcionalidade fornecida anteriormente pela API de gerenciamento. Para mais informações, consulte Excluir a política de informações do OAuthV2. (MGMT-2257)

Nova política de informações de exclusão do OAuth v1.0

Uma nova política "Excluir informações do OAuth v1.0" permite excluir tokens de solicitação, tokens de acesso e códigos do verificador do OAuth v1.0. A política substitui a funcionalidade fornecida anteriormente pela API de gerenciamento. Saiba mais em Excluir política de informações do OAuth V1. (APIRT-1351)

Política de controle de acesso

A política de controle de acesso foi aprimorada para permitir avaliações mais refinadas de endereços IP para inclusão na lista de permissões e de bloqueio quando os endereços IP estão contidos no cabeçalho HTTP X-FORWARDED-FOR.

Com a verificação de vários endereços IP ativada no cabeçalho (entre em contato com o suporte para definir feature.enablemultipleXForwardCheckForACL), um novo elemento <ValidateBasedOn> na política permite verificar o primeiro IP, o último IP ou todos os IPs no cabeçalho. Para mais informações, consulte Política de controle de acesso.

Novas entidades na política de entidade de acesso

A política de entidade de acesso fornece acesso às seguintes entidades novas: consumerkey-scopes, Authorizationcode, requesttoken e verificado.. Para mais informações, consulte a Política de entidade de acesso.

Política do coletor de estatísticas: conversão automática do nome das estatísticas para letras minúsculas

Ao criar um conjunto de análises personalizadas no editor de proxy de API (página Desenvolver > Ferramentas > Coleta de análise personalizada), a variável do coletor (estatística) "Nome" precisa estar em letras minúsculas. Se você digitar o nome com letras maiúsculas, a ferramenta converterá automaticamente o nome da estatística em letras minúsculas na política do coletor de estatísticas. (MGMT-740)

Remoção do Trace clássico no editor de proxy da API

A versão mais recente da funcionalidade do Trace no editor de proxy de API passou da versão Beta para a disponibilidade geral. O acesso ao "trace clássico" com o link "Acessar a versão clássica do trace" não está mais disponível.

Acesso à comunidade da Apigee no menu de ajuda da interface de gerenciamento

Você pode acessar a comunidade da Apigee no menu "Ajuda" da interface de gerenciamento.

Mensagens de erro na interface de gerenciamento

Veja a seguir as melhorias nas mensagens de erro na interface de gerenciamento:

• A interface de gerenciamento usada para agrupar e exibir todas as mensagens de erro na interface durante toda a sessão de login, a menos que você as tenha dispensado. Com essa atualização, as mensagens de erro serão apagadas automaticamente quando você sair da página em que ocorreram. (MGMT-2254)
• A interface de gerenciamento não suprime mais mensagens de erro duplicadas. (MGMT-2242)

Melhorias no desempenho da interface e erros

Foram feitas melhorias gerais em diferentes áreas da interface de gerenciamento, incluindo o desempenho de exibição de páginas e a limpeza de mensagens de erro.

Hiperlinks de função na página "Usuários da organização" na interface de gerenciamento

Na página "Usuários da organização" na interface do usuário de gerenciamento (Administrador > Usuários da organização), os nomes dos papéis agora têm hiperlinks, permitindo que você navegue rapidamente para as páginas dos papéis. (MGMT-1055)

Novas variáveis de destino no fluxo de mensagens

As novas variáveis nos fluxos de mensagens oferecem informações de URL mais completas para endpoints e servidores de destino:

• TargetEndpoint: request.url substitui target.basepath.with.query.
• TargetServer: loadbalancing.targetserver substitui targetserver.name. Além disso, target.basepath é preenchido apenas quando o elemento <Path> é usado no elemento <LoadBalancer> HTTPTargetConnection do TargetEndpoint.

Suporte à indicação de nome do servidor (SNI, na sigla em inglês)

O Edge permite o uso da indicação de nome do servidor no sentido sul (do processador de mensagens aos endpoints de destino). Se você quiser usar o SNI, entre em contato com o suporte da Apigee.

Java 1.7 é obrigatório.

Com a SNI, que é uma extensão do TLS/SSL, vários destinos HTTPS podem ser veiculados no mesmo endereço IP e porta, sem exigir que todos usem o mesmo certificado.

Nenhuma configuração específica do Edge é necessária. Se o ambiente estiver configurado para SNI no sentido sul (a nuvem do Edge é por padrão), o Edge vai oferecer suporte a ele.

O Edge extrai automaticamente o nome do host do URL da solicitação e o adiciona à solicitação de handshake de SSL. Por exemplo, se o host de destino for https://example.com/request/path, o Edge adicionará a extensão server_name, conforme mostrado abaixo:

Para mais informações sobre SNI, consulte http://en.wikipedia.org/wiki/Server_Name_Indication.

"Algoritmo de assinatura" nos detalhes de certificados SSL

Um novo campo "Algoritmo de assinatura" foi adicionado aos detalhes do certificado SSL, disponível na interface de gerenciamento (Administrador > Certificados SSL) e na API de gerenciamento (Acessar detalhes do certificado de um Keystore ou Truststore). O campo mostra "sha1WithRSAEncryption" ou "sha256WithRSAEncryption", dependendo do tipo de algoritmo de hash usado para gerar o certificado.

Mostrando certificados SSL que estão próximos do vencimento

A página "Certificados SSL" na IU de gerenciamento (Administrador > Certificados SSL) indica quando os certificados SSL expiram em 10, 15, 30 ou 90 dias, dependendo da sua seleção no novo campo suspenso de expiração.

Configuração de erro da proteção contra ameaças

Por padrão, o Edge gera um código de status "Erro interno do servidor HTTP 500" e um erro "ExecutionFailed" se uma mensagem não passar de uma política de proteção contra ameaças JSON ou XML. É possível alterar esse comportamento de erro com uma nova propriedade no nível da organização. Ao definir a propriedade da organização features.isPolicyHttpStatusEnabled como verdadeira, o seguinte comportamento ocorre:

• Solicitação: com uma política de proteção contra ameaças anexada a qualquer fluxo de solicitação, as mensagens inválidas retornam um código de status 400, além de uma mensagem de erro da política correspondente.
• Resposta: com uma política de proteção contra ameaças anexada a qualquer fluxo de resposta, as mensagens inválidas ainda retornam um código de status 500, e uma das mensagens de erro de política correspondentes é gerada (em vez de apenas ExecutionFailed).

Os clientes do Cloud precisam entrar em contato com o Suporte da Apigee para definir a propriedade da organização. Esse recurso vai estar disponível para os clientes da nuvem privada do Edge no próximo lançamento trimestral da nuvem privada.

Esquemas atualizados para endpoints, proxies e outras entidades

Os esquemas de referência foram atualizados para entidades sem política, como TargetEndpoint, ProxyEndpoint, APIProxy e muitas outras. Consulte https://github.com/apigee/api-platform-samples/tree/master/schemas. (APIRT-1249).

Serviços do desenvolvedor

Veja a seguir os novos recursos dos serviços para desenvolvedores incluídos nessa versão.

Disponibilidade geral do SmartDocs

O SmartDocs está passando da versão Beta para a disponibilidade geral. As atualizações e os novos recursos incluem:

• Suporte para Swagger 2.0, incluindo importação por arquivo ou URL, inclusive suporte a objetos de segurança com nomes personalizados.
• Melhorias de design visual nos modelos que geram SmartDocs.
• Melhorias de usabilidade e fluxo de trabalho no portal do desenvolvedor, disponíveis no menu Conteúdo > SmartDocs no Drupal.
• O que era conhecido como autenticação por "token personalizado" agora é chamado de "chave de API".
• Objetos de "segurança" de autenticação definidos no nível da revisão.
• Configuração da autenticação do cliente no nível do modelo. As novas revisões não redefinem mais as credenciais pré-configuradas do cliente SmartDocs.

Para ver mais descrições de recursos, consulte esta postagem do blog (link em inglês).

Para conferir a documentação do SmartDocs, consulte Como usar o SmartDocs para documentar APIs.

Nome do app do desenvolvedor exibido na interface de gerenciamento

Os apps do desenvolvedor no Edge têm um nome interno que não muda e um nome de exibição que você pode mudar. Em uma página "App do desenvolvedor" na interface de gerenciamento (Publicar > Apps do desenvolvedor > nome do app), o "Nome" interno do app é exibido junto com o "Nome de exibição", facilitando a identificação visual dos apps pelos nomes internos para solução de problemas e gerenciamento de APIs.

Serviços de análise

Veja a seguir os novos recursos de serviços do Google Analytics incluídos nessa versão.

Limite de tempo de dados preservados

Ao gerar relatórios de análise com a API ou interface de gerenciamento, dados anteriores a seis meses da data atual não podem ser acessados por padrão. Se você quiser acessar dados com mais de seis meses, entre em contato com o suporte da Apigee.

A versão clássica dos relatórios personalizados será removida da interface de gerenciamento

A versão clássica opcional dos relatórios de análise personalizados não está mais disponível na interface de gerenciamento.

Desempenho do widget de engajamento do desenvolvedor

O widget de funil no painel principal de análise (seção "Engajamento do desenvolvedor") foi aprimorado para oferecer um desempenho melhor.

Monetização

Veja a seguir os novos recursos de monetização incluídos nessa versão.

Notificações por e-mail sobre o plano de tarifa

Com um novo tipo de notificação por e-mail do plano de tarifas, você pode avisar os desenvolvedores quando eles alcançarem um determinado limite de transação ou dólar nos planos de tarifa com faixa de volume ou por pacote. Para mais detalhes, consulte Configurar notificações usando modelos de notificação.

Sincronização de taxas recorrentes e períodos de base de agregação

Em um plano de tarifa, havia possivelmente dois períodos diferentes em vigor:

• Período da tarifa recorrente, configurado na guia "Taxas" de um plano de tarifas, que é determinado quando uma taxa recorrente é cobrada dos desenvolvedores.
• Período de base de agregação, definido na tabela de preços dos planos com volume em banda ou pacotes, que determinou quando o uso do pacote foi redefinido para os desenvolvedores.

Esses dois períodos agora estão sincronizados. Quando uma taxa recorrente diferente de zero e uma tabela de preços com volume ou pacote existem em um plano de tarifas, o período da taxa recorrente é usado para ambos. Por exemplo, se existir uma taxa mensal recorrente, os pacotes da tabela de preços também serão redefinidos mensalmente (por padrão, no início do mês).

Se não houver taxa recorrente, os pacotes serão redefinidos com base na base de agregação definida na tabela de preços. Por exemplo, se um desenvolvedor começa a usar uma tabela de preços no dia 19 do mês e a base de agregação é todos os meses, o uso do pacote é redefinido um mês após o dia 19.

A base de agregação será descontinuada e será removida da monetização em uma versão futura. Para mais informações, consulte Especificar os detalhes do plano da tabela de preços.

Atributos personalizados nos relatórios de receita resumida

Com as políticas de registro de transações, você tem a opção de capturar dados de atributos personalizados das transações, além de incluir esses atributos personalizados em relatórios de resumo de receita. Ao adicionar uma propriedade MINT.SUMMARY_PERSONAL_ATTRIBUTES à organização, é possível indicar quais atributos personalizados foram adicionados às tabelas do banco de dados para uso nos relatórios.

Os clientes do Apigee Edge para nuvem privada podem definir a sinalização com a seguinte chamada de API e credenciais de administrador do sistema.

curl -u email:password -X PUT -H "Content-type:application/xml" http://host:8080/v1/o/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isMonetizationEnabled">true</Property>
        <Property name="MINT.SUMMARY_CUSTOM_ATTRIBUTES">[&quot;my_attribute_1&quot;,&quot;my_attribute_2&quot;]</Property>
        <Property name="features.topLevelDevelopersAreCompanies">false</Property>
    </Properties>
</Organization>"

A matriz de atributos personalizados na chamada de API é codificada para uso em URL.

Processo de upgrade do SmartDocs

Se você já usa o SmartDocs durante o período Beta, os novos recursos na versão de disponibilidade geral exigem que você faça upgrade do SmartDocs no portal do desenvolvedor.

Todas as páginas SmartDocs que já tiverem sido publicadas no seu portal do desenvolvedor continuarão funcionando, mas você precisará seguir o processo de atualização antes de editar ou publicar qualquer alteração em páginas novas ou existentes.

É importante lembrar que, embora seja possível renderizar e publicar SmartDocs dentro do portal do desenvolvedor, os SmartDocs são gerados a partir do modelo de API que reside nos serviços de gerenciamento de APIs Edge da Apigee. Todas as alterações feitas em um modelo de API no Edge serão as mesmas em todos os ambientes do Pantheon (semelhante à forma como os desenvolvedores existem nos ambientes do Pantheon).

Fazer upgrade da versão Beta do SmartDocs para a disponibilidade geral

1. Atualize e teste a versão 15.05.27 nos seus ambientes dev ou test do Pantheon.
2. Crie um novo modelo para substituir qualquer modelo de API que você esteja usando.
   • Se você estiver importando documentos Swagger ou WADL, importe-os novamente para uma nova revisão.
   • Se você tem mantido seu modelo de API por meio do módulo SmartDocs, exporte como JSON SmartDocs e importe-o para o novo modelo usando o anexo de arquivo.
3. Defina as propriedades de segurança da revisão do modelo. Na página Conteúdo > SmartDocs > modelo, selecione Configurações de segurança.
   
4. Verifique as autenticações pré-configuradas na página de configurações do modelo (Conteúdo > SmartDocs) clicando em Configurações na coluna Operações.
   
5. Atualize todos os modelos personalizados para usar a v6 dos recursos CSS e JS e faça alterações para refletir os novos nomes de objeto, como authSchemes e apiSchema. Para informações sobre como atualizar modelos do SmartDocs, consulte Como usar o SmartDocs para documentar APIs.
6. Renderize novamente e publique a revisão do modelo.
7. Depois de validar a nova documentação, atualize seu portal de produção para a versão 15.05.27.

Se você for um cliente Enterprise do Edge e tiver dúvidas sobre o processo de upgrade, envie um e-mail para marsh@apigee.com e cnovak@apigee.com. Caso contrário, use a Comunidade Apigee para receber a melhor resposta.

Futuras mudanças e melhorias nos recursos

Esta seção mostra as futuras mudanças e melhorias esperadas nos recursos:

Alteração no comportamento da política de cache de resposta

Em uma versão futura (a ser determinada), o comportamento padrão do elemento <ExcludeErrorResponse> da política de cache de resposta vai mudar.

Comportamento atual:o elemento <ExcludeErrorResponse> na política de cache de resposta é falso por padrão. Isso significa que, por padrão, as respostas com qualquer código de status HTTP possível (incluindo 3xx) são armazenadas em cache pela política do cache de resposta.

Comportamento futuro:o elemento <ExcludeErrorResponse> na política de cache de resposta vai ter o valor "true" por padrão. Isso significa que, por padrão, somente as respostas com códigos de status HTTP de 200 a 205 serão armazenadas em cache. Para modificar esse comportamento e armazenar em cache as respostas para todos os códigos de status, é necessário definir explicitamente o elemento <ExcludeErrorResponse> como verdadeiro.

Solução alternativa atual: para o Private Cloud 4.15.07.00 e versões anteriores, se você quiser armazenar respostas em cache somente com os códigos de status de 200 a 205, defina explicitamente o elemento <ExcludeErrorResponse> como verdadeiro.

Bugs corrigidos

Os bugs abaixo foram corrigidos nesta versão.

Problemas conhecidos

Esta versão tem os problemas conhecidos a seguir.

> source /{install-dir}/apigee4/bin/apigee-env.sh 

> VER=`basename $(find $SHARE_DIR/installer/monetization -name "mint-*.zip") | cut -d "-" -f 2,3,4` 

> sed -i "s/^MONETIZATION_VERSION=.*/MONETIZATION_VERSION=$VER/" /install-dir/apigee4/bin/apigee-env.sh 

> rm /install-dir/apigee4/share/monetization 

************************************** 
In order to complete the monetization upgrade please run: 
sudo /opt/apigee4/share/monetization/schema/migration/MOPDK4.15.04.00/
365-create-notification-condition.sh 
************************************** 

connect.ranges.denied=10.0.0.0/8,192.168.0.0/16,127.0.0.1/32

<install_dir>/apigge4/bin/apigee-service message-processor restart