Skip to main content

WCF - Riconoscere se una coppia Produttore - Titolare è stata migrata o meno

Work in progress. Documentazione in fase di completamento.

Come riportato in questo articolo i produttori e titolari sono oggetto di una migrazione che porterà produttori e titolari all'interno dell'ecosistema Digital. 

Durante il passaggio gli integratori potrebbero aver bisogno di sapere se una posizione è già stata oggetto di migrazione o meno. Proprio per questo è stata sviluppata una API specifica che, oltre a riportare lo stato corrente di un produttore rispetto alla migrazione, fornisce utili informazioni sullo stato della posizione, sulla possibilità di effettuare conservazione sulla specifica coppia titolare / produttore e infine, consente di ricevere utili informazioni sullo stato della Delega del Responsabile della Conservazione.

La documentazione della API è disponibile in test all'indirizzo: 

https://archive-config-read.test.teamsystem.digital/swagger-ui/index.html?url=/v3/api-docs#/Archive%20config%20read/getConfigStatusReport

La stessa API è disponibile in produzione all'indirizzo 

https://archive-config-read.teamsystem.digital/swagger-ui/index.html?url=/v3/api-docs#/Archive%20config%20read/getConfigStatusReport

L'endpoint è richiamabile da un utente del mondo Digital che abbia i permessi in lettura su submitter per ottenere un report sullo stato di attivazione della configurazione e attivazione della coppia submitter e holder. 

Nel caso in cui non esistano credenziali Digital che possano operare sul submitter e holder, oppure che la azienda non abbia una posizione correttamente registrata nel portale Digital e quindi non siano disponibili gli UUID per effettuare la chiamata a questo servizio è implicito che la migrazione non è ancora stata effettuata e deve essere regolarizzata la posizione come descritto in questo articolo.

Di seguito un esempio di chiamata CURL al servizio

curl -X 'GET'  'https://archive-config-read.test.teamsystem.digital/api/v1/config/[submitterUUID]/[holderUUID]/config-status-report' 
  -H 'accept: application/json' 
  -H 'User-Agent: {replace-with-caller-user-agent}' 
  -H 'X-App-Name: {replace-with-caller-app-name}' 
  -H 'X-App-Version: {replace-with-caller-app-name}' 
  -H 'X-Request-ID: {random-request-id}' 
  -H 'X-Correlation-ID: {correlation-id}' 
  -H 'X-Item-ID: {holderUUId}'
  -H 'X-User-ID: {replace-with-current-user-id}' 
  -H 'X-Manager-ID: {submitterUUID}' 
  -H 'Accept-Language: it' 
  -H 'X-Forwarded-For: {replace-with-forwarded-for-information}' 
  -H 'Authorization: Bearer  {auth jwt token}

Richiamando  il servizio con un token autorizzativo ottenuto dal sistema di autenticazione standard è possibile ottenere una risposta simile alla seguente:

{
  "lastModifiedDate": "2023-02-14T11:25:01.306098306Z",
  "configType": "DIGITAL",
  "preservationUploadAvailable": false,
  "userMessage": "Responsabile della conservazione non valorizzato;",
  "details": {
    "rdcConfigured": false,
    "readOnly": true
  }
}
si vede come nella sezione "configType" è riportato il termine DIGITAL, evidenza del fatto che la coppia produttore e titolare richiesti nella chiamata è stata effettivamente attivata nel nuovo sistema di configurazione.

 

Nel caso in cui invece il sistema venga utilizzato su una coppia di submitter e holder non ancora migrati troveremo una risposta smile alla seguente:

{
  "lastModifiedDate": null,
  "configType": "LEGACY",
  "preservationUploadAvailable": false,
  "userMessage": "Titolare non abilitato; Data attivazione Titolare non valida;",
  "details": {
    "rdcConfigured": true,
    "readOnly": false
  }
}
Infatti nella sezione "configType" è riportato il termine "LEGACY", evidenza del fatto che la coppia fornita è ancora attiva nel sistema legacy.

Vediamo inoltre altre informazioni interessanti nella risposta, infatti le proprietà 

"preservationUploadAvailable": false,

indica se la conservazione è disponibile. Nel caso in cui sia riportato "false" eventuali chiamate al servizio di versamento documenti andranno in errore in quanto la conservazione non è appunto disponibile.

Le motivazioni per cui la conservazione andrà in errore sono riportate in modo chiaro e leggibile nella proprietà userMessage che contiene una o più frasi che riconducono all'anomalia individuata nella configurazione: 

"userMessage": "Titolare non abilitato; Data attivazione Titolare non valida;"

In questo esempio vediamo come il titolare non sia stato abilitato dal sistema e, di conseguenza non abbia una data di attivazione valida.

Si riporta di seguito un elenco delle motivazioni più comuni per cui una configurazione potrebbe non essere valida. L'elenco è riportato a solo scopo informativo e Teamsystem si riserva la possibilità di variare i testi esposti senza preavviso.

  • Impossibile trovare le informazioni di sottoscrizione del submitter [submitteruuid] e del titolare
    [titolareuuid]
  • Dati Produttore non presenti
  • Dati Titolare non presenti
  • Responsabile della conservazione non valorizzato
  • Cognome Responsabile della conservazione non presente
  • Nome Responsabile della conservazione non presente
  • Codice Fiscale Responsabile della conservazione non corretto
  • Titolare non abilitato
  • Data attivazione Titolare non valida
  • Versamento non disponibile, Archive in sola lettura
  • Archive bloccato dal flag NoUseArchive

 

 

 

 

No comments to display

Back to top