sexta-feira, 21 de outubro de 2011
TopConnect - Configuração
Produto: Unspecified
Ambiente: Unspecified
Versão: 4.2
Avaliação
O procedimento para a instalação é bastante simples, basta executar o instalador, e seguir os passos avançando “NEXT” até sua conclusão, um diretório será criado na pasta “Arquivos de Programas” no DISCO LOCAL.
Solução
Configuração do Campo ODBC
Antes de configurar o TopConnect é preciso que seja configurado o ODBC,da seguinte maneira:
1- Acessar o Painel de controle | Ferramentas Administrativas |Fonte de Dados (ODBC).
Na pasta “Fontes de Dados do Sistema”, clicar em “Adicionar” e selecionar o DRIVER SQL SERVER.
OBS.: Caso o sistema operacional seja 64 bits, o ODBC encontra-se em outro caminho, acesse C:\WIN\SYSWOW64\odbcad32.
2- Para adicionar o Driver é necessário informar os dados abaixo:
*Servidor – Informar o Servidor onde está instalado o Banco de Dados SQL.
3- É necessário criar as instâncias para estabelecer a conexão no topconnect. Informe o nome da instância conforme figura abaixo:
4- A configuração do Logon deve ser parametrizada conforme abaixo e nos campos identificação de “Logon e Senha” deve ser preenchidos com seu usuário e senha do Banco.
4- Nesta tela deve-se marcar o parâmetro “Alterar o Banco de Dados” para, e selecionar uma Base de Dados válida.
OBS.: É recomendado que se crie uma base vazia e informe esta base no certificado, não escolhendo a sua base oficial, para não sobrecarregar a base oficial com informações referentes ao envio da NF-e e por questões de performace.
5- Nesta próxima etapa não é necessário alterar as configurações, basta finalizar e testar a conexão.
6 – Verifique se foi criado seu ambiente como na imagem abaixo:
Configuração do TopConnect:
Ao iniciar o aplicativo, irá aparecer uma janela com o nome do servidor TopConnect, como mostra a figura
Abaixo com as portas “Servidor :localhost” e a “Porta:7890” como default:
Após clicar em OK, o TopConnect irá iniciar uma tela mostrando as informações de conexão com o banco de dados:
Em seguida acesse a aba “Configuração” e selecione a aba referente ao banco de dados utilizado, no caso abaixo temos as configurações do Microsoft SQL.
Em “Ambiente” informe a instância criada no ODBC e usuário e senhas do Banco, informados também na criação do ODBC.
A configuração para o banco ORACLE é feita da seguinte forma, acesse a aba “configurações” em seguida a Aba “Oracle”.
Fique atento para os seguintes campos a serem marcados quando você utilizar uma base Oracle para o SPED.
1- Identificar queries para a monitoração
2- Usar BLOB para campos MEMO.
Caso não os marque podem ser gerados problemas na formatação do XML da nota.
Caso escolha trabalhar com uma base Oracle para o TSS o usuário deve acrescentar o caminho da OCI.DLL no arquivo de configuração do TopConne
Este arquivo fica gravado em: C:\Arquivos de programas\TOPConnect 4.0.
Edite o arquivo topconn.ini e acrescente a seguinte linha abaixo da tag
[ORACLE]
clientlibrary=C:\oracle\product\10.2.0\db_1\BIN\oci.DLL
Onde C:\oracle\product\10.2.0\db_1\BIN é o local de instalação o Oracle.
Após isto Valide a sua conexão na aba “Assistente”.
domingo, 16 de outubro de 2011
Como fazer para configurar os parâmetros de linha do TOTVS | Application Server
Abrangência
ERP 10 e 11
A seguir, observe as opções de linha do TOTVS | Application Server:
Parâmetro Descrição
-Console
-Debug
Apresenta as informações recebidas, na tela de console, das conexões com o TOTVS | Application Server.
-Install Permite instalar o TOTVS | Application Server como um serviço do Gerenciador de Tarefas do Windows. Com isso, o administrador do Sistema, poderá iniciar e parar o serviço diretamente no Gerenciador de Tarefas do Windows.
-Remove Permite remover o serviço, do TOTVS | Application Server, do Gerenciador de Tarefas do Windows.
sábado, 8 de outubro de 2011
Modelo Tcp/ip
Modelo Tcp/ip
Constitui um modelo também organizado por camadas. Em comparação com o modelo OSI, o modelo TCP/IP possui somente quatro camadas.
Arquitetura de Redes TCP/IP
Autor: Fernando Lozano
Tipo: Tutoriais Última Atualização: 08 de outubro de 1998
Página: 3 de 7
O Modelo de Pilha de 4 camadas do TCP/IP
O TCP/IP foi desenhado segundo uma arquitetura de pilha, onde diversas camadas de software interagem somente com as camadas acima e abaixo. Há diversas semelhanças com o modelo conceitual OSI da ISO, mas o TCP/IP é anterior à formalização deste modelo e portanto possui algumas diferenças.
O nome TCP/IP vem dos nomes dos protocolos mais utilizados desta pilha, o IP (Internet Protocol) e o TCP (Transmission Control Protocol). Mas a pilha TCP/IP possui ainda muitos outros protocolos, dos quais veremos apenas os mais importantes, vários deles necessários para que o TCP e o IP desempenhem corretamente as suas funções.
Visto superficialmente, o TCP/IP possui 4 camadas, desde as aplicações de rede até o meio físico que carrega os sinais elétricos até o seu destino:
4. Aplicação (Serviço) FTP, TELNET, LPD, HTTP, SMTP/POP3, NFS, etc.
3. Transporte TCP, UDP
2. Rede IP
1. Enlace Ethernet, PPP, SLIP
Além das camadas propriamente ditas, temos uma série de componentes, que realizam a interface entre as camadas:
Aplicação / Transporte DNS, Sockets
Rede / Enlace ARP, DHCP
Vamos apresentar agora uma descrição da função de cada camada do TCP/IP:
1. Os protocolos de enlace tem a função de fazer com que informações sejam transmitidas de um computador para outro em uma mesma mídia de acesso compartilhado (também chamada de rede local) ou em uma ligação ponto-a-ponto (ex: modem). Nada mais do que isso. A preocupação destes protocolos é permitir o uso do meio físico que conecta os computadores na rede e fazer com que os bytes enviados por um computador cheguem a um outro computador diretamente desde que haja uma conexão direta entre eles.
2. Já o protocolo de rede, o Internet Protocol (IP), é responsável por fazer com que as informações enviadas por um computador cheguem a outros computadores mesmo que eles estejam em redes fisicamente distintas, ou seja, não existe conexão direta entre eles. Como o próprio nome (Inter-net) diz, o IP realiza a conexão entre redes. E é ele quem traz a capacidade da rede TCP/IP se "reconfigurar" quando uma parte da rede está fora do ar, procurando um caminho (rota) alternativo para a comunicação.
3. Os protocolos de transporte mudam o objetivo, que era conectar dois equipamentos, para' conectar dois programas. Você pode ter em um mesmo computador vários programas trabalhando com a rede simultaneamente, por exemplo um browser Web e um leitor de e-mail. Da mesma forma, um mesmo computador pode estar rodando ao mesmo tempo um servidor Web e um servidor POP3. Os protocolos de transporte (UDP e TCP) atribuem a cada programa um número de porta, que é anexado a cada pacote de modo que o TCP/IP saiba para qual programa entregar cada mensagem recebida pela rede.
4. Finalmente os protocolos de aplicação são específicos para cada programa que faz uso da rede. Desta forma existe um protocolo para a conversação entre um servidor web e um browser web (HTTP), um protocolo para a conversação entre um cliente Telnet e um servidor (daemon) Telnet, e assim em diante. Cada aplicação de rede tem o seu próprio protocolo de comunicação, que utiliza os protocolos das camadas mais baixas para poder atingir o seu destino.
Pela figura acima vemos que existem dois protocolos de transporte no TCP/IP. O primeiro é o UDP, um protocolo que trabalha com datagramas, que são mensagens com um comprimento máximo pré-fixado e cuja entrega não é garantida. Caso a rede esteja congestionada, um datagrama pode ser perdido e o UDP não informa as aplicações desta ocorrência. Outra possibilidade é que o congestionamento em uma rota da rede possa fazer com que os pacotes cheguem ao seu destino em uma ordem diferente daquela em que foram enviados. O UDP é um protocolo que trabalha sem estabelecer conexões entre os softwares que estão se comunicando.
Já o TCP é um protocolo orientado a conexão. Ele permite que sejam enviadas mensagens de qualquer tamanho e cuida de quebrar as mensagens em pacotes que possam ser enviados pela rede. Ele também cuida de rearrumar os pacotes no destino e de retransmitir qualquer pacote que seja perdido pela rede, de modo que o destino receba a mensagem original, da maneira como foi enviada.
Agora, vamos aos componentes que ficam na interface entre os níveis 3 e 4 e entre os níveis 1 e 2.
O Sockets é uma API para a escrita de programas que trocam mensagens utilizando o TCP/IP. Ele fornece funções para testar um endereço de rede, abrir uma conexão TCP, enviar datagramas UDP e esperar por mensagens da rede. O Winsockets, utilizado para aplicações Internet em Windows é nada mais do que uma pequena variação desta API para acomodar limitações do Windows 3.1. No Windows NT e Win95 pode ser usada a API original sem problemas.
O Domain Name Service (DNS), que será visto com maiores detalhes mais adiante, fornece os nomes lógicos da Internet como um todo ou de qualquer rede TCP/IP isolada.
Temos ainda o ARP realiza o mapeamento entre os endereços TCP/IP e os endereços Ethernet, de modo que os pacotes possam atingir o seu destino em uma rede local (lembrem-se, no final das contas quem entrega o pacote na rede local é o Ethernet, não o TCP ou o IP).
Por fim, o DHCP permite a configuração automática de um computador ou outro dispositivo conectado a uma rede TCP/IP, em vez de configurarmos cada computador manualmente. Mas, para entender o porque da necessidade do DHCP, temos que entender um pouco mais do funcionamento e da configuração de uma rede TCP/IP.
segunda-feira, 3 de outubro de 2011
Balanceamento de carga entre serviços (LoadBalance)
Quando existe uma grande quantidade de usuários que utilizam o sistema, e o servidor (hardware) não possui uma configuração ideal para comportar todas as conexões simultaneamente, mas há mais de um servidor disponível, pode-se configurar balanceamento de carga de conexões, para permitir a escalabilidade da aplicação.
Para que isto seja possível, "nomeamos" um servidor intitulado de "servidor Master" que será o responsável por administrar o balanceamento.
Configurando o servidor Master
O único arquivo de configuração (xxxsrv.ini) que será alterado com as configurações abaixo é o do servidor Master, pois é ele quem administrará o balanceamento de carga de conexões. Todos os usuários se conectarão inicialmente ao servidor Master, e é este quem efetuará o balanceamento de carga das conexões para os outros servidores. Nos arquivos de configuração (*.ini) dos outros servidores será alterado apenas a chave "RootPath", para que eles peguem a mesma base de dados do servidor Master.
[ServerNetwork]
Servers=SERVER2, SERVER3 --> NÃO INFORME O NOME DO SERVIDOR MASTER
MasterConnection=0 --> O SERVIDOR MASTER NÃO RECEBE CONEXÃO
[SERVER2]
Type=TCPIP
Server=172.16.77.42
Port=1234
Connections=1
[SERVER3]
Type=TCPIP
Server=172.16.75.62
Port=1235
Connections=1
Configuração dos outros servidores
Conforme citado acima, nos demais servidores a única coisa que será alterada é a chave " RootPath" do arquivo de configuração do TOTVS Application Server. Para isso, o diretório raiz (P10), do servidor Master, deve ser compartilhado com direitos apenas para um usuário que será usado por todos os serviços. Assim, os outros usuários não conseguirão acesso a este diretório. Isto é necessário para que todos os servidores exerguem a mesma base de dados. Supondo que a base de dados esteja no servidor Master, os arquivos de configuração (*.ini) ficariam assim:
[Environment]
SourcePath=C:\XXX\APO
RootPath=\\SIGAMASTER\XXX\AP_DATA\ --> Veja que a raiz está sendo apontada para o servidor Master.
StartPath=\SIGAADV\ ou \SYSTEM\
(as demais configurações continuam iguais)
Observações
Cada servidor deverá ter o seu build e repositório, sendo que a base de dados fica centralizada no servidor Master ou no servidor de banco de dados.
O balanceamento de carga de conexões é monoplataforma para o TOTVS Application Server. Isso significa que o MASTER e todos os SLAVES devem rodar no mesmo sistema operacional.
Quando for realizada qualquer atualização de build e o repositório no servidor Master, a mesma alteração deverá ser feita nos outros servidores.
Um mesmo usuário Windows deve ter direitos na pasta compartilhada (RootPath) e deverá ser um usuário Administrador, para que possa ser associado ao serviço de cada servidor.
Para verificar onde os usuários estão conectados, basta utilizar a aplicativo TOTVS Monitor em cada servidor.
Crie seções [TCP] no arquivo de configuração, do TOTVS Smart Client, para receber conexão dos slaves (TCP1, TCP2, TCP3 e TCPN).
[TCP1]
Server=Slave1
Port=1237
[TCP2]
Server=Slave2
Port=1239
[TCP3]
Server=Slave3
Port=1241
Ao abrir o TOTVS Monitor, informe qual comunicação [TCP] que deseja verificar as conexões.
O nome do ambiente e portas de comunicação deve ser idêntico para todos os servidores.
Separe em um servidor dedicado, um TOTVS Application Server para o ambiente de compilação: compilação é uma operação crítica, exclusiva, que não deve ser executada no mesmo serviço do TOTVS Application Server que está atendendo conexões de usuários do TOTVS Smart Client e ambiente de produção.
No caso de balanceamento de carga de conexões em schedule, deve-se escolher um slave para receber a conexão. Lembre-se que o servidor Master NÃO recebe conexões.
O valor da chave Connections determina a distribuição de conexões entre os slaves usando RAZÃO MATEMÁTICA (Exemplo: 1:2:1)
O valor de RootPath=\\SIGAMASTER\XXX\AP_DATA\ deve ser a mesma para todas as instâncias para os ambientes [Environment] de mesmo nome. Para mais informações, consulte a documentação da seção [ServerNetwork].
Reserve 2 GB para cada TOTVS Application Server criado que pode ser na mesma máquina (desde que tenha capacidade para isso).
No ambiente de balance cada ambiente deve ter seu RPO (todos iguais). NÃO compartilhe RPO em rede, pelos seguintes motivos:
Em casos conhecidos os logs mostram que o sistema operacional está causando os erros de comunicação nos servidores de aplicação e não nas estações.
As mensagens que as estações enviam no momento de uma nova conexão mostram que foi a parte servidora da operação que cortou a conexão de rede.
Os servidores de aplicação fazem leitura intensiva dos RPOs quando executam o ERP, pois neles estão compiladas todas as regras de negócio, se o RPO é compartilhado em rede, tem como resultado:
Degradação na performance de execução dos servidores de aplicação que utilizam o RPO compartilhado (tráfego de RPO em rede).
O aumento do consumo de recursos de rede nos servidores que compartilham RPO, tipicamente, saturam o uso das interfaces de rede, criando uma concorrência de transmissão de dados com as estações que utilizam o TOTVS Smart Client.
sexta-feira, 30 de setembro de 2011
terça-feira, 27 de setembro de 2011
Assinar:
Postagens (Atom)