Workshop de lançamento das APIs Comuns, Produtos e serviços e Canais de atendimento

pessoal Bom dia a todos então Começando
aqui o quarto workshop aqui desse bloco
de lançamentos do início de 2024 então a
ideia hoje a gente apresentar eh as apis
ali de dados abertos Então a gente vai
ter atualização da api comum as apis de
produtos e serviços e de canais de
atendimento então primeiro queria
agradecer a presença de todo mundo
agradecer os grupos técnicos envolvidos
que viabilizaram a atualização D a
atualização dessas apis eh agradecer
também a um trabalho bem coletivo que
acontece aqui do lado do lado da
estrutura e com todos os voluntários
pessoal aqui do grupo de produtos e
queria agradecer também todo mundo que
tá presente aqui hoje participando aqui
que vai ser quem vai colocar a mão na
massa aqui agora para para conseguir
viabilizar o go Live dessas novas dessas
novas versões Então hoje a gente vai ter
o o Moacir que é pm aqui de dados de
dados abertos responsável por essas apis
o gilan Costa que é o arquiteto de
soluções responsável pela é o nosso api
Expert al pela que vai apresentar a
parte mais técnica o sweger que que vem
nessas apis o Cristian eh que vai
apresentar que vai apresentar os o que
vai ser testado de cada uma dessas apis
e depois eu entro com o que que é
esperado das instituições cronograma O
que que a gente tem como próximos passos
tá E no final a gente vai ter uma parte
específica para dúvidas mas vou pedindo
para vocês mandarem as dúvidas eh aqui
pelo chat a gente tá fazendo um esforço
para ir respondendo durante o próprio
durante a própria apresentação a gente
vai respondendo aqui pelo chat depois a
gente vai compilar e disponibilizar as
perguntas e respostas junto com o junto
com o material e qualquer coisa e o
workshop também vai ser gravado e tá
sendo disponibilizado no canal do
YouTube do PF
então com isso podemos começar aqui
então quero passar a palavra pro Moa Bom
dia
Moa Bom dia pessoal bom dia eh me
apresentando novamente ali repetindo o
que a Fabi falou atualmente eu tô faço
parte do grupo de produtos ali dentro do
GT de dados abertos eh e a ideia aqui é
minha ideia aqui é contextualizar um
pouco dos dos lançamentos que a gente
tem eh dentro das API de dados abertos
Então primeiramente só até pra
introdução das mudanças que a gente vai
vai fazer só contextualizando o que é
dados abertos acho que Diferentemente
das das dos demais grupos técnicos que
TM fluxos mais eh robustos ali dentro
das apis eh a API de dados as apis de
dados abertos Elas têm um fluxo um pouco
mais simplificado eh de até de mais
fácil acesso porque a ideia dela eh
principal objetivo das APS de dados
abertos É permitir a comparabilidade
entre produtos dos do ecossistema então
o principal objetivo mesmo é que eh as
instituições eh listem e divulguem os os
seus produtos ofertados para que eh
qualquer qualquer pessoa ali
participante ou não do ecossistema
consiga consultar e comparar eh tudo que
é ofere ofertado ali dentro
eh dividi dividimos ali em dois blocos
eh principalmente a parte de produto e
as demais apis Então hoje nós temos 12
apis eh Na verdade nós teremos 12 apis
vou comentar sobre isso eh em breve mas
eh relativas a produtos então contas
cartões de crédito financiamento
empréstimos direitos creditórios e
adiantamento depositantes fazem parte da
fase um que é a que tá sendo atualizada
nesse momento e a fase quatro traz
outros seis produtos ali que foram
lançados esse ano além das apis de
produtos nós temos outras três apis
dentro do escopo de dados abertos que
são APS de canais de atendimento que o
próprio nome já traz ali um pouco que
lista eh oferta né os os canais de
atendimento de todos os
participantes api admin que é api
utilizada para geração de métricas de
todas as instituições e api comum que
trata um pouco de disponibilidade das
apis e o estatus das implementações das
instituições e pode passar
Fabi
eh a fase um ela foi a primeira fase a
ser implementada ali dentro do do Open
finance e ela foi ela nasceu com duas
apis principais a API de produtos e
serviços e API de canais de atendimento
a partir de Fevereiro a gente deixa de
ter uma API de produtos e serviços e
passa a ter seis novas apis que é a
segregação de todas as apis todos os
produtos que estavam dentro da API de
produtos e serviços
eh atualmente a pi de produtos e
serviços possui possui seis produtos 12
end points Eh toda essa estrutura de end
points ela se mantém a estrutura de
produtos também mas cada um ganhou uma
ap uma API própria a partir de Fevereiro
ali a partir do go Live dessas novas
apis e além dessa segregação de apis
então além de termos seis novas apis que
de novo são os mesmos produtos que a
gente já tinha na api produtos e
serviços a gente fez duas grandes
mudanças eh principais que a
primeiramente a trazer paraa fase um
todos os padrões que foram estabelecidos
no open finance após o seu lançamento eh
as apis de produtos e serviços e canais
de atendimento passaram pela sua
primeira grande revisão eh nos últimos
meses e também eh tentar deixar mais
claro os o toda a especificação
eh Que que foi que que a gente tem ali
dentro dessas apis então a o principal o
principal ganho que a gente tem com com
essas mudanças é primeiramente a a
independência do ciclo de vida entre
todos essos produtos uma vez que
atualmente para atualizar a de produtos
e serviços a gente meio que teria que
atualizar todas as eh seria importante
né para paraa eficiência atualizar todos
os produtos para tentar não eh impactar
ali o ecosistema e o o ciclo de
desenvolvimento das instituições eh para
gerar o o diversas versões de uma mesma
api Então a partir de agora a gente
poderá atuar em um produto específico
dentro desses seis eh e também trazendo
todos os padrões que a gente trouxe eh
que a gente já tem dentro do Open
finance paraa fase um a expectativa de
que a gente normalize eh os dados e
aumente a comparabilidade entre
instituições também com a maior clareza
eh quem é obrigado a oferecer essos apis
basicamente eh os transmissores de
acordo com os produtos e serviços ou
todos os participantes que TM esses
produtos dentro do ecossistema eh então
quando a gente fala tem esse produto não
necessariamente você precisa ter as 12
APS de dados abertos ou as seis APS aqui
da fase um mas se você possui os
produtos que você que que você oferta
algum desses produtos essa api ela é é
imprescindível para você pode passar
Fabi
eh em relação ao api da de Canada de
atendimento a gente não quebrou ela
continua sendo uma API com cinco end
points eh cada um por um tipo de de
canal a as grandes mudanças aqui assim
como na page de produtos e serviços eh
são muito em relação à normalização dos
dados padronização ali de acordo com os
últimos eh asos últimas eh coisas que a
gente definiu no open finance e a maior
clareza de informações então fizemos eh
passamos todas as apis aqui lançamentos
passam pelo período de consultas e a
gente
eh ajusta ali para tentar eh minimizar o
maior número de de dúvidas eh no
desenvolvimento de de todas as
instituições E aí de novo
é mesma coisa PR obrigatoriedade de de
ofertar essa
api e por último ap comum e a gente
mudou um pouquinho o nome ali el ap
comum ap de métricas ap de status a
gente simplificou agora para pi comum
para facilitar que a forma como a gente
trata internamente e e de novo a gente
aqui foi mais conservador nas mudanças e
a gente também só atuou na maior clareza
especificações a definição de conceitos
básicos e na normalização de dados então
de novo é a pii comum assim como a dimin
acabou de ser Eh relançada agora a V2
elas também foram APS que surgiram antes
de muitos padrões que a gente adota
atualmente Então a nossa última Nossa
atualização da pi comum ela também traz
esses pequenos ajustes finos ali para
garantir que todas as instituições eh
forneçam os mesmos dados na mesma
estrutura e aumente a comparabilidade
entre eles eh Diferentemente das das API
de produtos e serviços as api comum e
api admin elas são obrigatórias ali para
todos os os participantes do do Open
finance porque elas tratam basicamente
sobre as apis do Open finance né Elas
não tratam sobre produtos então a ideia
da api comum é trazer dados sobre
disponibilidade programada e o status
das apis das implementações das apis
então eh acho que é isso
Fabi agora eu passo pro jva
Ok
então apresent
também de dados abertos né Ah acho que
tava falhando um pouquinho o seu áudio
mas tentei de novo estão me escutando
agora agora sim beleza Ah então meu nome
é jovan trabalho aqui em em grupos de
produtos no grupo de produtos de dados
abertos na sua arquiteto de soluções
Ah e eu vou comentar um pouco mais eh da
parte técnica né das alterações né mas
antes de comentar um pouco da parte
técnica
Ah nós vamos entrar nesse conceito de O
que é Campos obrigatórios por regulação
e o que é Campos obrigatórios
Tecnicamente né Falando Tecnicamente
dentro do sweger Nós só temos a opção de
colocar um campo ah como required sim ou
não né então Eh e toda vez que nós
colocamos esse Campo como required eu
preciso enviar esse essa informação
ah porém como nós temos um regulador que
determina algumas situações ah de quais
são os campos que nós precisamos
informar pode acontecer alguns casos né
Nós temos isso presente nas apis de
dados abertos nós temos isso presente em
outras apis também eh onde o campo ele
passa a ser eh condicional né ah no
sentido de que ele é obrigado a enviar
esse campo desde que eu tenha essa
informação por exemplo se for conta
poupança eu preciso enviar informação x
y z se for conta corrente eu preciso
enviar a informação x y z né então ele
passa a ser condicional de acordo com
uma regra de negócio e isso não é
possível nós eh implementarmos somente
com obrigatoriedade técnica naquele ele
require sweger né para isso nós
definimos então uma um atributo Esse
atributo é apenas informativo né o ex
regulatory required né
Ah ele não vai ser implementado pelas
casas eh não tem nenhum tipo de teste a
princípio para esse campo né e
basicamente ele vai nos informar Quais
são os campos que o que o regulador está
esperando que sej enviados né esses
campos eles podem eh ser enviados ou não
ser enviados dependendo de alguma
condicionalidade específica eu só ten
essa informação se for um produto x eu
só tenho aquela informação se o meu
cliente tiver em tal canto então Eh pode
existir essas condicionalidades
ãã pode ir pro próximo
slide então começando com as nossas IPI
mesmas né ah dentro da IPI de produtos e
serviços foi feito toda uma
reestruturação né como o moir comentou
eh nós dividimos esses produtos em seis
diferentes produtos por entender que são
produtos distintos e podem ter evoluções
distintas Ao decorrer do período embora
eles sigam uma mesma estrutura base eles
são produtos distintos que podem sofrer
suas suas evoluções em momentos
distintos né então foi feita essa
reestruturação foi feita uma
reestruturação do payload né para
mitigar problemas relacionados à
paginação
eh e foi criado Então esse objeto
participant onde esse objeto participant
é o mesmo que nós encontramos lá na fase
quatro né então foi eh reestruturada a
pi para que
eh ela seja um pouco mais próxima das
apis de fase 4 com a mesma estrutura
aquela estrutura base né ah foi foi
revistos os padrões que foram adotados
dentro do Open finance depois do
lançamento dessas ipis então foi
aplicado aqui esses novos padrões né Por
exemplo a remoção eh dos nas ou não
aplicável né
Eh foi adicionado o o atributo ex
regulatório required para informar Quais
são os campos regulatórios né isso passa
a ser muito importante principalmente
com a remoção dos naas né uma vez que eu
posso não ter aquele conteúdo e eu não
não tenho umas opç de enviar o na ah o
campo ele passa a ser condicional né
então nós precisamos ter Claro Quais são
os campos regulatórios que eu tenho que
enviar se eu tiver aquela informação
né criadas as especificações de retorno
de erro e exceções né que n dentro
dessas IP de fase um só tínhamos
o O Retorno 200 agora nós temos eh Quais
são as especificações para códigos de
erro e
exceção né e revisões de melhores
práticas em especificações de ipis né
validação de partner verif das
descrições exemplos de Campos enfim foi
revisto
eh todo esses cenários das ipis Ah deixa
eu compartilhar o
sweger rapidinho com vocês tá à
vontade Então dentro das especificações
né Nós temos as ipis de dados abertos né
de contas cartões de crédito ah direito
creditórios descontados empréstimos
financiamentos adiantamentos a
depositantes enfim ah e todas elas
seguem aquela estrutura base
Ah que nós comentamos do participant que
é mesmo encontrada lá na fase quatro né
então foi remodelado foi feito toda uma
um trabalho de reestruturação dessas
ipis para primeiro deixar dentro do do
padrão já adotado na fase 4ro né então
foi revisto esses padrões e segundo
resolver os problemas de paginação a
respeito de lista sobre lista né porque
antigamente nós tínhamos um objeto
Brand dentro do Brand nós tínhamos o
Company dentro do Company nós tínhamos o
produto né e aqui a gente também trouxe
todas as informações do produto já
direto pra raiz porque se aqui é um endp
de contas eu tenho as informações de
contas
eh de fácil acesso eu não preciso ir
descendo vários níveis até chegar nas
informações relativas a contas
Ah e isso ele segue todos para todos os
padrões das dessas ipis né então se nós
entrarmos em cartões de créditos nós
vamos ver basicamente aquela mesma
estrutura do par parpando né ah e os
dados referente aos produtos do cartão
de crédito já na raiz do
deira
tranquilo pode compartilhar novamente
Fabi
Claro a pode passar pro
próximo
sim
paraas ipis de canais de atendimento né
nós fizemos também essa reestruturação
ah Porém para canais de atendimento nós
fizemos um uma avaliação interna e
entendemos que
a os entps informados ali Eles já
seguiam uma estrutura totalmente
independente um do outro né então por
exemplo nós temos eh canais eletrônicos
telefones agências bancárias as
eh etc Então são produtos distintos com
estruturas distintas né então por isso
que nós não dividimos em cinco diferent
end points como na na produtos e
serviços que isso era muito claro que
era produtos distintos poderiam ter uma
mesma estrutura mas eh são produtos
distintos com evoluções distintas né
Aqui nós não temos
eh esse caso né ah mas foi feita a
reestruturação dos ent points novamente
para deixar com o mesmo padrão da fase
4ro e com e mitigar problemas
relacionado à paginação do lista sobre
lista né
ah novamente aplicando
eh alguns padrões já definidos no
passados dentro do Open finess n por
exemplo a remoção do do uso de nas né A
ção de atributos informativos sem
necessidade de implementação né o ex
regulatório required né ah criado aqui
também uma especificação de retorno de
erro e OB sessão né nós não tínhamos
isso implementado também nessa nessas
ipis foi adicionada essas informações e
revisão sobre as melhores práticas né
validação de Partner verificação das
descrições
exemplo de Campos então foi feito um
trabalho exaustivo em todos esses end
points para garantir que todos os campos
T um exemplo tem uma descrição válida
tem uma descrição que
condiga exatamente com que deve ser
eh enviado naquele campo para poder eh
facilitar a vida dos dos
desenvolvedores para para ententender o
que que é aquela informação tá sendo
passado ali naquele
momento tá
Ahã quí pro próximo
slide e apis comuns né dentro das ipis
ah
comuns nosso objetivo principal com as
ipis de relatórios de métricas
eh seria o dashboard do cidadão né o
viabilizar a construção do dashboard do
cidadão então para as ipis comuns aqui
não foi feit uma grande reestruturação
né diferente da pi de admins aqui foi
feito eh somente um trabalho de revisões
sobre melhores práticas e também
colocado o retorno de erro e exceção
nessas ipis deixa eu compartilhar
novamente minha
tela e nós podemos ver essas ipis de
relatórios simétricas elas estão
Ah nesse outro endereço e ipis ah comuns
né então basicamente o que foi
feito nessa revisão aqui
foi foi alterado muito pouco da
estrutura né Principalmente estruturas
eh de retorno de erro eh ajustado um ou
outro Campo justamente para poder
viabilizar eh para não ter tantos
impactos aqui na pi comum Ah e onde o
impacto maior estava na admin
justamente Com base
no na prioridade ser o o dashboard do
cidadão tá então aqui dentro da Ipa
comum nós temos uma estrutura muito
similar do Que Nós já tínhamos antes né
onde nós temos eh a IPI de status que
ele vai retornar o status da
implementação né então Eh vai vai
informar as casas devem informar se
todas as ipis já foram implementadas se
não foram implementadas enfim o estadus
da implementação e em outage eu vou
informar Quais são os ent points que
estão fora por algum
motivo
Ok e seria isso mais ou menos ah sobre
da parte técnica sobre esses essas
ipis legal obrigada Gilvan obrigada
também queria passar a palavra aqui
agora então e pro Cristian então
Cristian Bom dia então que a gente
queria entender de você aqui como que
vão ser os dessas apis como que vai
funcionar esse esse processo legal Fabi
Obrigado Bom dia pessoal sobre os testes
de fase um né de dados abertos ele tem
uma estrutura um pouquinho mais simples
do que os testes de fase dois acho que
todo mundo que eh deve estar mais
habituado com isso e agora para esses
novos testes a estrutura se mantém né
acho que eu vou só vou dar uma passada
rápida aqui sobre Quais são os planos os
módulos é como que está estruturado ali
dentro do motor falar algumas
características relativas a isso dentro
do diretório também mas vai ser é muito
de novo né um reflexo que o jovan e o
Mor já comentaram aqui basicamente
pegando as especificações e tornando ela
em cenários práticos ali para que as
implementações possam ser testadas e
certificadas né então sobre o que será
testado né é previsto um plano barra
módulo por end Point totalizando 19
módulos no total aqui a gente falando de
comuns produtos e serviços e canais de
atendimento então e acho que para fase
um né diferente de fase dois ou barra
fase 3 onde a gente tem geralmente um
plano por api com 50 70 módulos por
exemplo aqui a gente tem para cada end
Point um um módulo barra plano né então
é um plano com um módulo único onde
Fazendo uma chamada esse módulo
basicamente faz uma chamada no endp que
tá sendo solicitado e valer da resposta
de acordo com Sueg e um ponto
interessante aqui né do que o o Gilvan
comentou é que as validações que a gente
vai fazer dentro disso né existem muito
Muitas características desses Campos que
são voltadas para validações de negócio
e a gente Tecnicamente não tem como
validar isso então aquela questão do sh
fap regulatory required né Por exemplo
eh a gente dentro do motor isso não vai
ser validado porque é uma característica
de negócio dentro de cada de cada uma
das casas não é porque o motor não tá
testando né que é mais uma questão de de
viabilidade técnica que de que isso não
não vai ser necessário então é continua
sendo obrigatório mesmo motor não
validando isso mas todos os campos a
questão de obrigatoriedade de Campos no
sentido de se é um campo obrigatório ele
vai ter que est na resposta se é um
campo opcional ele pode não estar na
resposta e se ele estiver ele tem que
estar no formato específico e os campos
condicionais também então Aqueles Campos
Se for possível fazer uma validação
dentro da própria resposta né então esse
campo ele é ele é obrigatório se esse
outro Campo for um valor x YZ isso
também faz a validação dentro do motor
mas basicamente a estrutura de validação
de cada um dos end points vai ser esse
né um plano com um módulo dentro de cada
um a gente faz a chamada end Point
valida a resposta no retorno eh então
esses testes né eles estão disponíveis
dentro do m de conformidade eu vou
passar aqui todos eles já estão
disponíveis eh deixa eu também colocar o
release Notes aqui no chat para quem
quiser acessar a gente tem relis Notes
também aqui para dados abertos que tem
um resumo de todos esses testes eh e
eles então podem ser executadas dentro
do motor de conformidade e também acho
que Como já é de de praa ali dentro do
diretório no momento do registro do
recurso então quando a gente for
registrar o RL dentro do diretório de
participante para ficar disponível para
todo ecossistema é executado um teste
contra o motor também e você só vai
conseguir registrar o recurso dentro do
diretório caso você consiga passar no
teste né Então a nossa recomendação é
que eh esse teste que tá dentro do motor
de conformidade né uma vez que você
esteja passando no motor você consegue
fazer o registro ali se tiver dentro
outras datas e pontos que o que a Fabia
vai comentar daqui a pouco também n Você
já consegue fazer o registro dele dentro
do diretório né então de maneira geral é
isso né falando sobre os planos em si
como a gente comentou vai ser sempre um
plano barra módulo por end Point então
Eh os eh da da pid comuns ali né a gente
vai ter dois planos módulos porque a
gente tem dois dois end points para p de
produtos e serviços a gente vai ter 12
planos barra módulos porque são seis
produtos e aí cada produto tem um endp
de Business um endp de PF e um end Point
de PJ né basicamente então totalizam 12
módulos canais de atendimento cinco
planos barra módulos de acordo com cinco
end points ali que você tem para canais
de atendimento totalizando ali 19 no
total né a Fabi vou pegar sua tela
rapidinho aqui só pra gente passar pelo
pelo motor bar
noes legal pessoal então sobre primeiro
né o ponto que eu comentei do
da do release Notes release Notes eu
botei o link o link no no chat né todas
as releases que a gente vai fazendo
gente vai colocando aqui as datas caso
tenha algum bug ou algum ISO a ser
corrigido ali para para essas apis a
gente vai tá fazendo tracking aqui pela
página de isos então pela página de isch
que a gente comentou isso em outro
workshops a gente tem sempre Ash tags
relativas às fases tem tem nada aqui
fase um no caso tem um relativo a a uma
melhoria aqui de fase um né então
clicando aqui eu consigo verificar se é
um bug se é impeditivo não é qual é a
melhoria que tem que ser feita esse tipo
de coisa né aqui no caso é para API de
admin mas para essas APS aqui que a
gente tá comentando hoje né de comums
produtos eh e canais não tem nem
melhorias nem bugs você serem corrigidos
né No momento eh essa planilha aqui né a
gente tem uma planilha tá uma csv e
outra num modelo num formato de Excel é
basicamente o resumo ali de quais são os
planos então aqui para quem roda via pi
por exemplo a tem que pegar o plano o
nome dos módulos etc consegue pegar por
aqui então aqui vai ter o nome dos
planos e o nome dos módulos é como eu
comentei né aqui no caso são 20 porque
tem a p de admint também mas até até já
filtrei aqui né mas se eu tirar o filtro
vai ter a p admin também aqui são todas
de fase um que a gente soltou
recentemente todas de de de dados
abertos né E a gente vai ter o nome de
todos os módulos aqui que tem que ser
executados esses módulos como eu
comentei né então no release Notes a
gente tem as datas de release aqui pode
verificar quando que essas essas apis
estão sendo eh disponíveis ali para
ecossistema a gente vai ter a lista de
planos de testes e aqui na página de
isos eu consigo acessar para ver se tem
algum ISO algum erro a ser corrigido ou
levantar um erros se foi identificado
também então esse aqui é o release Notes
que eu coloquei ali dentro do chat
também indo pro Motor agora né todos os
planos eles já tão dentro do do motor de
conformidade um ponto de atenção aqui
que eu acho válido trazer é que no
momento né enquanto a gente tá
eh fazendo a certificação ou seja essa
pi ainda não foi pro golve a gente
precisa permitir que a pi que tá em
produção agora se tiver um novo entrante
por exemplo que ela se certifique né
então vocês vão ver que dentro do motor
a gente tem as versões antigas então a
gente Manteve as versões antigas até a
data do golve e a gente tem as novas
também então acho que ali no momento de
executar os testes só prestar atenção
Qual a versão que tá sendo executada e a
versão ela fica disponível aqui no final
do plano né então aqui por exemplo né
functional test for channels Bas on
swager version Aqui é 1.0.2 aqui é 2.0.0
eh um ponto de atenção que é relativo ao
que engan maí e juvan comentaram também
né Que produtos e serviços eles são
testes
eh eles são testes que foram quebradas
né então antes a gente tinha uma API
deixa eu mostrar aqui né só para ficar
claro acho que o pessoal já mostrou mas
só para reiterar a gente tinha antes né
produtos e serviços uma pi né que é essa
1.0.2 então se eu entrasse eu tinha uma
ap única na versão 1.0.2 com os 12 de
points e agora isso foi quebrado uma
estrutura de produtos né então eu tenho
uma pii de contas que tem uma versão
1.0.0 né então eu tenho a versão antiga
é a 1.0.2 a versão nova É 1.0.0 né e
isso é por justamente porque teve essa
quebra da api daquela API de produtos e
serviços com 12 ind points em um api 1.0
para cada produto ali até para questão
de vamento futuro etc né não precisar
verar tudo ao mesmo tempo mas essa mesma
estrutura tá refletida aqui dentro do
motor né então Eh mais atenção ali com
relação quando for executar os testes
eh para pegar o o correto ali né aquilo
que você quer então aqui embaixo a gente
vai ter products and Services barra tal
né então aqui essas products and
Services bar tal são aquelas antigas e
aqui em cima que é relativa a Beta 2 né
a Beta 1 desculpa que a gente comentou a
gente tem o
business finances api etc né então tudo
que tiver Beta 1 aqui é relativo a essa
nova versão e também ela não tá com
products and Services no começo né
porque aquela P antiga que a gente
mostrou aqui é a p de produtos e
serviços né então o que tiver produtos e
serviços barra 1.0 tá na versão estável
na versão antiga a versão nova é a que
tá em Beta né ainda então aqui por
exemplo eh contas né Tá na beta 2 agora
eh a gente vai mantém isso atualizado
ali dentro do motor também né
eh e aí basicamente só esse cuidado né
para não não acabar executando porque as
duas são 1.0 né um é 1.0.2 ou um 1.0.0
mas são APS diferentes né então a versão
nova é essa que tem a Beta e que não tem
produtos e serviços do lado eh Então
dentro dos planos aqui né não vou passar
por todos porque eles são bem similares
como eu comentei aqui eu tô usando uma
uma url mocada né mas informações que eu
preciso passar aqui aias descrição e
publish né acho que tá bem claro para
todo mundo também o que que é mas acho
que de de fato pro teste rodar seria
Qual que é a URL de recurso ali né O que
que eu quero executar de fato então
coloco ali aqui eu tô usando um exemplo
test vai falhar né porque é um exemplo.
comom aqui e qual que é a sua o seu
organization ID né pra gente poder
atrelar quem depois né posteriormente
quem Qual é a organização que tá
executando qual teste e aí criando o
plano né o plano em si acho que ele é
ele é bem simples como a gente comentou
né aqui também fica disponível qualquer
versão então se você já criou um plano
né tem dúvida qual que é versão isso vai
tá disponível nível aqui também e aí
quando eu clicar para rodar o teste ele
vai executar uma chamada ali no endp
como eu comentei né que eu peguei um
exemplo Dame que que não vai me retornar
uma um valor válido né mas aí ele vai só
fazer uma chamada e a partir dessa
chamada ele começa a validar a resposta
de acordo com aquela estrutura de campo
e se é obrigatório tem que tá lá se é
opcional ele pode não estar mas se ele
tiver ele tem que tá no formato
especificado no Sueg E se ele for
condonal também ele faz o cheque entre
os campos para ver se o campo deveria ou
não estar lá né E aí se você tiver
sucesso aqui e conseguir eh ter todos
esses campos aqui dentro ele vai ele vai
você vai ter um sucesso no teste né
então do que a gente comentou né
primeiro relas noves a lista tá
disponível segundo todos esses módulos
né eles estão disponíveis aqui dentro do
motor ponto para prestar atenção é com
relação a produtos e serviços ali porque
a pi foi quebrada então a gente saiu de
uma 1 a gente saiu de uma v1 e tá numa
v1 ainda né na nova versão mas é
justamente porque teve essa quebra da
estrutura da pi E aí o terceiro ponto
mais mais relativo a a diretório também
né acho que todo mundo tá já tá já tem
esse conhecimento né mas só passando
para ter certeza de que de que se caso
tiver alguém aqui né a gente possa
explicar isso também aqui dentro do
diretório quando a gente fazer o
registro do recurso né então tô dentro
do diretório aqui sandbox do Open
finance eu seleciono aqui authorization
servers seleciono a api os recursos da
api aqui né quando eu for selecionar o
novo aqui dentro né eu vou ter todos os
api Family o Api Family Type eh ou seja
Quais são as apis que eu tô que eu tô
registrando vou pegar por exemplo aqui
né comuns que é Discovery eu consigo
selecionar qual end Point que eu quero e
qual que é a versão que eu quero né E aí
baseado nisso aqui né eu coloco Qual que
é o RL de recurso então naquele caso ali
do teste que a gente mostrou eu botaria
aqui em https 2 p bar
www.exemplo.com e aí eu tentaria Fazer o
registro no momento que eu tentar fazer
esse registro aqui ele vai me avisar que
ele vai rodar um teste de motor de
conformidade se eu tiver de acordo com
isso eu clico ok E aí ele vai demorar
aqui C dependendo do segund de quanto
tempo demorar aqui né basicamente pro
teste vou dar e eu só vou conseguir
fazer o registro se eu tiver sucesso no
teste né então aqui no caso o teste de
certificação foi Não teve sucesso e aqui
ele aparece para mim api eu consigo
através desse link aqui que ele me
informa Verificar também né então eu
consigo ver porque que deu errado esse
teste e aí entrando aqui eu tenho o
teste que rodou lá no
diretório eu consigo ver o por que deu
erro né aqui no caso como a gente
comentou postando uma RL inválida O
teste vai Fer obviamente Mas passando a
ao RL que esteja de acordo que passou no
motor de conformidade não deve ter
nenhum problema aqui para registrar no
diretório porque é exatamente o mesmo
teste que que o diretório roda aqui
contra o motor né então aqui no
diretório quando for fazer esse registro
é selecionar api prestar atenção com com
relação à versão ali o que que vai
entrar e basicamente Fazer o registro da
api vai ter o vai rodar o teste contra o
motor de conformidade e se tiver sucesso
registra ali no diretório né então só
fazendo uma passagem em tudo que a gente
falou né o tes aqui para as apis de fase
um eles têm um plano barra um módulo por
end Point totalizando 19 quando a gente
tá falando de comum produtos serviços e
de
eh
e de comuns produtos e serviços e
de de canag n que a gente tava falando
então totalizando 19 end ponte de todos
eles são 12 de produtos e serviços um
end Point para cada para cada um dos
seus produtos Um para PF um para PJ
são dois de de comuns e são cinco de
canais ali e aí todos eles estão
disponíveis dentro da planilha que tá
aqui dentro do releas Notes então para
quem quiser ter acesso ali ao nome dos
planos ver quais são os planos end
points etc é possível verificar por esse
aqui também que eu já coloquei no chat
aqui pra gente os isos vão ser
acompanhados aqui pela página de isos né
então se tiver algum problema dando
cedic também tudo que aparece pelo cedic
da Cid a gente replica pro pro pro
gitlab aqui então vai est tudo aqui
sempre atualizado com relação a Quais
foram as solicitações de melhoria o que
O que que tem que ser feito etc eh dessa
planilha então como eu comentei tem esse
todos esses módulos os módulos já estão
disponíveis dentro do motor prestar
atenção com relação principalmente a
produtos e serviços porque a gente saiu
de uma v1 e tá indo para uma v1 também
por conta da quebra da estrutura aí só
verificar ali se tem produtos e serviços
ou não no início do nome eh e aí
executar o teste o teste estrutura
simples né para fazer uma chamada valida
a resposta vai ver se o campo é opcional
se ele obrigatório se ele é condicional
Qual que é o tipo se tem pattern tudo
isso né então basicamente faz a
validação do suegra Ali contra a o Jon
que tá sendo retornado ali da api e por
último no registro do diretório né
Depois que eu já tiver compli chegarem
as dadas que a Fabi vai comentar um
pouquinho melhor eh Quando eu fizer o
registro da pi eu vou dar um teste
contra o motor se eu tiver falha eh eu
vou ter esse essa URL aqui se eu tiver
sucesso vai ter o registro E aí lá no
endp data participants eh vai ficar
disponível para todo mundo também
conferir se api entrou lá mas tendo
sucesso a api entrando aqui ela vai
entrar no data participants lá
geralmente acontece dentro de 10 minutos
assim
eh e acho que é isso Fabi Obrigado
pessoal também fico à disposição se
tiver alguma dúvida vou olhando aqui no
chat e e vou respondendo Obrigado
pessoal legal Obrigadão Cris
eh pessoal então até aqui reforçando
essa mensagem que o Cris passou para
vocês agora então aqui a gente teve eh o
que que acontece agora né O que que é
esperado das instituições a partir desse
momento então a gente já teve a
publicação das especificações aí aqui a
gente entra num ciclo de eh
retroalimentação aqui de feedback então
instituições executam os testes nos
Marcos conforme vão desenvolvendo abrem
tickets para feedback eh tanto quando
tem alguma necessidade de correção
alguma melhoria isso é avaliado pelos
grupos técnicos para ver se alguma
necessidade de ajuste na especificação
ou se é alguma necessidade de ajuste no
motor de conformidade a gente atinge a
maturidade publica a versão estável das
apis a versão estável do motor de acordo
com essa última versão das apis E aí é
quando a gente entra no processo de
certificação então que que a gente que
que acontece aqui que que é diferente da
certificação de dados abertos que nem o
Christian Mostrou ela vai acontecer
direto na publicação no diretório então
não tem o processo de precisa executar
os testes pega os logs abre o ticket no
service desk com esses eh com esses logs
Eh aí tem a avaliação técnica assinatura
pelo diret e depois a publicação do
diretório essa parte burocrática ela não
existe paraas apis de dados abertos tá
então ela vai ser assim que a gente
tiver versões estáveis o diretório vai
ser atualizado para permitir a
publicação dessas novas versões e assim
que publicar eh os testes vão rodar ali
no no backend dentro do motor eh as apis
passando eh a publicação é feita as apis
tendo algum problema mensagem de erro
vai aparecer e a a publicação não vai
ser feita tá então aqui a parte mais
importante aqui dessa de diferente das
outras apis é essa mudança aqui no ciclo
de no no modelo da certificação que é
esse modelo automático tá E aí que que a
gente tem de datas aqui então a gente
tem a gente teve a publicação já das
primeiras versões de todas as apis e a
gente já tá com todas as primeiras
versões do motor disponíveis tá então de
comun produtos e serviços e de canais de
atendimento então a última de canal de
atendimento foi disponibilizado na
sexta-feira E aí agora todas as
instituições vão ter que passar em 1/4
dos Testes então em 25% até no dia 8/01
esse cálculo de 25% ele é de acordo com
o que a instituição disponibiliza então
especialmente ali paraa parte de
produtos e serviços que algumas
instituições
eh não tem todos os produtos a gente tem
aqui o registro de todas a das
instituições do de Quais produtos ela
oferece E aí vai ter que passar em 1/4
dos Testes tá de acordo com com o que
cada um oferece
Eh aí aqui a gente tem algumas páginas
alguns links úteis então tem tanto o
portal do desenvolvedor que tem as
especificações das apis a gente tem uma
página de calendários no portal do
desenvolvedor também eh que tem todas
essas datas aqui do cronograma
consolidadas eh tem os inform com as
informações relevantes release Notes que
o Christian mostrou agora eh com a
informação sobre os testes dúvidas sobre
os testes a gente recomenda abertura de
Ticket no gitlab dúvidas Gerais que nem
eu vi aqui no chat dúvidas sobre acesso
problema eh problema ali no no motor de
conformidade ou algum problema com
especificação aí a gente recomenda
abertura pelo service desk mas se
abrirem um não for o canal adequado a
gente dá as devidas orientações tá
pessoal então então no geral o que que é
esperado aqui das instituições próximo
passo passar em 1/4 dos Testes no dia
8/01 depois em metade dos Testes no dia
22 75% no dia 5 de Fevereiro passarem
todos os testes no dia 22 de fevereiro
aí o motor vai ser adequado e o aí a
gente vai lançar versão estável das apis
e versão estável
do versão estável do motor para todo
mundo publicar em produção a os end
points entre nos dias 26 e 27 de
fevereiro
então pessoal eh é isso que a gente tem
aqui mais de de conteúdo então dá um
espaço aqui para dúvidas a gente tá
tentando responder as que vieram pelo
chat mas se alguém quiser levantar a
mãozinha aqui alguma dúvida específica a
gente pode passar por
elas
Sheila
pessoal Bom dia eh eu tenho uma dúvida
eu vi o Acho que foi o mostrando a
questão ali do do diretório dos Testes
que são automáticos
eh a gente aqui passou por um problema
não é não é da fase um é da fase quatro
mas acredito que seja igual a questão
ali do diretório a gente coloca a o RL
ali da api
eh não dá erro ele fica aparecendo com
status selfie alguma coisa que eu não
lembro o nome agora só que quando roda o
automatizado que acho que é pela fvp dá
erro e a gente não tá com erro na api
não sei se vocês já TM algum ticket
sobre isso a gente abriu também é isso
obrigado Ron aparece self certified né E
só que quando roda aqu ele automatizado
pela fvp ele bota um erro lá e a gente
já avaliou que a nossa pi não tava fora
no momento do teste aí não sei se algum
outra instituição já passou por isso
queria entender um pouco se eh é
aparentemente não é um comportamento
esperado né Queria saber se alguém já
passou por isso ou se vocês já viram
algum ticket referente a
isso Sheila é só para para confirmar né
o ponto que você tá falando é quando ele
roda aquela automação de recertificação
né então você registra ele passa e aí
cada semana ali ele ele vai para
provavelmente para reject seria isso
isso exatamente tá
é o que o o que o diretório faz no final
assim ele faz uma chamada no mesmo teste
que foi executado contra aquela mesma
URL né então ele basicamente chama
aquela mesma o mesmo teste pro Motor né
E aí Se tiver ele passa para warn e na
próxima semana ele passa para rejected
Mas se você puder abrir um ticket acho
que você comentou que abriu né se você
puder botar o número do ticket aqui no
chat eu já dou uma olhada aqui para ver
o que que pode ser E aí acho que é mais
fácil olhando lá eu dou uma resposta
para você com mais clarezas se um
problema nosso o que que pode ser o esse
esse problema aí que você comentou ah
perfeito eu coloco sim ele dá um durante
o teste ele dá um erro de Connection
reset E aí ele aí coloca que o teste foi
interrompido só que quando a gente
coloca direto lá no no diretório a RL
ele não dá erro é isso que é estranho tá
é realmente não num comportamento
esperado se você puder botar o o o o
número do ticket no chat eu já dou uma
olhada aqui com o pessoal a gente
responde por lá tá bom obrigada
obada
pessoal Acabei mandando aqui também para
vocês um formulário de feedback no chat
então é o mesmo que a gente mandou na na
sexta-feira se vocês puderem eh
preencher pra gente é muito importante a
gente ter a visão do que tá sendo útil
para vocês se vocês estão sentindo falta
de alguma de alguma informação pra gente
poder ir melhorando aqui pros próximos
tá aqui de período de convivência eh as
apis vão ter assim período de
convivência a questão dos dados a gente
eh das datas a gente manda por informe
para vocês a gente complementa também no
na fac quando a gente for disponibilizar
esse material
tá pessoal então aqui acho eu queria
agradecer a presença de todo mundo
agradecer o pessoal ali do dos grupos
técnicos especialmente aqui dados
abertos qu sandbox eh pessoal grupo de
produtos aqui da rion também então
agradecer a presença de todo mundo
agradecer a presença de de vocês aqui eh
dos participantes também então obrigada
a todos uma ótima semana Eh vamos em
frente qualquer dúvida estamos à
disposição obrigada bom
dia