Buongiorno,
avrei necessità di chiarimenti in merito al gestione del KO della primitiva nodoInviaCarrelloRPT.
Response OK : a fronte di una response positiva da parte del nodo, l’utente verrà indirizzato sul portale del WISP tramite l’URL indicato che è associato al carrello inviato; in questo caso, per assegnare uno stato alla RPT bisogna invocare la primitiva nodoChiediStatoRPT? In caso contrario, deve esserle assegnato uno stato ulteriore non previsto dalla Tabella 35 ( ad esempio l’esito restituito dal portale ?
Response KO : a fronte di una response negativa da parte del nodo, si evince dalla documentazione che la strategia di gestione dell’indeterminatezza dello stato della RPT a fronte del KO prevede di invocare la primitiva nodoChiediStatoRPT.
Il dubbio è relativo al fatto che:
la primitiva viene chiamata per ogni singola RPT facente parte del carrello;
se la response è OK, viene restituito l’URL a cui eventualmente reindirizzare l’utente per quella RPT;
Di conseguenza, se ricevo n response per le n RPT che facevano parte del carrello, avrò per tutte in risposta lo stesso URL, e verranno quindi pagate tutte insieme? Come faccio a verificarlo? Se inoltre solo per una parte di esse mi venisse restituito l’URL, l’utente potrebbe pagare solo una parte del carrello?
gli stati della RPT indicati dalla specifica sono quelli individuati per il workflow di gestione da parte del Nodo dei Pagamenti che sicuramente troverai necessità di arricchire con gli stati di gestione dell’EC.
Come punto di riflessione posso dirti come abbiamo realizzato la gestione in GovPay dove abbiamo cercato di limitare il più possibile le interazioni con i servizi pagoPA:
Response OK : a fronte di una response positiva da parte del nodo, l’utente verrà indirizzato sul portale del WISP tramite l’URL indicato che è associato al carrello inviato; in questo caso, per assegnare uno stato alla RPT bisogna invocare la primitiva nodoChiediStatoRPT? In caso contrario, deve esserle assegnato uno stato ulteriore non previsto dalla Tabella 35 ( ad esempio l’esito restituito dal portale ?
Alla creazione di una RPT, indipendentemente dalla modalità di pagamento, impostiamo lo stato RPT_ATTIVATA. Al momento della spedizione, in caso di esito positivo del Nodo, le RPT transitano in stato RPT_ACCETTATA_NODO.
Response KO : a fronte di una response negativa da parte del nodo, si evince dalla documentazione che la strategia di gestione dell’indeterminatezza dello stato della RPT a fronte del KO prevede di invocare la primitiva nodoChiediStatoRPT .
Il dubbio è relativo al fatto che:
la primitiva viene chiamata per ogni singola RPT facente parte del carrello;
se la response è OK, viene restituito l’URL a cui eventualmente reindirizzare l’utente per quella RPT;
in caso di risposta negativa lo stato non e’ indeterminato, ma puoi impostarlo ad RPT_RIFIUTATA_NODO, stato terminale di gestione della RPT.
Di diversa gestione è invece il caso di errori di rete, per cui non si sa se la RPT è stata ricevuta o meno dal Nodo. In questo caso lasciamo le RPT in stato RPT_ATTIVATA ed il batch che gestisce la strategia di recupero si occuperà di verificarne l’effettivo stato sul Nodo ed eventualmente ritentarne la spedizione.
Ti confermo, che utilizzando la primitiva nodoInviaCarrello, la URL restituità inizielizzerà il WISP per il pagamento di tutto il carrello, non sarà possibile procedere sul WISP al pagamento parziale del carrello.
La composizione del carrello è una delle attività che l’utente dovrà fare sul portale dell’Ente.
@nardil grazie per la risposta dettagliata!!! Prenderò spunto
Un dubbio mi rimane: devo quindi selezionare tra i faultCode restituiti quelli che indicano errori di rete e gestirli con la chiamata al nodo per conoscere lo stato della RPT?
@Mario_Gammaldi grazie! Se posso, quello che vorrei sapere è come vengono gestite le n chiamate e le response alla primitiva nodoChiediStatoRPT
In caso di errori di rete o più in generale di errori non previsti dalla specifica (eg. connection timeout) non hai un faultBean in risposta (puoi non avere nemmeno una risposta). Quando invece hai un faultBean, la RPT è stata sempre rifiutata. Eventualmente devi trattare con una politica particolare i casi di PPT_RPT_DUPLICATA e PPT_SUPERAMENTOSOGLIA, nel primo caso condiderando la RPT già consegnata in un tentativo precedente, mentre nel secondo di schedulare la spedizione in un secondo momento.
Buongiorno @nardil ,
volevo condividere un dubbio in merito al confronto su questa tematica.
A livello logico sono d’accordo sull’impostare degli stati alla RPT e quindi al pagamento in maniera automatica in caso di faultCode o esito OK. Tuttavia, ragionandoci, per le RPT alcuni stati che assumono sul nodo condizionano il riuso o meno dello IUV. Di conseguenza, non si dovrebbe usare la primitiva nodoChiediStatoRPT per poter gestire questi casi? Altrimenti si rischia di non considerarli.
I dati del faultBean riportano il motivo del rifiuto (faultBean.faultCode) ed il soggetto che ha rifiutato (faultBean.id) che dovrebbero risultarti sufficienti a dedurre lo stato apportuno da associare alla RPT.
Detto questo, è comunque possibile anche utilizzare l’approccio che suggerisci.
