Home

TOTVS | Plataformas e tecnologias

Árvore de páginas

Importante

Caro Cliente,

O TOTVS ECM 3.0 foi fundamentado na tecnologia de interface Flash, do qual a Adobe irá descontinuar seu suporte em 31/12/2020.

Recomendamos que nossos clientes avaliem a utilização do TOTVS Fluig Plataforma, que proporciona uma maior abrangência de recursos e importantes inovações tecnológicas. São inúmeras novidades não só em ECM e BPM que o Fluig entrega aos seus mais de 4 mil clientes, mas também conta com recursos de portais, social e identidade única.

Entre em contato com seu executivo de conta para saber mais detalhes desta oferta.

Índice


Pré -Requisitos de Software


Servidor

O TOTVS | ECM foi desenvolvido na plataforma Java™ e as mídias de instalação do produto já possuem o Java™ embutido.
Verifique se as configurações do servidor atendem os requisitos mínimos de dimensionamento e se o sistema operacional do servidor está homologado, conforme documentos publicados em:

http://tdn.totvs.com/display/tec/Dimensionamento+TOTVS++ECM
http://tdn.totvs.com/display/tec/Matriz+de+portabilidade


Estação Cliente

Verifique na matriz de portabilidade do TOTVS | ECM, publicada em Matriz de portabilidade, os softwares (e respectivas versões homologadas) necessários para as estações cliente.

Instalação

Servidor de Aplicação

Um servidor de aplicação é um software que disponibiliza um ambiente para a instalação e execução de certas aplicações.

O TOTVS | ECM usa o servidor de aplicação JBoss® na versão 4.2.3. A instalação do JBoss® é efetuada ao executar a mídia de instalação do TOTVS | ECM.

Em princípio, o TOTVS | ECM usa a configuração padrão do JBoss® – pasta $JBOSS_HOME/server/default. A configuração da instância do servidor é apresentada no capítulo Configuração nas seções Servidor de E-mail, Java Message Service e Transações.

Para criação das configurações de produção e teste do JBoss® no mesmo servidor deve-se consultar o Guia de Instalação de Múltiplas Instancias do ECM no mesmo Servidor.

Banco de Dados

O banco de dados deve ser instalado no servidor, a escolha e adoção de qual banco de dados utilizar é uma opção do cliente. O servidor de aplicação oferece suporte a praticamente qualquer banco de dados que seja compatível com a especificação JDBC. Entretanto, os bancos de dados (e respectivas versões) homologados para o ECM estão descritos na Matriz de Portabilidade do produto.

A documentação para a instalação e administração do banco de dados pode ser encontrada no site de cada um dos respectivos fornecedores.

Para instalação do TOTVS | ECM não é necessário nenhum procedimento para a criação das tabelas e campos do banco de dados. O servidor de aplicação vai atualizar a base automaticamente no primeiro deploy da aplicação, sendo necessário apenas que o banco já esteja criado e disponível para acesso.

Em caso de migração de base de dados consulte o documento Guia de Conversão ECM.

Migração

Conversão Webdesk 2.04 para TOTVS | ECM

Nesta seção abordaremos a conversão de uma instância de bancos de dados Webdesk 2.04 para o TOTVS | ECM.
Versões anteriores do produto devem ser previamente migradas para a versão 2.04 antes da conversão para o TOTVS | ECM.
O programa de conversão do Webdesk para TOTVS | ECM é distribuído com a versão 2.04 do produto e encontra-se no diretório “conf”. O detalhamento da conversão é descrito no documento “Guia de Conversão ECM.doc”

Workflow

Após a migração do banco de dados para o TOTVS | ECM devemos tratar dos processos de workflow e seus respectivos formulários – se houverem.

Para cada processo de workflow existente no TOTVS | ECM devemos:

1. Migrar o código de customização do processo de workflow para JavaScript – leia-se reescrever o código 4GL de cada uma das funções do listener. Para esta tarefa é imprescindível criar uma configuração de teste do TOTVS | ECM. IMPORTANTE: Esta é uma atividade de projeto e deve ser realizado antes da conversão do produto;

2. Importar o processo de workflow no TOTVS | ECM.

3. Criar uma nova versão do processo;

4. Importar a customização ou eventos do processo;

5. Liberar a nova versão do processo;

6. Testar o processo.

Se o processo de workflow possuir fichário – situação bastante comum – então devemos realizar a migração do formulário deste fichário.

Os formulários quando customizados pelo cliente pedem atenção especial e assim como os processos devem ser tratados individualmente. Por exemplo, zoom, consulta a banco de dados, controles de tela carregados dinamicamente devem ser revisados. Em caso de plugin também é necessário reescrever cada uma das funções em JavaScript.

Para cada fichário de processo do workflow deveremos:

1. Revisar o formulário do processo de workflow verificando zoom, consulta a banco de dados e carga dinâmica de controles de tela – por exemplo, combo box. IMPORTANTE: Esta é uma atividade de projeto e deve ser realizado antes da conversão do produto;

2. Se houver plugin, o código deste deve ser reescrito em JavaScritpt;

Dois documentos foram criados para auxiliar na conversão do processo de workflow e fichário, são eles: Guia de Referência Customização de Workflow e Guia de Referência Customização de Fichários.

Conversão de Solicitações em Aberto

Com todos os processos de workflow e seus respectivos fichários convertidos poderemos resolver as solicitações que estavam em aberto no momento da migração do banco de dados.

Todas as solicitações em aberto serão bloqueadas após a migração. O desbloqueio deve ser realizado via TOTVS | ECM acessando Painel de Controle > Conversão de Processos.

Seleciona o processo desejado. Após selecione a versão do processo em que as solicitações em aberto devem ser convertidas. Clique no botão “Avançar”.

O próximo passo é fazer o mapeamento “de para” para cada uma das atividades que compõe o fluxo do processo. Ao finalizar o mapeamento das atividades clique no botão “Avançar”.

Por fim, selecione todas as solicitações que devem ser convertidas e clique no botão “Avançar”. A tela vai exibir todas as solicitações selecionadas para conversão. Clique no botão “Converter” e as solicitações selecionadas serão convertidos para a nova versão do processo. Ao término da conversão o log de cada uma das solicitações será exibido na tela.

Cópia do ECM para outro servidor

Caso seja copiada a instalação do ECM para outro servidor, devem ser analisados os seguintes passos e se necessário, alterados:

1) Caso seja alterado o servidor de e-mail, deve ser alterado as configurações no seguinte arquivo:

%JBOSS_HOME%/server/default/deploy/mail-service.xml

Para mais informações, consultar o item Servidor de e-mail.

2) Caso seja alterado o servidor de licença, deve ser alterado as seguintes propriedades contidas no arquivo %JBOSS_HOME%/server/default/deploy/wdk-service.xml:

LSHost: Servidor onde está instalado o License Server.
LSPort: Porta para conexão ao License Server.
LSClientPort: Porta para conexão ao License Server no Cliente.

3) Caso seja alterado o caminho do OpenOffice, deve ser alterado a propriedade OOoDir do arquivo %JBOSS_HOME%/server/default/deploy/wdk-service.xml

4) Caso seja alterada a URL do Solr (mecanismo de indexação), alterar a propriedade IndexerURL do arquivo %JBOSS_HOME%/server/default/deploy/wdk-service.xml

5) Caso seja alterado o nome do banco de dados ou o servidor que ele consta, deve ser alterado o arquivo %JBOSS_HOME%/server/default/deploy/wdk-ds.xml

6) Para criar o serviço do TOTVS ECM em um servidor Windows:

6.1) Abra o arquivo %Instalação_ECM%/bin/service.bat e verifique se está correto o caminho de instalação (aproxidamente linha 11). Caso não esteja, altere para o caminho correto.
6.2) Acesse o pronto do DOS (opção Executar do Windows®, digite cmd e execute), posicione no diretório %Instalação_ECM%/bin e execute o seguinte comando: service.bat install~
Obs: O pronto do DOS deve ser executado como Administrador.

7) Caso queira alterar a porta ou o servidor que irá ser iniciado o ECM, deve ser alterado os seguintes arquivos:

7.1) %Instalação_ECM%\server\default\conf\josso-agent-config.xml, procure pela tag <endpoint> (aproxidamente linha 69).
7.2) Edite o arquivo server.xml dentro da pasta “%Instalação_ECM%\server\deploy\jboss-web.deployer” desta nova pasta criada, alterando o valor da propriedade port (aproximadamente linha 22).

8) No banco de dados, caso tenha sido alterado servidor aonde está instalado o ECM e está o volume, verificar as seguintes tabelas para eventuais alterações nos registros:

8.1) SELECT NOM_DIR_FOTO_COLAB, NOM_DIR_CUSTOMIZACAO, NOM_DIR_INDICE, PASTA_FISICA_ASS_DIGITAL, PASTA_FISICA_PUBLICACAO, PASTA_FISICA_FORMS, PASTA_FISICA_RELATORIOS, NOM_PASTA_TEMPLATE, PASTA_FISICA_UPLOAD, NOM_SERVID_WEBDESK, NUM_PORTA_WEB FROM PARAM_GERAL;
8.2) SELECT * FROM VOL_FISIC; /*Campo NOM_DIR_FISIC*/
8.3) Verificar se tem serviços criados. Caso tenha, verificar se as URLs devem ser alteradas devido ao novo servidor:

SELECT * FROM SERV_DADOS;

Para mais informações, verificar as documentações Guia de Instalação ECM e Guia de Instalação de Múltiplas Instâncias do ECM no mesmo servidor.


Configuração

Acesso Banco de Dados

As configurações de acesso ao banco de dados no JBoss® podem ser encontradas em $JBOSS_HOME/Server/default/deploy/wdk-ds.xml. Edite o arquivo e altere as configurações para o servidor de banco de dados.

Servidor de E -mail

A configuração do servidor de e-mail é realizada no servidor de aplicação.
As configurações do servidor de e-mail para o JBoss® podem ser encontradas no arquivo $JBOSS_HOME/server/default/deploy/mail-service.xml.

Altere as propriedades mail.smtp.host e mail.smtp.port. A primeira é o endereço IP ou o nome do servidor de e-mail. A segunda é a porta configurada para o servidor de e-mail. Se o servidor de aplicação estiver executando basta reiniciá-lo para que a nova configuração seja carregada.

Abaixo alguns parâmetros que também podem ser configurados nesse mesmo arquivo, conforme necessidade do servidor de email. Os parâmetros devem ser informados antes da tag “</configuration>”:

ParâmetroObjetivo
mail.defaultSender

Indica que será utilizado um email específico como remetente das notificações do ECM.
Exemplo:
<property name="mail.defaultSender" value="true" />

mail.from

Endereço de email utilizado como remetente das notificações do ECM. Necessário que o parâmetro mail.defaultSender esteja como true.
Exemplo:
<property name="mail.from" value="ecm@server.com" />

mail.personal

Indica qual a descrição do e-mail do remetente. Por padrão o sistema utiliza o texto “ECM”. Necessário que o parâmetro mail.defaultSender esteja como true.
Exemplo:
<property name="mail.personal" value="Minha Empresa" />

mail.allNotification

Todas as notificações do sistema serão enviadas pelo e-mail padrão, e não somente os e-mails de sistema. Necessário que o parâmetro mail.defaultSender esteja como true.
<property name="mail.allNotification" value="true"/>

mail.senderReceiverValidation

O comportamento padrão do produto é validar se o endereço de e-mail do usuário remetente é igual ao endereço de e-mail do usuário destinarário e neste caso o e-mail não é enviado. Já que nesta situação não é necessário notificar o usuário, pois já tem conhecimento da ação que está sendo executada.
Para o comportamento padrão descrito acima o valor deste parâmetro deve ser "true" (verdadeiro).
Caso por algum motivo mais específico seja necessário ignorar a validação descrita acima e enviar e-mail, o valor do parâmetro deve ser alterado para "false" (falso).

Exemplo:
<property name="mail.senderReceiverValidation" value="false" />

Observação: Caso no Processo Workflow esteja cadastrado o evento "onNotify", o comportamento do produto também será de ignorar a validação de e-mails iguais para o remetente e destinatário.

 mail.smtp.auth Indica que a comunicação com o servidor de email será de forma autenticada.

Exemplo:

<property name="mail.smtp.auth" value="true" />

 mail.smtp.user Usuário utilizado para a autenticação no servidor de email. Necessário que o parâmetro mail.smtp.auth esteja como true.

Exemplo:
<property name="mail.smtp.user" value="ecm@server.com" />

 mail.smtp.password Senha para autenticação no servidor de email. Necessário que o parâmetro mail.smtp.auth esteja como true.

Exemplo:
<property name="mail.smtp.password" value="12345" />


Para configurar o servidor de e-mail com suporte ao Exchange Online 365 é necessário adicionar as seguintes propriedades a configuração de e-mail:

ParâmetroObjetivo
mail.smtp.starttls.enable

Habilita a utilização de TLS para envio de e-mail.
<property name="mail.smtp.starttls.enable" value="true" />


O Exemplo abaixo apresenta a configuração do ECM com o servidor de e-mail Exchange Online 365.

<server>
<mbean code="org.jboss.mail.MailService" name="jboss:service=Mail">
<attribute name="JNDIName">/Mail</attribute>
<attribute name="User">[email protected]</attribute>
<attribute name="Password">password</attribute>
<attribute name="Configuration">
<!-- A test configuration -->
<configuration>
<property name="mail.store.protocol" value="pop3"/>
<property name="mail.pop3.host" value="pod51028.outlook.com"/>
<property name="mail.pop3.port" value="995"/>
<property name="mail.transport.protocol" value="smtp"/>
<property name="mail.smtp.host" value="pod51028.outlook.com"/>
<property name="mail.smtp.port" value="587"/>
<property name="mail.smtp.user"
value="[email protected]"/>
<property name="mail.smtp.password" value="password"/>
<property name="mail.smtp.auth" value="true"/>
<property name="mail.smtp.starttls.enable" value="true"/>
<property name="mail.debug" value="true"/>
<!-- Enable from -->
<property name="mail.from" value="[email protected]"/>
<property name="mail.defaultSender" value="true"/>
<property name="mail.allNotification" value="true"/>
</configuration>
</attribute>
<depends>jboss:service=Naming</depends>
</mbean>
</server >


Para que o serviço funcione corretamente é necessário:

  • Habilitar o protocolo TLS;
  • Habilitar a autenticação SMTP;
  • Informar o usuário e senha para autenticação no SMTP;
  • Informar o remetente das notificações do ECM;
  • Habilitar o defaultSender;
  • Habilitar o allNotification;
  • Informar host e port SMTP do serviço do Exchange Online;

IMPORTANTE: Para utilizar o Exchange Online 365 é necessário que o e-mail remetente das notificações e o utilizando na autenticação do SMTP sejam iguais.


Pode ser criada a variável de ambiente “WDK_NOEMAIL” com o valor FALSE, para que os emails não sejam enviados. No log será exibida a mensagem "Ignoring e-mail" a cada tentativa de envio de email.


Java Message Service

O servidor de aplicação JBoss® possui um serviço de mensagens pré-definido em sua configuração padrão. Entretanto, este serviço de mensagens não é robusto para atender a uma demanda elevada de uso do TOTVS | ECM.


A instalação padrão do JBoss® usa o banco de dados Hypersonic para gerenciar o serviço de mensagens – banco de dados embutido no JBoss®. Assim, para instalações em ambientes de produção que exigem maior demanda dos recursos do ECM, recomendamos alterar as configurações do serviço de mensagens – leia-se JMS – para usar o banco de dados do TOTVS | ECM.


Para cada banco de dados existe um arquivo de configuração. O arquivo de configuração para os bancos de dados homologados para o TOTVS | ECM pode ser encontrado em $JBOSS_HOME/docs/examples/jms. Por exemplo, para bancos MySQL™, utilizar o arquivo mysql-jdbc2-service.xml.


Copie o arquivo para o diretório $JBOSS_HOME/server/default/deploy/jms. Verifique se a propriedade name do DataSourceBinding está com o valor jdbc/webdeskDS, conforme exemplo, e altere se necessário:
<depends optional-attribute-name="ConnectionManager"> jboss.jca:service=DataSourceBinding,name=jdbc/webdeskDS</depends>


Por fim, remova o arquivo da configuração padrão do JMS. O nome do arquivo é hsqldb-jdbc2-service.xml.


No caso de ambientes com muitos usuários concorrentes é necessário aumentar também o número máximo de eventos na fila, no arquivo “jms-ds.xml” localizado em “$JBOSS_HOME/server/default/deploy/jms”, aproximadamente linha 50. Recomendamos um valor mínimo de 40. Exemplo:
<max-pool-size>40</max-pool-size>


Dependendo do valor informado deve ser alterado também o número máximo de conexões ao banco de dados. Para isso adicionar as tags abaixo no arquivo “wdk-ds.xml” localizado em “$JBOSS_HOME\server\default\deploy”, aproximadamente linhas 12 (antes da tag “</local-tx-datasource>”) e 22 (antes da tag “</no-tx-datasource>”):

<min-pool-size>10</min-pool-size>

<max-pool-size>200</max-pool-size>

<blocking-timeout-millis>30000</blocking-timeout-millis>


Sem essas configurações a seguinte mensagem pode ser apresentada no log do ECM:
- Could not find new XAResource to use for recovering non-serializable XAResource


Transações

O JBoss® possui um tempo limite de cinco minutos entre o início e o término de uma transação. Em algumas funcionalidades do TOTVS | ECM este prazo não é suficiente para executar toda a rotina de negócio.

Quando o prazo de conclusão da transação expira o servidor de aplicação desfaz todas as operações que estavam em andamento. Por exemplo, uma solicitação de envio para 250 e-mails em alguns ambientes pode levar mais de cinco minutos.

Neste caso, devemos alterar o tempo de transação. Não existe um valor ideal para o tempo de transação. Acompanhe o uso do TOTVS | ECM e se alguma funcionalidade executar repetidamente e automaticamente após a ocorrência de erros altere o tempo de transação. A ocorrência de erros pode ser verificada no arquivo server.log do servidor de aplicação em $JBOSS_HOME/server/default/log.

O tempo de transação é configurado no arquivo $JBOSS_HOME/ server/default/conf/ jboss-service.xml. Encontre a configuração JBoss Transactions JTA e altere a propriedade TransactionTimeout. O valor da propriedade é definido em milissegundos.


Segurança

Nesta seção trataremos as questões de segurança referentes a senha dos usuários, autenticação de usuário integrada com sistema operacional e menu de acesso as funcionalidades do TOTVS | ECM.

Alteração de senha dos usuários após a migração

Após a migração do Webdesk 2.04 para o TOTVS | ECM a senha de todos os usuários é invalidada.

A alteração da senha dos usuários deve ser realizada pela funcionalidade “Forgot Password” disponível na tela de login do produto. Preencha o nome do usuário e clique sobre o link “Forgot Password”. Uma mensagem de confirmação será apresentada. Confirme a alteração da senha e uma nova senha será enviada para o usuário por e-mail.

Com a nova senha em mãos o usuário pode acessar o seu perfil e alterar sua senha para uma de sua preferência.

Nos casos em que a funcionalidade não está acessível é possível alterar diretamente no banco de dados. Este procedimento deve ser realizado pelo administrador do banco de dados. Altere o campo “senha” da tabela “colaborador”. IMPORTANTE: A senha do usuário deve ser criptografada usando o algoritmo MD5.

Segurança de senhas e acessos

Após uma nova instalação do ECM, é criado o usuário “wdkAdmin” com a senha “adm” como padrão. É importante que essa senha seja alterada assim que possível para uma senha segura, que apenas o administrador do ECM tenha acesso. Para alterar a senha do “wdkAdmin” faça o login com esse usuário e usando o ícone de “Preferências do Colaborador” localizado na parte superior da página, troque a senha desse usuário.

Adicionalmente, a opção de instalação Ambiente de Desenvolvimento, inclui o usuário “admin” com senha “admin” como padrão. Também para maior segurança do ambiente sugere-se a troca da senha desse usuário.

No produto ECM ainda existe a configuração de qualidade da senha escolhida pelo usuário. É altamente recomendado para segurança do sistema que durante a implantação essa opção seja ativada. Esta configuração está na aba de “Senhas” dentro do ícone “Parâmetros Gerais” do ECM.

Para maior confiabilidade de usuários e senhas recomenda-se a utilização de LDAP realizando a integração de senhas com o diretório de usuários do ambiente.

Autenticação de Usuário Integrada

No TOTVS | ECM é possível usar autenticação de usuário integrada com o Windows® no padrão NTLM (somente com a versão 1). Os usuários serão autenticados contra o domínio de rede / Active Directory®.

A configuração de autenticação de usuário integrada está disponível na área de administração do TOTVS | ECM para usuários administradores. Para alterar as configurações acesse http://<servidor>:<porta>/webdesk, usando usuário wdkAdmin, e senha adm.

Onde servidor é o nome do servidor onde o TOTVS | ECM foi instalado e porta é a porta habilitado para o acesso.

Para habilitar a autenticação integrada é necessário dispor do nome do servidor que controla o domínio de rede e o nome do domínio de rede.

Caso este tipo de autenticação seja válida somente para alguns IP’s específicos deve-se informá-los no campo “Faixa de IP”.

OBS: Se a sessão expirar, ou se o usuário efetuar Logoff basta deixar os campos usuário e senha em branco e clicar em ENTRAR para autenticar-se novamente. Se o usuário possuir login e senha somente no TOTVS | ECM basta digitar o usuário e senha e clicar em ENTRAR.


Conforme informações da Microsoft® (http://technet.microsoft.com/pt-br/library/dd566199(WS.10).aspx), os sistemas operacionais Windows® 7 e Windows® Server 2008, estão configurados por padrão para o NTLM versão 2 (128 bits), não compatível com o ECM, por isso é necessário alterar algumas configurações nas estações clientes para que a autenticação integrada funcione corretamente, conforme abaixo:

Acessar Control Panel > System and Security > Administrative Tools > Local Security Policy

Acessar Local Policies > Security Options

Alterar:
Network Security: LAN Manager authentication level = Send LM & NTLM responses
Network Security: Minimum session security for NTLM SSP based (including secure RPC) clients = DESMARCAR todas as opções
Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers = DESMARCAR todas as opções
Network Security: Restrict NTLM: Incoming NTLM traffic = Allow All
Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Allow All

Recomendamos reiniciar as estações depois de concluída as alterações.


IMPORTANTE: O uso da autenticação integrada requer uma limpeza constante de cache, para evitar o risco de invasão no sistema por usuários não autenticados. Esta situação faz com que algumas aplicações que estejam abertas no mesmo navegador percam suas informações de autenticação, ocasionando o logoff desses sites. Portanto, quando a autenticação integrada está ativa, é recomendado o uso apenas do ECM no mesmo navegador.

LDAP

Lightweight Directory Access Protocol ou LDAP “ … é um protocolo para atualizar e pesquisar diretórios rodando TCP/IP” – Wikipedia.

Nas diversas tecnologias que uma empresa de médio e grande porte utiliza hoje em dia, uma área para autenticação é exigida por praticamente todos os sistemas, o que pode muitas vezes ocasionar uma variada quantidade de cadastro de usuários replicados entre os sistemas. Como exemplo daquele usuário que tem muitos "logins" e "senhas" para acesso aos sistemas da empresa e toda semana precisa lembrar ou alterar alguma informação de seu cadastro. Ex: login e senha para acesso a máquina, a rede, ao e-mail, ao sistema de gestão (ERP), sistema de documentos (TOTVS | ECM), etc. Desta forma o usuário fica confuso e a equipe de TI perde tempo com serviço repetitivo e de suporte. Um servidor de diretórios como o OpenLDAP ou Microsoft® Active Directory® recebem esta autenticação dos muitos sistemas. O protocolo LDAP serve justamente para outras aplicações quaisquer da empresa se conectar e consultarem um servidor de diretórios. Detalhes sobre a implantação de servidor LDAP devem ser consultadas em sites de fabricantes.

O TOTVS | ECM suporta a autenticação através da conexão a um servidor LDAP, provendo assim um login único e atualização automática para a senha de usuários da rede. As configurações de acesso ao servidor LDAP deve ser realizada através definição de parâmetros no arquivo $JBOSS_HOME/server/default/conf/josso-gateway-config.xml:

  • Comente a autenticação padrão do TOTVS | ECM denominada: Basic Authentication Scheme;
  • Habilite a autenticação que está em comentário chamada: Basic LDAP Authentication Scheme;
  • Defina os parâmetros de autenticação do servidor de LDAP e salve o arquivo;


Altere o arquivo $JBOSS_HOME/server/default/deploy/wdk-service.xml e adicione a linha abaixo.

Fonte

<jndi:binding name="webdesk/LDAP"><jndi:value>true</jndi:value></jndi:binding>


Caso seja necessário poder utilizar tanto a senha cadastrada no ECM, ou no servidor LDAP, pode ser utilizado o parâmetro combined. Com este parâmetro o colaborador poderá acessar o sistema tanto com a senha cadastrada no banco de dados, ou com a senha LDAP.

Fonte

<jndi:binding name="webdesk/LDAP"><jndi:value>combined</jndi:value></jndi:binding>


Caso existe mais de um servidor de autenticação LDAP para domínios distintos, também existe a integração para dois servidores. Sendo necessário criar no arquivo josso-gateway-config.xml uma nova estrutura de tags authentication-scheme com a tag name definida com o valor 3nd-authentication.

Fonte

<jndi:binding name="webdesk/LDAP"><jndi:value>multiple</jndi:value></jndi:binding>


Reinicie o JBOSS®.

Em caso de uso de autenticação no TOTVS | ECM por meio de protocolo LDAP, é necessária a inclusão do usuário wdkAdmin no servidor LDAP para que seja possível acessar a área de administração do TOTVS | ECM.

Menu

O acesso para cada funcionalidade do TOTVS | ECM pode ser controlado pela segurança de menu.

Para configurar a segurança do menu acesse Painel de Controle > Segurança de Menu. A segurança das funcionalidades do produto pode ser definida por Grupos de Colaboradores.

Criptografar senha de conexão com Banco de Dados

Quando um datasource é configurado no TOTVS | ECM, as informações de usuário e senha são armazenadas em cleartext no arquivo wdk-ds.xml. Para não manter estas informações abertas no arquivo, existe a possibilidade de codificar a senha. Basicamente, a senha é codificada e inserida em um “Security-Domain”, que é utilizado pelo datasource para fazer a autenticação no banco de dados.

Para gerar a senha codificada abra o prompt de comando e navegue até a pasta de instalação do TOTVS | ECM (Ex: C:\TOTVS\ECM\), acesse a pasta bin e execute o passwd.bat (no Linux® passwd.sh) passando a senha a ser criptografada por parâmetro, por exemplo senhaecm.

Depois de criptografada a senha é necessário fazer alterações nos arquivos wdk-ds.xml e login-config.xml


Navegue até a pasta de instalação do TOTVS | ECM e acesse o arquivo wdk-ds.xml localizado em <INSTALL_ECM>\server\default\deploy. Neste arquivo remova as tags user-name e password e descomente/inclua a tag security-domain para local-tx-datasource e para no-tx-datasource.

Exemplo:

<datasources> <local-tx-datasource>
<use-java-context>false</use-java-context> <jndi-name>jdbc/webdeskDS</jndi-name>
<connection-url>jdbc:mysql://localhost:3306/webdesk</connection-url> <driver-class>com.mysql.jdbc.Driver</driver-class>
<security-domain>EncryptDBPasswordDS</security-domain>
<valid-connection-checker-class-name>
org.jboss.resource.adapter.jdbc.vendor.MySQLValidConnectionChecker </valid-connection-checker-class-name>
<exception-sorter-class-name> org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter
</exception-sorter-class-name> </local-tx-datasource> <no-tx-datasource>
<use-java-context>false</use-java-context> <jndi-name>jdbc/webdeskDS</jndi-name>
<connection-url>jdbc:mysql://localhost:3306/webdesk</connection-url> <driver-class>com.mysql.jdbc.Driver</driver-class>
<security-domain>EncryptDBPasswordDS</security-domain>
<valid-connection-checker-class-name>
org.jboss.resource.adapter.jdbc.vendor.MySQLValidConnectionChecker </valid-connection-checker-class-name>
<exception-sorter-class-name> org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter
</exception-sorter-class-name> </no-tx-datasource>
</datasources>


Navegue até a pasta de instalação do TOTVS | ECM e acesse o arquivo login-config.xml localizado em <INSTALL_ECM>\server\default\conf. Neste arquivo descomente/inclua os application-policy correspondente a EncryptDBPasswordDS e EncryptDBPasswordQuartzDS e adicione o nome de usuário do datasource e a senha criptografada conforme o exemplo abaixo.

Exemplo:

<application-policy name="EncryptDBPasswordDS"> <authentication> <login-module code="org.jboss.resource.security.SecureIdentityLoginModule" flag="required"> <module-option name="username"> root </module-option> <module-option name="password"> 2a227a1d21a8ef5cdf8592078de921bc </module-option> <module-option name="managedConnectionFactoryName"> jboss.jca:name=jdbc/webdeskDS,service=LocalTxCM </module-option> </login-module> </authentication> </application-policy> <application-policy name="EncryptDBPasswordQuartzDS"> <authentication> <login-module code="org.jboss.resource.security.SecureIdentityLoginModule" flag="required"> <module-option name="username"> root </module-option> <module-option name="password"> 2a227a1d21a8ef5cdf8592078de921bc </module-option> <module-option name="managedConnectionFactoryName"> jboss.jca:name=jdbc/webdeskQuartzDS,service=NoTxCM </module-option> </login-module> </authentication> </application-policy>


Para mais informações consulte o link:

http://community.jboss.org/wiki/encryptingdatasourcepasswords

Segurança no servidor de aplicação

O servidor de aplicação possui uma série de funcionalidades para administração do ambiente, elas ajudam na busca de problemas de execução do servidor. Entretanto elas permitem que usuários mal intencionados acessem informações confidenciais da empresa e podem, por exemplo, derrubar o servidor de aplicação, impossibilitando o acesso de outros usuários ao sistema.

Em ambientes de produção é recomendado que o acesso a essas funcionalidades estejam indisponíveis para os usuários. Para isto o serviço do ECM deve estar parado e no diretório de instalação do ECM, navegue até a pasta: “\server\default\deploy” e elimine as pastas “management”, “jmx-console.war” e "http-invoker.sar". Isso irá bloquear o acesso as interfaces de administração do ambiente. Após isso inicie o serviço do ECM novamente.

Observação: Caso o cliente não queira ver as informações do JBOSS® quando acessa o link “http://servidor:porta”, deve excluir a pasta “server\default\deploy\jboss-web.deployer\ROOT.war.” (Não é necessário reiniciar o serviço)


Visualizador Interno Versus Caminho Relativo


Para que os documentos publicados no ECM que estão armazenados em um servidor com caminho relativo, exemplo: \\SERVIDOR\VOLUME, possam ser visualizados através do visualizador interno do produto, é necessário que seja feito um mapeamento da unidade no servidor, exemplo: x: ou z:, além disso é necessário alterar o arquivo $JBOSS_HOME/bin/run.bat incluindo a seguinte linha no inicio do arquivo:

NET USE x: \\SERVIDOR\VOLUME

Onde x: é o nome do mapeamento e \\SERVIDOR\VOLUME é o volume mapeado no servidor.

Também é necessário alterar o arquivo $JBOSS_HOME/bin/shutdown.bat, incluindo a seguinte linha no inicio do arquivo:

NET USE x: /DELETE

OBS: Essa configuração é valida apenas para sistema operacional Windows®, ou seja, para outros sistemas operacionais a visualização interna não funciona quando o volume de documentos esta em um caminho relativo.


Tamanho e Limite do Arquivo de log

O ECM utiliza a ferramenta Log4j (http://logging.apache.org/log4j/) para gravação do log de dados da aplicação. Os arquivos de log podem ser verificados no diretório <INSTALL_ECM>/server/default/log.

Muitas vezes pode ser necessário configurar, além do nível de informação registrado em log (DEBUG, INFOR, WARN e ERROR), o tamanho e o limite dos arquivos físicos gravados no diretório padrão do sistema. O arquivo “jboss-log4j.xml”, localizado em <INSTALL_ECM>/server/default/conf, define a parametrização do log do JBoss® na versão 4.2.3., o qual é o servidor de aplicação utilizado pelo TOTVS | ECM.

A subclasse RollingFileAppender da classe FileAppender permite a configuração dos arquivos de log sempre que atingirem um determinado tamanho. Os parâmetros MaxFileSize e MaxSizeRollBackups desta subclasse, definem a configuração do tamanho e limite dos arquivos de log, sendo:

- MaxFileSize: tamanho físico máximo do arquivo de log.
- MaxSizeRollBackups: quantidade máxima de arquivos físicos que serão gravados.

Segue abaixo exemplo do trecho do arquivo “jboss-log4j.xml” configurado para registro do tamanho e limite do arquivo de log:


IMPORTANTE: Para habilitar deve ser retirado os comentários (“<!--, “-->”) da subclasse RollingFileAppender, aproximadamente linhas 48 à 58, e inserir os comentários (“<!--, “-->”) na subclasse DailyRollingFileAppender, aproximadamente linhas 24 à 45.

A subclasse DailyRollingFileAppender deve ser desabilitada, pois sua finalidade é gravar os arquivos de log de tempo em tempo, sendo atualmente “diário” na configuração default do TOTVS | ECM, porém quando definido tamanho e limite nos arquivos de log, os mesmos serão gravados e nomeados com um valor sequencial (server.log1, server.log2, server.log3, ...) de acordo com o tamanho e quantidade definido nos parâmetros.

Para mais informações:

http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/FileAppender.html
http://docs.jboss.org/jbossas/getting_started/v4/html/tour.html


Inicialização

Indexação

Quando o TOTVS | ECM é instalado a partir da migração do Webdesk 2.04 é necessário reindexar o conteúdo do repositório do produto.

Para reindexar o repositório acesse GED > Indexação. Duas opções estão disponíveis são elas:

  • Todo o repositório: realiza a indexação de todo o conteúdo criado no repositório. O tempo de indexação depende da dimensão do repositório do produto;
  • Somente documentos alterados ou novos documentos: é o modo de indexação de emergência. Executa a indexação para documentos que foram publicados e por alguma circunstância não puderam ser indexados no momento de sua publicação.

Licenciamento

Verifique o Guia de Instalação ECM como configurar o servidor de licenças.



  • Sem rótulos