WCF - Riconoscere se un Produttore - Titolare è stato migrato
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 sia rispetto alla migrazione fornisce utili informazioni sullo stato della posizione, sulla possibilità di effettuare conservazione sullo specifica coppia titolare / produttore e infine, consente di ricevere utili informazioni sullo stato della dichiarazione del responsabile della conservazione.
La documentazione della API è disponibile in test all'indirizzo:
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 }}Vediamo inoltre altre informazioni interessanti nella risposta, infatti