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