Integrazione servizio Avviso Digitale about govpay HOT 25 CLOSED

Ciao @ivan86to

suggerirei di gestire l'attivazione della funzione di avvisatura anche come configurazione a livello di dominio (default true)

Da un punto di vista implementativo e' necessario intervenire in tutte le funzioni che intervengono sull'archivio dei pagamenti in attesa, interno o remoto:

1. GpCaricaVersamento (alimentazione archivio pagamenti in attesa interno)
2. GpGeneraIUV (generazione IUV centralizzata per alimentazione archivio pagamenti in attesa remoto)
3. GpCaricaIUV (generazione IUV remota)

Nella gpCaricaVersamento i dati ci sono piu' o meno tutti. Deve essere aggiunta la data scadenza avviso a livello di versamento e la tassonomia nei dati del tributo a livello di singolo versamento. La tassonomia deve essere anche configurabile nell'anagrafica tributi, cosi da poter essere censita
Per quanto riguarda la GpGeneraIUV e GpCaricaIUV, l'interfaccia dovra' essere estesa con i campi mancanti all'avvisatura.

I campi saranno obbligatori (sull'interfaccia, non sul database) e le nuove interfacce esposte come nuova versione (presumibilmente 2.4)

Se mancano dei dati (ad esempio per mancata configurazione oppure per utilizzata una versione precedente delle interfacce) l'avviso digitale non viene emesso.

Il workflow dovrebbe essere piu' o meno il seguente:

1. Viene eseguita una delle operazioni GpCaricaVersamento, GpGeneraIUV o GpCaricaIUV
2. Se la richiesta specifica l'opzione di emissione dell'avviso digitale, se il dominio creditore ha l'opzione di avvisatura abilitato e se sono stati compilati sono disponibili tutti i dati necessari, viene inserita una entry nella tabella delle avvisature
3. Un batch, programmato per l'esecuzione in orario morto si occupa di acquisire le avvisature non inviate e le spedisce tramite apposito servizio soap registrando l'esito (pool di thread di dimensione configurabile).
4. La ricezione dell'esito aggiorna lo stato dell'avviso in inviato e inserisce una entry in tabella di esiti per ciascun elemento esitoAvvisatura acquisito

L'emissione dell'avvisatura ed il relativo esito deve essere consultabile tramite cruscotto in apposita sezione.(sia come dettaglio di un versamento, sia come menu dedicato)

Modifiche alla struttura dati proposta:

1. Aggiungere il campo dominio, sia alla richiesta che all'esito (necessario per identificare l'avviso)
2. Aggiungere il campo di stato per capire se un avviso e' stato o meno spedito
3. Togliere il progressivo dall'esito

La tabella dati dovrebbe essere compiliant anche ad un'eventuale implementazione dell'avvisatura tramite tracciati scambiati via ftp.

Punti aperti sulla specifica AgID:

1. Cosa deve esser fatto se un'avvisatura ha esito negativo?
2. Cosa ci si deve aspettare a fronte di un'avvisatura inviata piu' volte come duplicata?
3. Dove sono censite le tassonomie?
4. Che tempi di rilascio ha questa funzionalita' e quali sono le modalita' di verifica?

from govpay.

Grazie @nardil
la struttura delle tabelle, quindi, va bene quella proposta nel documento iniziale più le modifiche da te proposte o la ristrutturiamo?

from govpay.

Credo che la tua proposta con le modifiche vada bene.
Aggiungerei anche i campi:

• data_inserimento: su entrambe le tabelle per gestire l'ordinamento su console
• descrizione_stato: sempre per fini di visualizzazione su console per gli stati non ok (oltre agli errori di comunicazione non e' chiaro se possano essercene altri)

from govpay.

Ciao @nardil, ho creato tutti i file Sql necessari alla creazione delle due tabelle
"avvisi_digitali" e "avvisi_digitali_esiti", li ho potuti testare su mysql e funzionano correttamente.
Se qualcuno vuole/può si possono provare su oracle e postgre che non ho installato.
Ho creato il file 2.4.sql per le patch non so se va bene, ditemi voi.

Ciao

from govpay.

Sicuramente 2.4 non andrà bene (il prossimo rilascio è già in programma con quel numero di versione). Non avendo neppure una stima di rilascio da parte di agid del servizio di avvisatura, lascerei in sospeso il numero di versione per aggiornarlo quando lo programmeremo.

Per non incorrere in conflitti in fase di merge, usa un nome di file non usato (eg 2.x.sql)

from govpay.

Ok! Ho modificato il nome dei file in 2.x.x.sql così da non creare problemi. Ora, secondo le vostre metodologie di sviluppo/rilascio ecc, come è necessario procedere?
Bisogna creare tutto lo strato ORM per accedere alle tabelle e successivamente lo strato EJB/WS immagino.
Grazie!

from govpay.

Ciao @ivan86to,
possiamo occuparci certamente noi della realizzazione dello strato ORM necessario sul tuo fork. A valle dello sviluppo avrai a disposizione un BD con le consuete operazioni di insert, update, get e findAll per l'interazione con DB.

A questo proposito ti chiederei di confermare ed eventualmente completare le seguenti informazioni secondo quanto necessario alla logica di business che andrai a realizzare:

• Chiavi logiche univoche (su cui potrai fare get puntuali):
  • Avvisi: Dominio, Codice avviso
  • Avvisi: Id Messaggio Richiesta
  • Esiti: Id Messaggio Richiesta, progressivo
• Filtri di ricerca (usabili nella findAll)
  • Avvisi: Stato, Dominio, Data inserimento
  • Esiti: Id Messaggio Richiesta

Aspetto un tuo riscontro,
Lorenzo

from govpay.

Ciao @nardil

Per quanto riguarda gli script ho appena committato una piccola modifica ( l'aggiunta di un boolean sulla tabella domini per attivare / disattivare l'avvisatura digitale).
I Filtri di ricerca che hai impostato direi che vanno bene.
Per quanto riguarda le chiavi logiche univoche, cosa intendi per codice avviso?
Io pensavo a queste chiavi
Avvisi: ID Messaggio Richiesta (OK)
Avvisi: id_messaggio_richiesta,id_dominio,id_versamento
Esiti: id_avviso_digitale, id_messaggio_richiesta ( Il progressivo avevi consigliato di toglierlo. )
Gli scritp sql sono nella cartella resource/db/sql/ e hanno versione 2.x.x.sql

Per il resto direi che puoi procedere, grazie!

from govpay.

Ti ho inviato alcune proposte di modifica della base dati.
Il codice avviso e' l'identificativo di un avviso per un dominio creditore. Id_dominio e codice avviso quindi sono chiave identificativa per un avviso digitale.

Fammi sapere se ti risulta tutto corretto cosi procediamo alla realizzazione dell'orm.

from govpay.

from govpay.

In GitHub, una volta verificata la push request https://github.com/ivan86to/GovPay/pull/1 , accettala per far eseguire il merge sul tuo branch.

from govpay.

Ciao Lorenzo,
ho un paio di domande su GovPay.
Servizio gpCaricaVersamento:
Se carico un versamento con flag generaIUV true posso inserire un solo oggetto "SingoloVersamento"
Se carico un versamento con flag generaIUV false posso invece inserire più oggetti "SingoloVersamento"
Come mai questa decisione?

Utilizzando il servizio gpCaricaVersamento con il flag generaIUV false, successivamente devo chiamare
il servizio gpGeneraIUV passando le informazioni necessarie a creare lo IUV giusto?

from govpay.

È un vincolo imposto dalla specifica pagopa. Sul modello 3, quindi tramite avviso, sono pagabili solo versamenti con una sola struttura singoloVersamento.

SANP 1.7, cap 5.3.1 Richiesta Pagamento Telematico (RPT)
datiSingoloVersamento: Qualora l’informazione tipoVersamento assuma il valore “PO” il numero delle occorrenze è sempre uguale a 1.

È quindi corretto chiamare la gpCaricaVersamento con flag di generazione iuv a true. Inutile spezzare il processo con due chiamate.

from govpay.

Ciao @ivan86to,
abbiamo realizzato lo strato ORM per le tablelle di Avvisatura Digitale che hai proposto. Trovi il codice nel pull request https://github.com/ivan86to/GovPay/pull/2

from govpay.

Grazie mille! Attendo solo la correzione dell'errore su JDBCDominioServiceSearchImpl.java:[186,9] error: ';' expected. E faccio il merge

from govpay.

Ciao @nardil ,

sto iniziando gli sviluppi per le nuove interfacce, mi chiedevo se per il punto 3 definito qui sopra
"3. Un batch, programmato per l'esecuzione in orario morto si occupa di acquisire le avvisature non inviate e le spedisce tramite apposito servizio soap registrando l'esito (pool di thread di dimensione configurabile)"
Intendi utilizzare la property it.govpay.thread.pool oppure ne creo una nuova indipendente?

from govpay.

sicuramente meglio utilizzare un pool indipendente per non occupare risorse necessarie alle operazioni di pagamento.

from govpay.

Altra info,
per il servizio di avvisatura il wsdl è a parte di conseguenza tutte le classi autogenerate vengono messe in altri package. La classe NodoClient utilizza l'oggetto risposta mentre per il nuovo servizio è stato utilizzato "ctRisposta", stavo pensando di creare un altro NodoClient tipo NodoClientAvvisatura.java extends BasicClient. Secondo te va bene oppure preferisci che integro tutto in un unico WSDL?

from govpay.

L'operazione di avvisatura dovrebbe far parte del servizio NodoPerPA, anche in ottica di configurazione della Porta di Dominio. Non avrebbe alcuna utilita' separarla in un nuovo servizio, mentre trattarla come le altre semplifica molto la gestione.

from govpay.

Fase 1 = Fatto, ho mergiato i WSDL, generato le classi, e creato il metodo su NodoClient.java
Modifico i servizi di caricaVersamento, generaIUV e caricaIUV, il wsdl di quei servizi è GpApp_2.3.wsdl, posso creare GpApp_2.4.wsdl oppure come la versione dei file SQL non va bene? Metto anche in questo un nome tipo GpApp_2.x.wsdl ?

Oggi (se tutto va bene) ho una call con AgID per vedere come procedere con la sperimentazione del servizio.

from govpay.

A fronte di questa notizia da parte di AgID:
"Al momento, il WSDL utilizzato dal servizio di avvisatura del Nodo “NodoPerPaAvvisiDigitali.wsdl” rimane separato dal WSDL “NodoPerPa.wsdl”, che espone i servizi di pagamento del Nodo di Pagamenti SPC ed accessori definiti nelle SANP versione 1.7 e precedenti. Il servizio di avvisatura è difatti esposto dalla porta di dominio di collaudo di AgID, con un differente (nuovo) servizio SPCoop."
Vuol dire che gli sviluppi che ho fatto per mergiare i WSDL ecc.. sono inutili? O posso continuare secondo le linee guida che ci siamo impostati all'inizio?

from govpay.

Se il servizio è su un diverso servizio SPCoop, la url di invocazione sulla porta di dominio sarà diversa ed andrà censita. L'affermazione "Al momento" mi fa però supporre che sia una situazione temporanea.

Se trovi conferma di questo, il mio suggerimento è continuare con la linea attuale, cablando in codice la URL diversa per le sole operazioni di avvisatura. Codice che poi andrà rimosso quando unificheranno i WSDL.

Se invece prevedono di introdurre un nuovo servizio SPCoop, allora sarà necessario gestirne il supporto (spero di no).

from govpay.

Ok, procedo con la cablatura a codice. Volendo posso gestirlo come parametro sulla tabella connettori?
Giusto per non avere l'URL schiantato a codice. Che ne pensi?

from govpay.

Se lo gestisci come nuovo connettore, devi modificare l'interfaccia grafica per la configurazione. Visto che si tratta di una soluzione temporanea ti suggerirei di gestirlo tramite property su file, piu veloce e meno impattante.

from govpay.

Funzionalita' gestita in #52

from govpay.