Diretório “jsRule” -> Dentro deste diretório, contém N diretórios referenciando cada um a um sistema diferente (system e a sigla).
Dentro de cada um destes diretórios (ou sistemas) estão 2 arquivos: webrunFunctions.js e o webrunRules.js
Como o próprio nome diz, o webrunFunctions contém todas as funções do sistema (Geralmente a API + funções que você tenha criado).
Observação: Apenas as funções da camada CLIENTE estão ali, afinal, é um arquivo .JS.
O outro arquivo (webrunRules.js) contém todos os fluxos na camada cliente.

Diretório “reports” -> Possui o mesmo diretório system_sigla referenciando os relatórios do determinado sistema, este diretório contém todos os .rtm dos relatórios. Este de fato são os relatórios. Todos estes arquivos são numerados: 1.rtm, 6.rtm e assim em diante. Este número na verdade é o código do relatório.
Outro arquivo também é encontrado no diretório, o names.properties. Este arquivo contém o código e nome de todos os relatórios, desta forma, quando o Webrun possui apenas o código ou o nome de um relatório em algum momento, é possível obter a outra informação.

Diretório “src” -> Este é o diretório que contém basicamente tudo do sistema: Os formulários, os fluxos (camada servidor), dicionário de dados, menu, traduções, etc..
Dentro do diretório forms, se encontram os arquivos dos formulários. No diretório “rules”, encontram-se as regras e o WebrunFunctions.java (Que contém todas as funções do sistema na camada servidor).

Diretório “webservices” -> Caso hajam regras a serem exportadas como webservices, as mesmas estarão dentro do arquivo .jws no diretório.

Agora que você ja sabe o que é o .jar e o que contém, vamos ao principal: Como aplica-lo.
A pasta systems (C:\Program Files\Softwell Solutions\Maker 2.5\Webrun 2\systems) é o diretório que contém todos os apontadores (wfre) dos sistemas. Basicamente, o que precisa ser feito é copiar o .JAR gerado para este diretório e renomea-lo com o mesmo nome do apontador (Exceto pela extensão, obviamente) como na imagem:

Diretório system e o .JAR

Tenha certeza que o servidor de aplicações esteja parado ao efetuar esta atualização. Após isto, é necessário reiniciar o servidor de aplicações por duas vezes.
No diretório webapps, você deve manter apenas o webrun.war com a versão escolhida por você. O .jar será extraído e aplicado no webrun.

Neste tutorial será mostrado os principais passos.

1° Acesse o console de administração do Servidor através da url: http://HOST:8888/em/console/ias/oc4j/home

2° Preencha as informações de Nome de Usuário e Senha (o nome de usuário por padrão é oc4jadmin)

3° Ao logar, será apresentado a tela abaixo

4° Clique no link “Aplicações” (será exibida uma lista com todas as aplicações disponibilizadas no Servidor), na tela que se abrirá clique no botão “Disponibilizar”. Após a ação, a tela abaixo será aberta

5° Clique no botão “Enviar Arquivo” (indicado pela seta) para selecionar o WAR.

Obs.: Para a seção “Plano de Disponibilização” foi utilizada a opção “Crie automaticamente um novo plano de disponibilização”

6° Clique em “Próximo” e aguarde enquanto o servidor faz o upload do arquivo para a pasta (ORACLE_HOME(*)/j2ee\home\applications)

*ORACLE_HOME é o local onde está instalado o servidor.

7° Quando o upload estiver concluído, informe os dados conforme a tela abaixo (Seguindo a seqüência  até clicar em “Próximo” novamente)

8° Ao clicar em próximo, a tela abaixo será apresentada para confirmar os dados informados anteriormente, caso estejam corretos, clicar em “Disponibilizar”.

Ao clicar em “Disponibilizar, o servidor irá fazer os passos necessários para publicação do sistema. Aguarde até conclusão.

Após conclusão da publicação, o acesso pode ser feito em http://HOST:8888/meusistema

Obs.: A versão do OC4J utilizada no tutorial é a 10.1.3.5

Existem disponíveis na internet, algumas API’s do Twitter para várias linguagens, entre elas um pacote Java.
O pacote utilizado por mim chama-se jtwitter open source e criada pela winterwell. Se encontra na versão 1.3 neste momento em que escrevo.
Dentre as existentes (encontrei 4) escolhi o JTwitter por ser open source e muito simples de utilizar.

Foram criadas 3 funções:
Twitter – Abrir Conexão
Twitter – Atualizar Status
Twitter – Obter mensagens

Basicamente, com as 3 funções você pode enviar uma mensagem (ou tweet como é chamado) e verificar as últimas 20 mensagems nas últimas 24 horas da sua página do twitter.
As funções são bem simples de se utilizar. Só ler a pequena documentação que fiz em cada uma delas (Basicamente funciona como as funções de arquivo, onde se guarda a referencia do arquivo aberto para posteriormente utiliza-la para enviar ou receber mensagens).

Para utiliza-las, além de importar no Maker as funções, deve-se incluir o pacote jar da biblioteca do jtwitter no diretório: “…\Softwell Solutions\Maker 2.5\Webrun 2\tomcat\webapps\webrun\web-inf\libs”
Após inserir o pacote jar neste diretório, reinicie o servidor de aplicações 2x.

Pronto! Basta utilizar as funções agora em seu fluxo!
Segundo as “regras” da biblioteca gratuita, a única exigencia deles é expor o autor (feito acima). Se vocês observarem, a cada mensagem enviada, fica abaixo o “via JTwitter”. Caso queiram, basta editar o arquivo JTwitter.java que se encontra dentro do pacote e editar este trecho do código.

Downloads:
Pacote JAR (versão 1.3)
Funções Twitter

Simples e fácil, não?

package makerportal;

public class Principal {

	private String nome;
	private int idade;

	Principal (String nome){
		this.nome=nome;
	}

	public void setNome(String nome){
		this.nome=nome;
	}

	public void setIdade(int idade){
		this.idade=idade;
	}

	public String mostrar(){
		return "Nome: "+this.nome+"\nIdade: "+this.idade;
	}
}

Para utilizarmos esta classe no flugrama, devemos gerar um .JAR desta classe (ou conjunto de classes). É obrigatório a inclusão delas dentro de um pacote (por isso o código “package makerportal” no início). Utilizaremos o pacote para referenciar a classe no fluxograma posteriormente.
No eclipse (onde foi feito o exemplo), clicamos com o botão direito no pacote e escolhemos exportar e então escolhemos JAR como formato de exportação.

O pacote jar, deve ser incluso dentro do diretório …/WEB-INF/libs/ (que está dentro da pasta do Webrun onde foi feito o deploy no servidor de aplicações).
Observação 1: Ao invés de utilizar o pacote JAR diretamente na pasta WEB-INF/libs/ citada acima, você pode faze-lo a partir da pasta Maker.Commons
Observação 2: No momento desta cópia, garanta que o servidor de aplicações esteja PARADO.
Após o procedimento acima, inicie o servidor de aplicações, pare e então inicie novamente (Evitar caches e garantir que o pacote seja levado para a maquina virtual).

Pronto. Agora, o seu pacote está incluso com sucesso no contexto da aplicação. Vamos agora ao Fluxograma:

Observe que, em um processamento, foi chamada a função “Executar Java”. A partir dela, poderemos manipular a classe que criamos.
O que foi feito: Instanciada a classe Principal no formato pacote.classe  e passado o valor “MakerPortal”, pois o construtor utilizado no exemplo, espera um parametro do tipo String para preencher a variável privada “nome”.
Após isto, foi chamado o metodo mostrar() do objeto “principal” e retornado a partir de um cast feito com o metodo VariantPool.get();
Acontece que o Webrun, não trabalha com tipos de dados que não sejam Variante (assim como as funções). Todo objeto é um Variant.

Como a função “Executar Java” irá retornar uma string, a mesma foi repassada para a função “Alertar Aguardando OK”, que exibirá na tela o valor.

Resultado: Após salvo o fluxo, basta associar a um evento de qualquer componente e obter o valor!

Dúvidas?! Utilize o nosso fórum!

Para modificar a senha do usuário é necessário concatenar o código do usuário localizado no campo USR_CODIGO da tabela FR_USUARIO mais a nova senha.

Próximo passo é obter o md5 desta concatenação. Veja o exemplo abaixo:

Modificar senha do usuário

Feito isto, basta executar uma atualização no campo USR_CODIGO com o valor retornado pela função MD5 do Texto.

Segue o código abaixo:

<html>
<head></head>
<body>
<form method="POST" action="http://localhost:8080/webrun/logon.do?sys=SGC">
  <input type="text" name="user" value="master"/>
  <input type="text" name="password" value="1"/>
  <input type="submit" value="Clique!"/>
</form>
</body>
</html>

No código acima será executado um método POST no action LOGON.DO do Webrun.

Ao clicar no botão “Clique!” no navegador, o usuário será logado no sistema!

Para isto, basta acessar “Definições” do formulário desejado, acessando o seu “Assistente de Consulta”. Na consulta deste formulário, selecione uma linha onde não exista nenhum campo a preenchendo, e faça uma soma dos campos desejados, da seguinte forma:

Criando o campo calculado

Perceba que na tabela “soma”, foi criado o campo virtual que é a soma dos campos “som_valor_1” com “som_valor2”, e lhe foi atribuído o Alias “Soma”.

No formulário, utilize um componente Caixa de Texto, e na propriedade “Campo” dele preencha com o seu campo virtual:

Associando o Campo Calculado ao Formulário

Após isto, basta visualizar o resultado no Webrun (Imagem abaixo). Observe que, da mesma forma que foi feita uma soma, poderia ter sido feita uma concatenação, subconsulta, enfim, qualquer valor que puder ser obtido através de um comando sql.

Resultado:

Resultado no Webrun com o componente vinculado a um campo calculado

Dúvidas!? Visite o nosso forum!

Atualmente, apenas os leitores digitais da NitGen são homologados. Mais especificamente, a linha Hamster, que contam com os leitores Hamster I e Hamster II.

Hamster I

Se você ja possui, instale os drivers do dispositivo e suas devidas configurações (Caso necessário). Os drivers podem ser obtidos direto do site do fabricante em: http://www.nitgen.com.br/Downloads/Downloads_Driver.aspx

Hamster II

Após a instalação, o dispositivo está pronto para ser utilizado, faltando apenas o Servidor de Digitais da Softwell.
Este “Servidor de Digitais” nada mais é do que um serviço responsável pelo armazenamento das digitais em um pequeno banco de dados embarcado. O instalador do servidor de digitais pode ser encontrado na nossa página de downloads.
Após o download do Servidor de Digitais, basta seguir os passos Next, Next, Next do Instalador e o serviço será instalado e iniciado automáticamente, sem a necessidade de configuração alguma.
Como nenhum usuário possui uma digital devidamente cadastrada, deve-se primeiramente, acessar o Maker com algum usuário de administrador e então cadastrar as digitais para os devidos usuários no controle de acessos. (Imagem Abaixo)

Cadastrando impressão digital para os usuários

Se for apresenta a mensagem de erro: “Não foi possível iniciar o dispositivo de captura de digitais.”, possívelmente o driver não foi corretamente instalado ou não foi detectado ou a máquina precisa ser reiniciada. (Imagem abaixo).

Dispositivo não encontrado

Após cadastradas as digitais, basta utilizar o ícone ao lado da caixa de texto “Usuário” da tela de Login do Maker ou do Webrun para se autenticar por meio do leitor de digital sem a necessidade de digitação. (Imagem abaixo)

Botão para login utilizando o leitor biométrico

No caso do Webrun, o meio de login é da mesma forma que pelo Maker. Inclusive as digitais podem ser cadastradas também pelo browser, entretanto, um ActiveX / Applet deverá ser previamente instalado. Este aplicativo já está embarcado no Webrun dentro da pasta APPS:

• SDigitalCapture.jar

• DigitalCaptureNativeWin.jar

• DigitalCaptureWithoutChecksum.jar

Alguma dúvida?! Utilize o nosso fórum!

Se o servidor de aplicações estiver na porta 80, fica então apenas o endereço IP para acessar o sistema. http://127.0.0.1/ visto que a porta 80 é o padrão utilizado pelos navegadores. É desta forma que são utilizados os sistemas no estilo: http://sistema.empresa.com.br

Dúvidas!? Utilize o nosso fórum!

1. Webrun Enterprise Reports
2. Webrun Enterprise UTF-8

Vejamos suas características abaixo:

Webrun Enterprise Reports

O Webrun Reports nada mais é do que o Webrun Enterprise com um conjunto de Applet’s/ActiveX do gerador de relatórios local.
O gerador de relatórios local tem como objetivo gerar os relatórios na maquina do cliente. Desta forma, os relatórios são processados pelo computador de quem está visualizando, evitando assim que o servidor seja o responsável pela geração de todos os relatórios.
Outra vantagem do gerador de relatório local é a possibilidade de imprimir “Na Tela” que é uma cópia fiel ao que é feito no Report Builder (Maker). Nem sempre o que fazemos no Maker é como fica ao fim quando imprimimos em PDF ou HTML por exemplo.
Como nem tudo são flores, existe a questão: O Applet/ActiveX “custa” em torno de 25-35mb de tamanho. Ou seja, o cliente deverá na primeira vez que for instalar, efetuar o download para sua maquina, o que leva tempo e consome banda (tanto do servidor quanto do cliente).
Entretanto, caso o sistema esteja numa rede local, talvez seja uma boa alternativa para eliminar um possível gargalo do servior.

O gerador local deve ser usado com cautela e por pessoas com uma boa bagagem de desenvolvimento com o Maker. A melhor forma de eliminar gargalo do servidor com geração de relatórios, é definir um outro servidor apenas para geração de relatórios através da ferramenta de Servidor de Relatórios da Softwell. Seja uma máquina física ou uma máquina virtual. O gerador local deve ser utilizado como último recurso.

Webrun Enterprise UTF-8

O Webrun Enterprise UTF-8 usa a codificação UTF-8. Com ela, é possível representar qualquer caracter universal padrão do Unicode, sendo também compatível com o ASCII. A tendencia dos aplicativos, softwares, banco de dados é a utilização deste padrão, visto que as informações serão retrocompatíveis seja aqui ou no japão.

Para mais informações sobre UTF-8 procure no Wiki ou Google !

O Webrun Enterprise padrão utiliza a codificação ISO-8859 que não dá suporte a caracteres  japoneses por exemplo.