Configurando o servidor MobileFirst

Visão Geral

Considere sua política de backup e recuperação, otimize a configuração do MobileFirst Server Server e aplique restrições de acesso e opções de segurança.

Ir para

• Terminais do servidor de produção do MobileFirst Server
• Configurando o MobileFirst Server para ativar o TLS V1.2
• Configurando a autenticação do usuário para administração do MobileFirst Server
• Lista de propriedades JNDI dos aplicativos da web do MobileFirst Server
• Configurando as Origens de Dados
• Configurando mecanismos de criação de log e monitoramento
• Configurando vários tempos de execução
• Configurando rastreamento de licença
• Configuração de SSL e adaptadores HTTP do WebSphere Application Server

Terminais do servidor de produção do MobileFirst Server

É possível criar listas de desbloqueio e listas de bloqueio para os terminais do IBM MobileFirst Server.

Nota: As informações referentes a URLs que são expostas pelo Mobile Foundation são fornecidas como uma diretriz. As organizações devem assegurar que as URLs sejam testadas em uma infraestrutura corporativa, com base no que estiver ativado para as listas de bloqueio e desbloqueio.

Configurando o MobileFirst Server para ativar o TLS V1.2

Para o MobileFirst Server se comunicar com dispositivos que suportam somente Transport Layer Security v1.2 (TLS) V1.2, entre os protocolos SSL, deve-se concluir as instruções a seguir.

As etapas para configurar o MobileFirst Server para ativar a Segurança da Camada de Transporte (TLS) V1.2 dependem de como o MobileFirst Server se conecta aos dispositivos.

• Se o MobileFirst Server estiver atrás de um proxy reverso que decriptografa pacotes codificados em SSL dos dispositivos antes de passar os pacotes para o servidor de aplicativos, você deverá ativar o suporte ao TLS V1.2 no proxy reverso. Se você usar o IBM HTTP Server como seu proxy reverso, consulte Protegendo o IBM HTTP Server para obter instruções.
• Se o MobileFirst Server se comunicar diretamente com dispositivos, as etapas para ativar o TLS V1.2 dependerão de seu servidor de aplicativos ser Apache Tomcat, perfil Liberty do WebSphere Application Server ou perfil completo do WebSphere Application Server.

Apache Tomcat

1. Confirme se o Java Runtime Environment (JRE) suporta o TLS V1.2. Assegure-se de ter uma das versões de JRE a seguir:
   • Oracle JRE 1.7.0_75 ou mais recente
   • Oracle JRE 1.8.0_31 ou mais recente
2. Edite o arquivo conf/server.xml e modifique o elemento Connector que declara a porta HTTPS para que o atributo sslEnabledProtocols tenha o seguinte valor: sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1,SSLv2Hello".

perfil Liberty do WebSphere Application Server

1. Confirme se o Java Runtime Environment (JRE) suporta o TLS V1.2.

   • Se você usar um IBM Java SDK, certifique-se de que seu IBM Java SDK seja corrigido para a vulnerabilidade POODLE. É possível localizar as versões mínimas do IBM Java SDK que contêm a correção para sua versão do WebSphere Application Server em Security Bulletin: vulnerability in SSLv3 affects IBM WebSphere Application Server (CVE-2014-3566).

     Nota: é possível usar as versões que estão listadas no boletim de segurança ou as versões mais recentes.

   • Se você usar um Oracle Java SDK, certifique-se de que tenha uma das seguintes versões:

     • Oracle JRE 1.7.0_75 ou mais recente
     • Oracle JRE 1.8.0_31 ou mais recente
2. Se você usar um IBM Java SDK, edite o arquivo server.xml.
   • Inclua a linha a seguir: <ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" sslProtocol="SSL_TLSv2"/>
   • Inclua o atributo sslProtocol="SSL_TLSv2" em todos os elementos <ssl> existentes.

WebSphere Application Server Full Profile

1. Confirme se o Java Runtime Environment (JRE) suporta o TLS V1.2.

   Certifique-se de que o IBM Java SDK seja corrigido para a vulnerabilidade POODLE. É possível localizar as versões mínimas do IBM Java SDK que contêm a correção para a sua versão do WebSphere Application Server em Boletim de segurança: a vulnerabilidade no SSLv3 afeta o IBM WebSphere Application Server (CVE-2014-3566).

   Nota: é possível usar as versões que estão listadas no boletim de segurança ou as versões mais recentes.

2. Efetue login no console administrativo do WebSphere Application Server e clique em Segurança → Certificado SSL e gerenciamento de chave → Configurações SSL.
3. Para cada configuração de SSL listada, modifique a configuração para ativar o TLS V1.2.
   • Selecione uma configuração SSL e, em seguida, em Propriedades adicionais, clique em configurações de Qualidade de proteções (QoP).
   • Na lista Protocolo, selecione SSL_TLSv2.
   • Clique em Aplicar e, em seguida, salve as mudanças.

Configurando a autenticação do usuário para o MobileFirst Server administration

MobileFirst Server A administração do requer autenticação do usuário. É possível configurar a autenticação do usuário e escolher um método de autenticação. Então, o procedimento de configuração depende do servidor de aplicativos da web usado.

Importante: Se você usar o perfil completo do WebSphere Application Server independente, use um método de autenticação diferente do simple WebSphere authentication method (SWAM) na segurança global. É possível usar Lightweight Third Party Authentication (LTPA). Se usar SWAM, talvez você enfrente falhas de autenticação não esperadas.

Deve-se configurar autenticação após o instalador implementar os aplicativos da web de administração do MobileFirst Server no servidor de aplicativos da web.

A administração do MobileFirst Server tem as seguintes funções de segurança Java Platform, Enterprise Edition (Java EE) definidas:

• mfpadmin
• mfpdeployer
• mfpoperator
• mfpmonitor

Você deve mapear as funções para os conjuntos de usuários correspondentes. A função mfpmonitor pode visualizar dados, mas não pode alterar nenhum deles. As tabelas a seguir listam atribuições e funções do MobileFirst para servidores de produção.

Implementação

Gerenciamento do MobileFirst Server

Gerenciamento de Aplicativos

Basicamente, todas as funções podem emitir solicitações GET, as funções mfpadmin, mfpdeployer e mfpmonitor também podem emitir solicitações POST e PUT e as funções mfpadmin e mfpdeployer também podem emitir solicitações DELETE.

Solicitações relacionadas às notificações push

Disabling

Se você optar por usar um método de autenticação por meio de um repositório do usuário como o LDAP, é possível configurar o MobileFirst Server de administração para que você possa usar usuários e grupos com o repositório de usuários para definir a Lista de Controle de Acesso (ACL) do MobileFirst Server de administração. Esse procedimento depende do tipo e da versão do servidor de aplicativos da web usado.

Configurando o perfil completo do WebSphere Application Server para administração do MobileFirst Server

Configure a segurança mapeando as funções Java EE de administração do MobileFirst Server para um conjunto de usuários para ambos os aplicativos da web.

Defina os conceitos básicos da configuração de usuário no console do WebSphere Application Server. O acesso ao console é geralmente por este endereço: https://localhost:9043/ibm/console/

1. Selecione Segurança → Segurança Global.
2. Selecione Assistente de Configuração de Segurança para configurar os usuários. É possível gerenciar contas do usuário individuais selecionando Usuários e Grupos → Gerenciar usuários.
3. Mapeie as funções mfpadmin, mfpdeployer, mfpmonitor e mfpoperator para um conjunto de usuários.
   • Selecione Servidores → Tipos de servidores → Servidores de aplicativos WebSphere.
   • Selecione o servidor.
   • Na guia Configuração, selecione Aplicativos → Aplicativos corporativos.
   • Selecione MobileFirst_Administration_Service.
   • Na guia Configuração, selecione a função Detalhes → Segurança para mapeamento de usuário/grupo.
   • Execute a customização necessária.
   • Clique em ** OK **.
   • Repita as etapas para mapear as funções para o aplicativo da web do console. Dessa vez selecione MobileFirst_Administration_Console.
   • Clique em Salvar para salvar as alterações.

Configurando o perfil Liberty do WebSphere Application Server para administração do MobileFirst Server

No perfil Liberty do WebSphere Application Server, configure as funções de mfpadmin, mfpdeployer, mfpmonitor e mfpoperator no arquivo de configuração server.xml do servidor.

Para configurar as funções de segurança, você deve editar o arquivo server.xml. No elemento <application-bnd> de cada elemento <application>, crie elementos <security-role>. Cada elemento <security-role> destina-se a cada uma das funções: mfpadmin, mfpdeployer, mfpmonitor e mfpoperator. Mapeie as funções para o nome do grupo de usuários apropriado, neste exemplo: mfpadmingroup, mfpdeployergroup, mfpmonitorgroup ou mfpoperatorgroup. Esses grupos são definidos por meio do elemento <basicRegistry>. É possível customizar esse elemento ou substituí-lo completamente por um elemento <ldapRegistry> ou um elemento <safRegistry>.

Em seguida, para manter tempos bons de resposta com um grande número de aplicativos instalados, por exemplo com 80 aplicativos, você deve configurar um conjunto de conexões para o banco de dados de administração.

1. Edite o arquivo server.xml. Por exemplo:

   <security-role name="mfpadmin">
      <group name="mfpadmingroup"/>
   </security-role>
   <security-role name="mfpdeployer">
      <group name="mfpdeployergroup"/>
   </security-role>
   <security-role name="mfpmonitor">
      <group name="mfpmonitorgroup"/>
   </security-role>
   <security-role name="mfpoperator">
      <group name="mfpoperatorgroup"/>
   </security-role>
   
   <basicRegistry id="mfpadmin">
      <user name="admin" password="admin"/>
      <user name="guest" password="guest"/>
      <user name="demo" password="demo"/>
      <group name="mfpadmingroup">
        <member name="guest"/>
        <member name="demo"/>
      </group>
      <group name="mfpdeployergroup">
        <member name="admin" id="admin"/>
      </group>
      <group name="mfpmonitorgroup"/>
      <group name="mfpoperatorgroup"/>
   </basicRegistry>
   

2. Defina o tamanho de AppCenterPool:

   <connectionManager id="AppCenterPool" minPoolSize="10" maxPoolSize="40"/>
   

3. No elemento <dataSource>, defina uma referência para o gerenciador de conexões:

   <dataSource id="MFPADMIN" jndiName="mfpadmin/jdbc/mfpAdminDS" connectionManagerRef="AppCenterPool">
   ...
   </dataSource>
   

Configurando o Apache Tomcat para o MobileFirst Server administration

Deve-se configurar as funções de segurança Java EE para administração do MobileFirst Server no servidor de aplicativos da web Apache Tomcat.

1. Se você instalou a administração do MobileFirst Server manualmente, declare as seguintes funções no arquivo conf/tomcat-users.xml:

   <role rolename="mfpadmin"/>
   <role rolename="mfpmonitor"/>
   <role rolename="mfpdeployer"/>
   <role rolename="mfpoperator"/>
   

2. Incluir funções para os usuários selecionados, por exemplo:

   <user name="admin" password="admin" roles="mfpadmin"/>
   

3. É possível definir o conjunto de usuários conforme descrito na documentação do Apache Tomcat, INSTRUÇÕES de Configuração do Domínio.

Lista de propriedades JNDI dos aplicativos da web MobileFirst Server

Configure as propriedades JNDI para os aplicativos da web MobileFirst Server implementados no servidor de aplicativos.

• Configurando propriedades JNDI para aplicativos da web do MobileFirst Server
• Lista de propriedades JNDI para o serviço de administração do MobileFirst Server
• Lista de propriedades JNDI para o serviço de atualização em tempo real do MobileFirst Server
• Lista de propriedades JNDI para o tempo de execução do MobileFirst
• Lista de propriedades JNDI para o serviço de push do MobileFirst Server

Configurando propriedades JNDI para aplicativos da web do MobileFirst Server

Defina as propriedades JNDI para configurar os aplicativos da web do MobileFirst Server que são implementados no servidor de aplicativos.
Configure as entradas de ambiente JNDI de uma das seguintes formas:

• Configure as entradas de ambiente do servidor. As etapas para configurar as entradas de ambiente do servidor dependem do servidor de aplicativos utilizado:

  • WebSphere Application Server:
    1. No console de administração do WebSphere Application Server, acesse Aplicativos → Tipos de aplicativos → Aplicativos corporativos WebSphere → application_name → Entradas de ambiente para módulos da web.
    2. Nos campos Valor, insira valores que são apropriados para seu ambiente do servidor.

    

  • WebSphere Application Server Liberty:

    Em liberty_install_dir/usr/servers/serverName, edite o arquivo server.xml e declare as propriedades JNDI conforme a seguir:

    <application id="app_context_root" name="app_context_root" location="app_war_name.war" type="war">
          ...
    </application>
    <jndiEntry jndiName="app_context_root/JNDI_property_name" value="JNDI_property_value" />
    

    A raiz de contexto (no exemplo anterior: app_context_root) se conecta entre a entrada JNDI e um aplicativo do MobileFirst específico. Se diversos aplicativos do MobileFirst existirem no mesmo servidor, será possível definir entradas JNDI específicas para cada aplicativo usando um prefixo do caminho do contexto.

    Nota: Algumas propriedades são definidas globalmente no WebSphere Application Server Liberty, sem prefixar o nome da propriedade pela raiz de contexto. Para obter uma lista dessas propriedades, consulte Entradas JNDI globais.

    Para todas as outras propriedades JNDI, os nomes devem ser prefixados com a raiz de contexto do aplicativo:

    • Para o serviço de atualização em tempo real, a raiz de contexto deve ser /[adminContextRoot]config. Por exemplo, se a raiz de contexto do serviço de administração for /mfpadmin, a raiz de contexto do serviço de atualização em tempo real deverá ser /mfpadminconfig.
    • Para o serviço de push, deve-se definir a raiz de contexto como /imfpush. Caso contrário, os dispositivos do cliente não poderão se conectar a ela, já que a raiz de contexto está codificada permanentemente no SDK.
    • Para o aplicativo de Serviço de Administração do MobileFirst e o tempo de execução do MobileFirst Operations Console e do MobileFirst, é possível definir a raiz de contexto que desejar. No entanto, por padrão, ela é /mfpadmin para o Serviço de Administração do MobileFirst, /mfpconsole para o MobileFirst Operations Console e /mfp para o tempo de execução do MobileFirst.

    Por exemplo:

    <application id="mfpadmin" name="mfpadmin" location="mfp-admin-service.war" type="war">
          ...
    </application>
    <jndiEntry jndiName="mfpadmin/mfp.admin.actions.prepareTimeout" value = "2400000" />
    

  • Apache Tomcat:

    Em tomcat_install_dir/conf, edite o arquivo server.xml e declare as propriedades JNDI conforme a seguir:

    <Context docBase="app_context_root" path="/app_context_root">
          <Environment name="JNDI_property_name" override="false" type="java.lang.String" value="JNDI_property_value"/>
    </Context>
    

    • O prefixo do caminho de contexto não é necessário, porque as entradas JNDI são definidas dentro do elemento <Context> de um aplicativo.
    • override="false" é obrigatório.
    • O atribuo type é sempre java.lang.String, a menos que seja especificado de modo diferente para a propriedade.

    Por exemplo:

    <Context docBase="app_context_root" path="/app_context_root">
          <Environment name="mfp.admin.actions.prepareTimeout" override="false" type="java.lang.String" value="2400000"/>
    </Context>
    

• Se você instalar com tarefas Ant, também será possível configurar os valores das propriedades JNDI no momento da instalação.

  Em mfp_install_dir/MobileFirstServer/configuration-samples, edite o arquivo XML de configuração para as tarefas Ant, e declare os valores para as propriedades JNDI usando o elemento da propriedade dentro das seguintes tags:

  • <installmobilefirstadmin>, para MobileFirst Server administração, MobileFirst Operations Consolee serviços de atualização em tempo real. Para obter informações adicionais, consulte Tarefas Ant para instalação de artefatos do MobileFirst Operations Console, do MobileFirst Server, administração do MobileFirst Server e serviços de atualização em tempo real.
  • <installmobilefirstruntime>, para MobileFirst propriedades de configuração de tempo de execução do. Para obter informações adicionais, consulte Tarefas Ant para instalação de ambientes de tempo de execução do MobileFirst.
  • <installmobilefirstpush>, para configuração do serviço de push. Para obter informações adicionais, consulte Tarefas Ant para instalação do serviço de push do MobileFirst Server.

  Por exemplo:

  <installmobilefirstadmin ..>
        <property name = "mfp.admin.actions.prepareTimeout" value = "2400000" />
  </installmobilefirstadmin>
  

Lista de Propriedades JNDI para serviço de administração do MobileFirst Server

Ao configurar o serviço de administração do MobileFirst Server e o MobileFirst Operations Console para seu servidor de aplicativos, você configura propriedades JNDI opcionais e obrigatórias, em específico para Java Management Extensions (JMX).

As seguintes propriedades podem ser configuradas no aplicativo da web do serviço de administração mfp-admin-service.war.

Propriedades JNDI para serviço de administração: JMX

Propriedades JNDI para serviço de administração: tempo limite

Propriedades JNDI para serviço de administração: criação de log

Propriedades JNDI para serviço de administração: proxies

Propriedades JNDI para serviço de administração: topologias

Propriedades JNDI para serviço de administração: banco de dados relacional

Propriedades JNDI para serviço de administração: licenciamento

Propriedades JNDI para serviço de administração: configurações de JNDI

O serviço de administração usa um serviço de atualização em tempo real como recurso auxiliar para armazenar várias configurações. Use essas propriedades para configurar como atingir o serviço de atualização em tempo real.

Propriedades JNDI para serviço de administração: serviço de atualização em tempo real

O serviço de administração usa um serviço de push como recurso auxiliar para armazenar várias configurações de push. Use essas propriedades para configurar como atingir o serviço de push. Como o serviço de push é protegido pelo modelo de segurança OAuth, deve-se configurar várias propriedades para permitir clientes confidenciais em OAuth.

Propriedades JNDI para serviço de administração: serviço de push

Propriedades da JNDI para o MobileFirst Operations Console

As seguintes propriedades podem ser configuradas no aplicativo da web (mfp-admin-ui.war) do MobileFirst Operations Console.

Lista de propriedades JNDI para serviço de atualização em tempo real do MobileFirst Server

Quando você configura o serviço de atualização em tempo real do MobileFirst Server para seu servidor de aplicativos, é possível configurar as seguintes propriedades JNDI. A tabela lista as propriedades JNDI para o serviço de atualização em tempo real do banco de dados relacional IBM.

Para saber como configurar essas propriedades, consulte Configurando propriedades JNDI para aplicativos da web do MobileFirst Server.

Lista de propriedades JNDI para tempo de execução do MobileFirst

Quando você configura o tempo de execução do MobileFirst Server para seu servidor de aplicativos, é necessário configurar as propriedades JNDI opcionais ou obrigatórias.
A tabela a seguir lista as propriedades do MobileFirst que estão sempre disponíveis como entradas JNDI:

Lista de Propriedades JNDI para serviço de push do MobileFirst Server

Configurando Origens de Dados

Descubra alguns detalhes de configuração de origem de dados pertencentes aos bancos de dados suportados.

• Gerenciando o tamanho do log de transações do DB2
• Configurando o failover contínuo do DB2 HADR para origens de dados do MobileFirst Server e do Application Center
• Manipulando conexões antigas
• Dados antigos após a criação ou exclusão de aplicativos do MobileFirst Operations Console

Gerenciando o tamanho do log de transações do DB2

Ao implementar um aplicativo que tem pelo menos 40 MB com o IBM MobileFirst Operations Console, você pode receber um erro de log de transações cheio.

A seguinte saída do sistema é um exemplo do código de erro de log de transações cheio.

Erro de DB2 SQL: SQLCODE=-964, SQLSTATE=57011

O conteúdo de cada aplicativo é armazenado no banco de dados de administração do MobileFirst.

Os arquivos de log ativos são definidos em número pelo LOGPRIMARY e LOGSECOND parâmetros de configuração do banco de dados, e tamanho pelo parâmetro de configuração do banco de dados LOGFILSIZ. Uma única transação não pode usar mais espaço de log do que LOGFILSZ * (LOGPRIMARY + LOGSECOND) * 4096 KB.

O DB2 GET DATABASE CONFIGURATION comando inclui informações sobre o tamanho do arquivo de log e o número de arquivos de log primários e secundários.

Dependendo do maior tamanho do aplicativo do MobileFirst que está implementado, pode ser necessário aumentar o espaço de log do DB2.

Usando o DB2 update db cfg comando, aumente o parâmetro LOGSECOND. Space não está alocados quando o banco de dados é ativado. Em vez disso, o espaço será alocado apenas se necessário.

Configurando o failover contínuo do DB2 HADR para origens de dados do MobileFirst Server e do Application Center

Deve-se ativar o recurso de failover contínuo com o perfil Liberty do WebSphere Application Server e do WebSphere Application Server. Com este recurso, é possível gerenciar uma exceção quando um banco de dados executa failover e é roteado novamente pelo driver JDBC DB2.

Nota: O failover do DB2 HADR não é suportado para Apache Tomcat.

Por padrão, com o DB2 HADR, quando o driver JDBC DB2 executa uma nova rota do cliente após detectar que um banco de dados executou failover durante a primeira tentativa de reutilizar uma conexão existente, o driver aciona com.ibm.db2.jcc.am.ClientRerouteException, com ERRORCODE=-4498 e SQLSTATE=08506. O WebSphere Application Server mapeia essa exceção para com.ibm.websphere.ce.cm.StaleConnectionException antes de ela ser recebida pelo aplicativo.

Nesse caso, o aplicativo terá de capturar a exceção e executar novamente a transação. Os ambientes de tempo de execução do MobileFirst e do Application Center não gerenciam a exceção, mas dependem de um recurso que é chamado de failover contínuo. Para ativar esse recurso, deve-se configurar a propriedade JDBC enableSeamlessFailover como “1”.

Configuração de perfil Liberty do WebSphere Application Server

Deve-se editar o arquivo server.xml e incluir a propriedade enableSeamlessFailover para o elemento properties.db2.jcc das origens de dados do MobileFirst e do Application Center. Por exemplo:

<dataSource jndiName="jdbc/WorklightAdminDS" transactional="false">
  <jdbcDriver libraryRef="DB2Lib"/>
  <properties.db2.jcc databaseName="WLADMIN"  currentSchema="WLADMSC"
                      serverName="db2server" portNumber="50000"
                      enableSeamlessFailover= "1"
                      user="worklight" password="worklight"/>
</dataSource>

configuração do WebSphere Application Server

No console administrativo do WebSphere Application Server para cada origem de dados do MobileFirst e do Application Center:

1. Acesse Recursos → JDBC → Origens de dados → Nome do DataSource.
2. Selecione Novo e inclua a seguinte propriedade customizada, ou atualize os valores, se as propriedades já existirem: enableSeamlessFailover : 1
3. Dê um clique em Aplicar.
4. Salve a sua configuração.

Para obter mais informações sobre como configurar uma conexão com um banco de dados DB2 ativado por HADR, consulte Configurando uma conexão com um banco de dados DB2 ativado por HADR.

Manipulando conexões antigas

Configure seu servidor de aplicativos para evitar problemas de tempo limite de banco de dados.

Uma StaleConnectionException é uma exceção gerada pelo código de conexão do banco de dados do perfil do servidor de aplicativos Java quando um driver JDBC retorna um erro irrecuperável de uma solicitação de conexão ou operação. A StaleConnectionException é levantada quando o fornecedor de base de dados emite uma exceção para indicar que uma conexão atualmente no conjunto de conexões não é mais válida. Essa exceção pode acontecer por vários motivos. A causa mais comum da StaleConnectionException é devido à recuperação de conexões do conjunto de conexões com o banco de dados e à descoberta de que a conexão atingiu o tempo limite ou caiu quando ficou inutilizada por um longo período.

É possível configurar seu servidor de aplicativos para evitar essa exceção.

Configuração do Apache Tomcat

MySQL
O banco de dados MySQL fecha suas conexões após um período de não atividade em uma conexão. Esse tempo limite é definido pela variável do sistema chamada wait_timeout. O padrão é de 28.000 segundos (8 horas).

Quando um aplicativo tenta conectar ao banco de dados após o fechamento da conexão por MySQL, a seguinte exceção é gerada:

com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after statement closed.

Edite os arquivos server.xml e context.xml e, para cada elemento <Resource>, inclua as seguintes propriedades:

• testOnBorrow=”true”
• validationQuery=”select 1”

Por exemplo:

<Resource name="jdbc/AppCenterDS"
  type="javax.sql.DataSource"
  driverClassName="com.mysql.jdbc.Driver"
  ...
  testOnBorrow="true"
  validationQuery="select 1"
/>

Configuração de perfil Liberty do WebSphere Application Server

Edite o arquivo server.xml e, para cada elemento <dataSource> (tempo de execução e bancos de dados do Application Center), inclua um elemento <connectionManager> com a propriedade agedTimeout:

<connectionManager agedTimeout="timeout_value"/>

O valor de tempo limite depende principalmente do número de conexões abertas em paralelo, mas também dos números mínimo e máximo de conexões no conjunto. Por isso, deve-se ajustar os diferentes atributos connectionManager para identificar os valores mais adequados. Para obter informações adicionais sobre o elemento connectionManager, consulte Liberty: elementos de configuração no arquivo server.xml.

Nota: O MySQL, em conjunto com o perfil Liberty do WebSphere Application Server ou o perfil completo do WebSphere Application Server, não é classificado como uma configuração suportada. Para obter informações adicionais, consulte WebSphere Application Server Support Statement. Use o IBM DB2 ou outro banco de dados que seja suportado pelo WebSphere Application Server para beneficiar-se de uma configuração totalmente suportada pelo Suporte IBM.

Dados antigos após criar ou excluir aplicativos do

MobileFirst Operations Console

Em um servidor de aplicativos Tomcat 8, se você usar um banco de dados MySQL, algumas chamadas de MobileFirst Operations Console para serviços retornam um erro 404.

Em um servidor de aplicativos do Tomcat 8, se você trabalhar com um banco de dados MySQL, ao usar o MobileFirst Operations Console para excluir um aplicativo ou incluir um novo e tentar atualizar o console algumas vezes, dados antigos poderão ser exibidos. Por exemplo, os usuários podem ver um aplicativo já excluído na lista.

Para evitar esse problema, mude o nível de isolamento para READ_COMMITTED, na origem de dados ou no sistema de gerenciamento de banco de dados.

Para o significado de READ_COMMITTED, consulte a documentação do MySQL em http://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html.

• Para mudar o nível de isolamento para READ_COMMITTED na origem de dados, modifique o arquivo de configuração do Tomcat server.xml: na seção <Resource name=”jdbc/mfpAdminDS” …/>, inclua o atributo defaultTransactionIsolation=”READ_COMMITTED”.
• Para mudar o nível de isolamento para READ_COMMITTED globalmente no sistema de gerenciamento de banco de dados, consulte a página SET TRANSACTION Syntax da documentação do MySQL em http://dev.mysql.com/doc/refman/5.7/en/set-transaction.html.

Configuração de perfil completo do WebSphere Application Server

DB2 ou Oracle
Para minimizar os problemas de conexão antiga, verifique a configuração dos conjuntos de conexões em cada origem de dados no console de administração do WebSphere Application Server.

1. Efetue login no console administrativo do WebSphere Application Server.
2. Selecione Recursos → Provedores JDBC → database_jdbc_provider → Origens de dados → your_data_source → Propriedades do conjunto de conexões.
3. Configure o valor Mínimo de conexões como 0.
4. Configure o valor Tempo de Coleta para que ele seja menor que o valor Tempo Limite Não Usado.
5. Certifique-se de que a propriedade Política de limpeza esteja configurada como EntirePool (padrão).

Para obter mais informações, consulte Configurações do conjunto de conexões.

MySQL

1. Efetue login no console administrativo do WebSphere Application Server.
2. Selecione Recursos → JDBC → Origens de dados.
3. Para cada origem de dados MySQL:
   • Clique na origem de dados.
   • Selecione as propriedades do Conjunto de conexões em Propriedades adicionais.
   • Modifique o valor da propriedade Tempo Limite Transcorrido. O valor deve ser inferior ao da variável do sistema MySQL wait_timeout para que as conexões sejam limpas antes de o MySQL fechar essas conexões.
   • Clique em ** OK **.

Nota: O MySQL, em conjunto com o perfil Liberty do WebSphere Application Server ou o perfil completo do WebSphere Application Server, não é classificado como uma configuração suportada. Para obter informações adicionais, consulte WebSphere Application Server Support Statement. Use o IBM DB2 ou outro banco de dados que seja suportado pelo WebSphere Application Server para beneficiar-se de uma configuração totalmente suportada pelo Suporte IBM.

Configurando mecanismos de criação de log e monitoramento

Mobile Foundation relata erros, avisos e mensagens informativas em um arquivo de log. O mecanismo de criação de log subjacente varia de um servidor de aplicativos para outro.

MobileFirst Server

Mobile Foundation (MobileFirst Server O abreviado) usa o pacote java.util.logging padrão. Por padrão, toda a criação de log do MobileFirst vai para os arquivos de log do servidor de aplicativos. É possível controlar a criação de log do MobileFirst Server usando as ferramentas padrão que estão disponíveis em cada servidor de aplicativos. Por exemplo, se desejar ativar a criação de logs de rastreio no WebSphere Application Server Liberty, inclua um elemento de rastreio no arquivo server.xml. Para ativar a criação de logs de rastreio no WebSphere Application Server, use a tela de criação de log no console e ative o rastreio para logs do MobileFirst.

MobileFirst Todos os logs do começam com com.ibm.mfp.
Os logs do Application Center começam com com.ibm.puremeap.

Para obter mais informações sobre os modelos de criação de log de cada servidor de aplicativos, incluindo o local dos arquivos de log, consulte a documentação para o servidor de aplicativos relevante, conforme mostrado na tabela a seguir.

Mapeamentos em nível de log

MobileFirst Server usa a API java.util.logging. Os níveis de criação de log são mapeados para os seguintes níveis:

• WL.Logger.debug: FINE
• WL.Logger.info: INFO
• WL.Logger.warn: WARNING
• WL.Logger.error: SEVERE

Ferramentas de monitoramento de log

Para Apache Tomcat, é possível usar o IBM Operations Analytics - Log Analysis ou outras ferramentas de monitoramento de arquivos de log padrão de mercado para monitorar logs e destacar erros e avisos.

Para o WebSphere Application Server, use os recursos de visualização de log que estão descritos no IBM Knowledge Center. As URLs estão listadas na tabela na seção MobileFirst Server desta página.

Conectividade backend

Para ativar o rastreio para monitorar a conectividade backend, consulte a documentação da plataforma do servidor de aplicativos específica na tabela da seção MobileFirst Server desta página. Use o pacote com.ibm.mfp.server.js.adapter e configure o nível de log para FINEST.

Log de auditoria para operações de administração

MobileFirst Operations Console armazena um log de auditoria para login, logout e para todas as operações de administração, como implementação de aplicativos ou adaptadores ou bloqueio de aplicativos. É possível desativar o log de auditoria, configurando a propriedade JNDI mfp.admin.audit como false no aplicativo da web do serviço de administração do MobileFirst (mfp-admin-service.war).

Quando o log de auditoria estiver ativado, você poderá fazer seu download no MobileFirst Operations Console clicando no link Log de Auditoria no rodapé da página.

Problemas de login e autenticação

Para diagnosticar problemas de login e autenticação, ative o pacote com.ibm.mfp.server.security para rastreio e configure o nível de log para FINEST.

Configurando vários tempos de execução

É possível configurar o MobileFirst Server com vários tempos de execução, criando uma diferenciação visual entre “tipos” de aplicativos no MobileFirst Operations Console.

Nota: diversos tempos de execução não são suportados em uma instância do servidor Mobile Foundation criada pelo serviço Mobile Foundation IBM Cloud. Por isso, é necessário criar diversas instâncias de serviço no serviço IBM Cloud.

Ir para

• Configurando vários tempos de execução no perfil Liberty do WebSphere
• Registrando aplicativos e implementando adaptadores em diferentes tempos de execução
• Exportando e importando configurações de tempo de execução

Configurando vários tempos de execução no perfil Liberty do WebSphere

1. Abra o arquivo server.xml do servidor de aplicativos. Geralmente localizado na pasta [application-server]/usr/servers/server-name/. Por exemplo, com o MobileFirst Developer Kit, o arquivo pode ser localizado em [installation-folder]/mfp-server/usrs/servers/mfp/server.xml.

2. Inclua um segundo elemento do aplicativo:

   <application id="second-runtime" name="second-runtime" location="mfp-server.war" type="war">
        <classloader delegation="parentLast">
            </classloader>
   </application>
   

3. Inclua um segundo conjunto de entradas JNDI:

   <jndiEntry jndiName="second-runtime/mfp.analytics.url" value='"http://localhost:9080/analytics-service/rest"'/>
   <jndiEntry jndiName="second-runtime/mfp.analytics.console.url" value='"http://localhost:9080/analytics/console"'/>
   <jndiEntry jndiName="second-runtime/mfp.analytics.username" value='"admin"'/>
   <jndiEntry jndiName="second-runtime/mfp.analytics.password" value='"admin"'/>
   <jndiEntry jndiName="second-runtime/mfp.authorization.server" value='"embedded"'/>
   

4. Inclua um segundo elemento dataSource:

   <dataSource jndiName="second-runtime/jdbc/mfpDS" transactional="false">
        <jdbcDriver libraryRef="DerbyLib"/>
        <properties.derby.embedded databaseName="${wlp.install.dir}/databases/second-runtime" user='"MFPDATA"'/>
   </dataSource>
   

   Observação:

   • Certifique-se de que o dataSource esteja apontando para um esquema do banco de dados diferente.
   • Certifique-se de ter criado outra instância de banco de dados para o novo tempo de execução.
   • No ambiente de desenvolvimento, inclua createDatabase="create" no elemento-filho properties.derby.embedded.

5. Reinicie o servidor de aplicativos.

Registrando aplicativos e implementando adaptadores em diferentes tempos de execução

Quando um MobileFirst Server é configurado com vários tempos de execução, o registro de aplicativos e a implementação de adaptadores são um pouco diferentes.

• Registrando e implementando a partir do MobileFirst Operations Console
• Registrando e implementando a partir da linha de comandos

Registrando e implementando a partir do MobileFirst Operations Console

Ao executar essas ações no MobileFirst Operations Console, agora é preciso selecionar o tempo de execução para registro ou implementação.

Registrando e implementando a partir da linha de comandos

Ao executar essas ações usando a ferramenta de linha de comandos mfpdev, agora é preciso incluir o nome do tempo de execução para registro ou implementação.

Para registrar um aplicativo: mfpdev app register <server-name> <runtime-name>.

mfpdev app register local second-runtime

Para implementar um adaptador: mfpdev adapter deploy <server-name> <runtime-name>.

mfpdev adapter deploy local second-runtime

• local é o nome da definição do servidor padrão no MobileFirst CLI. Substitua local por um nome de definição do servidor que precisa de registro ou implementação.
• runtime-name é o nome do tempo de execução para registro ou implementação.

Saiba mais com os seguintes comandos de ajuda da CLI:

• mfpdev help server add
• mfpdev help app register
• mfpdev help adapter deploy

Exportando e importando configurações de tempo de execução

É possível exportar uma configuração de tempo de execução e importá-la para outro MobileFirst Server usando as APIs REST do serviço de administração do MobileFirst Server.

Por exemplo, é possível definir uma configuração de tempo de execução em um ambiente de desenvolvimento, exportar sua configuração e, em seguida, importá-la para um ambiente de teste para uma configuração rápida e, em seguida, configurá-la melhor para as necessidades específicas do ambiente de teste.

Descubra todas as APIs REST disponíveis na Referência da API.

Configurando rastreamento de licença

O rastreamento de licença é ativado por padrão. Leia os tópicos a seguir para saber como é possível configurar o rastreamento de licença. Para obter mais informações sobre rastreamento de licença, consulte Rastreamento de licença.

• Configurando rastreamento de licença para dispositivo do cliente e dispositivo endereçável
• Configurando arquivos de log do IBM License Metric Tool

Configurando rastreamento de licença para dispositivo do cliente e dispositivo endereçável

O rastreamento de licença para dispositivos do cliente e dispositivos endereçáveis fica ativado por padrão. Relatórios de licença estão disponíveis no MobileFirst Operations Console. É possível especificar as propriedades JNDI a seguir para mudar as configurações padrão para rastreamento de licença.

Nota: Se você tiver um contrato que define o uso do licenciamento de token, consulte também Instalando e configurando para licenciamento de token.

É possível especificar as propriedades JNDI a seguir para mudar as configurações padrão para rastreamento de licença.

mfp.device.decommission.when
O número de dias de inatividade após o qual um dispositivo é desatribuído pela tarefa de desatribuição de dispositivo. Relatórios de licença não contam dispositivos desatribuídos como dispositivos ativos. O valor padrão para a propriedade é 90 dias. Não configure um valor menor que 30 dias se seu software for licenciado pelo Dispositivo do Cliente ou pelo Dispositivo Endereçável ou os relatórios de licença podem não ser suficientes para comprovar a conformidade.

mfp.device.archiveDecommissioned.when
Um valor, em dias, que define quando dispositivos desatribuídos são colocados em um archive quando a tarefa de desatribuição é executada. Os dispositivos arquivados são gravados em um arquivo no diretório home\devices_archive do IBM MobileFirst Server. O nome do arquivo contém o registro de data e hora em que o archive foi criado. O valor padrão é 90 dias.

mfp.device.decommissionProcessingInterval
Define com que frequência (em segundos) a tarefa de desatribuição é executada. Padrão: 86400, que é um dia. A tarefa de desatribuição executa as ações a seguir:

• Desatribui dispositivos inativos com base na configuração mfp.device.decommission.when.
• Opcionalmente, arquiva dispositivos desatribuídos mais antigos com base na configuração mfp.device.archiveDecommissioned.when.
• Gera o relatório de rastreamento de licença.

mfp.licenseTracking.enabled
Um valor usado para ativar ou desativar rastreamento de licença no Mobile Foundation. Por padrão, o rastreamento de licença fica ativado. Por motivos de desempenho, é possível desativar essa sinalização quando o Mobile Foundation não for licenciado por Dispositivo do cliente ou Dispositivo endereçável. Quando o rastreamento de dispositivo for desativado, os relatórios de licença também serão desativados e nenhuma métrica de licença será gerada. Nesse caso, somente registros do IBM License Metric Tool para contagem de Aplicativos são gerados.

Para obter informações adicionais sobre como especificar propriedades JNDI, consulte Lista de propriedades JNDI para tempo de execução do MobileFirst.

Configurando arquivos de log do IBM License Metric Tool

O Mobile Foundation gera arquivos do IBM Software License Metric Tag (SLMT). Versões do IBM License Metric Tool que suportam o IBM Software License Metric Tag podem gerar Relatórios de Consumo de Licença. Leia isso para entender como configurar o local e o tamanho máximo dos arquivos gerados.

Por padrão, os arquivos do IBM Software License Metric Tag estão nos seguintes diretórios:

• No Windows: %ProgramFiles%\ibm\common\slm
• Em sistemas operacionais como UNIX e UNIX: /var/ibm/common/slm

Se os diretórios não forem graváveis, os arquivos serão criados no diretório de log do servidor de aplicativos que executa o ambiente de tempo de execução do MobileFirst.

É possível configurar o local e o gerenciamento desses arquivos com as propriedades a seguir:

• license.metric.logger.output.dir: local dos arquivos do IBM Software License Metric Tag
• license.metric.logger.file.size: tamanho máximo de um arquivo SLMT antes de uma rotação ser executada. O tamanho padrão é 1 MB.
• license.metric.logger.file.number: número máximo de archives SLMT para manter em rotações. O número padrão é 10.

Para mudar os valores padrão, deve-se criar um arquivo de propriedade Java, com o formato key=value, e fornecer o caminho para o arquivo de propriedades por meio da propriedade JVM license_metric_logger_configuration.

Para obter informações adicionais sobre relatórios do IBM License Metric Tool, consulte Integração com o IBM License Metric Tool.

Configuração SLL e adaptadores HTTP do WebSphere Application Server

Ao configurar uma propriedade, é possível permitir que adaptadores HTTP se beneficiem da configuração SSL do WebSphere.

Por padrão, os adaptadores HTTP não usam SSL do WebSphere concatenando o armazenamento confiável do Java Runtime Environment (JRE) com o keystore do MobileFirst Server, que é descrito em Configurando o keystore do MobileFirst Server. Consulte também Configurando SSL entre adaptadores e servidores backend usando certificados autoassinados.

Para que adaptadores HTTP usem a configuração SSL do WebSphere, configure a propriedade JNDI ssl.websphere.config como true. A configuração tem os seguintes efeitos por ordem de precedência:

1. Os adaptadores em execução no WebSphere usam o keystore do WebSphere e não o keystore do MobileFirst Server.
2. Se a propriedade ssl.websphere.alias estiver configurada, o adaptador usará a configuração de SSL associada ao alias, conforme configurado nessa propriedade.