Como o iBOLT faz a sua mágica?

Manoel Frederico

Um dos pontos fortes, e mais apregoados desde o início, em relação aos recursos existentes no iBOLT, é sem dúvida a sua biblioteca de componentes:

No mundo EAI e BPMS, a habilidade de se comunicar com o maior número possível de tecnologias e sistemas faz toda a diferença.

O iBOLT investe nesta habilidade disponibilizando componentes nativos para alguns dos sistemas mais utilizados/presentes nas organizações. Veja o destaque abaixo:

Estes componentes são especializados na conversa com a API destes sistemas, permitindo acesso as suas funções de negócio (ou objetos de negócio).

E aqui, um detalhe importante: a API.

Estes componentes para interface com sistemas específicos são construídos com base na API que estes sistemas disponibilizam.

Veja por exemplo as APIs requeridas (pré-requisitos) de alguns deles:

 

SAP B1 DI API
SAP R/3, A/1            BAPI (RFC) e iDoc
JDE E1   Java Dynamic Connector API
JDE World   Z-Tables e RPG Program
Google Docs, Calendar  Google Java API
Notes DB Lotus Notes Java API
SalesForce SOAP API e Bulk API
Dynamics CRM   CRM WebServices API
Exchange                EWS Java API e SOAP WebServices
SharePoint SOAP WebServices

 

Por mais diferentes que sejam as tecnologias destas APIs, e elas são mesmo, toda a complexidade fica encapsulada dentro do componente.

Estes componentes, muito diferentes entre si, possuem sempre a mesma ‘cara’ dentro do iBOLT Studio.

Esta interface simples, gráfica, intuitiva e unificada, facilita muito o acesso às funcionalidades destes sistemas dentro de um projeto iBOLT, e dá versatilidade e dinâmica ao projeto.

Esta é a mágica do iBOLT: transformar o ‘complicado’ em algo simples, fácil e rápido.

 

Só funciona deste jeito?

Sabemos que alguns produtos disponibilizam mais de uma API. Como os da Google, por exemplo.

Em outros, estas APIs não estão incluídas na instalação/implantação padrão.

E em outros, as APIs até podem ser comercializadas à parte.

O raciocínio é simples: se o componente foi construído em cima de uma API específica, ela se torna pré-requisito para este componente. Se ela não estiver presente/disponível e funcional, o componente não irá funcionar.

 

Então, sem esta API específica não tem solução?

Tem, sempre tem.

Uma das várias qualidades do iBOLT é poder se comunicar com diversas tecnologias, e também bases de dados.

Se o sistema que você deseja acessar possuir alguma interface COM/OCX, Java, .NET, Win32, HTTP, EJB, SOAP, etc, certamente ele poderá interfacear com o iBOLT.

Provavelmente alguma complexidade será adicionada ao projeto, por não utilizar aquele componente nativo que foi criado exclusivamente para esta tarefa.

Mas o importante é não perder a visão: de um jeito, ou de outro, sempre tem jeito com o iBOLT.

 

E se o componente não me servir?

Você está com o sistema e a API disponível, mas o componente não disponibiliza algum recurso que você gostaria ou precisa ter?

 

Construa o seu!

Além de tudo o que o iBOLT disponibiliza nativamente, ele ainda tem um SDK para construção de novos componentes personalizados.

Veja aqui: http://blog.magicsoftware.com.br/?p=1964

Afinal, não seria inteligente abrir mão de todos os benefícios de um servidor BPMS/EAI com o iBOLT, por causa de um componente.  Não é?

 

Manoel Frederico Silva
Product Manager & MAGIC Evangelist / Magic Software Brasil

Deixe um comentário

O seu endereço de e-mail não será publicado.