Step 2. Requesting authorization for given IBAN

Po wywołaniu tworzy się sesja dla danego użytkownika w bazie sql w tabeli:

1select * from ApiSession where userid = 'ExternalUserId'

W kolumnie status zapisany będzie status sesji który aktualizuje się w czasie

Statusy sesji:

W kolumnie Stage, zapisany jest aktualnie wykonywany stage sesji który może przyjmować wartości:

Jeśli na którymś z tych etapów wystąpi błąd, sesja zatrzyma się na tym statusie.

Opis cyklu życia sesji AIS: Session management

W przypadku błędu na którymś z etapów sesji, wypisany będzie w kolumnie FailureMessageId, Id danego logu w mongo, który można znaleźć poprzez zapytanie w MongoDB:

db.getCollection('Nazwa kolekcji’).find({'executionData.logId':’Skopiowane FailureMessageId '}) .sort({date:1}).limit(900)

Następnie kopiujemy z danego loga wartość id z sekcji executionData.id i wklejamy do zapytania w MongoDB:

1db.getCollection(Nazwa kolekcji').find({'executionData.id':’Skopiowane id z kroku wcześniej’}) .sort({date:1}).limit(900)

Logi podczas inicjacji autoryzacji można znaleźć od razu poprzez:

1db.getCollection(‘Nazwa kolekcji’).find({'message':/.*authorize:*/i, 'details.call.body.scope_details.consentId':’ConsentId’})

ID Consentu możemy znaleźć np. w tabeli sql :

1select * from psucredentials where userid = ''

Z takiego logu z mongo możemy wyciągnąć executionData.id i znaleźć całe wywołanie :

1db.getCollection(‘Nazwa kolekcji').find({'executionData.id':’Skopiowane id z kroku wcześniej’}) .sort({date:1}).limit(900)

W takim logu należy na początku zweryfikować jaki poszedł :call do banku i jaki :response nam zwrócili.

Analiza będzie wymagała weryfikacji podanych informacji w callu, a także status consentu klienta, statusu sesji oraz response z banku.

Takie akcje można znaleźć poprzez

1db.getCollection(‘Nazwa kolekcji’).find({'message':/.*token:*/i, 'details.call.body.scope_details.consentId':’ID Consentu'})

Z takiego calla można wyciągnąć correlationId i wykorzystać go do znalezienia :call i :response lub executionData.id

Wykorzystując :

1db.getCollection(Nazwa kolekcji').find({'details.correlationId':’Skopiowane correlation id z kroku wcześniej’}) .sort({date:1}).limit(900)

lub

1db.getCollection(‘Nazwa kolekcji').find({'executionData.id':’Skopiowane id z kroku wcześniej’,’message’:/token/i}) .sort({date:1}).limit(900)

Po tym kroku w bazie mongo consent dla danego klienta powinien mieć już status Confirmed

Możemy go znaleźć w mongo w kolekcji Consent

1db.getCollection('Consent').find({_id:UUID("ID consentu")})

Jeśli poprzednie punkty zakończyły się powodzeniem, następuje strzał o szczegóły kont

Step 5. Get account details

W danym executionData.id możemy wyszukać call'e i responsy:

1db.getCollection(‘Nazwa kolekcji').find({'message':/.*getAccount*/,'executionData.id':executionData id'})

Tutaj możemy zobaczyć dla jakich rachunków poleciał request o informacje o kontach i co zwrócił bank (w celu weryfikacji danych)

Możemy zmodyfikować wcześniejsze zapytanie i użyć w ramach danego executionData.id:

1db.getCollection(Nazwa kolekcji’).find({'message':/.*getTransaction*/,'executionData.id':wkleić executionData.id'})

Po poprawnie zagregowanych transakcjach następuje wypchnięcie danych do CBT, w ramach executionData.id możemy wyfiltrować takie wiadomości poprzez:

1db.getCollection('Nazwa kolekcji’).find({'logger':/push/i, 'executionData.id':’wkleić executionData id’ }).sort({date:-1}).limit(500)

Po tym kroku należy zweryfikować co przyszło do CBT / ewentualnie w razie problemów zbadać strukturę danych

Każde zapytanie można sobie dodatkowo filtrować poprzez dodanie dowolnej wartości takich jak np.:

1db.getCollection(‘Nazwa kolekcji').find({'executionData.id':’Skopiowane id z kroku wcześniej’,level:’Error’}) .sort({date:1}).limit(900)

Należy pamiętać że przy zgłaszaniu błędów dla BanqUP zawsze należy wysłać pełny trace po executionData.id.

Tylko tego typu dane zapewnią nam pełny zestaw logów. Jako informacja do logów musi zostać podjęta analiza, na jakim etapie w nawiązaniu do powyższych kroków wystąpił ewentualny błąd. Jaki był call z aplikacji APIHUB a jaki response od ASPSP.

Dodatkowo, gdyby problem był ze zgodami należy podesłać logi z bazy Consent w mongo wyfiltrowane dla danego użytkownika.

Przydatne tabele w LDS do analizy problemów: