Ensemble melhor software de integração do mercado? Não exatamente...

Outro dia estava pesquisando algo no Big G (não lembro exatamente o quê), e me deparo com essa notícia: Pesquisa reconhece Ensemble como o melhor software de integração do mercado. Fiquei atônito! Não que o Ensemble seja de todo ruim, mas o fato é que ele está muuuuuito longe do que eu gostaria (OK, ele tem partes realmente horríveis).

Segui o link, e lendo a página, descubro que como muitas chamadas de imprensa, essa aí tb é no mínimo incompleta. Vamos aos fatos: Realmente, uma pesquisa de mercado apontou isso. Entretanto, faltou mencionar que esse 'mercado' é bem restrito, mais especificamente o mercado de empresas de TI ligadas a saúde (Healthcare IT), nos States. Nada de mal nisso, mas a chamada ficou meio apelativa, já que a expressão 'do mercado' remete a uma idéia muito mais ampla.

A empresa que fez a pesquisa é a KLAS, empresa "especializada em monitoramento e relatórios de performance de vendedores e empresas de serviços profissionais de TI voltadas a área de saúde" (tradução livre que consta no relatório). A pesquisa propriamente dita não está disponível completa (pelo menos não gratuitamente no site), mas um pequeno "trailer" dela vc pode baixar aqui.

O resultado dessa pesquisa nem me surpreendeu muito (depois de eu ler a página). O Caché (e por tabela, o Ensemble, que é construído sobre este) é muito forte na área médica (TI em hospitais, etc) nos EUA, graças a herança do MUMPS. Apesar da Intersystems não gostar muito, o Caché é uma implementação do MUMPS, algo que por questões de marketing eu acho (e não sei porquê), eles não gostam de alardear por aí.

Na minha opinião, se fosse realmente uma pesquisa no mercado geral, o Ensemble não se sairia muito bem. Não tenho dados que confirmem isso, então se algum leitor que porventura tenha caído aqui souber de dados confiáveis, me avise! (por favor, sem aqueles 'white papers' da própria empresa, que o pessoal de marketing deve elaborar).

Paralisação na Celesc - Tempo

Depois da ameaça (e efetiva paralisação hoje de manhã), a diretoria e o presidente Pinho Moreira (da Celesc)se sentaram para negociar. Por isso, a paralisação terminou. Vamos ver se não acontece mais nenhum perrengue, que obrigue a chegar a esse ponto (ou pontos mais fundos ainda).

Paralisação na Celesc - Prólogo

Como já disse, trabalho na Celesc.

Bem, amanhã (dia 21/09) talvez haja uma paralisação, em decorrência da diretoria ficar enrolando (e pior, ficar enrolando de uma maneira que diz: "vamos te enrolar pq vcs são trouxas"), alguns assuntos pro acordo coletivo de trabalho.

Não sei se vou aderir, afinal, não pretendo continuar por muito tempo na empresa, e não quero ficar tendo dor de cabeça por causa de outras pessoas, muitas delas, mesmo tendo interesse no assunto, vão ficar só esperando pelos outros. (Isso sim é ser brasileiro: eu sou brasileiro e não desisto nunca. Não desisto de esperar alguém fazer por mim...)

Se ainda não notou, já perdi as esperanças nessa humanidade...

Web Services no Caché/Ensemble - A Saga - parte 3

Finalizando a trilogia...

Como havia dito no fim do post parte 2, escrevendo o SOAP-Body na mão, eu consegui que fosse enviada a mensagem de requisição corretamente para o Web Service. Entretanto, por algum motivo que desconhecia, a mensagem de resposta não estava chegando corretamente. Primeiro pensei que não havia funcionado, mas depois analisando o tráfego da máquina, olhando a stream TCP, vi que o serviço estava retornando corretamente. O problema é que o Caché/Ensemble não entendia a resposta.

Testei com as classes cliente geradas automaticamente, e mesmo eu não mudando uma vírgula, o erro continuava. Conclusão: de nada adiantara toda a minha ginástica até agora. Analisando o código fonte, e pelas poucas pistas que o erro retornava, cheguei a conclusão de que o Caché não estava conseguindo instanciar uma classe com base na mensagem de resposta do Web Service:


(exemplo de uma resposta a uma requisição bem sucedida)

A esta altura, já cansado de tanto fuçar tanto a documentação quanto o código fonte das classes do pacote %SOAP do Caché, parti para o baixo nível: já que o pacote %SOAP não conseguia entender o Web Service, então desci na pilha de protocolos pra implementar de uma maneira que desse certo. O Caché puro não tem classes para lidar direto com o HTTP (pelo menos eu não achei), mas o Ensemble tem um "Adapter" HTTP. Lá vou fazer testes com ele, e descubro que não consigo usar no Web Service específico, porque esse Adapter não me deixa setar no cabeçalho um campo, e o serviço exige que contenha no cabeçalho da requisição HTTP o campo SOAPAction.

(Um parêntese: Adapters na linguagem do Ensemble são pedaços de softwares que têm a função de conectar o Ensemble a outros sistemas/tecnologias. A documentação desses Adapters deixa muuuito a desejar, pra ter uma idéia, na página que lista os Adapters nem está listada o Adapter HTTP, e muitos dos Adapters ali listados não consta do que eu tenho aqui disponível. Estranho, muito estranho)

Não conseguindo usar o HTTP, resolvi descer mais um nível na pilha, e usar direto o TCP. O Adapter TCP do Ensemble nada mais é do que um "wrapper" para os Sockets do Caché, um assunto que eu já dei um pitáculo neste dois posts anteriores aqui e aqui.


(pilha de protocolos... quase que chego no IP =P )

O bom de usar TCP é que eu tenho o controle de tudo, dos cabeçalhos do HTTP, do conteúdo da mensagem XML SOAP, etc. O ruim é que você pra usar isso, além de entender boa parte de toda essa parafernália, tem que fazer tudo no braço. Mas como as ferramentas prontas do Caché/Ensemble estavam só me dando erro, não tive muita escolha. XD

Olhem como ficou (mais ou menos, aqui tá simplificado):



E assim, apesar de ficar com um código horrível, usando mais anti-patterns possível, finalmente funcionou. E com tudo isso chamam o Ensemble de "Integrador"... Imagina se não fosse...

Web Services no Caché/Ensemble - A Saga - parte 2

Continuando a saga...

Eu havia me baseado na versão anterior do Web Service/Wsdl que me foi passado, pra implementar todas as estruturas internas no Ensemble (a saber, o BPEL e as "Business Operations", na linguagem deste).

Bem, na versão anterior, o wizard gerava todas as estruturas como classes, ou seja, se eu tivesse que atualizar uma estrutura "Pessoa", eu teria uma classe "Pessoa" com as propriedades "Nome", "Idade", etc... e o método receberia uma instância desta classe. Entretanto, agora o wizard gerou o método recebendo cada propriedade da estrutura como um parâmetro, ou seja, antes eu tinha:


atualizaPessoa(p as Pessoa)


E agora ele me gerou:


atualizaPessoa(nome as %String, idade as %Integer, ...)


E é CLARO que isso quebrou tudo o que eu havia feito. Para não ter que retrabalhar todas as outras classe, resolvi que seria melhor alterar na mão as classes que o wizard havia gerado, para se adaptarem aos objetos com que eu já trabalhava.

Então lá fui eu alterar a classe Web Client gerada:


(antes)


(depois)

Pensei que só isso já bastaria para funcionar. Compilei e mandei rodar. Não funcionou... Resumindo a luta, descobri que desse modo ele não estava escrevendo o Body do envelope SOAP conforme o Web Service esperava, contendo os namespaces corretamente declarados.

Procurando uma solução, me deparei com a propriedade "WriteSOAPBodyMethod" da classe %SOAP.WebBase, que é superclasse de %SOAP.WebClient. Essa propriedade permite definir um método que escreva de maneira personalizada o body de uma mensagem SOAP.

Usando essa propriedade, temos:


(escrevendo um elemento SOAP-Body personalizado)

Com isso, finalmente consegui preservar todo o código que eu havia feito anteriormente, e ainda acionava corretamente o Web Service. Entretanto, a saga não acaba aqui...

Continua...

Web Services no Caché/Ensemble - A Saga - parte 1

Há um tempo atrás postei um pequeno elogio ao Caché/Ensemble no que concerne a suporte a Xml. Seguindo o pensamento, poderíamos crer que o suporte a SOAP e Web Services seria igualmente bom. Infelizmente, acabei encontrando problemas por aí. Neste post estou começando uma série, que deve ilustrar toda uma saga XD.

Inicialmente, eu tinha um Wsdl descrevendo alguns serviços de um software que a Celesc comprou, e que precisaríamos usar para integrar com os nossos sistemas (a saga para conseguir esse Web Service tb é longa, mas muito chata, não devo postá-la aqui).

Bem, já tendo realizado alguns testes criando clientes para outros Web Services, pensei: "moleza". Ledo engano. O Wizard que gera um cliente SOAP de cara me jogou um erro. Infelizmente, como pode-se ver no print screen abaixo, o Caché/Ensemble não é muito informativo, então fiquei na dúvida: será que me enviaram um Wsdl bixado, ou o Caché não entende certas coisas? (Neste ponto, ambas as hipóteses eram igualmente prováveis).


(Tela com o erro do wizard)

Resolvi testar o Web Service utilizando o soapUI, um programa feito em Java, muito bom, que permite vc testar Web Services. Eu falei dele no post anterior.

Usando o soapUI, eu consegui não só montar o esqueleto correto das mensagens SOAP, como também testar o serviço. Isso me levou a conclusão de que havia alguma coisa errada com o wizard do Caché. Mas como curioso que eu sou, fui procurar o que nesse Wsdl específico estava causando erro. Depois de perdido meio dia, comparando Wsdls, e fuçando nas especificações, finalmente encontrei o problema: a mensagem de requisição estava com dois elementos, quando o normal é ter apenas um:


(pedaço do Wsdl que estava me causando problema)

Comentando a tag do segundo elemento da mensagem, o wizard funcionou. Um alívio que durou pouco...

Numa versão antiga deste Web Service (que haviam me passado anteriormente), o wizard havia funcionado corretamente, e eu havia baseado a implementação toda nele. Claro que agora haviam algumas mudanças, mas achei que não era muitas. Eu estava totalmente errado...

Continua...

SoapUI

Hoje vou falar sobre um programa muito útil que eu uso aqui, especialmente quando se trata de testar Web Services SOAP. O programa se chama soapUI, e é open-source, mas com uma opção paga com suporte. A instalação desse programa é simples, e está bem documentada no site.

Depois de instalado, primeiramente criamos um projeto, (File -> New WSDL Project). Este projeto pode conter quantas referências a web services você quiser, é mais uma maneira de se organizar logicamente do que uma imposição.

Suponhamos que eu tenha criado um projeto chamado 'zzz'. Para adicionar um Wsdl, basta clicar com o botão direito em cima do projeto, e ir na opção de adicionar um Wsdl de uma Url ou de um arquivo.



Responda sim a questão de criar requisições padrão para todas as operações e pronto. Basta você ir abrindo na árvore a esquerda, e vai ver as operações listadas, bem como uma requisição padrão para cada uma delas. Na figura, vemos apenas uma operação, com uma requisição (mas você pode criar várias mensagens de requisição, e deixar todas ali registradas, facilitando os seus testes):



Agora, basta você preencher as tags com os valores que quiser testar, e clicar no botão de submeter requisição (o botão verde), e ver na no quadro a direita, o Xml com o resultado:



Agora é só instalar aí na sua máquina e testar um pouco.