Project

General

Profile

Bug #2918

DIBS ved lang betalingstid - FBS fejler

Added by Steen Larsen almost 2 years ago. Updated over 1 year ago.

Status:
Needs analysis
Priority:
High
Assignee:
Target version:
Estimated time:
URL med eksempel:
Kategorier:
Min konto - Mellemværende

Description

Når DIBS kalder ddbcms (callback) vil der først blive foretaget et kald til FBS og hvis dette går godt gennemføres kaldet (capture) til DIBS.
Går dette også godt kvitteres med et ok så DIBS gennemfører / hæver beløbet.

I visse tilfælde er FBS lang tid om at svare og ddbcms giver op og der kommer en timeout (i drupal).
Resultatet er at betalingen fejler (når rettelsen i #2364 er implementeret)
Dagen efter vil der blive sendt en mail med de relevante oplysninger (sag #805 med udvidelsen i #2577)

Og man kan nu finde betalingen i FBS og betalingen i DIBS og ordne sagen manuelt.


I visse tilfælde er betalingen i FBS alligevel gennemført og det ikke fordi låneren efterfølgende prøver igen.
Det sker også men kigger man i DIBS rapporterne viser det ikke at regningsnummeret er betalt (desværre viser FBS ikke det konkrete brugte orderID).
Men processen sættes i gang ved kaldet til FBS men afbrydes ikke blot fordi ddbcms giver op (hvilket er normal procedure med client-server kald)


Et forsøg på en løsning er at kaldene får ekstra tid - at timeout sættes op.

To ting:

  • Skal det være en global ændring i alle kald til FBS (det tror jeg ikke)
  • Hvilken grænse har DIBS-serveren (i det oprindelige callback til ddbcms) (det undersøger jeg)

 


Related issues

Related to DDB CMS - Bug #3435: Fejl i betaling (måske sammenhængende med #2918?)Closed
Related to DDB CMS - Bug #3589: Bruger kan ikke logge ind pga. FBS-kald timer ud - KASPER SKAL SE PÅ NEW RELICNeeds analysis

History

#1 Updated by Rolf Madsen almost 2 years ago

  • Status changed from New to Need more info
  • Assignee set to Steen Larsen
  • Priority changed from Normal to High
  • Target version set to Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1)

Tak for det Steen!

Vi afventer din undersøglese.

#2 Updated by Pernille Kirsten Wuttke almost 2 years ago

Rolf Madsen skrev:

Tak for det Steen!

Vi afventer din undersøglese.

 

Hej,

Jeg ved ikke, om dette hører til her, men det er pt. ikke muligt at betale på testsitet, da OrdreID ikke er unikt ifølge fejlmeddelelesen. Skal/kan vi sætte noget op for at teste eller skal vi vente, til vi er i produktion? Da vi overgik til DDB CMS, var der lidt knas med opsætning af DIBS, da det influerede på andre services, herunder vores printsystem, som ikke kunne håndtere, at vi indsatte en MD5-kontrol. Vi vil naturligvis helst teste det FØR vi går over.

Vh Pernille W

#3 Updated by Steen Larsen almost 2 years ago

Nej, din manglende test skyldes forkert opsætning

Sæt et passende prefix og orderID under indstillinger - det gælder om at prefix+orderId ikke "rammer" nogle af de tidligere brugte id'ere i DIBS så langt tilbage som DIBS nu gemmer oplysningerne. OrderID tæller op med én ved hver betaling.

Disse indstillinger er på samme side hvor du skal indsætte MD5-nøglerne i sektionen "Indstillinger for Orderid".

Jeg bruger P1 på produktion og S1 på staging/test-server og så et passende stort orderid (da vi skiftede til FBS) så alle oprettede numre derved bliver nye hos os.

#4 Updated by Pernille Kirsten Wuttke almost 2 years ago

Steen Larsen skrev:

Nej, din manglende test skyldes forkert opsætning

Sæt et passende prefix og orderID under indstillinger - det gælder om at prefix+orderId ikke "rammer" nogle af de tidligere brugte id'ere i DIBS så langt tilbage som DIBS nu gemmer oplysningerne. OrderID tæller op med én ved hver betaling.

Disse indstillinger er på samme side hvor du skal indsætte MD5-nøglerne i sektionen "Indstillinger for Orderid".

Jeg bruger P1 på produktion og S1 på staging/test-server og så et passende stort orderid (da vi skiftede til FBS) så alle oprettede numre derved bliver nye hos os.

Tak for hurtigt svar. Ja, det regnede jeg også med. Men mener du, at du som prefix bruger P1 / S1 eller hvor indsætter du det? Skal vi indsætte samme nøgler i testsitet også? Der gik som sagt noget galt sidst, da vores printsystem ikke kunne håndtere MD5-kontrollen og derfor vil jeg gerne være 101% sikker.

Vh Pernille

#5 Updated by Steen Larsen almost 2 years ago

https://platform.dandigbib.org/projects/ddb-cms/wiki/_Konfiguration_fra_A-Z#Administration-indstilling-af-DIBS-betalingsservice er beskrevet hvor.

Prefix kan være næsten hvad som helst - i vejledningen står at det skal være biblioteksnummer (der står ikke hvorfor) men det kan evt. kombineres med unikke tegn så man adskiller test/produktion og nye/gamle numre.

#6 Updated by Pernille Kirsten Wuttke almost 2 years ago

Steen Larsen skrev:

https://platform.dandigbib.org/projects/ddb-cms/wiki/_Konfiguration_fra_A-Z#Administration-indstilling-af-DIBS-betalingsservice er beskrevet hvor.

Prefix kan være næsten hvad som helst - i vejledningen står at det skal være biblioteksnummer (der står ikke hvorfor) men det kan evt. kombineres med unikke tegn så man adskiller test/produktion og nye/gamle numre.

 

Tak. Det kan være, at vi vælger et andet prefix, når vi går over, for pt. kommer alle OrdreID ud som 714700 i et andet system, som vores sekretariat bruger - i DIBS-rapporterne, kan vi dog heldigvis finde relevante info, men det er lidt irriterende. Men for lige at være sikker: hvor taster du så P1 og S1 ind? Og kan jeg undlade MD5-kontrol eller blot indtaste samme nøgler i testsitet?

Vh P

#7 Updated by Steen Larsen almost 2 years ago

Hvis man benytter samme konto i DIBS til forskellige systemer er det rigtigt fint (vil jeg mene) at have forskellige prefix - det eneste krav fra DIBS/DDBCMS side er at prefix+orderid er unikke.
Gå ind på urlen ovenfor og søg efter " Indstillinger for ordre ID " - jeg kan nok ikke forklare det anderledes.

#8 Updated by Pernille Kirsten Wuttke almost 2 years ago

Steen Larsen skrev:

Hvis man benytter samme konto i DIBS til forskellige systemer er det rigtigt fint (vil jeg mene) at have forskellige prefix - det eneste krav fra DIBS/DDBCMS side er at prefix+orderid er unikke.
Gå ind på urlen ovenfor og søg efter " Indstillinger for ordre ID " - jeg kan nok ikke forklare det anderledes.

 

Ok. Jeg må prøve mig frem - det har jeg også gjort før, det er bare så tidskrævende, hvis der sker fejl, og jeg kunne ikke helt huske, hvad jeg satte ind. Tak. Vh P

#9 Updated by Rolf Madsen over 1 year ago

  • Target version changed from Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1) to Release 29-2 - Bugfixes (7.x-4.5.0)

#10 Updated by Rolf Madsen over 1 year ago

  • Status changed from Need more info to Needs analysis
  • Target version changed from Release 29-2 - Bugfixes (7.x-4.5.0) to Release 29-2 - Bugfixes (Needs analysis)

#11 Updated by Steen Larsen over 1 year ago

Jeg havde lavet en ændring således at kaldet til FBS fik 60 sek og det virkede nogenlunde, men der opstod stadig fejl.
Det kunne dog være fejl pga utilgængelighed og så er timeout jo ligegyldig.

I release 1.9.2 (9. feb) findes denne rettelse "Unnecessary call to OpenSearch when receiving external payments (DDB-CMS) " - tja, det giver jo vældig god mening IKKE at hente marcposterne når man blot ønsker at betale (sic!).

I 2018 har der være 12 fejl fordelt over 8 dage og heraf har der været 3 efter 9. feb.

Jeg sætter nu timeout til 30.0 (standardværdien) så lad os se hvad der er af fejl i løbet af næste måned.

Og derefter beslutte hvad der skal ske med sagen på det tidspunkt.

 

#12 Updated by Rolf Madsen over 1 year ago

Tak for det Steen!

#13 Updated by Rolf Madsen over 1 year ago

  • Related to Bug #3435: Fejl i betaling (måske sammenhængende med #2918?) added

#14 Updated by Rolf Madsen over 1 year ago

  • Target version changed from Release 29-2 - Bugfixes (Needs analysis) to Release 33 - Bugfixes

#15 Updated by Rolf Madsen over 1 year ago

  • Related to Bug #3589: Bruger kan ikke logge ind pga. FBS-kald timer ud - KASPER SKAL SE PÅ NEW RELIC added

#16 Updated by Rolf Madsen over 1 year ago

  • Assignee changed from Steen Larsen to Simon Holt

Kan rettelsen i https://platform.dandigbib.org/issues/3589#note-11 også være løsningen på dette issue?

NB. Tilsvarende spørgsmål i de to andre issues.

Also available in: Atom PDF