Um ex-aluno mandou um e-mail com uma pergunta simples, fácil até:


Olá professor como vai?
Fui seu aluno da última turma da 4linux de Pentaho e estou interessado em
usar o PDI como webservice e também em usá-lo para fazer stream de arquivos.
Você tem alguma referência sobre isso?


Uau, eu ministro esse curso há 7 anos e sempre aprendo coisas novas com meus alunos! PDI para stream? Quem pensaria nisso?

E porque ele pensou? Bom, eu respondi:


Vou bem, obrigado, e você? Tudo em riba? :-)

O PDI, especialmente combinado com um ESB ou mesmo com o BA Server, pode se tornar um provedor de webservices. Existe literatura sobre isso aqui e aqui.

Agora, sobre streaming é mais complicado. Já vi um exemplo de ler uma stream contínua do Twitter, mas nunca ouvi falar de servir streaming com o PDI. Procurei um pouco, mas não vi nada…


Só que não é assim que funciona. Veja, ninguém chega a um médico e pergunta “doutor, o ácido acetilsalicílico pode ser usado contra angina?”

Meu complemento:

Qual é, exatamente, seu caso de uso, sua necessidade?

E veio a resposta dele:


A questão do stream seria para transmitir arquivos entre servidores. Pensei em um webservice em C# que seria consumido pelo PDI, que enviaria arquivos através dessa sessão! O que acha? Ou usar um daqueles componentes de post para tentar enviá-los! Não sei bem ainda como pensar.


WTF?! Se você está coçando a cabeça, imagine eu.

O que eu consegui entender dali foi que existe um problema e ele imaginou que passar um arquivo por streaming resolveria esse problema. Note que já fomos do “dá para fazer X com Y?” para “preciso fazer Z, mas não sei bem como”.

Minha resposta:


Veja, transferir arquivos é o que você quer fazer. A questão é: que problema você resolve ao fazer isso? Qual é a “dor” que te motivou a buscar esse “remédio”? ;-)

É que, devido às normas de segurança, eu não posso usar métodos normais como compartilhamento entre máquinas ou sftp. Esses arquivos serão transmitidos pra outro servidor e redirecionados por email! Voce tem alguma outra sugestão? Eu pensei em stream porque lembrei daqueles servidores do Kazzar de transferência de música! A ideia era transmitir via stream e da memória mesmo, do outro servidor, passar por email.

É muita viagem? Heheheh


Sim, meu caro aluno, bastante! :-D Mas eu admito que foi muito criativo.

Notaram como agora estamos mais perto do problema, mas ainda não chegamos lá?

Pois foi o que eu disse:


Estamos chegando lá!

Pelo que você contou, o problema que você tem em mãos é resolvido com a transferência de arquivos, que não dá para ser feito por métodos mais ordinários, simples. Que problema é esse? Que necessidade é essa, que vai ser resolvida pela transferência de arquivos?

Transferir os arquivos, em si, é só a operacionalização da solução, não a solução do problema. O problema não é “como transferir arquivos”, mas sim o que requer que arquivos sejam transferidos.

Confuso? Vai melhorar, apenas pense um pouco mais. ;-)


Eu estou editando nossa correspondência para ficar mais clara e sucinta, mas confesso que eu mesmo não tenho bem certeza do que eu queria dizer naquele final… Enfim… ;-/

O fato é que surtiu efeito:


A necessidade é a seguinte professor!

Estou montando o BI aqui na empresa e temos muitos requisitos de segurança devido à norma PCI1.

Preciso prover relatórios por e-mail, o que é muito tranquilo de se fazer com Jobs e Transformations do PDI. O problema é que os arquivos serão gerados em uma máquina “interna”, que tem acesso ao banco de dados, mas essa máquina não pode falar com o servidor de e-mail, que está em um servidor “externo”, com acesso à Intranet.

A solução é enviar os arquivos de relatórios renderizados para um servidor intermediário, que daí os enviará por e-mail. Seria fácil se pudesse usar SFTP (que inclusive é um componente PDI), mas ainda não consegui a liberação para isso.

Por isso a ideia do stream: eu controlaria a transmissão do webservice a partir do “lado de fora”, onde montaria o e-mail com anexo para então enviar aos usuários.


U-la-lá! Envio de relatórios por e-mail, prejudicado por causa do bloqueio da rede por conta de normas de segurança! ESSE é o problema.

Meu comentário:


Ah! Agora sim! :-) Esse é o problema.


Foi o que eu disse…

No fundo o caso dele é uma situação complicada mais por conta da norma PCI1 que dos dados ou da tarefa em si. Na verdade, e se você ler a norma PCI vai entender isso, provavelmente o PDI vai poder fazer pouco por ele. É uma questão mais de administração e aderência a regras que ferramentas em si.

Por Quê Até Sangrar a Língua

O que eu queria trazer para divir com vocês era um caso real da dinâmica que rola em todo processo de levantamento de requisitos em BI. O mesmo ocorre em outros cenários, mas em BI isso é crítico: o cliente chega pedindo a receita do remédio para ele ir até a farmácia, comprá-lo e tomar sozinho. O cliente não está se reunindo com o analista de requisitos com quem vai ao médico e coloca uma situação, descrevendo os detalhes e perguntando o que fazer.

Não!

O clientes vão para sala de reunião dizer o que eles querem, e em 90% dos casos assumem que já bolaram a melhor solução, e que cabe ao projeto apenas implementá-la. Poucos carregam humildade o bastante para questionar a própria opinião ou, melhor ainda, oferecer o problema e pedir orientação.

Esse pequeno exercício de vai-e-vem, de abrir caminho no cipoal de achismos e “viagens” até pisar no cerne da questão, é o feijão-com-arroz do levantamento de requisitos em BI. Se você quer ajudar mais seu cliente, sofrer menos no desenvolvimento e passar menos frustrações, aprenda a perguntar porquê até não sobrar nada, até a língua sangrar!

Fábio, drama queen

:-D

Claro que a coisa precisa ser feita com um mínimo de tato e inteligência, ou vai virar uma patetada digna do Chaves.

Chamam isso de técnica dos “cinco porquês”, pois ao perguntar “por quê?” pelo menos cinco vezes chegamos à raiz de qualquer coisa. Este blog tem um texto mais detalhado.

Por Que Sim!

Fui vendedor de soluções de BI e depois de algum tempo percebi que 100% dos clientes pediam coisas que achavam que solucionariam o problema deles, mas que se eu vendesse o que eles pediam nunca daria certo.

Para entender o problema do cliente e descobrir o que resolve – ou seja, qual é a Solução de BI que ele precisa – é preciso um tempo de relacionamento, uma alma insatisfeita e muita paciência. Raramente você vai conseguir perguntar porquê? cinco vezes, de cara, na mesma reunião ou telefonema e sair com algo útil.

Por quê?…

Por que nem sempre o cliente tem paciência para isso.

?…

Por que ele sempre acha que já te respondeu e que você está sendo um chato.

?…

Por ele demora um tempo até perceber quão vazias são as respostas que ele está te dando – porque leva um tempo até a ficha cair.

?…

Por que raramente ele espera que o profissional de BI ajude com o problema dele.

?…

Por que quase todos clientes acham que vendedor de BI vende software, e não solução! ;-)

Até a próxima! ;-)

Por quê? Por que sim, pô! :-P


  1. PCI vem de Payment Card Industry Data Security Standard, ou padrão de segurança de dados da indústria de cartões de pagamento. 

2 comentários sobre “Santa Inquisição, Batman!

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s