Messias Bittencourt

Boa tarde, estou recebendo o seguinte erro quando faço uma requisição a aplicação. Alguém tem alguma luz sobre o problema? # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000783200caaed2, pid=26387, tid=26417 # # JRE version: OpenJDK Runtime Environment (21.0.6+7) (build 21.0.6+7-Ubuntu-122.04.1) # Java VM: OpenJDK 64-Bit Server VM (21.0.6+7-Ubuntu-122.04.1, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # C [libacbrboleto64.so+0x2aaed2] # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /opt/tomcat/bin/core.26387) # # An error report file with more information is saved as: # /opt/tomcat/bin/hs_err_pid26387.log [14.113s][warning][os] Loading hsdis library failed # # If you would like to submit a bug report, please visit: # https://bugs.launchpad.net/ubuntu/+source/openjdk-21 # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. #

Isto no ambiente de PROD do Banco Santander. Resumo: conseguimos pagar o boleto que vem do serviço "Recupera PDF" fornecido pelo banco mas não o gravado na pasta pela biblioteca.

Boa noite pessoal. Tenho uma aplicação consumindo o .so do boletoACBr. Já estamos em Produção com mais de um Banco. No caso do Santander, novo banco que estamos homologando, estamos passando por um problema no PDF (o registro é realizado com sucesso). O pdf que é gravado na pasta definida no servidor está com um QrCode e Linha Digitável diferentes da que realmente foi registrada no Banco Santander. Assim sendo, quando tentamos pagar o PDF salvo pela biblioteca, ele mostra "Boleto não registrado...". O Santander disponibiliza um serviço para recuperar o pdf pelo nosso Número. Ao recuperar o mesmo boleto verificamos que não é o mesmo Código de barras nem linha digitável. Envio anexo pdf gravado pela biblioteca (GeradoPelaBiblioteca.pdf) e o pdf recuperado no Banco Santander (RecuperadoPeloBanco.pdf) para checagem. Observem que apenas alguns blocos de dados são divergentes... Recuperado no Banco: Gerado pela biblioteca: Como proceder? Att

Bom dia. Gostaria de saber se existe algum outro procedimento que pode ser adotado. Mesmo seguinte à risca as orientações, o problema persiste. Na realidade é intermitente. Ele começa funcionando normalmente mas de uma hora para outra surge o erro. E após o erro apenas reiniciando a aplicação.

Combinado e no aguardo. Muito obrigado!

Bom dia @antonio.carlos. Eles não possuem uma documentação em pdf. Mas acessei aqui o "https://developercielo.github.io/manual/apipix#segurança" com meu usu e senha e te passo abaixo a parte que fala de segurança. Se realizar um cadastro no site "https://desenvolvedores.cielo.com.br/api-portal/" poderá checar a documentação com mais profundidade. Pelo postman eu utilizei os .cer e .key obtendo sucesso. Segurança Devem ser observadas para desenvolver e implementar a API seguindo boas práticas de segurança, atendendo aos requisitos obrigatórios abaixo. Requisitos de segurança obrigatórios: A conexão à API deve ser criptografada utilizando o protocolo TLS versão 1.2 ou superior, permitindo apenas cipher suites que atendam ao requisito de forward secrecy. O PSP deve implementar o framework OAuth 2.0 (RFC 6749) com TLS mútuo (mTLS – RFC 8705) para autenticação na API, conforme especificações abaixo: a. Os certificados digitais dos clientes da API poderão ser emitidos pelo próprio PSP ou por ACs externas, conforme definido por cada PSP. Não deverão ser aceitos certificados auto-assinados pelo cliente. b. Cada PSP deve possuir seu próprio Authorization Server e Resource Server associado à API Pix, e ambos devem implementar TLS mútuo. c. O Authorization Server do PSP deve implementar a técnica de vinculação do certificado do cliente aos access tokens emitidos (“Client Certificate-Bound Access Tokens”), conforme seção 3 da RFC 8705. d. O Resource Server do PSP deve confirmar que o thumbprint do certificado associado ao access token apresentado pelo cliente é o mesmo do utilizado na autenticação TLS (proof-of-possession). e. O fluxo OAuth a ser utilizado é o “Client Credentials Flow”. f. Os escopos OAuth serão definidos na especificação Open API 3.0 da API Pix e permitirão associar diferentes perfis de autorização ao software cliente. O processo de cadastro/onboarding do cliente para acesso à API deve ser realizado em ambiente logado no PSP, e deve incluir um canal seguro para envio das credenciais ao usuário, de forma a permitir a rastreabilidade das ações executadas. A API deve suportar múltiplos níveis de autorização ou papéis, segregando as funcionalidades de acordo com perfis (escopos OAuth) dos usuários clientes. O PSP deve implementar tecnologia que permita garantir a alta disponibilidade da API. A API deve garantir a confidencialidade e a integridade das informações dos usuários e de suas transações, tanto em trânsito como em repouso. O PSP deve manter logs de auditoria dos acessos à API pelo período mínimo de 1 ano. A credencial de acesso utilizada na autenticação (Client_ID) deve ser vinculada ao CNPJ ou CPF do usuário recebedor e deve permitir acesso a recursos apenas de contas transacionais de titularidade do CNPJ ou CPF associado. Para a funcionalidade de webhooks, as notificações oriundas do PSP recebedor ao usuário recebedor trafegarão utilizando um canal mTLS. a. Recomenda-se que os certificados utilizados para autenticação mútua no canal TLS do webhook sejam os mesmos da API Pix. De todo modo, não há objeção quanto à utilização de outros certificados, mediante acordo entre o PSP e o usuário recebedor. O BC entende que os PSPs poderão adotar as tecnologias e soluções de segurança para a API que mais acharem apropriados, desde que sejam atendidos os requisitos obrigatórios de segurança e, sempre que possível, as recomendações descritas acima, com atenção também aos elementos listados nos tópicos a seguir.

Boa noite @antonio.carlos. Vou ver se arrumo esta documentação e lhe passo. De qq forma e antecipadamente, afirmo que existe sim o uso do certificado. Já testei diretamente no Banco via postman. Homologação não precisa. Basta apenas clientId e clientSecret. Em produção, também funcionou, mas além destas credenciais acima descritas, precisei utilizar os certificados que o proprietário da conta me forneceu. Att

Muito obrigado pela ajuda @Juliomar Marchetti. Eu até cheguei a abrir o fonte da config em https://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Fontes/PIXCD/ACBrLibPIXCDConfig.pas. Sicoob e Bradesco realmente tem estas properties. Mas o Cielo está sem as mesmas. Agradeço se puder dar esta ajuda....

Mesmo problem para ArquivoChavePrivada ou ArqChavePrivada

Boa tarde e obrigado pelo auxílio. E qual é o nome da ACBRSessao que devo utilizar? Eu tentei Cielo mas aparece o erro dizendo que não existe este atributo na Sessão. Já tentei como ArqCertificado e como ArquivoCertificado. 16/10/24 18:01:06:343 - LIB_ConfigGravarValor(Cielo, ArquivoCertificado, C:\dev\pix\certificado\GV-BUS.cer) 16/10/24 18:01:06:354 - SetRetorno(-3, Chave [%s] não existe na Sessão [%s] no arquivo de configuração)

Boa tarde. Gostaria de saber como, no caso do PIX Produção do Banco Cielo, eu passo os dados dos certificados. Como podemos ver na imagem acima não existe a opção de certificados como no Banco Bradesco ou Sicoob por exemplo. Agradeço desde já a atenção e no aguardo.

Boa tarde. Gostaria de saber como, no caso do PIX Produção do Banco Cielo, eu passo os dados dos certificados. Como podemos ver na imagem acima não existe a opção de certificados como no Banco Bradesco ou Sicoob por exemplo. Agradeço desde já a atenção e no aguardo.

Muito obrigado pelo esclarecimento Diego. Eu não sabia desta implementação com uso de ponteiros. Já o estou implementando aqui. Muito obrigado. Muito obrigado pelas orientações Daniel.

Boa tarde Srs. Estou utilizando o boleto em um ambiente Linux (arquivo .so). Até então venho utilizando o .so que se encontra na pasta Cdecl ou StdCall. Funcionando tudo normal desta forma. Só pelo fato de eu alterar o .so, utilizando a mesma versão, para o que se encontra na pasta MT/Linux ocorre o erro abaixo. Como deu o erro e já estou em ambiente de produção, voltei com o .so que funciona para dar continuidade. Já viram algo parecido? # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f236ec4c37b, pid=1489, tid=1514 # # JRE version: OpenJDK Runtime Environment (11.0.24+8) (build 11.0.24+8-post-Ubuntu-1ubuntu322.04) # Java VM: OpenJDK 64-Bit Server VM (11.0.24+8-post-Ubuntu-1ubuntu322.04, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # C [libacbrboleto64.so+0x24c37b] # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/ubuntu/core.1489) # # An error report file with more information is saved as: # /home/ubuntu/hs_err_pid1489.log # # If you would like to submit a bug report, please visit: # https://bugs.launchpad.net/ubuntu/+source/openjdk-lts # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Att

Senhores, resolvido a questão. Era o endereçamento do pdf que estava com a barra invertida. Aff

E o interessante é que o log mostra tudo ok. Teve um response conforme manda o figurino. Mas parece que algo que falta no Linux não é capaz de me devolver corretamente. Aí devolve apenas a url do pdf. ACBrLibBoleto-20240806.logLogWS-Sicoob.log

Boa tarde. Implementei aplicação java + BoletoLib para 3 bancos. No Windows a consulta, baixa e geração funcionam normalmente. Mas ao migrar para o linus a Geração de Boletos me devolve apenas a URL do pdf no servidor. O Boleto é gerado com sucesso tanto que depois eu consigo consultar o mesmo. Mas o retorno pós geração vem conforme imagem abaixo: Sabem o que deve ser? Creio eu que esteja faltando alguma config ou instalação neste meu servidor Linux. Conseguem me dar um help? Att

Seguindo o video funcionou, mesmo usando o tomcat/java. Infelizmente via Docker não funcionou por causa das dependencidas das bibliotecas pro X, voltarei a tentar em outra ocasião, mas para o problema reclamado podem fechar o post. Muito obrigado a todos.

Vi o video, estou começando uma maquina do zero seguindo as instruções la do video. Acho que vai resolver. Muito obrigado.

Onde devo colocar isso?

Instalei as dependencias conforme o link que passei acima: https://acbr.sourceforge.io/ACBrLib/ComoInstalarDistribuir.html E agora da esse erro: (java:1): Gtk-WARNING **: 14:56:56.865: cannot open display:

https://acbr.sourceforge.io/ACBrLib/ComoInstalarDistribuir.html Vi que usam uma série de bibliotecas especificas, estou mudando a distribuição do docker pra Ubuntu e facilitar a instalação. Alguém aqui ja subiu esse projeto via Docker?

Ao tentar subir o projeto em uma imagem Alpine com o Tomcat estou tendo o erro abaixo na hora que vai fazer o LOAD na biblioteca libacbrboleto64.so java.lang.UnsatisfiedLinkError: /boleto/dll/libacbrboleto64.so: Error loading shared library libgdk-x11-2.0.so.0: No such file or directory (needed by /tacom/boleto/dll/libacbrboleto64.so) Ele reclama que não encontra: libgdk-x11-2.0.so.0 Estou subindo um container limpo, com base em: FROM nginx:alpine RUN apk add openjdk11 E então eu copio meu tomcat: RUN mkdir -p /opt/tomcat COPY apache-tomcat-10.1.25 /opt/tomcat O serviço sobe normalmente e funciona no windows, usando a .dll, ao mudar pro container Linux eu fiz essa troca da biblioteca para a versão Linux e estou tendo esse erro. O tomcat está funcionando perfeitamente, subo o projeto e consigo usar, menos quando chega na parte que faz chamadas a biblioteca de boleto. Por ser um container Docker, pode ser que seja preciso instalar essa biblioteca/dependencia para que a biblioteca de vocês funcione no linux. Como posso instalar ela na minha imagem DOCKER (visto que o Alpine não tem APT ou APT-GET por default)

Continuando o post em que mostro como configurar via Maven a biblioteca, agora fiz um exemplo simples que gera o .PDF pra facilitar a vida de quem está querendo começar a utilizar a bibliteca em seus projetos Java. Para configurar esse projeto você precisa colocar na pasta arquivos_ini a sua DLL, (não zipei junto pq o anexo limite é 2mb. Os diretórios estão fixos pois é apenas para fins de demonstração o codigo, e eles devem ser configurados no arquivo: AcBrBoleto.java As variaveis: ACBR_BOLETO_DLL, CEDENTE_INI, TITULO_INI, DIRETORIO. E o nome do arquivo gerado na linha 31 ao usar a função: INSTANCE.Boleto_SetDiretorioArquivo O codigo anexado pode ser enviado para o SVN da ACBR caso queiram, como exemplo, com um link apontando para esse post para facilitar a vida de quem precisar. O projeto é simples mas isso pode ser o pontapé inicial de quem está querendo usar a biblioteca com Java, pois o exemplo existente hoje usa o Netbeans que não é mais a principal IDE do Mercado e da forma como está feito agora pode ser importado em qualquer IDE. O post inicial está em: Você também pode ver o HELP.MD que vai conter as instruções lá. boleto-simples - bkp.zip

Olá pessoal! Seguem abaixo os passos que segui para configurar o ACBr via Maven para usar com Eclipse ou IntelliJ. Os passos foram relativamente simples Buildar o Ac Br Commons, exporar um jar (1.0.0) Pega esse Jar e instalar no seu Maven Repository mvn install:install-file -Dfile="C:\projetos\AcBr\boleto-service\src\main\resources\lib\ACBr Common.jar" -DgroupId="br.com.acbr" -DartifactId="acbr" -Dversion="1.0.0" -Dpackaging="jar" E adicionar no projeto as dependencias: <dependency> <groupId>net.java.dev.jna</groupId> <artifactId>jna</artifactId> <version>5.9.0</version></dependency> <dependency> <groupId>net.java.dev.jna</groupId> <artifactId>jna-platform</artifactId> <version>5.9.0</version> </dependency> <dependency> <groupId>br.com.acbr</groupId> <artifactId>acbr</artifactId> <version>1.0.0</version> </dependency> Trouxe para cá pois isso pode ajudar outra pessoa a fazer essa configuraçao, pois pouca gente usa o NetBeans.... maioria usar o Eclipse ou o IntelliJ... e com essa configuração via Maven, essa dependencida do Netbeans mostrada nos videos não é mais necessária, se torna opcional.