SCR3040 Manual de Consulta Web Service
SCR3040 Manual de Consulta Web Service
SCR3040 Manual de Consulta Web Service
A consulta ao SCR via Web Service permite a consulta da posição consolidada de crédito de um tomador
(tanto pessoa física como pessoa jurídica).
Para a utilização desta opção de consulta, a Instituição Financeira deve desenvolver uma aplicação específica
(um programa) para comunicar-se com o Banco Central através de um componente de serviço padrão (que
serve como um conector para permitir esta comunicação).
Cada consulta efetuada através da interface desenvolvida pela Instituição Financeira, ou seja, pela aplicação
desenvolvida, disparará uma consulta aos servidores do Banco Central, retornando a posição de crédito de um
único tomador em uma única data-base.
Esta aplicação desenvolvida pela Instituição Financeira deverá apresentar os dados de forma mais clara e
intuitiva para o usuário da informação.
2.1. WSDL
Todo Web Service é descrito por um documento WSDL (Web Service Definition Language), o qual descreve o
serviço referido, seus parâmetros de entrada e saída e a estrutura de dados destes parâmetros, caso esta seja
complexa.
O documento WSDL pode ser acessado por meio de um link no sítio do Banco Central ou na própria aplicação
web provedora do Web Service.
O documento WSDL é utilizado pelos desenvolvedores das aplicações que utilizam Web Service para a
geração de stubs de comunicação através de uma interface (IDE) apropriada. Uma IDE tipicamente analisa o
WSDL e produz um código que implementa a comunicação de rede para invocação dos serviços. A IDE
também reproduz, na linguagem de programação em questão, as estruturas de dados necessárias para
representar os parâmetros de entrada e saída do Web Service.
O WSDL do SCR2 expõe dois métodos: getResumoDoClienteBACEN e getResumoDoCliente, sendo o
primeiro de uso interno do Banco Central do Brasil. A instituição financeira, portanto, deve utilizar
exclusivamente o método getResumoDoCliente para obter a posição de crédito de um cliente em uma data-
base.
Quando as requisições SOAP trafegam pela rede, há o risco de o seu conteúdo - texto XML - ser observado
por terceiros. Embora existam diversas propostas para se impor segurança por criptografia em mensagens
SOAP, a arquitetura mais simples consiste em delegar esta tarefa ao transporte da mensagem, utilizando-se
HTTPS no lugar de HTTP.
O reconhecimento das autoridades emissoras dos certificados digitais dos servidores é pré-requisito para o
funcionamento das aplicações clientes, para o Web Service disponível via HTTPS. Para clientes .NET, a
instalação dos certificados digitais pode ser feita diretamente pelo browser. Para clientes Java/J2EE, a
instalação dos certificados digitais deve ser feita pela ferramenta de linha de comando keytool. Mais detalhes
são dados no item 3.1. Clientes Java Stand-alone.
Toda conexão HTTPS pressupõe a existência de um certificado digital válido no servidor web com o
qual a conexão é estabelecida. Este certificado, por sua vez, foi emitido por uma autoridade
certificadora, a qual também deve ser considerada confiável.
Quando se navega em um site via HTTPS, o browser sempre nos alerta caso o certificado digital do
mesmo não seja considerado válido ou confiável. O exemplo abaixo se refere a um certificado cujo
emissor não é considerado confiável:
Pressionando-se o botão ‘Exibir certificado’ será exibida uma descrição mais detalhada do problema:
Neste caso, é o certificado da autoridade certificadora (SERPRO) que não é considerado confiável pelo
browser. Há, nesta tela, a possibilidade de se instalar o certificado de forma que o browser passe a
reconhecer o SERPRO como uma autoridade confiável 1. As telas e procedimentos para exportação dos
certificados para arquivos que foram exibidas acima como exemplo são as apresentadas pelo Internet
Explorer. Todavia, qualquer browser apresenta as mesmas funcionalidades.
O certificado do servidor aceito pelo browser (veja figura abaixo) pode ser exportado para um arquivo
".cer". Este arquivo contém não apenas o certificado do servidor, como também o da autoridade
certificadora que o emitiu, isto é, o caminho da certificação:
1
Os certificados do SERPRO também podem ser baixados e instalados diretamente do site https://thor.serpro.gov.br/ACSERPROSPB.
2
Considere [KEYSTORE] = [JAVA_HOME]/jre/lib/security/cacerts. A senha padrão para o keystore do JDK da Sun é "changeit", mas isto pode ser mudado
pelo próprio keytool.
A opção "Copiar para arquivo..." permite gerar localmente um arquivo com o certificado (ex:
"C:\TEMP\bccert.cer").
Para importar para dentro do keystore os certificados das autoridades certificadoras, basta o comando
abaixo:
Clientes .NET também exigem que os certificados tenham sido importados e registrados como
confiáveis. Isto pode ser feito a partir do próprio browser, na opção "Instalar certificado".
Em uma aplicação (stand-alone ou web), deve ser criada uma web reference:
No passo seguinte, deve ser fornecido o caminho para o documento WSDL (pode ser um caminho local
para onde foi feito um download do WSDL ou mesmo uma URL para o documento original):
Após este passo, as classes de dados e o stub serão criados pelo próprio Visual Studio .NET, sendo
sua manipulação bastante simples.
Para ter acesso às Consultas de Informações dos Clientes, é necessário estar habilitado no serviço
WSCR0001 - Acesso ao SCR - Perfil IF - CONSULTA VIA WEB SERVICE.
A solicitação do serviço deve ser feita através do envio de um e-mail para [email protected], com
cópia para [email protected], informando:
Para viabilizar o acesso após cadastramento da instituição financeira no serviço WSCR0001, o master da
instituição deve atribuir este serviço (transação) às dependências por meio do aplicativo AutranWeb, disponível
na página do Banco Central, cadastrando a seguir um usuário genérico, utilizando-se do mesmo aplicativo.
A viabilização do acesso também pode ser realizada por meio da transação PTRA800 do Sistema de
Informação do Banco Central (Sisbacen) para atribuir o serviço às dependências. A seguir, deve ser feito o
cadastramento do usuário genérico utilizando a transação PTRA700 do Sisbacen.
Cada Instituição Financeira (IF) deverá cadastrar apenas um usuário do serviço que poderá utilizar, no máximo,
duas conexões simultâneas. Casos excepcionais deverão ser discutidos previamente com o Banco Central
(Bacen).
IMPORTANTE: Reforçamos que consultas via Web Service deverão utilizar um único usuário virtual por
instituição financeira e por tipo de servidor (produção/homologação).
É obrigatório que testes tenham sido realizados no ambiente de homologação antes da solicitação do serviço
em produção.
a. Código do Cliente consultado: 8 dígitos numéricos para CNPJ e 11 dígitos numéricos para CPF
b. Tipo do Cliente: 1 dígito numérico (‘1’ para Pessoa Física e ‘2’ para Pessoa Jurídica)
c. Data-base a ser consultada, no formato ano/mês ('AAAA-MM')
d. Declaração de autorização de consulta do cliente (AutConsCli): deve ser informado o valor „S‟, que
indica a existência de autorização por parte do cliente. Qualquer caractere diferente de „S‟ impedirá a
realização da consulta.
Para cada consulta, são aplicadas validações sobre os parâmetros informados. Alguns erros podem ser
retornados, conforme descrição abaixo:
Retorno do Sistema
Tipo de Erro
Código Mensagem
Data-base consultada fora do período permitido (*) 51 Data-base indisponível para consulta
Data-base não disponível para a instituição financeira (*) 52 Data-base indisponível para a Instituição Financeira’
Instituição financeira não habilitada a efetuar a consulta 53 Erro ao validar a instituição financeira
Campo requerido “código do cliente” não informado 58 Código do cliente não informado: campo obrigatório
Campo requerido “tipo do cliente” não informado 59 Tipo do cliente não informado: campo obrigatório
(*) O Bacen verifica se a data-base indicada está disponível para consulta. A data-base requisitada deverá estar dentro do período
parametrizado para consulta, que corresponde atualmente as 24 datas-bases anteriores ao mês corrente. Por exemplo: se o mês corrente
for março/2019, o período parametrizado será de março/2017 a fevereiro/2019 (24 datas-bases). As informações serão fornecidas apenas
se o status da IF na data-base requisitada para o documento 3040 for “Aceito” ou “Dispensado”.
Cada consulta ao SCR feita via Web Service será respondido com os seguintes parâmetros:
O valor de cada código de vencimento a ser informado é dado pelo somatório de todas as operações de cliente
que tiverem a mesma modalidade/submodalidade e vinculação à moeda estrangeira. Somente são informados
códigos de vencimento cujos valores sejam maiores que diferentes de zero.
As “operações excluídas por determinação judicial”, as “operações excluídas por vícios de contrato” e as
operações com informações negativas acima de 5 anos não são apresentadas nas informações retornadas
para a IF. Se o cliente possuir exclusivamente operações de um destes 3 tipos será considerado cliente sem
operação no SFN na data-base solicitada (erro 50). As operações marcadas “sub judice” e com “manifestação
de discordância” são apresentadas com os valores das operações normalmente.
Atualização de número de datas- O número de datas-base disponíveis para consulta passou de 13 a 24,
18/03/2019
base disponíveis para consulta a partir de 18/05/2018.