Open FSESardegna opened 1 day ago
salve,
come comunicato in altre issue e in sede di SAL, il nostro sistema controlla che il codice fiscale autore sia valido e quello utilizzato non è formalmente un codice fiscale valido. Potete riprovare con un qualsiasi codice fiscale formalmente corretto, anche fittizio, come autore del documento? Grazie!
Buongiorno,
durante una nuova pubblicazione di un documento abbiamo inserito un Codice Fiscale formalmente corretto, come da voi suggerito, e la transazione è stata eseguita con successo. Ecco i dettagli:
DocumentID: 2.16.840.1.113883.2.9.4.3.8^200106CQTDLT66H01Z356V20241104152625014417
WII: 2.16.840.1.113883.2.9.2.120.4.4.f1d0891a68d1a90dfff2e0d2cf7519d7dc4af355c2c63312c2c14b8d9bd0589a.d42ccac82c^^^^urn:ihe:iti:xdw:2013:workflowInstanceId
TraceId: 6728da7a51c1f3243ad2c4a4d40536f9
Esito Stato transazione: SUCCESS
Successivamente, abbiamo effettuato una transazione di tipo Replace per sostituire il documento pubblicato in precedenza, ma questa operazione ha generato un errore. Di seguito i dettagli:
DocumentID: 2.16.840.1.113883.2.9.4.3.8^200106CQTDLT66H01Z356V20241104153727996269
WII: 2.16.840.1.113883.2.9.2.120.4.4.de1d7ce6e67532ff074ee055b63f224d66b82e0e10f8416b86b373fdb2a29439.c864cf5e0e^^^^urn:ihe:iti:xdw:2013:workflowInstanceId
TraceId: 6728dcf241f99b25432337f087645449
Esito verifica stato transazione: SEVERITY:urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error ERROR_CODE:CRF2 CODE_CONTEXT: RDA generated an internal error.
@izamberlan
Molto strano, i due documenti risultano correttamente processati lato nostro. Chiedo a @vigliottim @LucaRogledi se il fatto che l'ambiente di test nostro abbia risposto in oltre otto secondi possa essere il problema.
Recuperato il trace completo, non comprendiamo e chiediamo supporto: la query riporta una response (su schema sbagliato, apparentemente è una response di una register) con un CRF2 che non è sicuramente stato generato da noi. Infatti la register riporta poi correttamente l'association di RPLC con uuid corretto (ed evidentemente restituito da noi), tanto che nel nostro registry (e dai nostri log) il documento risulta correttamente indicizzato e il precedente documento sostituito e deprecato. Vorremmo capire cos'è successo e facciamo notare che nello scenario RDA=RDE (e da quanto possiamo analizzare anche nelle transazioni di altre regioni) la nostra replace funziona. Grazie. 200106CQTDLT66H01Z356V20241104153727996269.txt
Aggiungo: neanche l'ipotesi del timeout è plausibile, la risposta alla GetDocuments ObjectRef di recupero riferimenti è sotto il secondo. Dai nostri log abbiamo risposto con l'uuid del documento da sostituire come nei casi funzionanti.
Buongiorno, abbiamo effettuato un tentativo di pubblicazione verso la regione
traceId: 6720bc4398fed11ba73a7ed946f87323 DocumentEntry.uniqueId: 2.16.840.1.113883.2.9.4.3.8^200106CQTDLT66H01Z356V20241029114046695244
workflowInstanceId: 2.16.840.1.113883.2.9.2.120.4.4.4b68a45d8440b544ebb28a2a6f2559d76caf7fbea747a3c5cd121921fcde9cef.b48810e5fa^^^^urn:ihe:iti:xdw:2013:workflowInstanceId successivamente, controllando l'esito stato transazione otteniamo il seguente errore: SEVERITY: message=SEVERITY:urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:ErrorERROR_CODE:CRF2CODE CONTEXT:RDA generated an internal error.
Vi chiediamo gentilmente di eseguire una verifica sul problema riscontrato per identificare le cause dell’errore e supportarci nella risoluzione, al fine di consentire il corretto completamento della pubblicazione.
Rimaniamo a disposizione