sábado, 11 de fevereiro de 2017

REST e Data Provider

Fechando o ciclo dos webservices do tipo REST falta ainda discutir um pouco a respeito da obtenção de uma lista de registros de um certo sistema, ou kb, para que possamos ter informação em nosso sistema cliente.

Em nossos artigos anteriores tratamos a respeito da metodologia para se desenvolver o CRUD utilizando uma transação: REST & SOAP, porém este modelo nos permite atuar sobre determinado registro apenas. Discutimos inclusive a importância de se estabelecer um mecanismo de segurança, que optamos pelo GAM pela praticidade e recursos. O último tratou de uma ferramenta de apoio para que possamos testar o serviço remotamente, REST client. O que falta agora é discutir como acessar informações no servidor, trazendo uma coleção de registros ao mesmo tempo.

Data Provider

Este recurso está passando por algumas transformações importantes, e desde o seu nascimento, a então Artech já dava as premissas de uma revolução no modelo de programação com seu descreva ao invés de programar.

Creio que a grande maioria dos genexandos já se depararam com este objeto, talvez apenas não avançaram para torná-lo um serviço REST, então vamos dedicar alguns parágrafos para explicá-lo. O Wiki Genexus traz muito boas informações sobre este tema.

1) Começamos montando um SDT 

Criar um SDT com a estrutura da informação desejada é o primeiro passo para exportarmos informação. E aqui vale inclusive arrastar a transação para o editor de SDT para que este inclua todos os campos desta no objeto que estamos construindo.

Seguindo a linha dos exemplos anteriores, vamos gerar uma lista de empresas a partir da transação Empresa. O SDT é o mesmo do exemplo em REST & SOAP


2) Criando o Data Provider

O próximo passo é arrastar o SDT para dentro do objeto Data Provider. Se encontrar alguma dificuldade para remover as atribuições padrões do Genexus temos aqui a solução Krueger.



A aplicação de filtros where é permitida, e neste caso teremos que enviar parâmetros para o serviço REST. Não esqueça de incluir uma regra Parm com os parâmetros

parm(&EmpresaId);

3) Definindo as propriedades do DP

Além de definir o Output como Collection=true, também será necessário expor o objeto como Serviço REST.



4) Montando o cliente

Uma segunda KB ou qualquer programa externo poderá consultar nosso DP REST, e claro, mantendo o mesmo esquema de proteção do GAM, o cliente deverá realizar primeiramente o login, para em seguida poder executar o DP. Uma chamada ao serviço /oauth, passando-se os parâmetros corretos, realiza a proposta. Como informamos no artigo anterior o client_id é obtido no GamHome.

sub 'login'
 &httpclient.Host = 'localhost/'
 &httpclient.Port = 80
 &httpclient.BaseUrl = '/Kb.NetEnvironment/oauth/'
 &addstring ='client_id=068868de058b4798bd3b90f696fa37f8&grant_type=password&scope=FullControl&username=admin&password=admin123'
 &httpclient.AddHeader("Content-Type", "application/x-www-form-urlencoded")
 &httpclient.AddString(&addstring)
 &httpclient.Execute('POST','access_token')
 &AccessTokenSDT.FromJson(&httpclient.ToString())
 &websession.set('TOKEN', &AccessTokenSDT.access_token)
EndSub

Para completar o processo de login e necessário obter o token, e para isto programamos o AccessTokenSDT que formata a respota do GAM. Se estivermos tratando de Genexus para Genexus, os objetos podem ser exportados e importados na Kb cliente, porém, para outros ambientes teremos que definir, na linguagem específica a respectiva estrutura.


Armazenamos o Token na sessão para poder acessar seu valor quando necessário.


&websession.set('TOKEN', &AccessTokenSDT.access_token)

A chamada ao Data Provider deve ser realizado passando-se o token.

&httpclient.AddHeader('Authorization','OAuth ' + &websession.get('TOKEN'))

Em seguida uma variável querystring é programada para informar o parâmetro a ser passado. Observe que o parametro deve ser declarado neste modelo, "?EmpresaId=" + trim(&EmpresaId.ToString()). O Data Provider é incluído no querystringempresadp.

&querystring='empresadp' + "?EmpresaId=" + trim(&EmpresaId.ToString())

O código completo da chamada é apresentado a seguir.

Event Enter
do 'login'

&httpclient.Host = 'localhost/'
&httpclient.Port = 80
&httpclient.BaseUrl = '/Kb.NetEnvironment/rest/'
&httpclient.AddHeader('content-type','application/json')
&httpclient.AddHeader('Authorization','OAuth ' + &websession.get('TOKEN'))
&querystring='empresadp' + "?EmpresaId=" + trim(&EmpresaId.ToString())
&httpclient.Execute('GET', &querystring)
&resposta = &httpclient.ToString()
Endevent

Para transformar a resposta em uma variável SDT é possível desde que definido. Fizemos isto no primeiro passo, ao criar o EmpresaSDT. Será necessário é transferir o objeto da Kb onde se encontra o Data Provider para a Kb cliente.


Uma variável do tipo EmpresaSDT deve ser criada como Collection=true. E, em seguida, um FromJson resolverá a parada.

&EmpresaSDT.FromJson(&httpclient.ToString())

O resultado disso? temos os registros recuperados da tabela Empresa, filtrados pela variável &EmpresaSDT. Desta forma podemos 'consultar' esta tabela em memória, na máquina cliente.

Fechando a conta

Temos muitos recursos interessantes que poderemos utilizar para solucionar nossos problemas de programação. O uso de webservices é importante porque toda lógica de proteção dos dados se encontra sob o domínio da Kb que fornece o serviço. Diferentemente de um acesso direto à tabela, por meio de um DataView, os webservices permitem um maior controle sobre o acesso e autorizações sobre as operações que cada sistema cliente terá.

Talvez não sirva para todas as situações, mas com certeza, para cenários de multiplos sistemas que necessitam trocar informações é uma excelente aposta.

Maiores informações:
Acesso aos exemplos, formato XPZ:

REST Client

Quando trabalhamos com chamadas REST é importante utilizar uma ferramenta cliente para que possamos testar os parâmetros de conexão.  Se optarmos pelo Genexus para realizar estes testes teremos que passar por diversas compilações para termos certeza que o serviço responde adequadamente.

Recentemente fui apresentado pelo Mauricio, a uma extensão do Google muito interessante chamada postman, gratuita e muito interessante para realizarmos chamadas na Web, testar serviços, entender a comunicação entre o servidor e o cliente.


No chrome basta instalar a extensão, e em seguida a mesma poderá ser chamada pelo próprio Desktop do Windows.


Fica a dica ai!

sexta-feira, 10 de fevereiro de 2017

REST & SOAP

Temos ha algum tempo dois modelos de conexão a webservices implementados no Genexus a sua disposição para que inicie seus projetos: SOAP (Simple Object Access Protocol) e o REST (Representational State Transfer). O primeiro um protocolo de comunicação e o segundo um modelo de conexão entre sistemas. Esquisito? sim e muito, veja aqui as diferenças de implementação e uso.

Objetos Tipo Webservices

Primeiramente, Genexus permite que vários de seus objetos atuem como webservice, de forma que podemos implementar cenários bastante interessantes:
  • Transaction: permite fazer com que o CRUD (Create, Read, Update, and Delete) de uma Transação opere como webservice. Em outras palavras, podemos disponibilizar serviços que façam o Insert, Update e Delete de registros em tabelas a partir da porção Business Component da transação.
  • Procedures: poderíamos implementar regras de negócio mais especificas para realizar tanto a operação de manutenção das tabelas, como também para devolver informações que deveriam passar por algum tipo de processamento.
  • Data Provider: permite-nos criar um recurso que facilmente recupera informações das tabelas, podendo gerar 'views dinâmicas', que associados aos webservices podem alimentar sistemas externos famintos por informação.
Desta forma, a ferramenta suporta, digamos, com o padrão Genexus de fazer as coisas ficarem mais simples, uma ampla gama de possibilidades quando pensamos nos tais webservices.

REST & SOAP

Ja apresentamos alguns exemplos aqui no Genexando a respeito da aplicação e consumo de webservices SOAP, principalmente devido a sua simplicidade de construção e uso em Genexus. Pois para consumir basta utilizarmos uma ferramenta que aponta para o WSDL do serviço e que cria automaticamente um objeto externo que aponta para a execução da procedure remota, esta ferramenta é chamada WSDL IMPORT. Para construir, basta pegar uma procedure qualquer e marcá-la com as opções Main Program = true e Call Protocol = SOAP.

Os webservices do tipo SOAP são mais simples de utilizar porque, no Genexus, estão associados a um objeto externo. Podemos encarar a coisa mais ou menos assim, imagina que uma procedure está em uma Kb e foi pubicada como SOAP, em outra Kb, quando apontamos para este SOAP com o WSDL Import, o Genexus criará um objeto (External Object) com o mesmo nome desta procedure 'externa', permitindo que executemos esta procedure. Seria algo como, tornar uma procedure, que inicialmente encontra-se sob o escopo privado em uma Kb, como pública e acessível para outras Kbs ou mesmo sistemas externos, não Genexus.

Agora quando falamos de REST a coisa muda um pouquinho. Praticamente o que temos é estilo para chamar recursos na Web mediante a definição da operação na URI, mas deixemos as discussões quanto às diferenças para os filósofos da Internet, melhor focar na implementação do Genexus para ambos os recursos.

Genexus publica ambos os modelos para que possam ser acessados mediante chamadas HTTP ou HTTPS, SOAP vai se comunicar utlizando XML, e REST é mais flexível, permitindo que a transferência de informações ocorra tanto com XML, JSON, Texto, ou mesmo outro modelo qualquer.

Em ambos os cenários a questão da segurança é muito importante, porque se estamos transferindo algo valioso entre sistemas, pela Web, com certeza algum bisbilhoteiro vai tentar interceptar a comunicação. Desta forma se você não é adepto a certificados digitais SSL, esqueça este recurso, isto aqui não é para você. Bom, na verdade, as credenciais dos seus usuários neste momento também estão expostas, neste caso.

Programando REST

Para entender um pouco mais da programação webservice Genexus com SOAP, recomendo a leitura do artigo http://www.genexando.com/2009/07/web-services.html, em que já apresentamos um exemplo sobre este modelo.

Quanto ao REST necessitamos explorar um pouco deste tema aqui no Genexando, pois o modo de programação é bastante diferente.

1) Segurança é tudo!

Primeiramennte é necessário entender um pouco a respeito da segurança da chamada ao serviço, e no caso do Genexus o GAM sempre é uma boa opção para proteger tudo.

No GAM é necessário realizar um login na aplicação, controlado pelo protocolo OAuth implementado no recurso, e este cria um Token assim que se estabelece a conexão. Por meio deste Token será possível realizar as próximas conexões com o servidor sem que se tenha de reenviar o usuário e senha. Por isso a importância do protocolo SSL, pois a passagem dos parâmetros, principalmente neste momento deve estar completamente encriptada e protegida. GAM com http não vai adiantar nada!

Para procedermos é necessário fazer uso do tipo HttpClient do Genexus que permite configurar os parâmetros para a execução do processo, que deve acontecer pela chamada POST ao serviço /oauth/access_token. A seguir um exemplo de login no GAM.

Event 'login'
  &httpclient.Host = 'localhost/'
  &httpclient.Port = 80
  &httpclient.BaseUrl = '/Kb.NetEnvironment/oauth/'
  &addstring ='client_id=068868de058b4798bd3b90f696fa37f8&grant_type=password&scope=FullControl&username=admin&password=admin123'

  &httpclient.AddHeader("Content-Type", "application/x-www-form-urlencoded") 
  &httpclient.AddString(&addstring)
  &httpclient.Execute('POST','access_token')
 
  &json = &httpclient.ToString()
  &AccessTokenSDT.FromJson(&json)

  &websession.set('TOKEN', &AccessTokenSDT.access_token)
EndEvent

O valor de client_id informado deve ser obtido no GAM, na área Applications - Client Application Data.


O retorno da chamada é no formato JSON, desta forma é necessário converter o texto recebido em um SDT. No nosso exemplo, algo como:


Um exemplo de retorno da chamada deste serviço seria algo como:

{
 "access_token":"54f03097-e105-4bfd-9ff4-eba57KM6hSB39vFRlA7a4iAE",
 "scope":"FullControl",
 "refresh_token":"",
 "user_guid":"985ee5fe-8d5c-4008-8a0b-050beb6bddb0"
}

A estratégia do exemplo é armazenar o Token na websession, para em seguida obtê-lo quando necessário.


2) Inserindo registros

Considerando uma transação Empresa que foi definida como REST.


Poderemos realizar operação de inserção de registros por meio do serviço, que se encontrará disponibilizado na URL a seguir, observe que se deve incluir um /rest e o /Empresa é a transação, que não precisamos ascrescentar a extensão aspx (se for .Net)

localhost/Kb.NetEnvironment/rest/Empresa

A sequencia de ações para se chamar este serviço REST é a seguinte:
  1. Definir o caminho ao serviço
  2. Incluir no Header da mensagem o Token do GAM
  3. Incluir no corpo da mensagem o registro a  ser inserido
  4. Definir a chave primária do registro a ser inserido
  5. Executar o POST

A primeira ação é a operação de conexão ao servidor, que definimos em uma sub rotina chamada Host. Observe que é necessário passar o Token obtido no login anteriormente apresentado, incluíndo-o no cabeçalho da chamada.

Sub 'Host'
  &httpclient.Host = 'localhost/'
  &httpclient.Port = 80
  &httpclient.BaseUrl = '/ Kb.NetEnvironment/rest/'
  &httpclient.AddHeader('Authorization','OAuth ' + &websession.get('TOKEN'))
EndSub

Em seguida,  será necessário incluir o registro a ser inserido no corpo da mensagem, através do &httpclient.AddString(&EmpresaSDT.ToJson()). Desta forma, deveremos ter um objeto EmpresaSDT para definir a estrutura da informação.


Falaremos do gx_md5_hash logo abaixo.

Um detalhe importante na chamada é a passagem do Id do registro, no caso EmpresaId, que para o insert, deve ser zero. Ou seja, temos como enviar parâmetros para a regra Parm do objeto.

O Execute no método POST realiza a chamada ao serviço.

Event 'Insert'
  do 'Host'
  &httpclient.AddHeader('content-type','application/json')
  &httpclient.AddString(&EmpresaSDT.ToJson())
  &querystring='Empresa' + "/" + &EmpresaSDT.EmpresaId.ToString()
  &httpclient.Execute('POST', &querystring)
  &StatusCode=201
  do 'Message'
Endevent

Para tratar o resultado temos o código de retorno 201 sendo o StatusCode correto para a operaçao, ou seja, se acontecer o registro foi inserido corretamente.

Sub 'Message'
  if &httpclient.StatusCode=&StatusCode
    msg("Informação atualizada")
  else
    msg("Ocorreu um erro.." + &httpclient.ToString())
  endif
EndSub


2) Atualizando registros

A atualização é muito semelhante ao processo de inserção, com apenas um pequeno detalhe, será necessário obter primeiro o registro que se encontra na tabela. Isto é feito para que o Genexus realize o controle de concorrência no processo de atualização.

Sendo assim, a carga do registro deve ser feita por uma chamada GET ao serviço, a seguir um exemplo.

Event 'get'
  do 'Host'
  &httpclient.AddHeader('content-type','application/json')
  &querystring='Empresa' + "/" + &EmpresaSDT.EmpresaId.ToString()
  &httpclient.Execute('GET',&querystring)
  &EmpresaSDT.FromJson(&httpclient.ToString()) 
  &StatusCode=200
  do 'Message'
Endevent

O registro deve ser manipulado a partir de uma variável SDT, e em seguida sua atualização deve ser enviada ao servidor chamando-se um método PUT, conforme o modelo a seguir. Em todo processo será necessário informar a chave primária do registro.

Event 'update'
  if &EmpresaSDT.gx_md5_hash.IsEmpty()
    msg('Do a get first')
  else
    do 'Host'
    &json=&EmpresaSDT.ToJson()  
    &httpclient.AddHeader('content-type','application/json')
    &httpclient.AddString(&json) 
    &querystring='Empresa' + "/" + &EmpresaSDT.EmpresaId.ToString()
    &httpclient.Execute('PUT', &querystring)
    &StatusCode=200
    do 'Message'
 endif
EndEvent

O detalhe importante neste processo é a necessidade de se armazenar um código Hash gerado pelo Genexus para controlar a concorrência, obtido no GET e enviado para o servidor no PUT, em seguida. Este hash se altera a cada operação de consulta ao banco.


Este Hash é guardado no SDT na propriedade gx_md5_hash, toda comunicação que venha atualizar o mesmo deverá informar esse valor.

3) Apagando registros

Finalmente, para se apagar o registro precisaremos de uma simples chamada DELETE, conforme o exemplo apresentado a seguir.

Event 'delete'
 do 'Host'
 &querystring='Empresa' + "/" + &EmpresaSDT.EmpresaId.ToString()
 &httpclient.Execute('DELETE', &querystring)
 &StatusCode=200
 do 'Message'
Endevent

Resumindo

Podemos utilizar uma transação e implementar um mecanismo de operação remota dos registros publicando-a como REST.  O próprio Genexus utiliza esta estratégia para prover informações e funcionalidades para as aplicações SD.

O mecanismo torna o modelo de programação um pouco mais cheia de código, porém, oferece novos cenários de aplicação.

O que se deve levar em conta é a velha história do desempenho x controle, pois neste modelo teremos um forte controle sobre o compartilhamento da informação, por outro lado, teremos um novo cenário no qual não poderemos explorar muito o desempenho do acesso direto ao banco de dados. Para compensar, o modelo vai exigir um pouco mais de infra-estrutura para compensar a pequena ineficiência.

Particularmente, acho interessante.

Mais informação em:
Acesso aos exemplos, formato XPZ:



sábado, 12 de novembro de 2016

Global Events


Os habitantes de Funafuti acordaram muito preocupados nesta última semana. E isto se deve principalmente aos últimos acontecimentos, também pudera, não é sempre que o famoso Tuvalu-News noticiou algo tão estranho como a eleição americana. Simplesmente a bolsa de valores de Tuvalu teve uma queda expressiva!

Realmente estamos vivendo uma era de eventos globais, e a eleição nos Estados Unidos é um bom exemplo, pois como pode algo específico do povo americano afetar o funcionamento do mundo inteiro? Será que os americanos se deram conta da responsabilidade que possuem neste momento? Será que ao saírem de casa, no dia da eleição eles pensaram, muito bem vamos derrubar a bolsa de Tuvalu?

Por mais que gostem ou não do resultado, alguns países ficam mais 'afetados' com o problema dos outros. A própria imprensa brasileira está 'decepcionada' com o resultado, e são intermináveis programas, entrevistas, debates sobre este 'tão relevante' assunto para o Brasil, e claro que a conclusão de todos é sempre a tal: vamos ver como é que fica.  Também como explicar uma imprensa que torce ao invés de reportar.

De fato vivemos momentos globais.

Mas deixemos o Trump trabalhar e o pessoal de Tuvalu jogar o seu kilikiti em paz, e vamos ao que, de fato, interessa.


Global Events

Assim como o acontecimento americano, Genexus 15 também afetou a economia. Porém, não estamos falando de dinheiro, e sim da economia de se criar uma única WebPanel para todas as interfaces do sistema! A chamada Single Page Application.

Este tema ficou meio esquecido principalmente porque faltava exatamente o Global Events, e os resultados produzidos não eram, assim, tão legais.

Acontece que GeneXus 15 nos entregou um novo objeto em nossa Kb, o Global Events, que ao ser configurado nos permite que os nossos WebComponents possam 'conversar' com o WebPanel.


Lembrando que isso não era então possível, simplesmente porque o WebPanel tinha a mania de não escutar o que o WebComponent tentava lhe falar, era quase um monólogo onde o painel passava seus parâmetros para o componente, e esperava que este funcionasse, porém não se preocupava nem um pouco se este produzia alguma coisa que lhe pudesse interessar.

Esta situação de falta de comunicação ficou muito evidente com a GeneXus Ev3 porque a mudança do cenário dos eventos Smooth, já não aceitava mais o conceito de reconstruir a interface inteira com um Refresh total, coisa das 'antiquadas interfaces' da Ev2, Ev1, e dai pra baixo. Isto passou a ser quase um pecado, pois como você pode fazer algo com o avançado recurso de atualizar apenas um pedaço da interface (Smooth), se de vez em quando tem que ser forçado a atualizar tudo, parece que a coisa perde um pouco sua importância.

Uma Single Page Application de uma única via também parecia ter um limite de funcionamento, então, o pessoal, 'ouvindo a voz da comunidade' meteu a mão na massa e nos entregou o Global Events.

Nada como termos uma conversa franca, não é mesmo?

Para que serve isso?

Simples, serve para que você possa enviar para um WebPanel alguma ocorrência de um de seus componentes, e com isso permitir que o painel principal possa fazer alguma coisa.

Por exemplo, se você possui um WebPanel e precisa carregar um component, o comando Create é suficiente para enviar para este os parâmetros necessários para sua construção.


Desta forma um comando Component1.Object = Comp1.Create(&p1, &p2), vai passar para o objeto Comp1, que é um WebComponent, os parâmetros &p1 e &p2. E assim o objeto Comp1 será incluído na interface e apresentar seu conteúdo.

O problema é que o objeto Comp1 não possui uma maneira eficaz de enviar para o WebPanel o resultado de algum evento que possa ocorrer. Por exemplo, se este tiver um Grid, ao se selecionar uma linha, não teremos como enviá-la para a página principal. Pode-se dizer que utilizávamos algumas técnicas aleatórias profissionais para fazer isso.


Bem, não tínhamos, agora temos, pois com o Global Events, registramos um evento que ao acontecer disparará uma ação global no sistema, e poderemos interceptar esta ação em nosso WebPanel. Não fique nervoso, é simples.

É mais ou menos assim, registre um novo evento no Global Event, definindo os parâmetros que utilizará para realizar a comunicação.
Em seguida, para gerar o evento será necessário 'chamar' este evento, num formato muito parecido com a chamada a um objeto qualquer. Entre parenteses se deve informar o valor a ser transmitido,a como, por exemplo, GlobalEvents.MeuEvent(2). Esta ação é realizada no WebComponent.

Esta operação disparará um evento global, que poderá ser interceptado por um WebPanel. Para que isto ocorra será necessário criar um Event GlobalEvents.MeuEvento, neste WebPanel.



Em seguida,  uma vez que o evento tenha sido interceptado com Event MeuEvento, será possível tomar uma decisão, como por exemplo, se trocar o Comp1 para outra interface qualquer, criando o efeito da Single Page Application. Teríamos vários componentes a serem apresentados em apenas um WebPanel.

Um Exemplo

No Wiki HowTo: Using Global Events in Web Objects temos um excelente exemplo apresentado pela Sabrina Juarez, inclusive com o XPZ que pode ser baixado e colocado em sua Kb. Neste a Sabrina apresenta uma lista de autores e seus livros, e quando se escolhe algum no Grid à esquerda, os componentes que apresentam os detalhes são disparados.


É um recurso muito interessante e simples de entender.  No exemplo, apenas um pequeno detalhe, caso ocorra um erro na carga das imagens, no DataProvider LiteraryWork_DataProvider, mais especificamente nas linhas que carregam as capas dos livros, devem ser comentadas. // LiteraryWorkImage = Link("bodas_de_sangre")

Conclusão

O Global Event do GeneXus se mostra um recurso excepcionalmente interessante e com certeza vai se adequar muito bem aos projetos mais ambiciosos de interface.

Infelizmente, quanto à eleição americana, parece que o mundo também tem sido influenciado globalmente pela falta de candidatos adequados para que a população possa escolher alguém de fato representativo. Os políticos de aqui e de acolá estão adotando aquela velha estratégia suja de fechar uma lista de pessoas que infelizmente não poderiam ser escolhidas, na qual o melhor seria não escolher ninguém, digamos, que tal o menos pior?

Se a tendência perdurar até 2018, pode ser que tenhamos um Trump aqui também.