Home

TOTVS | Plataformas e tecnologias

Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

Índice
maxLevel4
outlinetrue
exclude.*ndice
stylenone

 

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.

...

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 compatível com a especificação JDBC. Entretanto, os bancos de dados (e respectivas versões) homologados para o ECM estão descritos em:
http://tdn.totvs.com/display/tec/Matriz+de+portabilidade

...

mailIndica mailUsuário mailSenha
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.

Bloco de código
languagexml
<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.

Informações
titleFonte

<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.

Informações
titleFonte

<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.

Informações
titleFonte

<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.

Image Added

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:

Bloco de código
languagexml
<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:

 

Bloco de código
languagexml
<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” e “jmx-console.war”. 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:

Image Added

 

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.