Instalando o servidor MobileFirst em um servidor de aplicativos
Visão Geral
A instalação dos componentes pode ser feita usando tarefas Ant, o Server Configuration Tool ou manualmente. Descubra quais são os pré-requisitos e os detalhes sobre o processo de instalação para que seja possível instalar os componentes no servidor de aplicativos com sucesso.
Antes de continuar com a instalação dos componentes no servidor de aplicativos, assegure-se de que os bancos de dados e as tabelas para os componentes estejam preparados e prontos para serem usados. Para obter informações adicionais, consulte Configurando bancos de dados.
A topologia do servidor para instalar os componentes também deve estar definida. Consulte Topologias e fluxos de rede.
Dependendo de sua escolha de servidor de aplicativos, selecione um dos tópicos a seguir para descobrir os pré-requisitos que devem ser cumpridos antes da instalação dos componentes do MobileFirst Server.
MobileFirst Server tem alguns requisitos para a configuração do Apache Tomcat que estão detalhados nos tópicos a seguir.
Assegure-se de cumprir os seguintes critérios:
Apache Tomcat deve ser executado com JRE 7.0 ou posterior.
A configuração JMX deve ser ativada para permitir a comunicação entre o serviço de administração e o componente de tempo de execução. A comunicação usa RMI conforme descrito em Configurando a conexão JMX para Apache Tomcat abaixo.
Você deve configurar uma conexão JMX segura para o servidor de aplicativos Apache Tomcat.
O Server Configuration Tool e as tarefas Ant pode configurar um padrão seguro conexão JMX, que inclui a definição de uma porta remota JMX, e a definição de propriedades de autenticação. Eles modificam tomcat_install_dir/bin/setenv.bat e tomcat_install_dir/bin/setenv.sh para incluir essas opções em CATALINA_OPTS:
Nota: 8686 é um valor padrão. O valor para essa porta poderá ser alterado se a porta não estiver disponível no computador.
O arquivo setenv.bat será usado se você iniciar o Apache Tomcat com tomcat_install_dir/bin/startup.bat ou tomcat_install_dir/bin/catalina.bat.
O arquivo setenv.sh será usado se você iniciar o Apache Tomcat com tomcatInstallDir/bin/startup.sh ou tomcat_install_dir/bin/catalina.sh.
Esse arquivo talvez não seja usado se você iniciar o Apache Tomcat com outro comando. Se você tiver instalado o Apache Tomcat Windows Service Installer, o ativador de serviço não usará o setenv.bat.
Importante: Esta configuração não é segura por padrão. Para proteger a configuração, você deve concluir manualmente as etapas 2 e 3 do procedimento a seguir.
Configurando Manualmente o Apache Tomcat:
Para uma configuração simples, inclua as seguintes opções para CATALINA_OPTS:
Se a instância Tomcat está atrás de um firewall, o JMX Remote de Ciclo de Listener deve ser configurado. Consulte a documentação do Apache Tomcat para JMX Remote Listener de Ciclo de Vida.
As propriedades do ambiente a seguir também devem ser usadas para a seção Contexto do aplicativo de serviço de administração no arquivo server.xml, como no exemplo a seguir:
registryPort deve ter o mesmo valor que o atributo rmiRegistryPortPlatform do JMX Remote Lifecycle Listener.
serverPort deve ter o mesmo valor que o atributo rmiServerPortPlatform do JMX Remote Lifecycle Listener.
Se você instalou o Apache Tomcat com o Apache Tomcat Windows Service Installer em vez de incluir as opções em CATALINA_OPTS, execute tomcat_install_dir/bin/Tomcat7w.exe e inclua as opções na guia Java da janela Propriedades.
Pré-requisitos do WebSphere Application Server Liberty
O IBM Mobile Foundation tem alguns requisitos para a configuração do servidor Liberty que são detalhados nos tópicos seguintes.
O Liberty deve ser executado com JRE 7.0 ou posterior. JRE 6.0 não é suportado.
Algumas versões do Liberty suportam os recursos de Java EE 6 e Java EE 7. Por exemplo, o recurso Liberty jdbc-4.0 faz parte de Java EE 6, enquanto o recurso Liberty jdbc-4.1 faz parte de Java EE 7. O MobileFirst Server V8.0.0 pode ser instalado com recursos de Java EE 6 ou Java EE 7. Entretanto, se desejar executar uma versão mais antiga do MobileFirst Server no mesmo servidor Liberty, você deverá usar os recursos do Java EE 6. MobileFirst Server V7.1.0 e anterior não suporta recursos do Java EE 7.
O JMX deve ser configurado conforme documentado em Configurando a conexão JMX para o perfil Liberty do WebSphere Application Server abaixo.
Para uma instalação em um ambiente de produção, talvez você queira iniciar o servidor Liberty como um serviço em sistemas Windows, Linux ou UNIX para que: os componentes do MobileFirst Server são iniciados automaticamente quando o computador é iniciado.
O processo que executa o servidor Liberty não seja interrompido quando o usuário, que iniciou o processo, efetuar logout.
MobileFirst Server V8.0.0 não possa ser implementado em um servidor Liberty contendo os componentes do MobileFirst Server implementados de versões anteriores.
Para uma instalação no ambiente do Liberty Collective, o controlador do Liberty Collective e os membros de cluster do Liberty Collective devem ser configurados conforme documentado em
Configurando um Liberty Collective.
O MobileFirst Server requer que a conexão JMX segura seja configurada.
O Server Configuration Tool e as tarefas Ant pode configurar um padrão seguro conexão JMX, que inclui a geração de um certificado SSL auto-assinado por um período de validade de 365 dias. Essa configuração não deve ser usada para produção.
O rest-connector está disponível para WebSphere Application Server, Liberty Core e outras edições do Liberty, mas é possível empacotar um servidor Liberty com um subconjunto dos recursos disponíveis. Para verificar se o recurso rest-connector está disponível em sua instalação do Liberty, insira o comando a seguir:
liberty_install_dir/bin/productInfo featureInfo
Nota: verifique se a saída desse comando contém restConnector-1.0.
Pré-requisitos do WebSphere Application Server e do WebSphere Application Server Network Deployment
MobileFirst Server O tem alguns requisitos para a configuração do WebSphere Application Server e do WebSphere Application Server Network Deployment que são detalhados nos tópicos seguintes.
Assegure-se de cumprir os seguintes critérios:
Use uma versão suportada do WebSphere Application Server. Consulte Requisitos do Sistema.
A segurança administrativa deve estar ativada. MobileFirst Operations Console, o serviço de administração do MobileFirst Server e o serviço de configuração do MobileFirst Server são protegidos pelas funções de segurança. Para obter informações adicionais, consulte Ativando a Segurança.
A configuração JMX deve ser ativada para permitir a comunicação entre o serviço de administração e o componente de tempo de execução. A comunicação usa SOAP. Para WebSphere Application Server Network Deployment, o RMI pode ser usado. Para obter informações adicionais, consulte Configurando a conexão JMX para WebSphere Application Server e WebSphere Application Server Network Deployment abaixo.
O MobileFirst Server requer que a conexão JMX segura seja configurada.
O MobileFirst Server requer acesso à porta SOAP ou à porta RMI para executar operações JMX. Por padrão, a porta SOAP está ativa em um WebSphere Application Server. MobileFirst Server usa a porta SOAP por padrão. Se ambas as portas SOAP e RMI estiverem desativadas, o MobileFirst Server não será executado.
O RMI é suportado somente pelo WebSphere Application Server Network Deployment. O RMI não é suportado por um perfil independente, ou um server farm do WebSphere Application Server.
Você deve ativar Administrativa e Segurança do Aplicativo.
Pré-requisitos do sistema de arquivos
Para instalar o MobileFirst Server para um servidor de aplicativos, as ferramentas de instalação do MobileFirst devem ser executadas por um usuário que possui privilégios do sistema de arquivos específicos.
As ferramentas de instalação incluem:
IBM Installation Manager
O Server Configuration Tool
As tarefas Ant para implementar o MobileFirst Server
Para o perfil Liberty do WebSphere Application Server, é preciso ter a permissão necessária para executar as seguintes ações:
Leia os arquivos no diretório de instalação do Liberty.
Criar arquivos no diretório de configuração do servidor Liberty, que geralmente é usr/servers/server-name, para criar cópias de backup e modificar server.xml e jvm.options.
Criar arquivos e diretórios no diretório de recurso compartilhado do Liberty, que geralmente é usr/shared.
Criar arquivos no diretório de aplicativos do servidor Liberty, que geralmente é usr/servers/server-name/apps.
Para o perfil completo do WebSphere Application Server e o WebSphere Application Server Network Deployment, é preciso ter a permissão necessária para executar as seguintes ações:
Ler os arquivos no diretório de instalação do WebSphere Application Server.
Ler o arquivo de configuração do perfil completo do WebSphere Application Server selecionado ou do perfil do Deployment Manager.
Executar o comando wsadmin.
Criar arquivos no diretório de configuração de perfis. As ferramentas de instalação colocam recursos, como as bibliotecas compartilhadas ou drivers JDBC, nesse diretório.
Para o Apache Tomcat, deve-se ter a permissão necessária para executar as ações a seguir:
Leia o diretório de configuração.
Criar arquivos de backup e modificar arquivos no diretório de configuração, como server.xml e tomcat-users.xml.
Criar arquivos de backup e modificar arquivos no diretório bin, como setenv.bat.
Criar arquivos no diretório lib.
Criar arquivos no diretório webapps.
Para todos esses servidores de aplicativos, o usuário que executa o servidor de aplicativos deve ser capaz de ler os arquivos que foram criados pelo usuário que executou as ferramentas de instalação do MobileFirst.
Instalando com o Server Configuration Tool
Use o Server Configuration Tool para instalar os componentes do MobileFirst Server em seu servidor de aplicativos.
O Server Configuration Tool pode configurar o banco de dados e instalar os componentes em um servidor de aplicativos. Essa ferramenta destina-se a um único usuário. Os arquivos de configuração são armazenados em disco. O diretório no qual eles são armazenados pode ser modificado com o menu Arquivo → Preferências. Os arquivos devem ser usados somente por uma instância do Server Configuration Tool no momento. A ferramenta não gerencia acesso simultâneo ao mesmo arquivo. Se você tiver várias instâncias da ferramenta acessando o mesmo arquivo, os dados podem ser perdidos. Para obter informações adicionais sobre como a ferramenta cria e configura os bancos de dados, consulte Criar as tabelas de banco de dados com o Server Configuration Tool. Se os bancos de dados existirem, a ferramenta poderá detectá-los testando a presença e o conteúdo de algumas tabelas de teste e não modificará essas tabelas de banco de dados.
É possível usar o Server Configuration Tool se você estiver nos seguintes sistemas operacionais:
Windows x86 ou x86-64
macOS x86-64
Linux x86 ou Linux x86-64
A ferramenta não está disponível em outros sistemas operacionais. É necessário usar tarefas Ant para instalar os componentes do MobileFirst Server, conforme descrito em Instalando com tarefas Ant.
O ativador do ServerConfigurationTool (SCT) no Mac OS requer a instalação do Java SE 6 Runtime anterior. Você poderá ver a mensagem abaixo quando iniciar o ativador do SCT no Mac OS.
Como solução alternativa, é possível seguir uma das abordagens a seguir e executar o SCT usando o executável do SCT sem ter que instalar o Java SE 6 Runtime.
Abordagem 1
Clique com o botão direito no ativador ServerConfigurationTool.
Selecione Mostrar conteúdos do pacote
Clique em Conteúdos > MacOS.
Clique no executável ServerConfigurationTool para ativar o SCT.
Abordagem 2
É possível ter o Java SE 8 e o Java SE6 instalados em seu computador sem problemas.
Quando a janela pop-up aparecer ao usar o ativador do SCT, clique em Mais informações.
Você será direcionado para o site de Suporte da Apple. Aqui, é possível localizar mais instruções sobre como obter o Java SE 6 Runtime.
Siga as instruções, instale o Java SE 6 Runtime e, em seguida, inicie o ativador do SCT.
Topologias suportadas
O Server Configuration Tool instala os componentes do MobileFirst Server com as seguintes topologias:
Todos os componentes (MobileFirst Operations Console, o serviço de administração do MobileFirst Server, o serviço de atualização em tempo real do MobileFirst Server e o tempo de execução do MobileFirst) estão no mesmo servidor de aplicativos. No entanto, no WebSphere Application Server Network Deployment, ao instalar em um cluster, é possível especificar um cluster diferente para a administração e serviços de atualização em tempo real e para o tempo de execução. No Liberty Collective, o MobileFirst Operations Console, o serviço de administração e o serviço de atualização em tempo real são instalados em um controlador coletivo e o tempo de execução em um membro coletivo.
Se o serviço de push do MobileFirst Server estiver instalado, ele também será instalado no mesmo servidor. No entanto, no WebSphere Application Server Network Deployment, ao instalar em um cluster, é possível especificar um cluster diferente para o serviço de push. No Liberty Collective, o serviço de push é instalado em um membro do Liberty que pode ser igual ao membro onde o tempo de execução está instalado.
Todos os componentes usam o mesmo sistema de banco de dados e usuário. Para DB2, todos os componentes também usam o mesmo esquema.
O Server Configuration Tool instala os componentes para um único servidor, exceto para o Liberty Collective e o WebSphere Application Server Network Deployment para implementação assimétrica. Para uma instalação em vários servidores, um farm deve ser configurado após a ferramenta ser executada. A configuração de server farm não é necessária no WebSphere Application Server Network Deployment.
Para outras topologias ou outras configurações de banco de dados, é possível instalar os componentes com tarefas Ant ou manualmente.
Executando o Server Configuration Tool
Antes de executar o Server Configuration Tool, certifique-se de que os seguintes requisitos sejam preenchidos:
O banco de dados e as tabelas para os componentes estão preparados e prontos para uso. Consulte Configurando bancos de dados.
No painel Configurações de Console, selecione se deseja ou não instalar o MobileFirst Operations Console. Se o console não estiver instalado, será necessário usar ferramentas de linha de comandos (mfpdev ou mfpadm) ou a API REST para interagir com o serviço de administração do MobileFirst Server.
No painel Seleção de Banco de Dados, selecione o sistema de gerenciamento de banco de dados que pretende usar. Todos os componentes usam o mesmo tipo de banco de dados e a mesma instância de banco de dados. Para obter informações adicionais sobre as áreas de janela do banco de dados, consulte Criar as tabelas de banco de dados com o Server Configuration Tool.
No painel Seleção de Servidor de Aplicativos, selecione o tipo de servidor de aplicativos em que deseja implementar o MobileFirst Server.
No painel Configurações do Servidor de Aplicativos, escolha o servidor de aplicativos e execute as etapas a seguir:
Para uma instalação no WebSphere Application Server Liberty:
Insira o diretório de instalação do Liberty e o nome do servidor no qual deseja instalar o MobileFirst Server.
É possível criar um usuário padrão para efetuar login no console. Esse usuário é criado no registro Básico do Liberty. Para uma instalação de produção, talvez você queira limpar a opção Criar um Usuário Padrão e configurar o acesso de usuário após a instalação. Para obter mais informações, consulte Configurando a autenticação do usuário para administração do MobileFirst Server.
Selecione o tipo de implementação: Implementação Independente (padrão), Implementação de Server Farm ou Implementação de Liberty Collective.
Se a opção de implementação do Liberty Collective for selecionada, execute as seguintes etapas:
Especifique o servidor Liberty Collective:
Onde o serviço de administração e o serviço de atualização em tempo real do MobileFirst Operations Console estão instalados. O servidor deve ser um controlador do Liberty Collective.
Onde o tempo de execução está instalado. O servidor deve ser um membro do Liberty Collective.
No qual o serviço de push está instalado. O servidor deve ser um membro do Liberty Collective.
Insira o ID do servidor do membro. Esse identificador deve ser diferente para cada membro do Collective.
Insira o nome do cluster dos membros coletivos.
Insira o nome do host do controlador e o número da porta HTTPS. Os valores devem ser iguais ao que está definido no elemento variable dentro do arquivo server.xml do controlador coletivo do Liberty.
Insira o nome do usuário e a senha do administrador do controlador.
Para uma instalação no WebSphere Application Server ou no WebSphere Application Server Network Deployment:
Insira o diretório de instalação do WebSphere Application Server.
Selecione o perfil do WebSphere Application Server onde você deseja instalar o MobileFirst Server. Se você instalar no WebSphere Application Server Network Deployment, selecione o perfil do gerenciador de implementação. No perfil de gerenciador de implementação, é possível selecionar um escopo (Servidor ou Cluster). Se selecionar Cluster, você deverá especificar o cluster:
Onde o tempo de execução está instalado.
Onde o serviço de administração e o serviço de atualização em tempo real do MobileFirst Operations Console estão instalados.
No qual o serviço de push está instalado.
Insira um ID e uma senha de login de administrador. O usuário administrador deve ter uma função de administrador.
Se você selecionar a opção Declarar o WebSphere Administrator como um usuário administrador no MobileFirst Operations Console, o usuário que é usado para instalar o MobileFirst Server será mapeado para a função de segurança de administração do console e poderá efetuar login no console com privilégios de administrador. Esse usuário também é mapeado para a função de segurança do serviço de atualização em tempo real. O nome do usuário e a senha são configurados como propriedades JNDI (mfp.config.service.user e mfp.config.service.password) do serviço de administração.
Se você não selecionar a opção Declarar o WebSphere Administrator como um usuário administrador no MobileFirst Operations Console, antes de usar o MobileFirst Server, deve-se executar as seguintes tarefas:
Ativar a comunicação entre o serviço de administração e o serviço de atualização em tempo real:
Mapeando um usuário para a função de segurança configadmin do serviço de atualização em tempo real.
Incluindo o ID e a senha de login desse usuário nas propriedades JNDI (mfp.config.service.user e mfp.config.service.password) do serviço de administração.
Insira o diretório de instalação do Apache Tomcat.
Insira a porta usada para a comunicação JMX com RMI. Por padrão, o valor é 8686. O Server Configuration Tool modifica o arquivo tomcat_install_dir/bin/setenv.bat ou tomcat_install_dir/bin/setenv.sh para abrir essa porta. Se desejar abrir a porta manualmente, ou se você já tiver algum código que abre a porta no setenv.bat ou setenv.sh, não use a ferramenta. Instale com as tarefas Ant. Uma opção para abrir a porta RMI manualmente é fornecida para uma instalação com tarefas Ant.
Crie um usuário padrão para efetuar login no console. Esse usuário também é criado no arquivo de configuração tomcat-users.xml. Para uma instalação de produção, talvez você queira limpar a opção Criar uma opção de usuário padrão e configurar o acesso de usuário após a instalação. Para obter mais informações, consulte Configurando a autenticação do usuário para administração do MobileFirst Server.
No painel Configurações de Serviço de Push, selecione a opção Instalar o Serviço de Push se desejar que o serviço de push seja instalado no servidor de aplicativos. A raiz de contexto é imfpush. Para ativar a comunicação entre o serviço de push e o serviço de administração, é necessário definir os parâmetros a seguir:
Insira a URL do serviço de push e a URL do tempo de execução. Essa URL pode ser calculada automaticamente se você instalar no Liberty, Apache Tomcat ou WebSphere Application Server independente. Ela usa a URL do componente (o tempo de execução ou o serviço de push) no servidor local. Se você instalar no WebSphere Application Server Network Deployment ou as comunicações passarem por um proxy da web ou balanceador de carga, será preciso inserir a URL manualmente.
Insira o segredo e os IDs do cliente confidencial para comunicação OAuth entre os serviços. Caso contrário, a ferramenta gerará valores padrão e senhas aleatórias.
No painel Configurações do Analytics, selecione Ativar Conexão com o Servidor Analytics se o MobileFirst Analytics estiver instalado. Insira as configurações de conexão a seguir:
A URL do console do Análise de Dados.
A URL do servidor Analytics (o serviço de dados do Analytics).
O ID e a senha de login do usuário com permissão para publicar dados no servidor Analytics.
A ferramenta configura o tempo de execução e o serviço de push para enviar dados para o servidor Analytics.
Clique em Implementar para continuar com a instalação.
Após a instalação ser concluída com sucesso, reinicie o servidor de aplicativos no caso de um Apache Tomcat ou perfil Liberty.
Se o Apache Tomcat for ativado como um serviço, o arquivo setenv.bat ou setenv.sh que contém a instrução para abrir o RMI pode não ser lido. Como resultado, o MobileFirst Server pode não estar apto para trabalhar corretamente. Para configurar as variáveis necessárias, consulte Configurando a conexão JMX para Apache Tomcat.
No WebSphere Application Server Network Deployment, os aplicativos são instalados, mas não iniciados. É necessário iniciá-los manualmente. É possível fazer isso a partir do console de administração do WebSphere Application Server.
Mantenha o arquivo de configuração no Server Configuration Tool. Você pode reutilizá-lo para instalar correções temporárias. O menu para aplicar uma correção temporária é Configurações > Substituir os arquivos WAR implementados.
Aplicando um fix pack usando o Server Configuration Tool
Se o MobileFirst Server for instalado com a ferramenta de configuração e o arquivo de configuração for mantido, será possível aplicar um fix pack ou uma correção temporária reutilizando o arquivo de configuração.
Inicie o Server Configuration Tool.
No Linux, em atalhos de aplicativo Aplicativos → IBM MobileFirst Platform Server → Server Configuration Tool.
No Windows, clique em Iniciar → Programas → IBM MobileFirst Platform Server → Server Configuration Tool.
No macOS, abra um console de shell. Acesse mfp_server_install_dir/shortcuts e digite ./configuration-tool.sh.
O diretório mfp_server_install_dir é onde foi instalado o MobileFirst Server.
Clique em Configurações → Substituir os arquivos WAR implementados e selecione uma configuração existente para aplicar o fix pack ou uma correção temporária.
Instalando com tarefas Ant
Use tarefas Ant para instalar os componentes do MobileFirst Server em seu servidor de aplicativos.
É possível localizar os arquivos de configuração de amostra para instalar o MobileFirst Server no diretório mfp_install_dir/MobileFirstServer/configuration-samples.
Também é possível criar uma configuração com o Server Configuration Tool e exportar os arquivos Ant usando Arquivo → Exportar configuração como arquivos Ant…. Os arquivos Ant de amostra possuem as mesmas limitações que o Server Configuration Tool:
Todos os componentes (MobileFirst Operations Console, serviço de administração do MobileFirst Server, serviço de atualização em tempo real do MobileFirst Server, artefatos do MobileFirst Server e tempo de execução do MobileFirst) estão no mesmo servidor de aplicativos. No entanto, no WebSphere Application Server Network Deployment, ao instalar em um cluster, é possível especificar um cluster diferente para a administração e serviços de atualização em tempo real e para o tempo de execução.
Se o serviço de push do MobileFirst Server estiver instalado, ele também será instalado no mesmo servidor. No entanto, no WebSphere Application Server Network Deployment, ao instalar em um cluster, é possível especificar um cluster diferente para o serviço de push.
Todos os componentes usam o mesmo sistema de banco de dados e usuário. Para DB2, todos os componentes também usam o mesmo esquema.
O Server Configuration Tool instala os componentes para um único servidor. Para uma instalação em vários servidores, um farm deve ser configurado após a ferramenta ser executada. A configuração de server farm não é suportada no WebSphere Application Server Network Deployment.
É possível configurar serviços do MobileFirst Server para execução no server farm com tarefas Ant. Para incluir seu servidor em um farm, você precisa especificar alguns atributos que configurem seu servidor de aplicativos de acordo. Para obter informações adicionais sobre como configurar um server farm com tarefas Ant, consulte Instalando um server farm com tarefas Ant.
Para outras topologias que são suportadas em Topologias e fluxos de rede, é possível modificar os arquivos Ant de amostra.
É possível executar um arquivo Ant com a distribuição Ant que faz parte da instalação do produto. Por exemplo, se você tiver o cluster do WebSphere Application Server Network Deployment e seu banco de dados for IBM DB2, será possível usar o arquivo Ant mfp_install_dir/MobileFirstServer/configuration-samples/configure-wasnd-cluster-db2.xml. Depois de editar o arquivo e inserir todas as propriedades necessárias, é possível executar os seguintes comandos a partir do diretório mfp_install_dir/MobileFirstServer/configuration-samples:
mfp_install_dir/shortcuts/ant -f configure-wasnd-cluster-db2.xml help - Esse comando exibe a lista de todos os destinos possíveis do arquivo Ant para instalar, desinstalar ou atualizar alguns componentes.
mfp_install_dir/shortcuts/ant -f configure-wasnd-cluster-db2.xml install - Esse comando instala o MobileFirst Server no cluster do WebSphere Application Server Network Deployment, com o DB2 como uma origem de dados, usando os parâmetros inseridos nas propriedades do arquivo Ant.
Após a instalação, faça uma cópia do arquivo Ant para poder reutilizá-la para aplicar um fix pack.
Aplicando um fix pack usando os arquivos Ant
Atualizando com o arquivo Ant de amostra
Se você usar os arquivos Ant de amostra fornecidos no diretório mfp_install_dir/MobileFirstServer/configuration-samples para instalar o MobileFirst Server, será possível reutilizar uma cópia desse arquivo Ant para aplicar um fix pack. Para valores de senha, é possível inserir 12 estrelas (*) em vez do valor real, a ser solicitado interativamente quando o arquivo Ant for executado.
Verifique o valor da propriedade mfp.server.install.dir no arquivo Ant. Ele deve apontar para o diretório que contém o produto com o fix pack aplicado. Esse valor é usado para obter os arquivos WAR do MobileFirst Server atualizados.
Execute o comando: mfp_install_dir/shortcuts/ant -f your_ant_file update
Atualizando com seu próprio arquivo Ant
Se você usar seu próprio arquivo Ant, certifique-se de que, para cada tarefa de instalação task (installmobilefirstadmin, installmobilefirstruntime e installmobilefirstpush), você tenha uma tarefa de atualização correspondente em seu arquivo Ant com os mesmos parâmetros. As tarefas de atualização correspondentes são updatemobilefirstadmin, updatemobilefirstruntime e updatemobilefirstpush.
Verifique o caminho da classe do elemento taskdef para o arquivo mfp-ant-deployer.jar. Ele deve apontar para o arquivo mfp-ant-deployer.jar em uma instalação do MobileFirst Server à qual o fix pack é aplicado. Por padrão, os arquivos WAR do MobileFirst Server atualizados são obtidos do local mfp-ant-deployer.jar.
Execute as tarefas de atualização (updatemobilefirstadmin, updatemobilefirstruntime e updatemobilefirstpush) de seu arquivo Ant.
Modificações de arquivos Ant de amostra
É possível modificar os arquivos Ant de amostra fornecidos no diretório mfp_install_dir/MobileFirstServer/configuration-samples para adaptação a seus requisitos de instalação.
As seções a seguir fornecem os detalhes sobre como é possível modificar os arquivos Ant de amostra para adaptar a instalação às suas necessidades:
As tarefas Ant installmobilefirstadmin, installmobilefirstruntime e installmobilefirstpush declaram os valores para as propriedades JNDI necessárias para os componentes funcionarem. Essas propriedades JNDI são usadas para definir a comunicação JMX e também os links para outros componentes (como serviço de atualização em tempo real, serviço de push, o serviço de análise de dados ou serviço de autorização). Entretanto, também é possível definir valores para outras propriedades JNDI. Use o elemento <property> existente para essas três tarefas. Para obter uma lista de propriedades JNDI, consulte:
Além disso, o usuário que é criado pelos arquivos Ant de amostra é mapeado para as funções de segurança do serviço de administração e do console. Com essa configuração, é possível usar esse usuário para efetuar logon no
MobileFirst Server após a instalação. Para alterar esse comportamento, remova o elemento <user> dos arquivos Ant de amostra. Como alternativa, é possível remover o atributo password do elemento <user> e o usuário não será criado no registro local do servidor de aplicativos.
Especifique o nível Liberty Java EE
Algumas distribuições do WebSphere Application Server Liberty suportam recursos de Java EE 6 ou de Java EE 7. Por padrão, as tarefas Ant detectam automaticamente os recursos a serem instalados. Por exemplo, o recurso do Liberty jdbc-4.0 é instalado para Java EE 6 e o recurso jdbc-4.1 é instalado no caso do Java EE 7. Se a instalação do Liberty suportar ambos os recursos do Java EE 6 e Java EE 7, talvez você queira forçar um certo nível de recursos. Um exemplo pode ser que você pretende executar o MobileFirst Server V8.0.0 e V7.1.0 no mesmo servidor Liberty. O MobileFirst Server V7.1.0 ou anterior suporta somente recursos de Java EE 6.
Para forçar um determinado nível de recursos Java EE 6, use o atributo jeeversion do elemento <websphereapplicationserver>. Por exemplo:
É possível especificar as propriedades para a conexão JDBC. Use o elemento <property> de um elemento <database>. O elemento está disponível nas tarefas Ant configureDatabase, installmobilefirstadmin, installmobilefirstruntime e installmobilefirstpush. Por exemplo:
Execute os arquivos Ant em um computador no qual o MobileFirst Server não esteja instalado
Para executar as tarefas Ant em um computador no qual o MobileFirst Server não está instalado, você precisa dos seguintes itens:
Uma instalação Ant
Uma cópia do arquivo mfp-ant-deployer.jar para o computador remoto. Essa biblioteca contém a definição das tarefas Ant.
Para especificar os recursos a serem instalados. Por padrão, os arquivos WAR são levados para perto do mfp-ant-deployer.jar, mas é possível especificar o local desses arquivos WAR. Por exemplo:
Para obter informações adicionais, consulte as tarefas Ant para instalar cada componente do MobileFirst Server em Referência de instalação.
Especifique destinos do WebSphere Application Server Network Deployment
Para instalar no WebSphere Application Server Network Deployment, o perfil do WebSphere Application Server especificado deve ser o gerenciador de implementação. É possível implementar nas configurações a seguir:
Um cluster
Um único servidor
Uma célula (todos os servidores de uma célula)
Um nó (todos os servidores de um nó)
Os arquivos de amostra, como configure-wasnd-cluster-dbms-name.xml, configure-wasnd-server-dbms-name.xml e configure-wasnd-node-dbms-name.xml contêm a declaração a ser implementada em cada tipo de destino. Para obter informações adicionais, consulte as tarefas Ant para instalar cada componente do MobileFirst Server na Referência de instalação.
Nota: a partir da V8.0.0, o arquivo de configuração de amostra para a célula do WebSphere Application Server Network Deployment não é fornecido.
Configuração manual da porta RMI no Apache Tomcat
Por padrão, as tarefas Ant modificam o arquivo setenv.bat ou o arquivo setenv.sh para abrir a porta RMI. Caso prefira abrir a porta RMI manualmente, inclua o atributo tomcatSetEnvConfig com o valor false no elemento <jmx> das tarefas installmobilefirstadmin, updatemobilefirstadmin e uninstallmobilefirstadmin.
Instalando componentes do MobileFirst Server manualmente
Também é possível instalar componentes do MobileFirst Server em seu servidor de aplicativos manualmente.
Os tópicos a seguir fornecem informações completas para guiá-lo pelo processo de instalação dos componentes nos aplicativos suportados na produção.
O serviço de administração do MobileFirst Server, o serviço de atualização em tempo real do MobileFirst Server e o tempo de execução do MobileFirst devem ser instalados no mesmo servidor de aplicativos. A raiz de contexto do serviço de atualização em tempo real deve ser definida como the-adminContextRootconfig. A raiz de contexto do serviço de push deve ser imfpush. Para obter informações adicionais sobre as restrições, consulte Restrições nos componentes do MobileFirst Server e MobileFirst Analytics.
Definições de servidores de aplicativos
Deve-se configurar o elemento webContainer para carregar os servlets imediatamente. Essa configuração é necessária para a inicialização por meio de JMX. Por exemplo: <webContainer deferServletLoad="false"/>.
Opcionalmente, para evitar problemas de tempo limite que interrompem a sequência de inicialização do tempo de execução e do serviço de administração em algumas versões do Liberty, mude o elemento executor padrão. Configure valores grandes para os atributos coreThreads e maxThreads. Por exemplo:
Também é possível configurar o elemento tcpOptions e definir o atributo soReuseAddr como true: <tcpOptions soReuseAddr="true"/>.
Recursos do Liberty requeridos pelos aplicativos MobileFirst Server
É possível usar os recursos a seguir para Java EE 6 ou Java EE 7.
Serviço de administração do MobileFirst Server
jdbc-4.0 (jdbc-4.1 para Java EE 7)
appSecurity-2.0
restConnector-1.0
usr:MFPDecoderFeature-1.0
Serviço de push do MobileFirst Server
jdbc-4.0 (jdbc-4.1 para Java EE 7)
servlet-3.0 (servlet-3.1 para Java EE 7)
ssl-1.0
usr:MFPDecoderFeature-1.0
Tempo de execução do MobileFirst
jdbc-4.0 (jdbc-4.1 para Java EE 7)
servlet-3.0 (servlet-3.1 para Java EE 7)
ssl-1.0
usr:MFPDecoderFeature-1.0
Entradas JNDI globais
As entradas JNDI globais a seguir são necessárias para se configurar a comunicação JMX entre o tempo de execução e o serviço de administração:
mfp.admin.jmx.host
mfp.admin.jmx.port
mfp.admin.jmx.user
mfp.admin.jmx.pwd
mfp.topology.platform
mfp.topology.clustermode
Essas entradas JNDI globais são configuradas com essa sintaxe e não são prefixadas por uma raiz de contexto. Por exemplo: <jndiEntry jndiName="mfp.admin.jmx.port" value="9443"/>.
Nota: Para proteger contra uma conversão automática dos valores JNDI, para que 075 não seja convertido em 61 ou 31.500 não seja convertido em 31.5, use essa sintaxe ‘“075”’ quando definir o valor.
O serviço de administração é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml . O arquivo WAR do serviço de administração está em mfp_install_dir/MobileFirstServer/mfp-admin-service.war. É possível definir a raiz de contexto conforme desejado. No entanto, geralmente ela é /mfpadmin.
Propriedades JNDI obrigatórias
Quando você define as propriedades JNDI, os nomes JNDI devem ser prefixados com a raiz de contexto do serviço de administração. O exemplo a seguir ilustra o caso para declarar mfp.admin.push.url por meio do qual o serviço de administração é instalado com /mfpadmin como a raiz de contexto:
O nome JNDI da origem de dados para o serviço de administração deve ser definido como jndiName=the-contextRoot/jdbc/mfpAdminDS. O exemplo a seguir ilustra o caso por meio do qual o serviço de administração é instalado com a raiz de contexto /mfpadmin, e se o serviço está usando um banco de dados relacional:
O serviço de atualização em tempo real é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml . Antes de continuar, revise Instalação manual no WebSphere Application Server Liberty para obter os detalhes de configuração que são comuns a todos os serviços.
O arquivo WAR do serviço de atualização em tempo real está em mfp_install_dir/MobileFirstServer/mfp-live-update.war. A raiz de contexto do serviço de atualização em tempo real deve ser definida desta forma: /the-adminContextRootconfig. 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.
Origem de dados
O nome JNDI da origem de dados para o serviço de atualização em tempo real deve ser definido como the-contextRoot/jdbc/ConfigDS. O exemplo a seguir ilustra o caso por meio do qual o serviço de atualização em tempo real é instalado com a raiz de contexto /mfpadminconfig, e se o serviço está usando um banco de dados relacional:
Declare a função configadmin no elemento application-bnd do aplicativo. Pelo menos um usuário deve ser mapeado para essa função. O usuário e sua senha devem ser fornecidos para as seguintes propriedades JNDI do serviço de administração:
O console é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml . Antes de continuar, revise Instalação manual no WebSphere Application Server Liberty para obter os detalhes de configuração que são comuns a todos os serviços.
O arquivo WAR do console está em mfp_install_dir/MobileFirstServer/mfp-admin-ui.war. É possível definir a raiz de contexto conforme desejado. No entanto, geralmente ela é /mfpconsole.
Propriedades JNDI obrigatórias
Quando você define propriedades JNDI, os nomes JNDI devem ser prefixados com a raiz de contexto do console. O exemplo a seguir ilustra o caso para declarar mfp.admin.endpoint por meio do qual o console é instalado com /mfpconsole como raiz de contexto:
Declare as seguintes funções no elemento application-bnd do aplicativo:
mfpadmin
mfpdeployer
mfpmonitor
mfpoperator
Qualquer usuário mapeado para uma função de segurança do console também deverá ser mapeado para a mesma função de segurança do serviço de administração.
O tempo de execução é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml . Antes de continuar, revise Instalação manual no WebSphere Application Server Liberty para obter os detalhes de configuração que são comuns a todos os serviços.
O arquivo WAR de tempo de execução está em mfp_install_dir/MobileFirstServer/mfp-server.war. É possível definir a raiz de contexto conforme desejado. Entretanto, por padrão, ela é /mfp.
Propriedades JNDI obrigatórias
Quando você define as propriedades JNDI, os nomes JNDI devem ser prefixados com a raiz de contexto do tempo de execução. O exemplo a seguir ilustra o caso para declarar mfp.analytics.url por meio do qual o tempo de execução é instalado com /mobilefirst como raiz de contexto:
O nome JNDI da origem de dados para o tempo de execução deve ser definido como jndiName=the-contextRoot/jdbc/mfpDS. O exemplo a seguir ilustra o caso por meio do qual o tempo de execução é instalado com a raiz de contexto /mobilefirst, e se o tempo de execução está usando um banco de dados relacional:
O serviço de push é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml . Antes de continuar, revise Instalação manual no WebSphere Application Server Liberty para obter os detalhes de configuração que são comuns a todos os serviços.
O arquivo WAR do serviço de push está em mfp_install_dir/PushService/mfp-push-service.war. 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.
Propriedades JNDI obrigatórias
Quando você define as propriedades JNDI, os nomes JNDI devem ser prefixados com a raiz de contexto do serviço de push. O exemplo a seguir ilustra o caso para declarar mfp.push.analytics.user por meio do qual o serviço de push é instalado com /imfpush como a raiz de contexto:
O componente de artefatos é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml . Antes de continuar, revise Instalação manual no WebSphere Application Server Liberty para obter os detalhes de configuração que são comuns a todos os serviços.
O arquivo WAR para esse componente está em mfp_install_dir/MobileFirstServer/mfp-dev-artifacts.war. Deve-se definir a raiz de contexto como /mfp-dev-artifacts.
Instalação manual no WebSphere Application Server Liberty Collective
O serviço de administração do MobileFirst Server, o serviço de atualização em tempo real do MobileFirst Server e o MobileFirst Operations Console devem estar instalados em um controlador do Liberty Collective. O tempo de execução do MobileFirst e o serviço de push do MobileFirst Server devem estar instalados em cada membro do cluster do Liberty Collective.
A raiz de contexto do serviço de atualização em tempo real deve ser definida como the-adminContextRootconfig. A raiz de contexto do serviço de push deve ser imfpush. Para obter informações adicionais sobre as restrições, consulte Restrições nos componentes do MobileFirst Server e MobileFirst Analytics.
Definições de servidores de aplicativos
Deve-se configurar o elemento webContainer para carregar os servlets imediatamente. Essa configuração é necessária para a inicialização por meio de JMX. Por exemplo: <webContainer deferServletLoad="false"/>.
Opcionalmente, para evitar problemas de tempo limite que interrompem a sequência de inicialização do tempo de execução e do serviço de administração em algumas versões do Liberty, mude o elemento executor padrão. Configure valores grandes para os atributos coreThreads e maxThreads. Por exemplo:
Também é possível configurar o elemento tcpOptions e definir o atributo soReuseAddr como true: <tcpOptions soReuseAddr="true"/>.
Recursos do Liberty requeridos pelos aplicativos MobileFirst Server
É preciso incluir os seguintes recursos para Java EE 6 ou Java EE 7.
Serviço de administração do MobileFirst Server
jdbc-4.0 (jdbc-4.1 para Java EE 7)
appSecurity-2.0
restConnector-1.0
usr:MFPDecoderFeature-1.0
Serviço de push do MobileFirst Server
jdbc-4.0 (jdbc-4.1 para Java EE 7)
servlet-3.0 (servlet-3.1 para Java EE 7)
ssl-1.0
usr:MFPDecoderFeature-1.0
Tempo de execução do MobileFirst
jdbc-4.0 (jdbc-4.1 para Java EE 7)
servlet-3.0 (servlet-3.1 para Java EE 7)
ssl-1.0
usr:MFPDecoderFeature-1.0
Entradas JNDI globais
As entradas JNDI globais a seguir são necessárias para se configurar a comunicação JMX entre o tempo de execução e o serviço de administração:
mfp.admin.jmx.host
mfp.admin.jmx.port
mfp.admin.jmx.user
mfp.admin.jmx.pwd
mfp.topology.platform
mfp.topology.clustermode
mfp.admin.serverid
Essas entradas JNDI globais são configuradas com essa sintaxe e não são prefixadas por uma raiz de contexto. Por exemplo: <jndiEntry jndiName="mfp.admin.jmx.port" value="9443"/>.
Nota: Para proteger contra uma conversão automática dos valores JNDI, para que 075 não seja convertido em 61 ou 31.500 não seja convertido em 31.5, use essa sintaxe ‘“075”’ quando definir o valor.
O serviço de administração é empacotado como um aplicativo WAR para você implementar no controlador do Liberty Collective. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml do controlador Liberty Collective.
O arquivo WAR do serviço de administração está em mfp_install_dir/MobileFirstServer/mfp-admin-service-collective.war. É possível definir a raiz de contexto conforme desejado. No entanto, geralmente ela é /mfpadmin.
Propriedades JNDI obrigatórias
Quando você define as propriedades JNDI, os nomes JNDI devem ser prefixados com a raiz de contexto do serviço de administração. O exemplo a seguir ilustra o caso para declarar mfp.admin.push.url por meio do qual o serviço de administração é instalado com /mfpadmin como a raiz de contexto:
O nome JNDI da origem de dados para o serviço de administração deve ser definido como jndiName=the-contextRoot/jdbc/mfpAdminDS. O exemplo a seguir ilustra o caso por meio do qual o serviço de administração é instalado com a raiz de contexto /mfpadmin, e se o serviço está usando um banco de dados relacional:
O serviço de atualização em tempo real é empacotado como um aplicativo WAR para implementação no controlador do Liberty Collective. É preciso fazer algumas configurações específicas para esse aplicativo no arquivo server.xml do controlador do Liberty Collective.
O arquivo WAR do serviço de atualização em tempo real está em mfp_install_dir/MobileFirstServer/mfp-live-update.war. A raiz de contexto do serviço de atualização em tempo real deve ser definida desta forma: /the-adminContextRootconfig. 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.
Origem de dados
O nome JNDI da origem de dados para o serviço de atualização em tempo real deve ser definido como the-contextRoot/jdbc/ConfigDS. O exemplo a seguir ilustra o caso por meio do qual o serviço de atualização em tempo real é instalado com a raiz de contexto /mfpadminconfig, e se o serviço está usando um banco de dados relacional:
Declare a função configadmin no elemento application-bnd do aplicativo. Pelo menos um usuário deve ser mapeado para essa função. O usuário e sua senha devem ser fornecidos para as seguintes propriedades JNDI do serviço de administração:
O console é empacotado como um aplicativo WAR para você implementar no controlador do Liberty Collective. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml do controlador Liberty Collective.
O arquivo WAR do console está em mfp_install_dir/MobileFirstServer/mfp-admin-ui.war. É possível definir a raiz de contexto conforme desejado. No entanto, geralmente ela é /mfpconsole.
Propriedades JNDI obrigatórias
Quando você define propriedades JNDI, os nomes JNDI devem ser prefixados com a raiz de contexto do console. O exemplo a seguir ilustra o caso para declarar mfp.admin.endpoint por meio do qual o console é instalado com /mfpconsole como raiz de contexto:
Declare as seguintes funções no elemento application-bnd do aplicativo:
mfpadmin
mfpdeployer
mfpmonitor
mfpoperator
Qualquer usuário mapeado para uma função de segurança do console também deverá ser mapeado para a mesma função de segurança do serviço de administração.
O tempo de execução é empacotado como um aplicativo WAR para você implementar nos membros do cluster do Liberty Collective. Você precisa fazer algumas configurações específicas para esse aplicativo no arquivo server.xml de cada membro de cluster do Liberty Collective.
O arquivo WAR de tempo de execução está em mfp_install_dir/MobileFirstServer/mfp-server.war. É possível definir a raiz de contexto conforme desejado. Entretanto, por padrão, ela é /mfp.
Propriedades JNDI obrigatórias
Quando você define as propriedades JNDI, os nomes JNDI devem ser prefixados com a raiz de contexto do tempo de execução. O exemplo a seguir ilustra o caso para declarar mfp.analytics.url por meio do qual o tempo de execução é instalado com /mobilefirst como raiz de contexto:
O nome JNDI da origem de dados para o tempo de execução deve ser definido como jndiName=the-contextRoot/jdbc/mfpDS. O exemplo a seguir ilustra o caso por meio do qual o tempo de execução é instalado com a raiz de contexto /mobilefirst, e se o tempo de execução está usando um banco de dados relacional:
Quando o serviço de push do MobileFirst Server é instalado em um Liberty Collective, ele pode ser instalado no mesmo cluster que o tempo de execução ou em outro cluster.
Você precisa fazer algumas configurações específicas para esse aplicativo no arquivo server.xml de cada membro de cluster do Liberty Collective. Antes de continuar, revise Instalação manual no WebSphere Application Server Liberty Collective para obter os detalhes de configuração que são comuns a todos os serviços.
O arquivo WAR do serviço de push está em mfp_install_dir/PushService/mfp-push-service.war. 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.
Propriedades JNDI obrigatórias
Quando você define as propriedades JNDI, os nomes JNDI devem ser prefixados com a raiz de contexto do serviço de push. O exemplo a seguir ilustra o caso para declarar mfp.push.analytics.user por meio do qual o serviço de push é instalado com /imfpush como a raiz de contexto:
O componente de artefatos é empacotado como um aplicativo WAR para você implementar no controlador do Liberty Collective. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml do controlador Liberty Collective. Antes de continuar, revise Instalação manual no WebSphere Application Server Liberty para obter os detalhes de configuração que são comuns a todos os serviços.
O arquivo WAR para esse componente está em mfp_install_dir/MobileFirstServer/mfp-dev-artifacts.war. Deve-se definir a raiz de contexto como /mfp-dev-artifacts.
O serviço de administração do MobileFirst Server, o serviço de atualização em tempo real do MobileFirst Server e o tempo de execução do MobileFirst devem ser instalados no mesmo servidor de aplicativos. A raiz de contexto do serviço de atualização em tempo real deve ser definida como the-adminContextRootconfig. A raiz de contexto do serviço de push deve ser imfpush. Para obter informações adicionais sobre as restrições, consulte Restrições nos componentes do MobileFirst Server e MobileFirst Analytics.
Definições de servidores de aplicativos
Deve-se ativar o Single Sign On Valve. Por exemplo:
O serviço de administração é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml do servidor de aplicativos.
Antes de continuar, revise Instalação manual no Apache Tomcat para obter os detalhes de configuração que são comuns a todos os serviços.
O arquivo WAR do serviço de administração está em mfp_install_dir/MobileFirstServer/mfp-admin-service.war. É possível definir a raiz de contexto conforme desejado. No entanto, geralmente ela é /mfpadmin.
Propriedades JNDI obrigatórias
As propriedades JNDI que são definidas no elemento Environment no contexto de aplicativos. Por exemplo:
O serviço de atualização em tempo real é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml .
Antes de continuar, revise Instalação manual no Apache Tomcat para obter os detalhes de configuração que são comuns a todos os serviços.
O arquivo WAR do serviço de atualização em tempo real está em mfp_install_dir/MobileFirstServer/mfp-live-update.war. A raiz de contexto do serviço de atualização em tempo real deve ser definida dessa forma: /the-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.
Origem de dados
O nome JNDI da origem de dados para o serviço de atualização em tempo real deve ser definido como jdbc/ConfigDS. Declare-a como um recurso no elemento Context.
Funções de segurança
A função de segurança disponível para o aplicativo de serviço de atualização em tempo real é configadmin.
Pelo menos um usuário deve ser mapeado para essa função. O usuário e sua senha devem ser fornecidos para as seguintes propriedades JNDI do serviço de administração:
O console é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml do servidor de aplicativos.
Antes de continuar, revise Instalação manual no Apache Tomcat para obter os detalhes de configuração que são comuns a todos os serviços.
O arquivo WAR do console está em mfp_install_dir/MobileFirstServer/mfp-admin-ui.war. É possível definir a raiz de contexto conforme desejado. No entanto, geralmente ela é /mfpconsole.
Propriedades JNDI obrigatórias
É preciso definir a propriedade mfp.admin.endpoint. O valor típico para essa propriedade é *://*:*/the-adminContextRoot.
O tempo de execução é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml .
Antes de continuar, revise Instalação manual no Apache Tomcat para obter os detalhes de configuração que são comuns a todos os serviços.
O arquivo WAR de tempo de execução está em mfp_install_dir/MobileFirstServer/mfp-server.war. É possível definir a raiz de contexto conforme desejado. Entretanto, por padrão, ela é /mfp.
Propriedades JNDI obrigatórias
Deve-se definir a propriedade mfp.authorization.server. Por exemplo:
O serviço de push é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo. Antes de continuar, revise Instalação manual no Apache Tomcat para obter os detalhes de configuração que são comuns a todos os serviços.
O arquivo WAR do serviço de push está em mfp_install_dir/PushService/mfp-push-service.war. 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.
Propriedades JNDI obrigatórias
É necessário definir as propriedades a seguir:
mfp.push.authorization.server.url
mfp.push.authorization.client.id
mfp.push.authorization.client.secret
mfp.push.services.ext.security - o valor deve ser com.ibm.mfp.push.server.security.plugin.OAuthSecurityPlugin.
mfp.push.db.type - para um banco de dados relacional, o valor deve ser DB.
Se MobileFirst Analytics estiver configurado, defina as seguintes propriedades JNDI:
mfp.push.analytics.endpoint
mfp.analytics.username
mfp.analytics.password
mfp.push.services.ext.analytics - o valor deve ser com.ibm.mfp.push.server.analytics.plugin.AnalyticsPlugin.
O componente de artefatos é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml do servidor de aplicativos. Antes de continuar, revise Instalação manual no Apache Tomcat para obter os detalhes de configuração que são comuns a todos os serviços.
O arquivo WAR para esse componente está em mfp_install_dir/MobileFirstServer/mfp-dev-artifacts.war. Deve-se definir a raiz de contexto como /mfp-dev-artifacts.
Instalação manual no WebSphere Application Server e no WebSphere Application Server Network Deployment
Em um WebSphere Application Server independente
O serviço de administração do MobileFirst Server, o serviço de atualização em tempo real do MobileFirst Server e o tempo de execução do MobileFirst devem ser instalados no mesmo servidor de aplicativos. A raiz de contexto do serviço de atualização em tempo real deve ser definida como the-adminContextRootConfig. A raiz de contexto do serviço de push deve ser imfpush. Para obter informações adicionais sobre as restrições, consulte Restrições nos componentes do MobileFirst Server e MobileFirst Analytics.
No WebSphere Application Server Network Deployment
O gerenciador de implementação deve estar em execução enquanto o MobileFirst Server estiver em execução. O gerenciador de implementação é usado para comunicação JMX entre o tempo de execução e o serviço de administração. O serviço de administração e o serviço de atualização em tempo real devem estar instalados no mesmo servidor de aplicativos. O tempo de execução pode estar instalado em servidores diferentes do serviço de administração, mas ele deve estar na mesma célula.
Definições de servidores de aplicativos
A segurança administrativa e a segurança do aplicativo devem estar ativadas. É possível ativar a segurança do aplicativo no console de administração do WebSphere Application Server:
Efetue login no console administrativo do WebSphere Application Server.
Clique em Segurança → Segurança Global. Certifique-se de que Ativar segurança administrativa esteja selecionado.
Além disso, assegure-se de que Ativar Segurança do Aplicativo esteja selecionada. A segurança do aplicativo pode ser ativada somente se a segurança administrativa estiver ativada.
Clique em ** OK **.
Salve as alterações.
Para obter informações adicionais, consulte Ativando a segurança na documentação do WebSphere Application Server.
A política do carregador de classes do servidor deve suportar última delegação de pai. Os arquivos WAR do MobileFirst Server devem ser instalados com o modo de carregador de classes do último pai. Revise a política do carregador de classes:
Efetue login no console administrativo do WebSphere Application Server.
Clique em Servidores → Tipos de Servidor → WebSphere Application Servers e clique no servidor que é usado para Mobile Foundation.
Se a política do carregador de classes estiver configurada para Múltiplo, não faça nada.
Se a política do carregador de classes estiver configurada para Único e o modo de carregamento de classes estiver configurado para Classes carregadas com carregador de classes local primeiro (pai por último), não faça nada.
Se a política do carregador de classes estiver configurada como Único e o modo de carregamento de classes estiver configurado como Classes carregadas com o carregador de classes-pai primeiro (pai primeiro), mude a política do carregador de classes para Múltiplo. Além disso, configure a ordem do carregador de classes para todos os aplicativos diferentes de aplicativos do MobileFirst Server para Classes carregadas com o carregador de classes-pai primeiro (pai primeiro).
Carregador de Classes
Para todos os aplicativos MobileFirst Server, o carregador de classes deve ter a última delegação de pai.
Para configurar a delegação de carregador de classes para o último pai após um aplicativo ser instalado, siga estas etapas:
Clique no link Gerenciar aplicativos ou clique em Aplicativos → Tipos de aplicativos → Aplicativos corporativos WebSphere.
Clique no aplicativo MobileFirst Server. Por padrão, o nome do aplicativo é o nome do arquivo WAR.
Na seção Detalhar Propriedades, clique no link Carregamento de classe e detecção de atualização.
Na área de janela Ordem do Carregador de Classes, clique na opção Classes carregadas com carregador de classes local primeiro (pai por último).
Clique em ** OK **.
Na seção Módulos, clique no link Gerenciar módulos.
Clique no módulo.
Para o campo Ordem do Carregador de Classes, selecione a opção Classes carregadas com carregador de classes local primeiro (pai por último).
Clique em OK duas vezes para confirmar a seleção e retornar ao painel Configuração do aplicativo.
O serviço de administração é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml do servidor de aplicativos.
O arquivo WAR do serviço de administração está em mfp_install_dir/MobileFirstServer/mfp-admin-service.war. É possível definir a raiz de contexto conforme desejado. No entanto, geralmente ela é /mfpadmin.
Propriedades JNDI obrigatórias
É possível configurar propriedades JNDI com o 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 e configure as entradas.
Para ativar a comunicação JMX com o tempo de execução, defina as seguintes propriedades JNDI:
No WebSphere Application Server Network Deployment
mfp.admin.jmx.dmgr.host
mfp.admin.jmx.dmgr.port - a porta SOAP no gerenciador de implementação.
mfp.topology.platform - configure o valor como WAS.
mfp.topology.clustermode - configure o valor como Cluster.
mfp.admin.jmx.connector - configure o valor como SOAP.
Em um WebSphere Application Server independente
mfp.topology.platform - configure o valor como WAS.
mfp.topology.clustermode - configure o valor como Standalone.
mfp.admin.jmx.connector - configure o valor como SOAP.
Se o serviço de push estiver instalado, você deverá configurar as seguintes propriedades JNDI:
mfp.admin.push.url
mfp.admin.authorization.server.url
mfp.push.authorization.client.id
mfp.push.authorization.client.secret
mfp.admin.authorization.client.id
mfp.admin.authorization.client.secret
As propriedades JNDI para comunicação com o serviço de configuração são as seguintes:
Crie uma origem de dados para o serviço de administração e mapeie-a para jdbc/mfpAdminDS.
Ordem de início
O aplicativo de serviço de administração deve ser iniciado antes do aplicativo de tempo de execução. É possível configurar a ordem na seção Comportamento de Inicialização. Por exemplo, configure a Ordem de inicialização como 1 para o serviço de administração e 2 para o tempo de execução.
Funções de segurança
As funções de segurança disponíveis para o aplicativo de serviço de administração são:
O serviço de atualização em tempo real é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml .
O arquivo WAR do serviço de atualização em tempo real está em mfp_install_dir/MobileFirstServer/mfp-live-update.war. A raiz de contexto do serviço de atualização em tempo real deve ser definida dessa forma: /the-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.
Origem de dados
Crie uma origem de dados para o serviço de atualização em tempo real e mapeie-a para jdbc/ConfigDS.
Funções de segurança
A função configadmin é definida para esse aplicativo.
Pelo menos um usuário deve ser mapeado para essa função. O usuário e sua senha devem ser fornecidos para as seguintes propriedades JNDI do serviço de administração:
O console é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml do servidor de aplicativos.
O arquivo WAR do console está em mfp_install_dir/MobileFirstServer/mfp-admin-ui.war. É possível definir a raiz de contexto conforme desejado. No entanto, geralmente ela é /mfpconsole.
Propriedades JNDI obrigatórias
É possível configurar propriedades JNDI com o console de administração do WebSphere Application Server. Acesse Aplicativos → Tipos de aplicativos → Aplicativos corporativos WebSphere → application_name → Entradas de Ambiente para os módulos da web e configure as entradas.
É preciso definir a propriedade mfp.admin.endpoint. O valor típico para essa propriedade é *://*:*/the-adminContextRoot.
As funções de segurança disponíveis para o aplicativo são:
mfpadmin
mfpdeployer
mfpmonitor
mfpoperator
Qualquer usuário mapeado para uma função de segurança do console também deverá ser mapeado para a mesma função de segurança do serviço de administração.
O tempo de execução é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml .
O arquivo WAR de tempo de execução está em mfp_install_dir/MobileFirstServer/mfp-server.war. É possível definir a raiz de contexto conforme desejado. Entretanto, por padrão, ela é /mfp.
Propriedades JNDI obrigatórias
É possível configurar propriedades JNDI com o console de administração do WebSphere Application Server. Acesse Aplicativos → Tipos de aplicativos → Aplicativos corporativos WebSphere → application_name → Entradas de Ambiente para os módulos da web e configure as entradas.
Deve-se definir a propriedade mfp.authorization.server com o valor como integrado.
Além disso, defina as propriedades JNDI a seguir para ativer a comunicação JMX com o serviço de administração:
No WebSphere Application Server Network Deployment
mfp.admin.jmx.dmgr.host - o nome do host do gerenciador de implementação.
mfp.admin.jmx.dmgr.port - a porta SOAP do gerenciador de implementação.
mfp.topology.platform - configure o valor como WAS.
mfp.topology.clustermode - configure o valor como Cluster.
mfp.admin.jmx.connector - configure o valor como SOAP.
Em um WebSphere Application Server independente
mfp.topology.platform - configure o valor como WAS.
mfp.topology.clustermode - configure o valor como Standalone.
mfp.admin.jmx.connector - configure o valor como SOAP.
Se o MobileFirst Analytics estiver instalado, é necessário definir as seguintes propriedades JNDI:
O aplicativo de tempo de execução deve ser iniciado após o aplicativo de serviço de administração. É possível configurar a ordem na seção Comportamento de Inicialização. Por exemplo, configure a Ordem de inicialização como 1 para o serviço de administração e 2 para o tempo de execução.
Origem de dados
Crie uma origem de dados para o tempo de execução e mapeie-a para jdbc/mfpDS.
O arquivo WAR do serviço de push está em mfp_install_dir/PushService/mfp-push-service.war. 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.
Propriedades JNDI obrigatórias
É possível configurar propriedades JNDI com o 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 e configure as entradas.
É necessário definir as propriedades a seguir:
mfp.push.authorization.server.url
mfp.push.authorization.client.id
mfp.push.authorization.client.secret
mfp.push.services.ext.security - o valor deve ser com.ibm.mfp.push.server.security.plugin.OAuthSecurityPlugin.
mfp.push.db.type - para um banco de dados relacional, o valor deve ser DB.
Se MobileFirst Analytics estiver configurado, defina as seguintes propriedades JNDI:
mfp.push.analytics.endpoint
mfp.analytics.username
mfp.analytics.password
mfp.push.services.ext.analytics - o valor deve ser com.ibm.mfp.push.server.analytics.plugin.AnalyticsPlugin.
O componente de artefatos é empacotado como um aplicativo WAR para você implementar no servidor de aplicativos. É necessário fazer algumas configurações específicas para esse aplicativo no arquivo server.xml do servidor de aplicativos. Antes de continuar, revise Instalação manual no WebSphere Application Server e no WebSphere Application Server Network Deployment para obter os detalhes de configuração que são comuns a todos os serviços.
O arquivo WAR para esse componente está em mfp_install_dir/MobileFirstServer/mfp-dev-artifacts.war. Deve-se definir a raiz de contexto como /mfp-dev-artifacts.
Instalando um server farm
É possível instalar seu server farm executando tarefas Ant, com o Server Configuration Tool ou manualmente.
Para planejar a configuração de um server farm, escolha o servidor de aplicativos, configure os bancos de dados do MobileFirst e implemente os arquivos WAR dos componentes do MobileFirst Server em cada servidor do farm. Existem as opções de usar o Server Configuration Tool, tarefas Ant ou operações manuais para configurar um server farm.
No Mobile Foundation, um server farm é composto por múltiplos servidores de aplicativo independentes que não são federados ou administrados por um componente de gerenciamento de um servidor de aplicativos. O MobileFirst Server fornece internamente um plug-in de farm como o meio para aprimorar um servidor de aplicativos para que possa ser parte de um server farm.
Quando declarar um server farm
Declare um server farm nos casos a seguir:
O MobileFirst Server está instalado em vários servidores de aplicativos Tomcat.
O MobileFirst Server é instalado em vários servidores WebSphere Application Server, mas não no WebSphere Application Server Network Deployment.
O MobileFirst Server é instalado em vários servidores WebSphere Application Server Liberty.
Não declare um server farm nos seguintes casos:
Seu servidor de aplicativos é independente.
Vários servidores de aplicativos são federados pelo WebSphere Application Server Network Deployment.
Por que é obrigatório declarar um farm
Cada vez que uma operação de gerenciamento é executada por meio do MobileFirst Operations Console ou por meio do aplicativo de serviço de administração do MobileFirst Server, a operação precisa ser replicada para todas as instâncias de um ambiente de tempo de execução. Exemplos dessas operações de gerenciamento são o upload de uma nova versão de um aplicativo ou de um adaptador. A replicação é feita via chamadas JMX executadas pela instância do aplicativo do serviço de administração que manipula a operação. O serviço de administração precisa contatar todas as instâncias de tempo de execução no cluster. Em ambientes listados em Quando declarar um server farm acima, o tempo de execução pode ser contatado por meio de JMX somente se um farm estiver configurado. Se um servidor for incluído em um cluster sem a configuração apropriada do farm, o tempo de execução nesse servidor estará em um estado inconsistente após cada operação de gerenciamento e até que seja reiniciado novamente.
Instalando um server farm com o Server Configuration Tool
Use o Server Configuration Tool para configurar cada servidor no farm, de acordo com os requisitos do único tipo de servidor de aplicativos que é usado para cada membro do server farm.
Quando você planejar um server farm com o Server Configuration Tool, primeiro crie os servidores independentes e configure seus respectivos armazenamentos confiáveis para que eles possam se comunicar uns com os outros de maneira segura. Em seguida, execute a ferramenta que realiza as operações a seguir:
Configure a instância de banco de dados compartilhada pelos componentes do MobileFirst Server.
Implementar componentes do MobileFirst Server em cada servidor
Modificar sua configuração para torná-lo membro de um server farm
O MobileFirst Server requer que a conexão JMX segura seja configurada.
Prepare os servidores de aplicativos que devem ser configurados como membros do server farm.
Escolha o tipo de servidor de aplicativos que usará para configurar os membros do server farm. Mobile Foundation suporta os servidores de aplicativos a seguir em server farms:
WebSphere Application Server Full Profile Nota: Em uma topologia de farm, não é possível usar o conector JMX RMI. Nessa topologia, somente o conector SOAP é suportado pelo Mobile Foundation.
perfil Liberty do WebSphere Application Server
Apache Tomcat
Para saber quais versões dos servidores de aplicativos são suportadas, consulte Requisitos do sistema.
Importante: O Mobile Foundation suporta apenas server farms homogêneos. Um server farm é homogêneo quando se conecta ao mesmo tipo de servidores de aplicativos. Tentar associar tipos diferentes de servidores de aplicativos levaria a um comportamento imprevisível no tempo de execução. Por exemplo, um farm com uma combinação de servidores Apache Tomcat e servidores de perfil completo do WebSphere Application Server é uma configuração inválida.
Configure tantos servidores independentes quanto o número de membros que você deseja no farm.
Cada um desses servidores independentes deve se comunicar com o mesmo banco de dados. Você deve se certificar também de que nenhuma porta usada por qualquer um desses servidores seja usada por outro servidor configurado no mesmo host. Essa restrição se aplica a portas usadas pelos protocolos HTTP, HTTPS, REST, SOAP e RMI.
Cada um desses servidores deve ter o serviço de administração do MobileFirst Server, o serviço de atualização em tempo real do MobileFirst Server e um ou mais tempos de execução do MobileFirst implementados.
Troque os certificados de assinante entre todos os servidores em seus respectivos armazenamentos confiáveis.
Nota: essa etapa é obrigatória para os farms que usam o perfil integral do WebSphere Application Server ou o Liberty, pois a segurança deve ser ativada. Além disso, para farms do Liberty, a mesma configuração de LTPA deve ser replicada em cada servidor para assegurar o recurso de conexão única. Para fazer essa configuração, siga as diretrizes na etapa 6 de Configurando um server farm manualmente.
Execute o Server Configuration Tool para cada servidor do farm. Todos os servidores devem compartilhar os mesmos bancos de dados. Certifique-se de selecionar o tipo de implementação: Implementação de Server Farm no painel Configurações do Servidor de Aplicativos. Para obter informações adicionais sobre a ferramenta, consulte Executando o Server Configuration Tool.
Instalando um server farm com tarefas Ant
Use tarefas Ant para configurar cada servidor no farm de acordo com os requisitos do único tipo de servidor de aplicativo usado para cada membro do server farm.
Ao planejar um server farm com tarefas Ant, primeiro crie os servidores independentes e configure seus respectivos armazenamentos confiáveis, de modo que eles possam se comunicar uns com os outros de uma maneira segura. Em seguida, execute tarefas Ant para configurar a instância de banco de dados compartilhada pelos componentes do MobileFirst Server. Por fim, execute tarefas Ant para implementar os componentes do MobileFirst Server em cada servidor e para modificar sua configuração para torná-lo membro de um server farm.
O MobileFirst Server requer que a conexão JMX segura seja configurada.
Prepare os servidores de aplicativos que devem ser configurados como membros do server farm.
Escolha o tipo de servidor de aplicativos que usará para configurar os membros do server farm. Mobile Foundation suporta os servidores de aplicativos a seguir em server farms:
Perfil completo do WebSphere Application Server. Nota: Em uma topologia de farm, não é possível usar o conector JMX RMI. Nessa topologia, somente o conector SOAP é suportado pelo Mobile Foundation.
perfil Liberty do WebSphere Application Server
Apache Tomcat
Para saber quais versões dos servidores de aplicativos são suportadas, consulte Requisitos do sistema.
Importante: O Mobile Foundation suporta apenas server farms homogêneos. Um server farm é homogêneo quando se conecta ao mesmo tipo de servidores de aplicativos. Tentar associar tipos diferentes de servidores de aplicativos levaria a um comportamento imprevisível no tempo de execução. Por exemplo, um farm com uma combinação de servidores Apache Tomcat e servidores de perfil completo do WebSphere Application Server é uma configuração inválida.
Configure tantos servidores independentes quanto o número de membros que você deseja no farm.
Cada um desses servidores independentes deve se comunicar com o mesmo banco de dados. Você deve se certificar também de que nenhuma porta usada por qualquer um desses servidores seja usada por outro servidor configurado no mesmo host. Essa restrição aplica-se a portas usadas pelos protocolos HTTP, HTTPS, REST, SOAP e RMI.
Cada um desses servidores deve ter o serviço de administração do MobileFirst Server, o serviço de atualização em tempo real do MobileFirst Server e um ou mais tempos de execução do MobileFirst implementados.
Troque os certificados de assinante entre todos os servidores em seus respectivos armazenamentos confiáveis.
Nota: essa etapa é obrigatória para os farms que usam o perfil integral do WebSphere Application Server ou o Liberty, pois a segurança deve ser ativada. Além disso, para farms do Liberty, a mesma configuração de LTPA deve ser replicada em cada servidor para assegurar o recurso de conexão única. Para fazer essa configuração, siga as diretrizes na etapa 6 de Configurando um server farm manualmente
.
Configure o banco de dados para o serviço de administração, serviço de atualização em tempo real e tempo de execução.
Decida qual banco de dados você deseja usar e escolha o arquivo Ant para criar e configurar o banco de dados no diretório mfp_install_dir/MobileFirstServer/configuration-samples:
Para DB2, use create-database-db2.xml.
Para MySQL, use create-database-mysql.xml.
Para Oracle, use create-database-oracle.xml.
Nota: não use o banco de dados Derby em uma topologia de farm porque o banco de dados Derby permite apenas uma única conexão de cada vez.
Edite o arquivo Ant e insira todas as propriedades necessárias para o banco de dados.
Para ativar a configuração do banco de dados usada pelos componentes do MobileFirst Server, configure os valores das propriedades a seguir:
Configure mfp.process.admin como true. Para configurar o banco de dados para o serviço de administração e o serviço de atualização em tempo real.
Configure mfp.process.runtime como true. Para configurar o banco de dados para o tempo de execução.
Execute os seguintes comandos a partir do diretório mfp_install_dir/MobileFirstServer/configuration-samples, em que create-database-ant-file.xml deve ser substituído pelo nome do arquivo Ant real escolhido: mfp_install_dir/shortcuts/ant -f create-database-ant-file.xml admdatabases e mfp_install_dir/shortcuts/ant -f create-database-ant-file.xml rtmdatabases.
Como os bancos de dados do MobileFirst Server são compartilhados entre os servidores de aplicativos de um farm, esses dois comandos só devem ser executados uma vez, seja qual for o número de servidores no farm.
Como opção, se desejar instalar outro tempo de execução, deve-se configurar outro banco de dados com outro esquema ou nome de banco de dados. Para isso, edite o arquivo Ant, modifique as propriedades e execute o seguinte comando uma vez, independentemente do número de servidores no farm: mfp_install_dir/shortcuts/ant -f create-database-ant-file.xml rtmdatabases.
Implemente o serviço de administração, o serviço de atualização em tempo real e o tempo de execução nos servidores e configure esses servidores como membros de um server farm.
Escolha o arquivo Ant que corresponde a seu servidor de aplicativos e seu banco de dados no diretório mfp\_install\_dir/MobileFirstServer/configuration-samples para implementar o serviço de administração, o serviço de atualização em tempo real e o tempo de execução nos servidores.
Por exemplo, escolha o arquivo configure-liberty-db2.xml para uma implementação no servidor Liberty com o banco de dados DB2. Faça a quantidade de cópias desse arquivo de acordo com o número de membros que você deseja ter no farm.
Nota: mantenha esses arquivos após a configuração, pois eles podem ser reutilizados para fazer upgrade dos componentes do MobileFirst Server que já foram implementados, ou para desinstalá-los de cada membro do farm.
Edite cada cópia do arquivo Ant, insira as mesmas propriedades para o banco de dados que são usadas na etapa 2, e também insira as outras propriedades necessárias para o servidor de aplicativos.
Para configurar o servidor como um server farm member, configure os valores das propriedades a seguir:
Configure mfp.farm.configure como true.
mfp.farm.server.id: um identificador que você define para este farm member. Certifique-se de que cada servidor no farm tenha seu próprio identificador exclusivo. Se dois servidores no farm tiverem o mesmo identificador, o farm poderá se comportar de maneira imprevisível.
mfp.config.service.user: o nome do usuário que é usado para acessar o serviço de atualização em tempo real. O nome do usuário deve ser o mesmo para todos os membros do farm.
mfp.config.service.password: a senha que é usada para acessar o serviço de atualização em tempo real. A senha deve ser a mesma para todos os membros do farm.
Para ativar a implementação dos arquivos WAR dos componentes do MobileFirst Server no servidor, configure os valores das propriedades a seguir:
Configure mfp.process.admin como true. Para implementar os arquivos WAR do serviço de administração e do serviço de atualização em tempo real.
Configure mfp.process.runtime como true. Para implementar o arquivo WAR do tempo de execução.
Nota: se você planeja instalar mais de um tempo de execução nos servidores do farm, especifique o ID de atributo e configure um valor, que deve ser exclusivo para cada tempo de execução nas tarefas Ant installmobilefirstruntime, updatemobilefirstruntime e uninstallmobilefirstruntime.
Por exemplo,
Para cada servidor, execute os seguintes comandos em que configure-appserver-database-ant-file.xml deve ser substituído pelo nome do arquivo Ant real escolhido: mfp_install_dir/shortcuts/ant -f configure-appserver-database-ant-file.xml adminstall e mfp_install_dir/shortcuts/ant -f configure-appserver-database-ant-file.xml rtminstall.
Opcionalmente, se você deseja instalar outro tempo de execução, execute as etapas a seguir:
Faça uma cópia do arquivo Ant configurado na etapa 3.b.
Edite a cópia, configure uma raiz de contexto distinta e um valor para o atributo id de installmobilefirstruntime, updatemobilefirstruntime e uninstallmobilefirstruntime que seja diferente da configuração do outro tempo de execução.
Execute o seguinte comando em cada servidor no farm em que configure-appserver-database-ant-file2.xml deve ser substituído pelo nome real do arquivo Ant que foi editado: mfp_install_dir/shortcuts/ant -f configure-appserver-database-ant-file2.xml rtminstall.
Repita essa etapa para cada servidor do farm.
Reinicialize todos os servidores.
Configurando um server farm manualmente
Deve-se configurar cada servidor no farm de acordo com os requisitos do único tipo de servidor de aplicativos usado para cada membro do server farm.
Ao planejar um server farm, crie primeiramente servidores independentes que se comuniquem com a mesma instância de banco de dados. Em seguida, modifique a configuração desses servidores para torná-los membros de um server farm.
Escolha o tipo de servidor de aplicativos que usará para configurar os membros do server farm. Mobile Foundation suporta os servidores de aplicativos a seguir em server farms:
WebSphere Application Server Full Profile Nota: Em uma topologia de farm, não é possível usar o conector JMX RMI. Nessa topologia, somente o conector SOAP é suportado pelo Mobile Foundation.
perfil Liberty do WebSphere Application Server
Apache Tomcat
Para saber quais versões dos servidores de aplicativos são suportadas, consulte Requisitos do sistema.
Importante: O Mobile Foundation suporta apenas server farms homogêneos. Um server farm é homogêneo quando se conecta ao mesmo tipo de servidores de aplicativos. Tentar associar tipos diferentes de servidores de aplicativos levaria a um comportamento imprevisível no tempo de execução. Por exemplo, um farm com uma combinação de servidores Apache Tomcat e servidores de perfil completo do WebSphere Application Server é uma configuração inválida.
Decida qual banco de dados você deseja usar. É possível escolher entre:
DB2
MySQL
Oracle
Os bancos de dados do MobileFirst Server são compartilhados entre os servidores de aplicativos de um farm, ou seja:
Você cria o banco de dados apenas uma vez, independentemente do número de servidores no farm.
Não é possível usar o banco de dados Derby em uma topologia de farm porque esse banco de dados permite somente uma única conexão de cada vez.
Configure tantos servidores independentes quanto o número de membros que você deseja no farm.
Cada um desses servidores independentes deve se comunicar com o mesmo banco de dados. Você deve se certificar também de que nenhuma porta usada por qualquer um desses servidores seja usada por outro servidor configurado no mesmo host. Essa restrição se aplica a portas usadas pelos protocolos HTTP, HTTPS, REST, SOAP e RMI.
Cada um desses servidores deve ter o serviço de administração do MobileFirst Server, o serviço de atualização em tempo real do MobileFirst Server e um ou mais tempos de execução do MobileFirst implementados.
Quando cada um desses servidores está trabalhando corretamente em uma topologia independente, é possível transformá-los em membros de um server farm.
Pare todos os servidores que devem ser membros do farm.
Configure cada servidor apropriadamente para o tipo de servidor de aplicativos. Deve-se configurar algumas propriedades JNDI corretamente. Em uma topologia de server farm, as propriedades JNI mfp.config.service.user e mfp.config.service.password devem ter o mesmo valor para todos os membros do farm. Para o Apache Tomcat, deve-se também verificar se os argumentos da JVM estão definidos adequadamente.
Perfil Liberty do WebSphere Application Server
No arquivo server.xml, configure as propriedades JNDI mostradas no seguinte código de amostra.
Essas propriedades devem ser configuradas com os valores apropriados:
mfp.admin.serverid: o identificador definido para este membro do farm. Esse identificador deve ser exclusivo entre todos os membros do farm.
mfp.admin.jmx.user e mfp.admin.jmx.pwd: esses valores devem corresponder às credenciais de um usuário conforme declarado no elemento administrator-role.
mfp.admin.jmx.host: configure este parâmetro para o IP ou nome do host usados pelos membros remotos para acessar esse servidor. Portanto, não o configure para localhost. Esse é o nome do host usado pelos outros membros do farm e deve estar acessível para todos os membros do farm.
mfp.admin.jmx.port: configure este parâmetro para a porta HTTPS do servidor usada para a conexão REST do JMX. É possível localizar o valor no elemento httpEndpoint do arquivo server.xml.
Apache Tomcat
Modifique o arquivo conf/server.xml para configurar as propriedades JNDI a seguir no contexto do serviço de administração e em cada contexto de tempo de execução.
A propriedade mfp.admin.serverid deve ser configurada para o identificador que você definiu para esse membro do farm. Esse identificador deve ser exclusivo entre todos os membros do farm.
Você deve se certificar de que o argumento de JVM -Djava.rmi.server.hostname esteja configurado para o IP ou nome do host usados pelos membros remotos para acessar esse servidor. Portanto, não o configure para localhost. Além disso, você deve se certificar de que o argumento da JVM -Dcom.sun.management.jmxremote.port esteja configurado com uma porta que ainda não estejam em uso para ativar conexões JMX RMI. Ambos os argumentos são configurados na variável de ambiente CATALINA_OPTS.
Perfil integral do WebSphere Application Server
Deve-se declarar as propriedades JNDI a seguir no serviço de administração e em cada aplicativo de tempo de execução implementado no servidor.
mfp.topology.clustermode
mfp.admin.serverid
No console do WebSphere Application Server,
selecione Aplicativos → Tipos de aplicativos → Aplicativos corporativos WebSphere.
Selecione o aplicativo de serviço de administração.
Em Propriedades do Módulo da Web, clique em Entradas de Ambiente para Módulos da Web para exibir as propriedades de JNDI.
Configure os valores das propriedades a seguir.
Configure mfp.topology.clustermode como Farm.
Configura mfp.admin.serverid para o identificador escolhido para este membro do farm. Esse identificador deve ser exclusivo entre todos os membros do farm.
Configure mfp.admin.jmx.user para o nome do usuário que têm acesso ao conector SOAP.
Configure mfp.admin.jmx.pwd para a senha do usuário conforme declarado no mfp.admin.jmx.user.
Configure mfp.admin.jmx.port para o valor da porta SOAP.
Verifique se mfp.admin.jmx.connector está configurado para SOAP.
Clique em OK e salve a configuração.
Faça mudanças semelhantes para cada aplicativo de tempo de execução do MobileFirst implementado no servidor.
Troque os certificados do servidor em seus armazenamentos confiáveis entre todos os membros do farm. A troca de certificados do servidor em seus armazenamentos confiáveis é obrigatória para farms que usam o perfil completo do WebSphere Application Server e o perfil Liberty do WebSphere Application Server, porque nesses farms, as comunicações entre os servidores são protegidas por SSL.
Perfil Liberty do WebSphere Application Server
É possível configurar o armazenamento confiável usando utilitários IBM como Keytool ou iKeyman.
Para obter informações adicionais sobre Keytool, consulte Keytool no IBM SDK, Java Technology Edition.
Para obter informações adicionais sobre iKeyman, consulte iKeyman no IBM SDK, Java Technology Edition.
As localizações do keystore e do armazenamento confiável são definidas no arquivo server.xml. Consulte os atributos keyStoreRef e trustStoreRef em Atributos de configuração SSL. Por padrão, o keystore do perfil Liberty está em ${server.config.dir}/resources/security/key.jks. Se a referência de armazenamento confiável estiver ausente ou não estiver definido no arquivo server.xml, o keystore especificado por keyStoreRef será usado. O servidor usa o keystore padrão e o arquivo é criado na primeira vez que o servidor é executado. Nesse caso, um certificado padrão é criado com um período de validade de 365 dias. Para produção, você pode considerar usar seu próprio certificado (incluindo os intermediários, se necessário) ou mudar a data de expiração do certificado gerado.
Nota: se desejar confirmar o local do armazenamento confiável, isso poderá ser feito incluindo a declaração a seguir no arquivo server.xml:
Por último, inicie o servidor e procure linhas que contenham com.ibm.ssl.trustStore no arquivo ${wlp.install.dir}/usr/servers/server_name/logs/trace.log.
Reinicie cada instância do perfil Liberty do WebSphere Application Server para que a configuração de segurança entre em vigor. As etapas a seguir são necessárias para a conexão única (SSO) funcionar.
Troque os certificados de assinante entre todos os servidores em seus respectivos armazenamentos confiáveis.
Nota: essa etapa é obrigatória para os farms que usam o perfil integral do WebSphere Application Server ou o Liberty, pois a segurança deve ser ativada. Além disso, para farms do Liberty, a mesma configuração de LTPA deve ser replicada em cada servidor para assegurar o recurso de conexão única. Para fazer essa configuração, execute as etapas a seguir.
Inicie um membro do farm. Na configuração padrão de LTPA, após o início bem-sucedido do servidor Liberty, ele gera um keystore LTPA como ${wlp.user.dir}/servers/server_name/resources/security/ltpa.keys.
Copie o arquivo ltpa.keys para o diretório ${wlp.user.dir}/servers/server_name/resources/security de cada membro de farm para replicar os keystores LTPA nos membros de farm. Para obter mais informações sobre a configuração de LTPA, consulte Configurando LTPA no perfil do Liberty.
Perfil integral do WebSphere Application Server
Configure o armazenamento confiável no console de administração do WebSphere Application Server.
Efetue login no console administrativo do WebSphere Application Server.
Selecione Segurança → Certificado SSL e gerenciamento de chave.
Em Itens relacionados, selecione Keystores e certificados.
No campo Usos do keystore, certifique-se de que Keystores SSL esteja selecionado. Agora é possível importar os certificados de todos os outros servidores no farm.
Clique em NodeDefaultTrustStore.
Em Propriedades adicionais, selecione Certificados de assinantes.
Clique em Recuperar a Partir da Porta. Agora é possível inserir os detalhes de comunicação e segurança de cada um dos outros servidores no farm. Siga as próximas etapas para cada um dos outros membros do farm.
No campo Host, insira o nome do host do servidor ou o endereço IP.
No campo Porta, insira a porta de transporte HTTPS (SSL).
Em Configuração SSL para conexão de saída, selecione NodeDefaultSSLSettings.
No campo Alias, insira um alias para esse certificado de assinante.
Clique em Recuperar Informações do Signatário.
Revise as informações que são recuperadas do servidor remoto e, em seguida, clique em OK.
Clique em Salvar.
Reinicialize o servidor.
Verificando uma configuração de farm
O propósito desta tarefa é verificar o status dos membros do farm e verificar se um farm está configurado corretamente.
Inicie todos os servidores do farm.
Acessar o MobileFirst Operations Console. Por exemplo, http://server_name:port/mfpconsole ou https://hostname:secure_port/mfpconsole no HTTPS.
Na barra lateral do console, aparece um menu extra que é nomeado como Nós do server farm.
Clique em Nós do Server Farm para acessar a lista de membros do farm registrados e seus status. No exemplo a seguir, o nó identificado como FarmMember2 é considerado inativo, o que indica que esse servidor provavelmente falhou e requer manutenção.
Ciclo de vida de um nó do server farm
É possível configurar a taxa de pulsação e os valores de tempo limite para indicar possíveis problemas do servidor entre os membros do farm, acionando uma mudança no status de um nó afetado.
Servidores de registro e monitoramento como nós farm
Quando um servidor configurado como um nó farm é iniciado, o serviço de administração nesse servidor o registra automaticamente como um novo membro do farm.
Quando um membro do farm é encerrado, ele cancela o registro automaticamente do farm.
Existe um mecanismo de pulsação para manter o controle de membros do farm que podem se tornar irresponsivos, por exemplo, por causa de uma indisponibilidade de energia ou de uma falha do servidor. Nesse mecanismo de pulsação, os tempos de execução do MobileFirst enviam periodicamente uma pulsação para os serviços de administração do MobileFirst em uma taxa especificada. Se o serviço de administração do MobileFirst registrar que decorreu muito tempo desde que um membro do farm enviou uma pulsação, o membro do farm será considerado inativo.
Membros do farm que são considerados inativos não atendem mais às solicitações de aplicativos móveis.
Ter um ou mais nós inativos não impede os outros membros do farm de atenderem às solicitações corretamente para aplicativos móveis, nem de aceitarem novas operações de gerenciamento acionadas por meio de MobileFirst Operations Console.
Configurando a taxa de pulsação e os valores de tempo limite
É possível configurar a taxa de pulsação e os valores de tempo limite definindo as propriedades de JNDI a seguir:
Planejador de tempo de execução de Mobile Foundation
O tempo de execução do Mobile Foundation usa planejadores quartz para executar algumas das atividades planejadas.
O planejador no tempo de execução do Mobile Foundation executa as atividades a seguir:
Rastreamento de Licença
Criando logs de auditoria
A execução do planejador é controlada pelas duas propriedades de JNDI a seguir,
mfp.licenseTracking.enabled
mfp.purgedata.enabled (introduzido no nível de iFix 8.0.0.0-MFPF-IF201812191602-CDUpdate-04)
Essas propriedades de JNDI são ativadas por padrão para todos os servidores de aplicativos suportados.
Nota: para o Mobile Foundation em execução no WebSphere Application Server, a propriedade de JNDI mfp.licenseTracking.enabled tem que ser ativada configurando seu valor como true nas entradas do Runtime Environment no console do WAS.
Rastreamento de Licença
O Rastreamento de licença rastreia as métricas relevantes para a política de licenciamento, como dispositivos ativos do cliente, dispositivos endereçáveis e aplicativos instalados. Essas informações ajudam a determinar se o uso atual da Mobile Foundation está dentro dos níveis de titularidade de licença e pode evitar potenciais violações de licença. O rastreamento de licença ajuda na desatribuição de dispositivos que não estão mais acessando o Mobile Foundation Server e também ajuda no arquivamento e exclusão de registros antigos de MFP_PERSISTENT_DATA.
A tabela a seguir lista as propriedades de JNDI relacionadas ao rastreamento de licença.
Propriedade de JNDI
Descrição
mfp.device.decommissionProcessingInterval
Define com que frequência (em segundos) a tarefa de desatribuição é executada. Padrão: 86400, que é um dia.
mfp.device.decommission.when
O número de dias de inatividade após o qual um dispositivo do cliente é desatribuído pela tarefa de desatribuição de dispositivo. Padrão: 90 dias.
mfp.device.archiveDecommissioned.when
O número de dias de inatividade após o qual um dispositivo do cliente que foi desatribuído é arquivado. Essa tarefa grava os dispositivos do cliente que foram desatribuídos em um archive. Os dispositivos arquivados do cliente são gravados em um arquivo no diretório home\devices_archive do Mobile Foundation Server. O nome do arquivo contém o registro de data e hora em que o archive foi criado. Padrão: 90 dias.
mfp.licenseTracking.enabled
Um valor que é usado para ativar ou desativar o rastreamento de dispositivo no IBM Mobile Foundation. Por motivos de desempenho, é possível desativar o rastreamento de dispositivo quando o IBM Mobile Foundation executa somente aplicativos Business-to-Consumer (B2C). 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. Os valores possíveis são true (padrão) e false.
Consulte os tópicos a seguir, para obter mais detalhes sobre o rastreamento de licença.
Um planejador será executado 8 horas após um início do servidor. Ou seja, se os servidores forem iniciados hoje às 23h, o planejador não será executado à 1h (tempo de execução do planejador padrão) do dia subsequente, ele começará a ser executado somente no dia seguinte à 1h. A diferença entre um início do servidor e uma execução do planejador é de 8 horas.
Iniciando o nível de iFix 8.0.0.0-MFPF-IF201907091643, a diferença entre um início do servidor e o executor do planejador é de 4 horas em vez de 8 horas.
Além disso, foi introduzida uma nova propriedade mfp.scheduler.startHour. Com essa propriedade, a execução do planejador pode ser configurada para qualquer horário de opção do cliente em vez do padrão 1h. A propriedade pode assumir um valor de 1 a 23. Essa propriedade assegurará que o cliente possa configurar seu planejador para iniciar em suas horas de tráfego leve e também possa assegurar as execuções do planejador apesar do início diário do servidor. Para um cliente que reinicia seu servidor todas as noites à 1h, ele pode configurar o valor para mfp.scheduler.startHour como 5. Isso assegura uma diferença de 4 horas entre a reinicialização de servidor e o planejador será executado às 5h.
É sugerido manter o rastreamento de licença desativado, pois as atividades de rastreamento de licença são intensivas no banco de dados. Somente aqueles clientes que usam o modelo de licenciamento de dispositivos endereçáveis da Foundation Mobile Foundation precisam executar o rastreamento de licença.
Os clientes que não ativaram o rastreamento de licença podem usar o recurso de limpeza para limpar os registros antigos e manter as tabelas MFP_PERSISTENT_DATA e MFP_TRANSIENT_DATA.
Criando o log de auditoria
O rastreamento de licença salva os dados de execução e de licença mais recentes na tabela de tempo de execução do Mobile Foundation LICENSE_TERMS. O log de auditoria cria um log com base na entrada de relatório mais recente nessa tabela. Os relatórios estão disponíveis como arquivos .slmtag na pasta de logs sob o diretório de instalação do servidor.
Desativando a atualização do Quartz
O tempo de execução do Mobile Foundation empacota as bibliotecas necessárias, incluindo algumas bibliotecas de terceiros. O Mobile Foundation usa planejadores de tarefas Quartz e inclui quartz2.2.0.jar.
O Quartz contém um recurso de verificação de atualização que se conecta ao servidor para verificar se há uma nova versão do Quartz disponível para download. Essa verificação é executada de forma assíncrona e não afeta a inicialização/tempo de inicialização do Quartz e falha normalmente se a conexão não pode ser feita. Se a verificação for executada e uma atualização for localizada, ela será relatada como disponível nos logs do Quartz.
A verificação de atualização pode ser desativada usando a sinalização org.quartz.scheduler.skipUpdateCheck = true. A implementação Liberty do Mobile Foundation cria um arquivo jvm.options e, durante a implementação por meio do Server Configuration Tool, o arquivo jvm.options recém-criado incluirá essa propriedade do nível de iFix 8.0.0.0-MFPF-IF201909190904 em diante. Para níveis anteriores de iFix, o cliente pode incluir essa propriedade no arquivo jvm.options.
No caso de implementações do WebSphere Application Server (WAS), a propriedade de JNDI acima precisa ser incluída na propriedade de ambiente do aplicativo Mobile Foundation por meio do console administrativo do WAS.
Inclusive terminology note: The Mobile First Platform team is making changes to support
the IBM® initiative to replace racially biased and other discriminatory language in our code and content
with more inclusive language. While IBM values the use of inclusive language, terms that are outside of
IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other
industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the
documentation to reflect those changes.
