SAP Blue Ruby

The Ruby Way to communicate with SAP Applications

Blue Ruby é um projeto ainda em desenvolvimento pela SAP Research que tem como finalidade criar um ambiente “enterprise-ready” para dar suporte à linguagem Ruby, executando nativamente códigos Ruby dentro da ABAP Virtual Machine. Nas palavras de Juergen Schmerder, o projeto reúne “o melhor de ambos os mundos”. Isto é, o projeto visa integrar as características marcantes em Ruby, como: programação puramente orientada a objetos, portabilidade, produtividade, sintaxe limpa, tipagem dinâmica e escalabilidade; com a robustez do SAP Web AS.

Para entender um pouco melhor sobre a complexidade, integração, status atual do projeto e objetivos, separei o assunto em tópico, como podemos verificar a seguir:

Um pouco de história: A Linguagem Ruby

Como já é de conhecimento da maioria dos profissionais da área de desenvolvimento web, a linguagem Ruby foi projetada e desenvolvida pelo japonês Yukihiro "Matz" Matsumoto, em 1995.

Ao projetar a linguagem, Matz reuniu os principais pontos de outras linguagens, como: as expressões regulares de Lisp, o lambda calculus de Eiffel, a orientação a objetos de Smalltalk, a tipagem dinâmica de Perl; e outras características provenientes de Python, Ada e CLU.

Algumas da principais característica da linguagem a orientação a objetos pura, sintaxe limpa, mixins, iterators, closures, exception handling, automatic garbage collection, metra-programação, introspecção, reflexão, continuations, generators e suporte a implementação de DSLs (Domain Specific Languages).

Nos paradigmas de programação Ruby é caracterizada como linguagem funcional, imperativa, reflexiva e orientada a objetos.

A linguagem Ruby foi escrita em C. E, de acordo com seu criador, Ruby foi criada para ser uma linguagem de scripting mais poderosa que Perl e mais orientada a objeto que Python. A primeira versão da linguagem tornou-se de conhecimento público no final de 1995, em sua versão 0.95.

Ainda de acordo com Matsumoto, Ruby foi criada visando não somente a produtividade mais a diversão, isto é, a fluência e comunicação programador/máquina.

“Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.”

( Matsumoto ).

Um exemplo do clássico “Hello World” escrito em Ruby:

puts “Hello World”

SAP Web Application Server

O SAP Web Application Server faz parte da plataforma SAP NetWeaver. É um middleware utilizado para o desenvolvimento e execução de aplicações web server-side e client-side. Estas aplicações web pode conter desde código HTML estáticos até códigos mais complexos, como códigos dinâmicos (XHTML e JavaScript).

Outro exemplo de servidores de aplicações web é o WebSphere AS, da IBM; WebLogic, da BEA Systems; Glasshfish, Apache, JBoss, etc.

Com o SAP WAS é possível a implementação e execução de sistemas baseados em ABAP e JAVA. Os sistemas baseados em ABAP podem ser implementados por BSP (Business Server Pages – explicado no post anterior).
Já os sistemas em Java podem ser implementados através de Servlets, JSP, JSPDynPages, etc.

Resumidamente, o SAP Web AS funciona da seguinte forma:

O usuário, através do web browser, envia uma solicitação ao servidor: Efetuar uma busca por fornecedor, por exemplo:

• A solicitação é recebida pelo componente ICM (Internet Communication Manager) server, já dentro do servidor de aplicação.
• Posteriormente, dependendo do tipo de solicitação (Abap ou Java) o ICM envia para o dispatcher correspondente.
• Dentro da engine dos sistemas (ABAP ou Java), o mesmo executa os work processes necessários, realizando a consulta no banco de dados, se for o caso, envia informações ao servidor de mensagens.
• Ao final do processamento, a engine devolve a resposta ao usuário (dados de exibição).

SAP Blue Ruby Virtual Machine

O projeto Blue Ruby está sendo implementado como uma extensão da máquina virtual ABAP. O runtime e as bibliotecas da máquina virtual Blue Ruby estão sendo, também, implementadas em ABAP para que haja compatibilidade dos aplicativos implementados em Ruby com o ambiente ABAP.

Blue Ruby é uma evolução organizada, onde é executada dentro do SAP não necessitando a utilização de qualquer tipo de servidor adicional e possibilita a implementação de DSLs (Domain Specific Languages).

Segundo os autores do projeto, o objetivo é dar ao desenvolvedor uma flexibilidade maior na construção de aplicações e extensões. As aplicações em Ruby podem se comunicar com os programas em ABAP e vice-versa, isto é, programas em Ruby podem compartilhar informações com códigos ABAP realizando chamadas nativas aos módulos de funções, BAPIs, Serviços, RFCs, etc. O mesmo deve acontecer no sentido oposto, onde programas ABAP podem ser capazes de realizar chamadas às classes e métodos Ruby. Outro desafio para a equipe desenvolvimento é estabelecer a comunicação entre as linguagens com o mínimo de overhead.

Ainda segundo eles, as aplicações de missão crítica dentro do SAP continuarão a ser implementadas em Java e ABAP, deixando o Blue Ruby como um recurso complementar.

Para executar um código Ruby dentro do ambiente SAP, o código primeiramente é compilado para uma linguagem intermediária chamada BRIL (Blue Ruby Intermediate Language). Esta conversão é realizada toda vez em que uma aplicação Ruby é gravada dentro da Blue Ruby VM; isto acontece para minimizar o impacto na performance em tempo de execução.

Para facilitar o entendimento deste conceito (BRIL), pode-se fazer uma comparação com a linguagem Java, onde o código Java é convertido em bytecode dentro da JVM para ser executado.

Comparação entre os códigos em Ruby e Bril:

Após a gravação do código Ruby na Blue Ruby VM, o sistema converte o mesmo para código BRIL e o armazena no Blue Ruby File System.

Embora a proposta do projeto seja a integração 2 dois ambientes de programação. Um filtro e/ou permissão de acesso está sendo desenvolvido neste sentido.

Com o objetivo de dar flexibilidade ao desenvolvedor e ao mesmo tempo manter a consistência e integridade dos dados e do ambientes, a equipe de desenvolvedores estabelecer7aacute; algumas &lrquo;regras” para a comunicação Ruby -> ABAP. A comunicação entre Ruby e ABAP é feita por um túnel bem definido chamado de pontes (“bridges”). Através desta ponte, programas em Ruby poderão fazer uso de dados gerenciados por aplicações em ABAP, mas não será permitida a atualização de dados no banco através da linguagem, diretamente; evitando a possibilidade de códigos Ruby maliciosos contornarem as autenticações em ABAP do sistema.

As chamadas de interfaces, classes, métodos e atributos atrav&eacut;s de um programa ABAP é possível através de BAdIs Bridges.

Exemplo de programa Ruby chamando a Bapi de consulta ao endereço do parceiro de negócio “BAPI_BUPA_ADDRESS_GETDETAIL”:


Require ‘rfc’
Bapi = rfc.new ‘BAPI_BUPA_ADDRESS_GETDETAIL’
Bapi.businesspartner = ‘0000000001’
Bapi.call!
puts bapi.addressdata.c_o_name
puts bapi.addressdata.city
puts bapi.addressdata.district
puts bapi.addressdata.street
puts bapi.addressdata.str_abbr
puts bapi.addressdata.house_no
. . .


Status do projeto

De acordo com o site do projeto, pode-se perceber que o status do projeto, com a data de atualização mais recente em 20/julho/2009:

• 665 de 743 das especificações da linguagem (89.5%) – Object, Class, Module, Block, Proc, …
• 3031 de 4152 da especificação da biblioteca (73.0%) – String, Fixnum, Array, Hash, Regexp, …
• 3696 de 4895 da especificação total (75.5%).

Vamos aguardar e testar este ambiente conforme o projeto vai evoluindo.
Vale lembrar que, por enquanto, o framework Rails e vários outros ficaram de fora.
SAP Blue Ruby, além de ser um projeto SAP, não é considerado SAP Product.
Para leitura complementar e estudos, segue os links de apresentações e artigos aqui, aqui, aqui, aqui e aqui.

Até a próxima…

[Post-Técnico]: SAP CRM – Relacionando a data de cabeçalho a partir da SLA do item.

Atualizando a data de vencimento de um Service Ticket a partir da data do item.

Após alguns meses ausente devido ao trabalho, volto ao meu blog tratando de um assunto não muito comum no mercado SAP: IC WebClient.

Confesso que não tinha conhecimento sobre este framework até, claro, aparecer uma demanda para manutenção neste sistema. A principio, uma percepção da complexidade, posteriormente, a certeza!

Bom, para iniciar, algumas coisas têm que estar claras para um melhor entendimento. SAP CRM 5.0, ICWC e BSP são os assuntos que trataremos aqui.

SAP CRM
CRM – Customer Relationship Management – como o próprio nome sugere, CRM é um sistema de gestão de relacionamento com o cliente. As áreas de atuação deste sistema é voltado para maximizar a experiência e produtividade do cliente, atendendo as áreas de service center, call center, vendas, marketing, canais web, canais de parceiros, suppliers, etc.

ICWC
Interaction Center WebClient – é uma aplicação client-side executada via web browser. Os dados transmitidos para o CRM WebClient são emitidos pelo SAP NetWeaver AS. O SAP NW Application Server possui dois ambientes: J2EE e ABAP; possui conexões para diversos protocolos, como: SOAP/XML, HTTP/HTTPS, SMTP, RFC, etc.

A camada de UI (user interface) é baseada em BSP e para o AS realizar a comunicação com o browser o mesmo possui um camada chamada ICM (Internet Communication Manager) que faz a interface (HTTP) entre o WebClient e o BSP runtime.
A aplicação WebClient é divida em três camadas: Presentation Layer, Business Layer e Business Engine.

Na camada de apresentação se concentram os códigos HTMLB e JavaScript.
A camada de negócio consiste de duas sub-camadas: BOL (Business Objet Layer) e GenIL (Generic Interaction Layer). Na sub-camada BOL estão concentradas os objetos de negócio, como: parceiro de negócio, ordens de serviço, ordens de venda, etc. GenIL é usada para a transferência de informações (ou dar sustentação) entre a BOL e as APIs da camada de business engine.
Na camada de Business Engine está concentrada toda a base de dados, isto é, o SAP CRM .

Tela da inbox do IC WebClient

BSP
Business Server Pages – a grosso modo é uma mistura de código ABAP Objects, HTMLB (HTML-Business, se preferirem) e JavaScript. Atualmente, BSP implementa o design pattern MVC (Model View Controller).

Assim como o JSP (Java ServerPages), PHP e ASP (Active ServerPages); o BSP é uma aplicação server-side utilizada para o desenvolvimento de aplicações para Web permitindo acesso ao conteúdo do servidor de aplicação.

O PROBLEMA
Para determinados perfis de usuário (como diretores, gerentes e presidente), sempre que a data de SLA do item de uma determinada ordem de serviço for alterada, a mesma deverá automaticamente ser refletida na data de SLA do cabeçalho e, consequentemente, o flag de sinalização da proximidade da data de vencimento deverá ser atualizado. Pois, atualmente, as datas de SLA do item estão sendo alteradas, mas a mesma não é refletida no cabeçalho (campo de vencimento).

A solução encontrada para este problema foi, primeiramente, criar uma view "Z" (qual ABAPer que nunca fez uma cópia do standard? Rs! Neste caso, isto é SAP recommendation), no meu caso, ZSrvTHead.

View ZSrvTHead

View de SLA do item.

Depois de criados, é necessário criar os atributos necessários para carregar dentro do mesmo contexto as datas de item e cabeçalho.
Lembrando que os campos no CRM são do tipo timestamp.

Com os atributos e setters e getters criados, é necessário instanciarmos os objetos do cotrollers e models, como: CuCoBT, Collection Wrapper e BOL Entity.
Isto será necessário para a implementação dos métodos que serão responsáveis por buscar os dados do item dentro do contexto (runtime).

Em runtime temos acesso ao conteúdo do cabeçalho do service ticket, então, para obtermos os dados do item será necessário a navegação por entre os elementos BOL. Isto é, os dados do item estão dentro do componente BTDate e, como temos acesso ao cabeçalho (BTAdminH), criar-se a navegação da seguinte forma:

Usaremos o controler para executar o CuCoBT para termos acesso ao item (BTAdminI).

CuCoBT = ClassController->get_custom_controller( controller_id = 'CuCoBT' ).

Posteriormente, chegaremos até o BTDate:

BTAdminI -> (rel) BTItemDatesSet -> BTDatesSet -> (rel) BTDatesAll -> BTDate

Com o objeto BTDate localizado, basta buscar o campo timestamp do item.

Após concluir os métodos para buscar a data do item, será necessário programarmos os métodos de atualização da data/hora do cabeçalho.

Para isso, usando a mesma linha de raciocínio para navegarmos até o BTDate do item, devemos encontrar o objeto BTDate do cabeçalho.

Dica:

BTAdminH -> (rel) BTHeaderDatesSet -> BTDatesSet -> (rel) BTDatesAll -> BTDate

Mas, uma aviso importante, para alterarmos a data de vencimento é necessário localizar o BTDate cujo campo APPT_TYPE do registro seja igual a SRV_CUST_END, pois a tabela também possui registros com valores iguais a SRV_CUST_BEG, ORDERACTUAL, etc. Meu caso!

Após localizar o BTDate correto, converter a nova data/hora em formato adequado, comparar com a data antiga e, caso sejam diferentes, atualizá-la (óbvio).

object = entity_col->set_property( ‘TIMESTAMP_FIELD’ ).

Esta implementaçã será feita para os campos FROM e TO do objeto BTDate.

Com os getters/setters implementados, temos que escolher o ponto onde o processo será iniciado.
Então, crie uma redefinição do evento do botão da GRAVAR da view "Z", EH_ONSAVE.

Instancie um objeto da classe do nó de contexto responsável pelos atributos e métodos criados anteriormente. E, neste objeto foi carregado os dados do cabeçalho (BTAdminH).

Depois de carregados os dados do cabeçalho no objeto, chamar o método GET do item do service ticket.
Posteriormente, chamar o método SET para a atualização da data do cabeçalho.

Depois de atualizados os dados do cabeçalho, chamar o método SAVE do controlador CuCoBT.

Fim do problema.

Espero ter ajudado seja na resolução do problema ou na agregação de conhecimento.

Até a próxima…

Semantic Intelligence

É o meu primeiro post em meu blog. Espero que releve minha informalidade e falhas gramaticais, pois eu não sou referência alguma neste quesito. No entanto, espero que seja uma leitura agradável a todos neste e nos posts subsequentes.

Inicio este blog com um assunto talvez pouco comum, embora importante, para o mercado: Semantic Intelligence.

O que vem a ser isto? Bom, primeiramente vou contar um pouco de história sobre o BI para entendermos melhor o assunto.

Business Intelligence (BI)

Business Intelligence[1] ou inteligência de negócios consiste, basicamente, na coleta de informações sobre o negócio de uma empresa. Refere-se às práticas, estratégias, aplicações, análise, gerenciamento e skills da empresa. É largamente utilizada como ferramenta para auxílio na tomada de decisões.

Algumas das características do BI é buscar as fontes de informações relevantes, fazendo análises e cruzamentos de informações de múltiplas fontes baseado no tempo estimado e objetivo da empresa. Através das informações coletadas é possivel calcular estatísticas e outras informações úteis para auxiliar a atingir metas.

Um exemplo de estudos realizados com o BI pode ser ilustrado da seguinte forma: uma empresa de televisores, interessada em maximizar as vendas de sua marca em uma cidade ou região, efetua várias análises, baseada em informações em seu sistema, sobre seus consumidores, como: faixa etária, condição financeira, número de pessoas beneficiadas com o produto; fornecedores, pontos de venda e, utilizando sistemas com informaçoes sobre referências geográfica, pode ser feito o cruzamentos dessas e outras fontes de informação para que sejam estudados as formas de serem realizados melhores investimentos em regiões com menor vendagem.

E a inteligência semântica, aonde entra na história?

Como podemos perceber, o Business Intelligence está voltado para as informações contidas dentro dos firewalls e servers das empresas. Atualmente, a velocidade com que são transmitidas as informações aos quatros cantos do planeta, as empresas ainda pensam no uso do BI somente para as “informações internas”, descartando as informações desestruturadas provenientes de artigos, blogs, jornais, satisfação dos consumidores, social network, twitter, etc.

Materializando o conceito Web 2.0 dentro das organizações é possivel realizar cruzamentos de informações de dados internos e externos (porque não fornecedor e consumidor) à empresa, resultando em uma base mais consistente e abrangente sobre um determinado assunto ou objetivo.

A proposta da semantic intelligence[2] é criar, modelar toda uma estrutura de busca, filtros e análises de dados para que haja o bom gerenciamento dessas informações desestruturadas, checando-as e “formatando-as” para que seja possivel a utilização uniforme com as já existentes dentro das empresas.

Com isso, o planejamento estratégico de propaganda ou tendência de consumo, por exemplo, pode ser analisado de uma forma mais eficaz e abrangente.

Até a próxima…