4.15.07.00: notas da versão do Apigee Edge para nuvem privada

Você está visualizando a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

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

Desde a versão trimestral anterior do Edge para nuvem privada (4.15.04.00), as seguintes versões foram lançadas 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 versão atual do Edge, você pode:

• Faça upgrade direto para a versão 4.15.07.00
• Upgrade incremental, ou seja, você precisa fazer upgrade da versão atual para outra versão do Edge e depois para 4.15.07.00.

Para mais informações, consulte Quais versões do Edge para nuvem privada podem ser atualizadas para 4.15.07.00.

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

1. Verifique a versão da SSTable do Cassandra:
   1. Mude o diretório para /<install-root>/apigee4/data/cassandra/data.
   2. Execute um comando de busca,
      > find . -name *-ic-*
      Os resultados vão retornar um conjunto de arquivos .db se você estiver executando a SSTable do Cassandra 1.2.
   3. Execute este comando de busca:
      > 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, você já pode fazer o upgrade para a versão 4.15.07.00.
      
      O formato hf é para SSTables do Cassandra 1.0. Se você tiver arquivos *.db no formato hf, será necessário fazer upgrade da SSTable conforme descrito no restante deste procedimento.
2. Se você encontrar arquivos *.db no formato hf, atualize a SSTable executando o comando a seguir em cada nó do Cassandra até atualizar 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 garantir que todos tenham sido atualizados para o estilo estável C* 2.0:
   > cd /<install-root>/apigee4/data/cassandra/data
   > find . -name *-jb-*
   Esse comando vai retornar um conjunto de arquivos .db se você estiver executando o Cassandra 2.0.

Novos recursos e melhorias

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

Instalação e upgrade

Upgrade e desinstalação seletivos de componentes

Os scripts apigee-upgrade.sh e apigee-uninstall.sh agora permitem selecionar os componentes do Edge para fazer upgrade ou desinstalar. Antes, ele atualizava ou desinstalava todos os componentes no nó. (OPDK-1377, OPDK-1175)

Reversão de upgrade

Se o apigee-upgrade.sh falhar durante um upgrade, agora é possível usar o script apigee-rollback.sh para reverter o upgrade. Depois de corrigir os problemas, tente novamente. (OPDK-1275)

Opções de script do instalador encurtadas

Os scripts de instalação não usam mais a forma longa de opções, como --help. Agora, eles só aceitam opções de uma única 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, o que garante que o SmartDocs seja instalado no local esperado. Antes, esses valores eram codificados no script. (OPDK-1310)

Como executar o update-cass-pwd-in-config.sh sem solicitações

O script update-cass-pwd-in-config.sh pode ser executado sem avisos se você definir as variáveis de ambiente ENABLE_CASS_AUTH, CASS_USERNAME e CASS_PASSWORD. (OPDK-1309)

Plataforma Edge

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

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 e removeu o suporte ao JDK 1.6. (OPDK-1187)

Suporte a SO

A Apigee Edge para nuvem privada expandiu 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.

O Cassandra 2.0.15 foi 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 hash de tokens OAuth (além do SHA1). Com as novas propriedades no nível da organização, é possível ativar e configurar o hash para novos tokens, além de manter o hash legados em todos os tokens que existiam antes desse novo recurso. Anteriormente, no Edge for Private Cloud, uma propriedade chamada hash.oauth.tokens.enabled no arquivo keymanagement.properties (no servidor de gerenciamento e nos processadores de mensagens) ativava o hash SHA1 automático de tokens OAuth. Essa propriedade foi descontinuada.

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

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

Estrutura de diretório plana para arquivos de registro

É possível configurar o Edge para armazenar arquivos de registro em uma estrutura de diretório plana definindo 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 em memória, as configurações "Número máximo de elementos na memória" nos 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 o cache na memória em um determinado processador de mensagens é 40% da memória total disponível, determinada pelas configurações de propriedade do cache no arquivo cache.properties do processador de mensagens. Os elementos só serão removidos do cache em memória quando houver memória de cache insuficiente ou quando os elementos expirarem.

Para reverter para o comportamento antigo de usar a propriedade "Maximum Elements in Memory" para gerenciamento de cache, defina a propriedade overrideMaxElementsInCacheResource=false no arquivo cache.properties. (APIRT-1140)

Serviços da API

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

Novo Editor de proxy como padrão

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

Nova política de informações do OAuth v2.0 "Excluir"

Uma nova política "Excluir informações do OAuth v2.0" permite excluir tokens de acesso e códigos de autorização 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 do OAuth v1.0 para excluir

Uma nova política "Excluir informações do OAuth v1.0" permite excluir tokens de solicitação, tokens de acesso e códigos de verificador do OAuth v1.0. 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 OAuth V1. (APIRT-1351)

Política de controle de acesso

A política de controle de acesso foi aprimorada para permitir uma avaliação mais detalhada dos endereços IP para permitir e negar a inclusão em listas 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 o 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 a Política de controle de acesso.

Novas entidades na política de acesso de entidade

A política de entidade de acesso fornece acesso às seguintes entidades: escopos de chave do consumidor, authorizationcode, requesttoken e verificador. Para mais informações, consulte a Política de acesso a entidades.

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

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

Remoção do Classic Trace no editor de proxy da API

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

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

Acesse a Comunidade da Apigee no menu "Help" da interface de gerenciamento.

Mensagens de erro na interface de gerenciamento

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

• A interface de gerenciamento usada para agrupar e mostrar 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 são limpas automaticamente quando você sai da página em que elas ocorreram. (MGMT-2254)
• A interface de gerenciamento não suprime mais mensagens de erro duplicadas. (MGMT-2242)

Melhorias na performance da interface e nos erros

Melhorias gerais foram feitas em diferentes áreas da interface de gerenciamento, incluindo a 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 de gerenciamento (Administrador > Usuários da organização), os nomes de função agora têm hiperlink, permitindo que você navegue rapidamente para as páginas de função. (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.

Compatibilidade com a indicação de nome do servidor (SNI)

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

O Java 1.7 é necessário.

Com a SNI, que é uma extensão do TLS/SSL, várias destinações HTTPS podem ser atendidas pelo mesmo endereço IP e porta sem exigir que todas as destinações usem o mesmo certificado.

Não é necessária nenhuma configuração específica do Edge. Se o ambiente estiver configurado para SNI de sentido único (a nuvem Edge é o padrão), o Edge oferece suporte a ele.

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

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

"Algoritmo de assinatura" nos detalhes dos certificados SSL

Um novo campo "Algoritmo de assinatura" foi adicionado aos detalhes do certificado SSL, que podem ser visualizados na interface de gerenciamento (Admin > SSL Certificates) e na API de gerenciamento (Get Cert Details from a Keystore or Truststore). O campo mostra "sha1WithRSAEncryption" ou "sha256WithRSAEncryption", dependendo do tipo de algoritmo de hash usado para gerar o certificado.

Mostrar certificados SSL que estão próximos da expiração

A página "Certificados SSL" na interface de gerenciamento (Administrador > Certificados SSL) indica quando os certificados SSL vão expirar em 10, 15, 30 ou 90 dias, dependendo da sua seleção no campo de lista suspensa "Nova expiração".

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

Por padrão, o Edge gera um código de status HTTP 500, "Erro de servidor interno", e um erro ExecutionFailed se uma mensagem não passar por 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 organizacional features.isPolicyHttpStatusEnabled como "true", o seguinte comportamento ocorre:

• Solicitação: com uma política de proteção contra ameaças anexada a qualquer fluxo de solicitações, mensagens inválidas retornam um código de status 400 com uma mensagem de erro de política correspondente.
• Resposta: com uma política de proteção contra ameaças anexada a qualquer fluxo de respostas, 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 clientes da nuvem privada do Edge na próxima versão trimestral da nuvem privada.

Esquemas atualizados para endpoints, proxies e outras entidades

Os esquemas de referência foram atualizados para entidades que não são políticas, como TargetEndpoint, ProxyEndpoint, APIProxy e muitos outros. Consulte https://github.com/apigee/api-platform-samples/tree/master/schemas. (APIRT-1249)

Serviços para desenvolvedores

Confira a seguir os novos recursos dos Serviços para Desenvolvedores incluídos nesta versão.

Disponibilidade geral do SmartDocs

O SmartDocs está saindo da versão Beta e vai ser disponibilizado para todos os usuários. As atualizações e os novos recursos incluem:

• Suporte ao Swagger 2.0, incluindo importação por arquivo ou URL, incluindo suporte a objetos de segurança com nomes personalizados.
• Melhorias no design visual dos modelos que geram SmartDocs.
• Melhorias na usabilidade e no fluxo de trabalho no portal do desenvolvedor, disponíveis no menu "Conteúdo" > "SmartDocs" no Drupal.
• O que era conhecido como autenticação de "Token personalizado" agora é chamado de "Chave de API".
• Objetos de "segurança" de autenticação definidos no nível de revisão.
• Configuração da autenticação do cliente no nível do modelo. As novas revisões não redefiniram mais nenhuma credencial de cliente preconfigurada do SmartDocs.

Para mais descrições de recursos, consulte esta postagem do blog.

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 para desenvolvedores no Edge têm um nome interno que não muda e um nome de exibição que pode ser alterado. Na página do 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

Confira a seguir os novos recursos dos Serviços de análise incluídos nesta versão.

Limite de tempo dos dados preservados

Ao gerar relatórios de análise com a API ou a interface de gerenciamento, os dados com mais de 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 está sendo 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 de análises principal (seção "Engajamento do desenvolvedor") foi aprimorado para melhorar a performance.

Monetização

Confira a seguir os novos recursos de monetização incluídos nesta versão.

Notificações por e-mail do plano de tarifa

Um novo tipo de notificação por e-mail de plano de taxas permite que você notifique os desenvolvedores quando eles atingirem um determinado limite de transações ou de dólares nos planos de taxas de faixa de volume ou de pacotes que compraram. Para mais detalhes, consulte Configurar notificações usando modelos.

Sincronização dos períodos de taxa recorrente e base de agregação

Em um plano de tarifas, dois períodos diferentes estavam em vigor:

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

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

Se não houver uma 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çar a usar uma tabela de preços no dia 19 do mês e a base de agregação for mensal, o uso do pacote será redefinido um mês após o dia 19.

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

Atributos personalizados nos relatórios de receita resumida

As políticas de registro de transações permitem capturar dados de atributos personalizados de transações e agora é possível incluir esses atributos em relatórios de receita resumida. Ao adicionar uma propriedade MINT.SUMMARY_CUSTOM_ATTRIBUTES à sua organização, você pode indicar quais atributos personalizados são adicionados às tabelas do banco de dados para uso em relatórios.

Os clientes do Apigee Edge para nuvem privada podem definir a flag com a seguinte chamada de API e as credenciais do 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 em URL.

Processo de upgrade do SmartDocs

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

As páginas do SmartDocs que já foram publicadas no seu portal de desenvolvedores vão continuar funcionando, mas você precisa seguir o processo de atualização antes de editar ou publicar qualquer mudança nas páginas atuais ou novas.

É possível renderizar e publicar SmartDocs no portal do desenvolvedor, mas eles são gerados com base no modelo de API que está nos Serviços de gerenciamento de API do Apigee. Todas as mudanças feitas em um modelo de API no Edge serão as mesmas em todos os ambientes do Pantheon, semelhante à forma como os desenvolvedores existem em todos os ambientes do Pantheon.

Para fazer upgrade da versão Beta do SmartDocs para a versão de disponibilidade geral

1. Atualize e teste a versão 15.05.27 nos ambientes dev ou teste no 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ê estiver mantendo seu modelo de API pelo módulo SmartDocs, exporte como JSON do SmartDocs e importe 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 qualquer autenticação pré-configurada na página de configurações do modelo (Conteúdo > SmartDocs) clicando em Configurações na coluna Operações.
   
5. Atualize os modelos personalizados para usar a v6 dos recursos de CSS e JS e faça mudanças para refletir novos nomes de objetos, como authSchemes e apiSchema. Para informações sobre como atualizar modelos do SmartDocs, consulte Como usar SmartDocs para documentar APIs.
6. Renderize 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 empresarial 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 da Apigee para receber a melhor resposta.

Mudanças e melhorias futuras nos recursos

Esta seção mostra uma prévia das mudanças e melhorias de recursos esperados para o futuro:

Mudar para o 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 de cache de resposta.

Comportamento futuro:o elemento <ExcludeErrorResponse> na política de cache de resposta vai ser "true" por padrão. Isso significa que, por padrão, apenas as respostas com códigos de status HTTP 200 a 205 serão armazenadas em cache. Para substituir esse comportamento e armazenar em cache as respostas de todos os códigos de status, defina o elemento <ExcludeErrorResponse> como verdadeiro de forma explícita.

Solução alternativa atual : para a Private Cloud 4.15.07.00 e versões anteriores, se você quiser armazenar em cache apenas respostas com os códigos de status 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 seguintes problemas conhecidos.

> 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