O SAP Business One é um sistema de gestão empresarial bastante relevante/conhecido no mercado mundial e nacional, e que possui uma interface de integração muito interessante: a DIAPI.
Como muitos já sabem, a SAP e a MSE possuem um acordo (parceria) global que permite ao iBOLT incluir um componente especializado para esta interface com o B1, como você pode verificar nestes links do DevNET MAGIC. Isso potencializa sobre maneira os recursos disponíveis a todos as implantações B1.
A DIAPI é uma biblioteca distribuída sob a tecnologia COM/OCX da MicroSoft, e que provê várias entidades que representam os objetos de negócio existentes no produto. Os métodos destes objetos permitem realizar as diversas atividades cotidianas do sistema.
A interface simples e intuitiva do iBOLT:
concede acesso total a estes objetos de negócio, encapsulando a DIAPI através de seus wizards, e insere definitivamente o B1 na arquitetura SOA da empresa.
Este post vai focar numa característica específica desta arquitetura: a tecnologia COM/OCX usada pela DIAPI.
Tecnicamente, a DIAPI é uma biblioteca cliente que se acopla como módulo das aplicações que pretendem acessar seus recursos. As bibliotecas COM/OCX são disponibilizadas quase sempre como arquivos de vínculo dinâmico (DLLs), e possuem uma dependência direta de diversas informações existentes no Registro do MS-Windows.
Não é diferente no caso do iBOLT. Um projeto que está acessando o B1 terá um processo iBOLT Server em execução, com as DLLs que compõem a DIAPI como seus módulos.
Quando um módulo COM/OCX apresenta alguma falha de execução, estas falhas são propagadas até sua aplicação host e podem afetá-las/desestabilizá-las.
Por exemplo, veja as SAP notes 1289282 e 1301770 do B1. Elas falam a respeito de problemas na alocação de memória em processos que, curiosamente (ou infelizmente), são os mais executados nos projetos de integração aqui no Brasil :(. O acesso repetido a alguns objetos ocasionam estes problemas.
Eles podem não aparecer com frequência em AddOns anexados a interface UI do produto, por conta do tipo de uso: pontual. Mas em um processo batch da empresa, que está recorrendo constantemente à DIAPI, o tipo de uso é outro: massivo.
E se um problema técnico ocorrer na DIAPI, ele será propagado e afetará as aplicações que estão utilizando-a.
Isto também não é diferente no caso do iBOLT.
Pesquisando sobre o tema, a equipe técnica da MAGIC Brasil acabou criando um protótipo que mais tarde evoluiu para uma versão final do: Componente SAP B1 8.8 SandBox, internamente batizado de B1BR 8.8.
‘SandBox’, porque o objetivo principal deste desenvolvimento foi acessar o B1 em um processo separado do processo principal (iBOLT Server). Como ocorre, por exemplo, com o Google Chrome. Cada página é exibida numa aba, e cada aba é um processo independente do sistema operacional. Assim, se uma página apresentar problemas e gerar crash no navegador (ninguém é perfeito), apenas aquela aba/processo será afetada.
A ideia por trás do B1BR 8.8 é a mesma: como a DIAPI estará sendo acessada em um processo (.exe) independente, qualquer eventual problema durante este acesso está confinado a este processo, e não deverá afetar o seu host, no caso, o iBOLT Server. O acesso específico ao componente pode até falhar (ninguém é perfeito), mas o fluxo do projeto continua normalmente e o servidor (iBOLT), inabalável.
Bom, pelo menos é esta a intenção 🙂
O componente B1BR 8.8 está disponível a todos os parceiros e desenvolvedores de projetos iBOLT com B1, gratuitamente, através deste endereço.
NOTA: este componente não é um produto da MAGIC Software Brasil ou da MAGIC Software Enterprise, mas uma contribuição gratuita para a comunidade iBOLT. Por isso, não há compromisso formal com evoluções ou suporte do mesmo. Ele é free, mas não é open source.
Este componente não está contido na biblioteca padrão do iBOLT. Ele é distribuído como um componente de usuário, e precisa ser instalado manualmente em um iBOLT já existente.
Isto é feito do seguinte modo:
1) Copie as pastas “icons” e “user resources” (do .zip baixado) para uma pasta (home) de uma instalação iBOLT (qualquer uma a partir da versão 3.2). Pode sobre-escrever.
2) Dentro do projeto, com o iBOLT Studio, vá em Project à Component… e clique “Add”, selecionando o componente e confirmando:
Com esta ação, a partir de agora o componente estará disponível para uso por este projeto:
O componente B1BR 8.8, como diz o nome, funciona exclusivamente com da DIAPI do B1 8.8, e possui um pré-requisito: o cache de gravação em disco da unidade onde está o iBOLT precisa estar desativado:
O componente B1BR 8.8 ainda possui algumas características exclusivas, que o diferenciam do componente standard de acesso ao B1:
a) Todo acesso a DIAPI é feito por um subprocesso inicializado pelo componente, chamado B1BR_88.exe. Este subprocesso é iniciado e encerrado a cada execução do componente. Em termos de performance, significa dizer que o seu desempenho é similar ao componente standard com a opção Keep Connected=NO.
b) Ele possui apenas a interface Method; não possui a interface XML. Significa que os XMLs a serem utilizados nele devem ser criados um passo antes, através de um DataMapper.
c) Ele permite interface apenas com os objetos de negócio da DIAPI, e não com outros tipos de objetos, como tabelas de usuário.
d) Ele disponibiliza as operações conhecidas (Add, Delete, Update, Cancel, Close e Query), mas não todos os objetos da DIAPI. Apenas os mais comuns (Items, BP, Documents, etc…) estão ali:
Não há impedimento em utilizarem-se os dois componentes (standard e B1BR) no mesmo projeto.
Mas se a ideia é ter um acesso isolado, qual seria a graça?
Por isso, fica a dica a todos os interessados (ou curiosos): acesse o endereço, baixe o componente e faça a sua própria avaliação.
Manoel Frederico Silva
Product Manager & MAGIC Evangelist / Magic Software Basil