[ws 4005 / N010] Richiesta Notifiche ANPR - Errore "Rejected by policy"

[AMonopoliADS]

ambiente PROD - comune di RIOLO TERME (039015)

in risposta alla richiesta di notifiche otteniamo l'errore "Rejected by policy" i servizi di notifica sono gli unici che restituiscono questo errore, avevamo il dubbio che l'operatore non fosse abilitato all'uso del servizi, ma abbiamo verificato anche questo dalla web-app. riuscite a verificare voi cosa blocca l'uso del servizio?

potete vedere come esempio la comunicazione con idOperazioneComune 2024401547

grazie Alessandro ADS

[azabatta]

Buonasera, per il comune indicato non è presente una richiesta con l'idOperazioneComune indicato. Può indicare l'idOperazioneANPR restituito dal sistema?

[busaster]

Mi accodo alla segnalazione perché è capitato a un paio di nostri clienti ultimamente e abbiamo risolto sostituendo il certificato "server" ( -CO ). IN quei comuni però non c'erano altri problemi di comunicazione con ANPR tranne le interazioni macchina-macchina dove viene usato come certificato di postazione il certificato "CO". Vorrei capire per quale motivo un certificato in apparenza pulito e funzionante improvvisamente da questi "Rejected by policy"

[AMonopoliADS]

2024401547

chiedo scusa ma non ho ricevuto (o più probabilmente non visto) la notifica collegata a questa risposta.

l'idOperazioneComune indicata la trovo tracciata con questa request:

<tnsb:Richiesta4005 xmlns:tns="http://sogei.it/ANPR/tipoDato" xmlns:tnsa="http://sogei.it/ANPR/vocabolario4000estrazione" xmlns:tnsb="http://sogei.it/ANPR/4000estrazione" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <testataRichiesta>
    <idOperazioneComune>2024401547</idOperazioneComune>
    <codMittente>039015</codMittente>
    <codDestinatario>ANPR05</codDestinatario>
    <operazioneRichiesta>4005</operazioneRichiesta>
    <dataOraRichiesta>2024-06-04T12:59:32</dataOraRichiesta>
    <tipoOperazione>C</tipoOperazione>
    <tipoInvio>PROD</tipoInvio>
    <nomeApplicativo>DE4GSD</nomeApplicativo>
    <versioneApplicativo>V4.5.7.3 - V9.0.c del 08 09 2023</versioneApplicativo>
    <fornitoreApplicativo>ADS - Gruppo Finmatica - Bologna</fornitoreApplicativo>
  </testataRichiesta>
  <elaborazione>
    <comuneRichiesta>
      <nomeComune>RIOLO TERME</nomeComune>
      <codiceIstat>039015</codiceIstat>
      <siglaProvinciaIstat>RA</siglaProvinciaIstat>
    </comuneRichiesta>
    <ricercaElenchiRichieste>
      <statoLavorazione>9</statoLavorazione>
      <operazioneRichiesta>N010</operazioneRichiesta>
      <periodoRiferimentoRichieste>
        <dataOraIniziale>2024-06-04T00:00:00</dataOraIniziale>
        <dataOraFinale>2024-06-04T12:59:32</dataOraFinale>
      </periodoRiferimentoRichieste>
    </ricercaElenchiRichieste>
  </elaborazione>
</tnsb:Richiesta4005>

passate ormai tre settimane dalla richiesta e nel dubbio che si tratti di una comunicazione difficilmente tracciabile, vi giro un nuovo idOperazioneComune da verificare: 2024401657

grazie

[Leonforte]

Buongiorno, ci occorre l'utenza con cui state facendo le request 4005, grazie

[AMonopoliADS]

Buongiorno, ci occorre l'utenza con cui state facendo le request 4005, grazie

l'utenza che esegue la chiamata è BSSRCR

[Leonforte]

Tutte le request per il 4000 arrivano senza l'utenza (CF vuoto), quindi ci deve essere qualcosa che non va quando create l'asserzione di sicurezza. I certificati sono ok, fateci sapere, saluti

[AMonopoliADS]

bene. grazie. abbiamo individuato la causa per la quale non partiva il CF dell'operatore. per quanto ci riguarda il problema è risolto. non chiudo la issue perchè c'è il collega @busaster che aspetta un riscontro al suo intervento.

grazie Alessandro

[Leonforte]

@busaster I certificati CO-9999 sono sostituiti con i CO-9998 all'approssimarsi della loro scadenza, ma non per altri motivi. Chiudo il git, buon lavoro