O café não é só cafeína

Café e Composição Química A maioria das pessoas que bebem café diariamente ignora quais são as substâncias que estão presentes no café e pensa que o café contém apenas ou principalmente cafeína. Grande engano. O café possui apenas 1 a 2,5 % de cafeína e diversas outras substâncias em maior quantidade. E estas outras substâncias podem até ser mais importantes do que a cafeína para o organismo humano. O grão de café (café verde) possui além de uma grande variedade de minerais como potássio (K), magnésio (Mg), cálcio (Ca), sódio (Na), ferro (Fe), manganês (Mn), rubídio (Rb), zinco (Zn), Cobre (Cu), estrôncio (Sr), cromo (Cr), vanádio (V), bário (Ba), níquel (Ni), cobalto (Co), chumbo (Pb), molibdênio (Mo), titânio (Ti) e cádmio (Cd); aminoácidos como alanina, arginina, asparagina, cisteína, ácido glutâmico, glicina, histidina, isoleucina, lisina,metionina, fenilalanina, prolina, serina, treonina, tirosina, valina; lipídeos como triglicerídeos e ácidos graxos livres , açúcares como sucrose, glicose, frutose, arabinose, galactose, maltose e polissacarídeos. Adicionalmente o café também possui uma vitamina do complexo B, a niacina (vitamina B3 , PP ou "Pelagra Preventing" do inglês) e, em maior quantidade que todos os demais componentes, os ácidos clorogênicos, na proporção de 7 a 10%, isto é, 3 a 5 vezes mais que a cafeína. Fonte http://www.abic.com.br/publique/cgi/cgilua.exe/sys/start.htm?sid=81

Exibir histórico de atualização

Para descobrir se uma atualização foi aplicada ao seu computador, verifique o histórico de atualização: Em uma instalação completa do Windows Server 2008, clique em Iniciar, em Windows Update, em Exibir histórico de atualização e em Atualizações Instaladas. Em uma instalação Server Core, no prompt de comando, digite: wmic qfe list Procure o número de atualização kbid=950050, que indica que a atualização do Hyper-V foi instalada.

Serial visio 2007

PHGVY-62VQH-6YR3J-46D86-TG2MT microsoft visio 2007

O que é RPC?

RPC - Remote Process Call é uma ferramenta que permite executar, no TOTVS Application Server local, funções que estejam compiladas em outro ambiente do TOTVS Application Server. Pontos importantes para execução do RPC Deve haver uma conexão TCP entres os dois servidores. A rotina que será executada, no servidor destino, deve estar compilada e pronta para utilização. Todos os parâmetros da função que serão executados devem ser respeitados para evitar erros. Exemplo #include "TOTVS.CH" // ------------------------------------ // Função chamada via RPC // ------------------------------------ User Function RpcCall(param1,param2) conout('--------------------------') conout('Conout executado via RPC') conout('Parametro 01: ' + param1) conout('Parametro 02: ' + param2) conout('--------------------------') Return ("Retorno RPC") // -------------------------------------- // Função para o teste da chamada via RPC // -------------------------------------- User Function TstRpc() // Prepara ambiente para conexão em outro Servidor cEnv := "TopPadrao" oRpcSrv := TRpc():New( cEnv ) // Conecta no ambiente cServer := "Localhost" cPort := 4321 If ( oRpcSrv:Connect( cServer, cPort ) ) // Executa função Time() através do CallProc cTime := oRpcSrv:CallProc('Time') // Executa função customizada e retorna valor da mesma cRet := oRpcSrv:CallProcEX('U_RpcCall', 'Parametro 01', 'Parametro 02') Alert( "Retorno da função RpcCall(): " + cRet ) // Fecha conexão oRpcSrv:Disconnect() Else UserException('Conexão RPC falhou...') Endif Return

Servidores alternativos no Protheus Remote

Abrangência Versão 6.09 Versão 7.10 Versão 8.11 Na configuração do Protheus Remote, podemos definir mais de um servidor Protheus para tentativa de conexão, como no exemplo abaixo: [TCP] Server=myserver Port=9003 Server1=myserver1 Port1=9344 Server2=myserver2 Port2=9876 ... Server10=myserver10 Port10=8877 Como funciona o exemplo acima: O usuário seleciona a opção de configuração TCP como sessão ativa de conexão na tela de parâmetros iniciais do Protheus Remote O Protheus Remote seleciona as opções de conexão da sessão TCP, Server=myserver e Port=9003 Se o servidor myserver não estiver disponível (queda de rede ou outra falha), o Protheus Remote tentará a configuração Server1=myserver1 e Port1=9344, assim por diante até no máximo Server10 (10 opções de configurações de servidor) Como Manipular dinâmicamente via ADVPL: Utilize a função WriteProfString conforme abaixo WriteProfString( 'TCP', 'SERVER1', 'myServer1', .T. ) WriteProfString( 'TCP', 'PORT1', '9344', .T. ) WriteProfString( 'TCP', 'SERVER2', 'myServer2', .T. ) WriteProfString( 'TCP', 'PORT2', '9876', .T. ) ... WriteProfString( 'TCP', 'SERVER10', 'myServer10', .T. ) WriteProfString( 'TCP', 'PORT10', '8877', .T. ) Situação É possível configurar servidores alternativos para o Protheus 8 Remote. Ocorrência Essa configuração é realizada no arquivo de configuração (mp8rmt.ini). No entanto, como o Protheus 8 Remote ActiveX não possui arquivo de configuração (*.ini), não era possível a implementação dessa opção. Correção A partir desta build, foi implementada a opção de configuração, no arquivo mp8rmt.htm, limitada a 10 opções. Exemplo

Controle de licenças com ByYou DBAccess

O controle de licenças do ByYou DBAccess é realizado por um serviço de License Server, do ERP, que deve ser configurado no ambiente. ByYou DBAccess utilizando License Server O ByYou DBAccess utiliza as seguintes licenças: 4091 = TOP Processor 4092 = TOP User Ao iniciar o serviço do ByYou DBAccess, o mesmo estabelece conexão com o servidor de licenças e verifica se o license possui alguma licença 4091 (processor). Se existir a licença 4091, o ByYou DBAccess consumirá o número de licenças 4091 igual ao número de processadores (core) encontrado no equipamento onde está sendo executado. Porém, caso não consiga obter essas licenças, é registrada falha no processo e apenas 2 conexões são liberadas. Caso o número de núcleos indentificados apresente alguma divergência com o resultado esperado, a configuração de um log adicional de informação de processos pode ser habilitado - clique aqui para mais detalhes - para gerar um log detalhado do processo de identificação. Caso o total de licenças 4091 seja 0 (zero), é verificada a quantidade de licenças 4092 (user). Se encontrado, por padrão todas as licenças 4092 são consumidas instantaneamente. No entanto, não é possível utilizar os dois tipos de licenças simultaneamente, mesmo que o License Server possua quantidade registrada para os dois tipos de licenças acima. Pois, o sistema sempre prioriza a utilização da licença TOP Processor (4091). Observação A verificação de licença inicialmente é realizada pelo total registrado e não pelo efetivamente disponível. Limitação de consumo de licenças TOP User (4092) Caso a liberação de licenças para o ByYou DBAccess seja realizada por conexão/usuário, todas as licenças são adquiridas pelo ByYou DBAccess, logo que conectar no License Server, após subir o serviço. Se utilizados, em um determinado ambiente, mais de um serviço do ByYou DBAccess, para banco de dados distintos e/ou base de teste, onde exista apenas um servidor de licenças, e este servidor de licenças possua licenciamento por usuário, é possível limitar a quantidade de licenças que o ByYou DBAccess vai obter do License Server, através da alteração do arquivo dbaccess.ini, seção [general], inserindo a chave LicenseLimit=nnn, onde nnn é o número de licenças TOP_User (4092) que o ByYou DBAccess vai solicitar ao License Server. Deste modo, caso o License Server possua 50 licenças, porém 40 são usadas para um ByYou DBAccess e o outros 10 por outro, basta configurar a chave acima em cada um dos ByYou DBAccess. No entanto, é importante lembrar que o serviço do ByYou DBAccess deve ser parado e iniciado novamente para que esta configuração seja realizada e que a quantidade é fixa por ambiente e não on-demand. ByYou DBAccess A aplicação ByYou DBAccess, utilizada a partir do produto Microsiga Protheus 11, utiliza o mesmo sistema de licenciamento.

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

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.

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.

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.