Beruflich Dokumente
Kultur Dokumente
TSS
Sumrio
1.
Introduo .................................................................................................................................................. 3
1.1.
Plataforma Operacional.............................................................................................................................. 3
2.
Balanceamento de Carga........................................................................................................................... 4
2.1.
Conceito ..................................................................................................................................................... 4
2.2
Verso 1.0
1. Introduo
O TSS (TOTVS Service SOA) uma aplicao baseada na arquitetura orientada a servios, em que o objetivo principal
prover os servios de emisso e manuteno de documentos fiscais eletrnicos (NFe, CTe, NFSe, CLe, MDFe, MDe, NFCe,
NFe Argentina, entre outros), realizando a comunicao entre a aplicao ERP e os servios web dos organismos fiscais.
Alm de servir como um software de prestao de servios, o TSS tambm possui interfaces grficas para demonstrar
informaes interativas de suas operaes e disponibilizar funcionalidades diretamente com alguns servios especficos do
produto, como Importao/Exportao de documentos eletrnicos, Notificao ao usurio por e-mail entre outros.
1.1.
Plataforma Operacional
O TSS foi desenvolvido sob a plataforma TOTVS Application Server, em linguagem AdvPL. Por esta razo, utiliza para
comunicao com servidor de banco de dados (SGDB) a aplicao TOTVS DBAccess. Logo, as informaes que dizem
respeito as plataformas de hardware, sistema operacional, virtualizao e bancos de dados homologados devem ser
consultadas diretamente na documentao sobre a plataforma TOTVS Application Server, disponvel no portal TDN, em
http://tdn.totvs.com.br, seo Plataforma Homologada.
Para informaes adicionais sobre os processos de Instalao e Configurao, recomenda-se a leitura integral dos
documentos especficos destes temas, disponveis no portal TDN, em http://tdn.totvs.com.br, seo Funcionalidades ->
TSS - TOTVS Service SOA -> Manuais
Verso 1.0
2. Balanceamento de Carga.
2.1.
Conceito
Quando um nico servidor (hardware) no possui uma configurao que comporte a carga gerada por um grande
processamento, possvel configurar uma nova instncia da aplicao em um outro servidor disponvel e balancear a
carga de processamento, de forma que o recurso computacional seja elevado com a adoo de um novo hardware. A
configurao de balanceamento de carga visa a escalabilidade da aplicao para permitir a utilizao do TSS mesmo
em cenrios de operao crtica ou que demandem alto volume de transaes dirias.
Ainda que o hardware utilizado comporte um volume expressivo de carga, as caractersticas de limite mximo de
consumo de memria da aplicao devem ser respeitadas, logo, podem ser adotadas novas instancias em um mesmo
hardware, desde que este comporte.
A seguir, apresentamos algumas premissas bsicas e requisitos mnimos para adoo do recurso de balanceamento:
Um mesmo tipo de sistema operacional deve ser utilizado em todos os servios criados;
Uma cpia do build deve ser utilizada para cada novo servio criado;
Uma atualizao de build, quando realizada deve ser replicada a todos os demais servios.
Um mesmo usurio Microsoft Windows deve ter direitos na pasta compartilhada (RootPath) e dever pertencer
ao grupo Administrador, para que possa ser associado ao servio de cada servidor.
O nome do ambiente, convencionalmente definido como [SPED] deve ser idntico para todos os servidores.
Separe em um servidor dedicado, o ambiente de homologao: homologao uma operao de menor
relevncia, que no deve ser executada no mesmo servio que atende as conexes do ambiente de produo
para que no haja concorrncias desvantajosas ao processo.
O valor de RootPath=\\SERVER1\protheus_data\ deve ser a mesma para todas as instncias para os ambientes
Environment de mesmo nome e no devem compreender unidades de letra mapeadas
Reserve 2 GB de memria RAM para cada instncia do servidor de aplicao, que pode ser na mesma mquina
desde que tenha capacidade para isso.
Nos ambientes balanceados deve haver um nico repositrio (RPO). No compartilhe RPO em rede, pois os
servidores de aplicao fazem leitura intensiva do RPO quando executam os JOBS, visto que neles esto
compiladas todas as regras de negcio, se o RPO compartilhado em rede, tem como resultado:
o
o
Fonte: http://tdn.totvs.com/display/tec/Balanceamento+de+carga
Importante/ Saiba Mais
O repositrio de funes do TSS (Apo) do tipo Small Application, e contempla apenas as funes
relativas as regras de negcio do TSS alm da LIB de Framework. Demais recursos do ERP no
esto presentes neste arquivo.
Verso 1.0
Exemplo prtico:
A partir da adoo de um cenrio fictcio de uma corporao que contempla 50 filiais, aonde 4 delas comportam volumes
medianos de trfego de documentos, 1 comporta volume alto e as demais baixo volume, pode ser adotado como
arquitetura de balanceamento um modelo segregado por Entidades, aonde um determinado servio (Application Server)
comporta o processamento de uma ou mais entidades previamente definidas.
Verso 1.0
No cenrio acima, o servio responsvel por receber as requisies do ERP, representado como Servio WebServices foi isolado em um
servio especifico para este fim. As entidades 01 e 02, 03 e 04 que possuem volume mediano de documentos, foram por esta razo
balanceados em servios especficos, denominados Proc 01 e Proc 02. A entidade 05 possui alto volume foi configurada em um servio
exclusivo (Proc 03), as demais entidades, que compreendem baixo volume, ficaram agrupadas em um mesmo servio, denominado Proc 03.
Verso 1.0
Manifestos de Documentos Fiscais MDFe, e baixa emisso de Notas Fiscais e Notas Fiscais de Servio pode ser adotado
um modelo de balanceamento por tipo de documento, uma vez que previamente conhecido os tipos de documentos
emitidos e seus volumes.
Neste exemplo, o servio responsvel por receber as requisies do ERP, representado como Servio WebServices foi isolado em um servio
especifico para este fim. O Servio 01 (ou Proc 01) responsvel pelas tarefas de processamento da NFe e NFSe . J o Servio 02 realiza as
mesmas atividades, mas para o documento CTe, pois este tem volume (quantidade) superior de emisses, bem como o Servio 03 para
Manifesto de Documentos Fiscais. possvel observar que os tipos que possuem maior volume utilizam servios exclusivos.
Verso 1.0
Exemplo prtico:
A partir da adoo de um cenrio fictcio de uma corporao de filial nica que tem como atividade principal o comercio
eletrnico de produtos diversificados, qual tem alto volume de emisso de documentos, em uma operao 24x7. Neste
cenrio a proporo das vendas de 10.000 pedidos/hora. Por envolver uma operao substancialmente crtica e de alto
volume, foi empregada um balanceamento por tipo de atividade.
Neste exemplo, o servio responsvel por receber as requisies do ERP, representado como Servio WebServices foi isolado em um servio
especifico para este fim. O Servio 01 (ou Proc 01) responsvel apenas pela atividade de assinatura dos documentos. J o Servio 02 realiza
apenas a atividade de transmisso da NFe. O Servio 03 tambm faz tarefas de transmisso, mas apenas para cancelamentos e inutilizaes.
O Servio 04 realiza apenas as tarefas de envio de e-mail da NFe aos clientes faturados.
Verso 1.0
Exemplo prtico:
A partir da adoo de um cenrio fictcio de um uma companhia de cloud computing que utiliza o TSS para fazer o
gerenciamento dos documentos fiscais de seus clientes. Esta companhia contempla 5000 clientes emissores de
documentos fiscais, cada qual com a suas caractersticas (Uns emitem mais NFe do que CTe, outros tem mltiplas
entidades mas pouco volume transacional, entre outros.) Alm disto esta companhia oferta uma soluo que tem como
caracterstica de nvel de servio uma disponibilidade de 24x7 (as manutenes no podem afetar as operaes).
Verso 1.0
10
Verso 1.0
3. Mtricas de balanceamento
Para adoo de cenrios balanceados, no existem definies pr-delimitadas que apresentem nmeros reais capazes
de fornecer insumos na elaborao de um cenrio de arquitetura balanceada (ou seja, uma anlise quantitativa sobre
nmeros que permitam a construo de um projeto). Isto porque a anlise baseada apenas sobre as quantidades de
documentos trafegados versus a relao de servios de processamento necessrios no pode ser levada em considerao
de forma genrica para todos os clientes, ou at mesmo para todas as entidades/filiais de uma mesma companhia, pois as
regras de negcio envolvidas no processo de concepo do documento influem significativamente no resultado final
esperado.
Como exemplo ao exposto, imagine que um cliente A emite 5000 documentos do tipo NFe por ms. E o cliente B
tambm emite a mesma quantidade, do mesmo tipo. Todavia, o cliente A, pertence ao ramo de comercio eletrnico, e
realiza o seu faturamento em tempo real (a cada fechamento de pedido). J o cliente B, pertence ao ramo de educao, e
realiza o seu faturamento no sempre no ltimo dia til do ms. Logo, podemos observar a existncia de dois clientes que
emitem quantidades iguais, do mesmo tipo de documento, mas que no podemos adotar como comparveis, visto que as
regras de negcio envolvidas em suas operaes afetam diretamente no cenrio proposto. Enquanto o cliente A emite 5000
documentos em um nico momento, o outro (B) faz a emisso em um perodo de 30 dias.
Tambm no deve ser adotado como referncia os valores que competem ao faturamento de uma companhia, uma vez
que 5000 documentos faturados ao valor de $ 1,00 resultam em um faturamento total de $ 5000, ao passo que um nico
documento faturado ao valor de $ 5000 resulta tambm em um faturamento total de $ 5000. Ambos tem mesmo faturamento
mas com quantidades diferentes de documentos.
Outro grande fator que deve ser pontuado para que esta definio no exista se refere ao contedo presente em cada
documento (ou seja, o seu teor). H diferenas no processamento de um documento simples, que contempla apenas um 1
item de um documento mais complexo, com mais de 500 itens e informaes fiscais complementares.
Logo, com exceo do guia de requisitos mnimos relacionadas a plataforma TOTVS Application Server, descritas no
tpico 1.1 Plataforma Operacional, os quais devem ser devidamente obedecidos para um funcionamento sistmico coerente,
a opo por um ambiente de balanceamento do TSS deve sempre ser apoiada na anlise das caractersticas do cliente,
relacionando-os por sua vez com os modelos de balanceamento disponveis, de modo a se optar pelo cenrio mais ideal a
necessidade apresentada, uma vez que cada modelo de balanceamento disponvel oferece uma tica diferente de anlise
sobre o processo de gesto de documentos fiscais eletrnicos. (Enquanto um visa a independncia de filiais por exemplo,
outro tem foco na relevncia do documento para a operao da companhia, entre outros). J a evoluo ou incrementao
dos cenrios balanceados, por sua vez, devem estar apoiados no monitoramento dos servios j existentes, na anlise dos
resultados obtidos e na experincia de uso provocada a partir da utilizao de um cenrio deste porte.
Verso 1.0
11
Tipo Documento
Baixa
Media
Alta
Entre 1 a 50 emisses/dia
Entre 1 a 50 emisses/dia
Entre 1 a 50 emisses/dia
Entre 1 a 50 emisses/dia
Entre 1 a 50 emisses/dia
Entre 1 a 50 emisses/dia
Entre 1 a 50 emisses/dia
12
Verso 1.0