Lista zrealizowanych zmian i rozszerzeń
Streaming danych o rachunkach
Streaming danych o transakcjach
Streaming informacji że wszystkie transakcje dla danego konta zostały już wysłane
Streaming danych o zgodach
Streaming danych o rachunkach i transakcjach
Wiadomość o dodaniu/aktualizacji konta wysyłana jest po tym jak konto zostanie dodane do bazy danych.
Za każdym razem, gdy konto jest synchronizowane wysyłane jest pojedyncze zdarzenie.
Za każdym razem, gdy transakcja jest synchronizowana wysyłane jest pojedyncze zdarzenie.
Z powyższych wynika, że możliwe są zduplikowane wiadomości, w wypadku, gdy nie było zmian na obiekcie a został ponownie pobrany.
Wiadomości nie są grupowane w żaden sposób po stronie banqUP, jedna wiadomość - jeden fakt.
Każdy event zawiera kompletny zestaw informacji o encji opisany JSON'ami poniżej.
Każdy obiekt ma unikalny identyfikator, który pozwoli łączyć fakty dotyczące jednej encji, tak więc zakładamy, że duplikaty nie są problemem.
W przypadku banku Citi Handlowy konta wysyłane są w zmodyfikowany sposób.
Gdy flow jest z odmaskowywaniem ibanów to wiadomość leci 2x. Za pierwszym razem idzie wiadomość jak w poniższym jsonie, a wartość pola operation = “Created”, a IBAN jest zamaskowany (PLxxxx1234). Drugia wiadomość przyjmue wartość pola operation = “Updated”, apole iban jest już normalnym IBANem z odmaskowanymi x’ami.
Gdy flow jest bez odmaskowywania IBAN, wiadomość leci 1x jak w jsonie poniżej, a IBAN jest zamaskowany (PLxxxx1234).
W tym momencie każde zdarzenie wysyłane będzie raz, nie ma możliwości manualnego ponowienia, nie ma możliwości weryfikacji czy każde zdarzenie zostało poprawnie przeprocesowane.
Dodatkowo obiekt obudowany jest w pola wygenerowane przez framework do pracy RabbitMQ o nazwie MassTransit. Payload będzie częścią wiadomości masstransitowej zawierającej także metadane - payload znajdował się będzie w propce "message".
Wiadomości będą zwracane w formacie JSON – ich struktura wraz z opisem znajduje się poniżej.
! – obowiązkowe
? – mogące przyjmować wartość NULL
Struktura komunikatu dla account
Wiadomości będą spływać na kolejkę podłączoną do exchange: Psd2Hub.Services.PushService.Models.Finat.Streaming.Accounts:AccountMessage
zawiera zmianę: https://bankup.atlassian.net/jira/servicedesk/projects/FIN/queues/custom/195/FIN-500
1{ 2 "data": { 3 "id": 1!, 4 "balances": { 5 "closingAvailable": { 6 "currency": "string"!, 7 "date": "2021-01-05T12:05:19.876Z"!, 8 "value": 1.0! 9 }, 10 "closingBooked": { 11 "currency": "string"!, 12 "date": "2021-01-05T12:05:19.876Z"!, 13 "value": 1.0! 14 }, 15 // potencjalnie także "expected", "forwardAvailable", "information", "interimAvailable", "interimBooked", "openingAvailable", "openingBooked", "previouslyClosedBooked", "other" 16 }, 17 "bankSwiftCode": "string"!, 18 "currency": "string"!, 19 "holderInformation": { 20 "nameAddress": "string"?, 21 "relations": [ // tablica może być pusta 22 "owner", 23 "borrower", 24 "guarantor", 25 "proxyOwnerGeneral", 26 "proxyOwnerSpecial", 27 "proxyOwnerAdministrator", 28 "proxyOwnerUser", 29 "beneficiary", 30 "trustee", 31 "other" 32 ]? // w przypadku braku przesyłana jest pusta tablica, nie null 33 }, 34 "holderType" : "string"?, // enum: individual, corporation <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 35 "isBusiness" : bool?, // flaga, true dla business, false dla retail <<<<<<<<<<<<<<<<<<<<<<<<< 36 "iban": "string"!, 37 "name": "string"?, 38 }, 39 "embedded": { 40 "user": { 41 "id": "string"!, 42 "businessContext": "individual/business"! 43 } 44 }, 45 "meta": { 46 "timestamp": "2021-01-05T12:05:19.876Z"! 47 "traceId": "debf5d7c-91e1-4ae3-aadc-ce938c6b1df4", 48 "operation": "string"! (created/updated) 49 "initiator": "string"!, (user/backgroundTask) 50 "timestamp": "date" ! ("2021-12-01T13:22:51.1872686Z"), 51 "buildId": "string"!, 52 "containerId": "string"!, 53 } 54}
data.balances: słownik Balance types
data.holderInformation.relations - słownik PSU relation type (PL)
"data.holderType" - enum: individual, corporation". Typ posiadacza rachunku, tak jak zwrócony przez ASPSP (firma, Klient indywidualny). Zgodnie z PL API: Rodzaj posiadacza rachunku: osoba fizyczna lub osoba prawna / Account holder type: individual person or corporation (
“data.isBusiness" - flaga czy konto biznesowe czy nie - true/false - tutaj oznaczane jest to przez APIHub na podstawie typu produktu.
"embedded.user.businessContext" - individual/business - kontekst usera nadawany przy jego tworzeniu w APIHub. Ten kontekst jest wykorzystywany na przykład w sytuacji kiedy dane ASPSP oferuje różne API/linki do SCA dla kont firmowych i indywidualnych. (*). Domyślna wartość to individual.
(*) jest możliwa sytuacja kiedy user biznesowy (embedded.user.businessContext" = business) doda konto indywidualne (data.isBusiness = false)
Struktura komunikatu dla transaction
Wiadomości będą spływać na kolejkę podłączoną do exchange: Psd2Hub.Services.PushService.Models.Finat.Streaming.Transactions:TransactionMessage
1{ 2 "data": { 3 "accountingDate": "string"?, //data ksiegowania transakcji, zwracana jako UTC, np 2021-01-05T13:52:12.180Z 4 "afterTransactionBalance": decimal?, //saldo po transakcji, np. 1.15 5 "amount": decimal!, // kwota, np 1.15 6 "currency": "string"?, //waluta konta, np “PLN” 7 "effectiveDate": "string"?, //data dokonania transakcji, zwracana jako UTC, np "2021-01-05T12:05:19.876Z" 8 "endToEndId": "string"?, //pole związane jest z PIS - pozwala skorelować payment zlecony PISem z transakcją pobraną AISem 9 "id": "string"!, //identyfikator systemu BUP 10 "recipient": { 11 "accountIdentifier": { 12 "type": "string"!, // typ identyfikatora, np “iban” 13 "value": "string"? // identyfikator, np “PL27114020040000300201355387” 14 }?, 15 "address": "string"?, //adres odbiorcy płatności 16 "name": "string"? //nazwa odbiorcy płatności 17 }, 18 "sender": { 19 "accountIdentifier": { 20 "type": "string"!, 21 "value": "string"? 22 }?, 23 "address": "string"?, 24 "name": "string"? 25 }, 26 "status": "string"!, //status transackji, mozliwe wartości: unauthorised, confirmed, added, booked, done, pending, rejected, cancelled, scheduled, hold, other 27 "title": "string"? // tytuł przelewu 28 }, 29 "embedded": { 30 "account": { // konto dla którego zagregowano transakcje 31 "id": int!, //identyfikator systemu BUP 32 "iban": "string"! // nr IBAN konta 33 }, 34 "user": { 35 "id": "string"!, //identyfikator systemu BUP 36 "businessContext": "string"! //informacja, czy user został utworzony jako osoba prywatna czy firma - możliwe wartości: “individual”, “business” 37 } 38 }, 39"meta": { 40 "buildId": "string"!, //identyfikator paczki - nr buildu z systemu BUP, np 20201130.4 41 "containerId": "string"!, // nazwa komponentu który generuje wiadomość - identyfikator kontenera, np “e1f64b0a5f32” 42 "operation": "string"!, //informacja, czy to pierwsza agregacja czy aktualizacja; mozliwe wartości: created, updated 43 "initiator": "string"!, // informacja o tym czy zdarzenie zostało wygenerowane z powodu akcji użytkownika czy jako akcja w tle; mozliwe wartości: “user”, “backgroundTask” 44 "timestamp": "string"! //data zdarzenia, zwracana jako UTC, np "2021-01-05T12:05:19.876Z" 45 } 46}
Struktura komunikatu dla ostatniej zagregowanej transakcji dla danego konta w danej sesji
Wiadomości będą spływać na kolejkę podłączoną do exchange: Psd2Hub.Services.PushService.Models.Finat.Streaming.Session:SessionFinishedMessage
jest to mechanizm rejestrujący informację o id ostatniej zagregowanej transakcji dla danego konta w danej sesji
komunikat jest wysyłany na kolejkę RabbitMQ - po 1 szt oddzielnie dla każdego konta
1{ 2 "data": { 3 "id": "string"!, <<<<<<<<<<<<<<<<<<<<<<<<< id ostatniej transakcji zagregowanej dla tego konta w tej sesji 4 }, 5 "embedded": { 6 "account": { 7 "id": 1!, 8 "iban": "string"! 9 }, 10 "user": { 11 "id": "string"!, 12 "businessContext": "individual/business"! 13 }, 14 "session": { 15 "id": "string"!, 16 "externalId": "string"? 17 } 18 }, 19 "meta": { 20 "buildId": "string"!, 21 "containerId": "string"!, 22 "initiator": "user/backgroundTask"!, 23 "timestamp": "2021-01-05T12:05:19.876Z"! 24 } 25}
Streaming danych o zgodach (consent)
Wiadomości będą spływać na kolejkę podłączoną do exchange: Psd2Hub.Services.PushService.Models.Finat.Streaming.Consents:ConsentMessage
Zdarzenie na utworzenie zgody jest wysyłane po jej potwierdzeniu przez użytkownika w procesie SCA i po uzyskaniu przez nią statusu 'Confirmed" w APIHUB oraz przypisaniu do niej kont. Cykl życia zgody opisany jest tutaj: Consent management
Zdarzenie na odwołanie/wygaśnięcie zgody po stronie ASPSP jest wysyłane, gdy APIHub otrzyma z ASPSP informację o zaprzestaniu honorowania zgody, w wyniku czego w systemie BUP otrzyma ona status 'Invalid'.
Uwaga: W większości przypadków ASPSP nie zwracają klarownej informacji o przyczynie nieważności zgody, tym samym nie będzie możliwe jasne rozróżnienie przyczyn jej wygaśnięcia po stronie ASPSP. W wysyłanej wiadomości w polu 'invalidationInfo.reason' przekazany zostanie powód przypisywany przez system BUP na podstawie otrzymanego błędu, w większości przypadków będzie to generyczne 'Expired'
Kod i wiadomość błędu z ASPSP, w efekcie którego zgoda została zinwalidowana po stronie APIHub, o ile dostępny, przekazany zostanie w polu 'invalidationInfo.description'.
Zdarzenie na usunięcie zgody poprzez wywołanie endpoint'u DELETE consent lub DELETE bankaccount jest wysyłane po zakończeniu procesu usuwania zgody i powiązanych z nią danych.
W takim wypadku w 'data' zostanie zwrócony ostatni snapshot zgody przed usunięciem, a w polu 'operation' zostanie zwrócona wartość 'deleted'.
Uwaga: BC: nazwa pola zostanie zmieniona na ‘operation’ by lepiej oddawać jego charakter
Każde zdarzenie wysyłane będzie raz, nie ma możliwości manualnego ponowienia, nie ma możliwości weryfikacji czy każde zdarzenie zostało poprawnie przeprocesowane.
Dodatkowo obiekt obudowany jest w pola wygenerowane przez framework do pracy RabbitMQ o nazwie MassTransit
Payload będzie częścią wiadomości masstransitowej zawierającej także metadane - payload znajdował się będzie w propce "message".
Struktura komunikatu dla consent
! – obowiązkowe
? – mogące przyjmować wartość null
1{ 2"data": { 3 "id": "string"!, //identyfikator zgody w systemie BUP 4 "externalId": "string"? //zewnętrzy identyfikator zgody 5 "bankSwiftCode": "string"!, // identyfikator swift code banku, np "BREXPLPW", 6 "status": "string"! // aktualny status zgody, np "invalid", 7 "previousStatus": "string"! // poprzedni status zgody, np "confirmed", 8 "invalidationInfo": { 9 "description": "string"!, // treść błędu z ASPSP 10 "invalidated" : "string"!, // data zinwalidowania zgody w systemie BUP, zwracana jako UTC, np "2021-01-05T12:05:19.876Z" 11 "reason" : "string"!// powód zinwalidowania zgody w systemie BUP, np."Expired" 12 }?, 13 "scope" : "string" // scope zgody, "Ais" lub "Pis" 14 }, 15"embedded": { 16 "user": { 17 "id": "string"!, //identyfikator usera nadany przez FIN - externalId w systemie BUP 18 "businessContext": "string"! // kontekst biznesowy użytkownika, np "individual" 19 }, 20"accounts": [ 21 { 22 "currencyCode": "string"? //np "EUR", 23 "iban": "string"? //np "PLxxxx", 24 "id": int! // np 1234 25 }!, 26 { 27 etc. 28 }? 29]?, 30}, 31"meta": { 32 "buildId": "string"!, //identyfikator paczki - nr buildu z systemu BUP, np 20201130.4 33 "containerId": "string"!, // nazwa komponentu który generuje wiadomość - identyfikator kontenera, np "e1f64b0a5f32" 34 "operation" :"string"!, //informacja, czy to pierwsza agregacja, aktualizacja czy deagregacja; mozliwe wartości: created, updated, deleted 35 "initiator": "string"!, // informacja o tym czy zdarzenie zostało wygenerowane z powodu akcji użytkownika czy jako akcja w tle; mozliwe wartości: "user", "backgroundTask" 36 "timestamp": "string"! //data zdarzenia, zwracana jako UTC, np "2021-01-05T12:05:19.876Z" 37 } 38}
data.status - słownik : Consent management
data.previousStatus - słownik: Consent management
Struktura komunikatu dla strzałów do ASPSP
Wiadomości będą spływać na kolejkę podłączoną do exchange: Psd2Hub.Services.PushService.Models:AspspCall
! – obowiązkowe
? – mogące przyjmować wartość null
1{ 2 "message": { 3 "bankSwiftCode": "string"!, // identyfikator swift code banku, np "BREXPLPW", 4 "endpointUrl": "string"!, // adres url na jaki został wykoany strzał z APIHUB np : "https://id.openapi.sandbox.bankmillennium.pl/v2_1_1.1/auth/v2_1_1.1/authorize", 5 "errorResponseContent": "string" ? // Wiadomość jaka została zwrócona przez ASPSP w przypadku błędu 6 "exception": "string" ? // Wewn. błąd z APIHUB jako poleciał na response od ASPSP 7 "initiator": "string"!, // informacja o tym czy zdarzenie zostało wygenerowane z powodu akcji użytkownika czy jako akcja w tle; mozliwe wartości: "user", "backgroundTask" 8 "requestContext": "string"! // typ strzału np. "RetrieveScaUrl", 9 "requestDuration": "date", // czas jaki trwał od wysłania requestu do uzyskania response np.: "00:00:00.0143177", 10 "session": { 11 "externalId": "string"? //zewnętrzy identyfikator sesji nadany przez klienta 12 "id": "string"! // wewn. identyfikator sesji nadany przez APIHUB 13 }, 14 "statusCode": int! // http status code np: 200 15 "user": { 16 "externalId": string? // zewn. identyfikator usera nadany przez klienta np.: "regression_AISP_BIGBPLPW_2021-12-03T10:35:37.028Z", 17 "id": "string"! // wewn. identyfikator usera nadany przez APIHUB"56b62fe5-9a2b-4927-aab1-e2a0f4da590d" 18 }, 19 "timestamp": "string"! //data zdarzenia, np. "2021-12-03T10:35:51.727948Z" 20 "executionId": "String"! // trace id dla zidentyfikowania w logach danego strzału np.: "c3b8e8af-f468-462d-98ab-416e404ae5fe", 21 "containerId": "string"!, // nazwa komponentu który generuje wiadomość - identyfikator kontenera, np “e1f64b0a5f32” 22 "buildId": "string"!, //identyfikator paczki - nr buildu z systemu BUP, np 20201130.4 23 } 24} 25
Diagnostyka
opisane tutaj: Diagnostyka streamingu