search

ministero-salute / it-fse-support

https://ministero-salute.github.io/it-fse-support/
34 stars 20 forks source link

CRASH PROGRAM: attivazione per Regione Piemonte #980

Closed marco-volpe closed 3 weeks ago

marco-volpe commented 2 months ago

Buongiorno

con la presente, come regione Piemonte, chiediamo l'attivazione per il Crash Program Il codice fiscale dell'assistito che useremo è

SCLSCL00A55G273T

Vi chiediamo quindi di poterci attivare in modo da poter iniziare la fase di test.

Grazie, restiamo a disposizione

g-maugeri-sogei commented 1 month ago

Buongiorno, il CF risulta registrato nella nostra base dati. Se state riscontrando problemi nell'utilizzarlo ci servirebbero maggiori dettagli per indagarne le cause.

marco-volpe commented 1 month ago

Buongiorno

eseguendo una prova di pubblicazione, il messaggio ricevuto dalla API /documents è il seguente

{
  "traceID": "d19058fb9543d867",
  "spanID": "d19058fb9543d867",
  "workflowInstanceId": "2.16.840.1.113883.2.9.2.120.4.4.97bb3fc5bee3032679f4f07419e04af6375baafa17024527a98ede920c6812ed.5daa9a5395^^^^urn:ihe:iti:xdw:2013:workflowInstanceId",
  "warning": ""
}

Succesivamente, eseguendo la API /status per verificare lo stato di pubblicazione, riceviamo il seguente messaggio

{
  "traceID": "4dc69e604a2c5a13",
  "spanID": "8e404d80a66b11c0",
  "transactionData": [
    {
      "eventType": "VALIDATION",
      "eventDate": "2024-09-04T08:40:21.566+00:00",
      "eventStatus": "SUCCESS",
      "subject": "PROVAX00X00X000Y^^^\u00262.16.840.1.113883.2.9.4.3.2\u0026ISO",
      "organizzazione": "010",
      "workflowInstanceId": "2.16.840.1.113883.2.9.2.120.4.4.97bb3fc5bee3032679f4f07419e04af6375baafa17024527a98ede920c6812ed.5daa9a5395^^^^urn:ihe:iti:xdw:2013:workflowInstanceId",
      "traceId": "3708938549339984",
      "issuer": "integrity:S1#010#REGIONEPIEMONTETEST",
      "expiringDate": "2025-09-04T08:40:21.575+00:00"
    },
    {
      "eventType": "PUBLICATION",
      "eventDate": "2024-09-04T08:40:24.409+00:00",
      "eventStatus": "SUCCESS",
      "identificativoDocumento": "2.16.840.1.113883.2.9.2.10.4.4.10205000000000020240819120092308",
      "subject": "PROVAX00X00X000Y^^^\u00262.16.840.1.113883.2.9.4.3.2\u0026ISO",
      "tipoAttivita": "CON",
      "organizzazione": "010",
      "workflowInstanceId": "2.16.840.1.113883.2.9.2.120.4.4.97bb3fc5bee3032679f4f07419e04af6375baafa17024527a98ede920c6812ed.5daa9a5395^^^^urn:ihe:iti:xdw:2013:workflowInstanceId",
      "traceId": "d19058fb9543d867",
      "issuer": "integrity:S1#010#REGIONEPIEMONTETEST",
      "expiringDate": "2025-09-04T08:40:24.419+00:00"
    },
    {
      "eventType": "SEND_TO_INI",
      "eventDate": "2024-09-04T08:40:28.785+00:00",
      "eventStatus": "BLOCKING_ERROR",
      "message": "SEVERITY:urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:ErrorERROR_CODE:XDSRegistryErrorCODE CONTEXT:Internal Error 9000",
      "workflowInstanceId": "2.16.840.1.113883.2.9.2.120.4.4.97bb3fc5bee3032679f4f07419e04af6375baafa17024527a98ede920c6812ed.5daa9a5395^^^^urn:ihe:iti:xdw:2013:workflowInstanceId",
      "expiringDate": "2025-09-04T08:40:28.895+00:00"
    }
  ]
}

Otteniamo quindi un errore con codice 9000

Grazie, resto a disposizione

g-maugeri-sogei commented 1 month ago

Buonasera, ho indagato il problema che ci avete segnalato. Al momento il flusso si interrompe quando INI prova a inviare la request ricevuta dal gateway al vostro endpoint che abbiamo registrato come: https://ts-cloud-interop.fsepiemonte.it/dmainimedpi/services/piFseComunicazioneMetadati In merito a questo passo vi chiedo alcuni chiarimenti: 1) L'endpoint che stiamo usando e' corretto ? 2) Vedete il messaggio che vi inviamo ? 2) Se la risposta per i punti 1) e 2) e' si', il processo che sta in listen sull'endpoint si aspetta il messaggio tradotto nel formato usato da FSE 1 oppure vi aspettate il messaggio in HL7 e quindi il semplice forward della request ricevuta del gateway ?

Al momento noi stiamo ipotizzando il primo caso quindi traduciamo il messaggio da HL7 al formato da voi usato per FSE 1

marco-volpe commented 1 month ago

Buongiorno

rispondo per punti

  1. Si l'endpoint è corretto
  2. No, non vediamo la richiesta in ingresso. I motivi possono essere due: problemi di autenticazione o struttura del XML non conforme allo schema XSD (ad esempio se lo schema è cambiato). Su questo endpoint riceviamo correttamente le Comunica Metadati da parte di SISTEMATS. Avete modo di fornirci la richiesta che mandate e la risposta che ottenete?
  3. Ci aspettiamo il messaggio tradotto, quindi un documento SOAP conforme al wsdl del servizio di ComunicazioneMetadati
g-maugeri-sogei commented 1 month ago

Allego il dump della request generata dal gateway. dump.txt

Non riceviamo risposta HTTP, il socket viene chiuso.

marco-volpe commented 1 month ago

Il messaggio non è conforme allo schema XSD del servizio di ComunicazioneMetadati proveniente dal traduttore. Come regione Piemonte accettiamo documenti secondo le specifiche presenti in questo documento

Per questo motivo fallisce la validazione ed ottenete un errore.

Potreste inviarci un messaggio tradotto?

g-maugeri-sogei commented 1 month ago

dump.txt da riferimento al messaggio prodotto dal gtw. Non ho al momento modo di prendere il messaggio tradotto in uscita dall'interfaccia di rete.

marco-volpe commented 1 month ago

Ho fatto un test verso il servizio nostro di Comunica Metadati, ed in effetti in presenza di un messaggio formalmente non corretto i log informano dell'errata validazione XSD

Quindi il problema è altrove, potrebbe essere a questo punto legato all'autenticazione?

g-maugeri-sogei commented 1 month ago

Il flusso relativo all'autenticazione e' lo stesso di FSE 1. Voi riuscite a verificare sul vostro apparato che si occupa dell'autenticazione se il messaggio arriva? Eventualmente possiamo provare lato nostro pero' non gestiamo la cosa a livello applicativo quindi ci occorre coinvolgere altri gruppi. Se riuscite lato vostro facciamo prima.

marco-volpe commented 1 month ago

Purtroppo non vediamo le richieste che arrivano con un'autenticazione non valida, immagino sia questo il problema perché la URL è corretta e l'unico ostacolo per accedere è il controllo dell'accesso Ad oggi vediamo correttamente entrare le richieste di Comunicazione Metadati che hanno come utente SISTEMATS e SYSTEM_FSE_INI_B

Ci servirebbe sapere da INI a questo punto qual è il problema che hanno. Fate voi da tramite oppure occorre che noi facciamo una richiesta tramite mail?

g-maugeri-sogei commented 1 month ago

Verifichiamo noi internamente.

marco-volpe commented 1 month ago

Verifichiamo noi internamente.

Buongiorno, avete novità in merito?

Vi informiamo che abbiamo anche predisposto il servizio per la notifica di avvenuta comunicazione metadati verso la RDA A breve vi manderemo apposita email

marco-volpe commented 1 month ago

Buongiorno

scusate l'insistenza ma vi chiediamo se potete darci un'indicazione circa quando sarà possibile riprendere i nostri test.

Vi chiediamo inoltre se è stata configurata la URL per le invio delle notifiche di avvenuta comunicazione metadati e, se per questa fase di test, inizieremo a ricevere delle richieste

Grazie

marco-volpe commented 1 month ago

Buongiorno

vi chiediamo se sia stato eseguito l'aggiornamento che avrebbe dovuto risolvere il problema. Un test eseguito poco fa mostra ancora l'errore

Grazie

vigliottim commented 1 month ago

Buongiorno, l'aggiornamento non è stato ancora rilasciato. La informeremo non appena sarà fatto. Grazie.

vigliottim commented 1 month ago

Buon pomeriggio, è stato rilasciato un aggiornamento. Le chiediamo gentilmente di riprovare e darci un riscontro. Grazie.

marco-volpe commented 1 month ago

Buongiorno

grazie per il riscontro. Dopo l'aggiornamento l'errore è cambiato ed è questo

  {
      "eventType": "SEND_TO_INI",
      "eventDate": "2024-09-27T13:48:42.573+00:00",
      "eventStatus": "BLOCKING_ERROR",
      "message": "SEVERITY:urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:ErrorERROR_CODE:R166CODE CONTEXT:Wrong value of referenceIdList",
      "workflowInstanceId": "2.16.840.1.113883.2.9.2.120.4.4.97bb3fc5bee3032679f4f07419e04af6375baafa17024527a98ede920c6812ed.a4ab0cfe73^^^^urn:ihe:iti:xdw:2013:workflowInstanceId",
      "expiringDate": "2025-09-27T13:48:42.635+00:00"
    }

Grazie

LucaRogledi commented 1 month ago

Buonasera, la referenceIdList viene girata verso INI così valorizzata "[NRE]^^^&2.16.840.1.113883.2.9.4.3.8&ISO^urn:ihe:iti:xds:2013:order". INI verifica il valore dell'NRE e quindi dovrebbe mandare un NRE reale attivo in validazione. La invitiamo gentilmente a riprovare con un NRE attivo o se non lo possiede può eliminare le sezione "inFulfillmentOf". Restiamo a disposizione per ulteriore supporto. Grazie

marco-volpe commented 1 month ago

Buonasera l'eliminazione di "inFulfillmentOf" fa fallire la validazione, l'inserimento di un NRE formalmente corretto, invece, restituisce sempre il medesimo errore (Wrong value of referenceIdList)

Abbiamo sostituito l'elemento con un contenuto diverso ed è riapparso nuovamente l'errore precedente

    {
      "eventType": "SEND_TO_INI",
      "eventDate": "2024-09-27T15:15:24.524+00:00",
      "eventStatus": "BLOCKING_ERROR",
      "message": "SEVERITY:urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:ErrorERROR_CODE:XDSRegistryErrorCODE CONTEXT:Internal Error 9000",
      "workflowInstanceId": "2.16.840.1.113883.2.9.2.120.4.4.97bb3fc5bee3032679f4f07419e04af6375baafa17024527a98ede920c6812ed.eff84442f1^^^^urn:ihe:iti:xdw:2013:workflowInstanceId",
      "expiringDate": "2025-09-27T15:15:24.535+00:00"
    }

Segnalo che il CDA che usiamo per i test è quello presente al seguente link e le modifiche consistono esclusivamente nella sostituzione del codice fiscale dell'assistito usato per il test

CDA

Restiamo a disposizione

LucaRogledi commented 1 month ago

Buongiorno, potrebbe gentilmente indicare se l'errore da lei indicato fa riferimento ad un CDA con inFulFillmentOf? Questo campo dovrebbe essere mandato vuoto se non si possiede un NRE dell'assistito con cui si vuole provare in validazione. La invitiamo pertanto a riprovare seguado questa modifica. La popolazione dell'attributo extension con "[NRE]" darà sicuramente errore una volta raggiunto INI. Restiamo a disposizione per ulteriore supporto. Grazie

marco-volpe commented 1 month ago

Buongiorno

abbiamo rieseguito un test con il campo "inFulFillmentOf" vuoto

`

`

il risultato è stato il seguente errore di validazione

{
  "traceID": "f5ebb5870f66a84e",
  "spanID": "f5ebb5870f66a84e",
  "workflowInstanceId": "2.16.840.1.113883.2.9.2.120.4.4.97bb3fc5bee3032679f4f07419e04af6375baafa17024527a98ede920c6812ed.10f71c6386^^^^urn:ihe:iti:xdw:2013:workflowInstanceId",
  "type": "/msg/syntax",
  "title": "Errore di sintassi.",
  "detail": "ERROR: -1,-1 cvc-complex-type.2.4.b: The content of element \u0027inFulfillmentOf\u0027 is not complete. One of \u0027{\"urn:hl7-org:v3\":realmCode, \"urn:hl7-org:v3\":typeId, \"urn:hl7-org:v3\":templateId, \"urn:hl7-org:v3\":order}\u0027 is expected.",
  "status": "400",
  "instance": "/validation/error"
}

Un errore di validazione, anche se diverso, è presente se il campo "inFulfillmentOf" viene omesso.

Successivamente abbiamo riprovato con un contenuto completo, preso da altro CDA

`

`

In questo caso la validazione è andata a buon fine, ma l'errore in fase di recupero status è stato il seguente

{
      "eventType": "SEND_TO_INI",
      "eventDate": "2024-10-01T06:00:43.544+00:00",
      "eventStatus": "BLOCKING_ERROR",
      "message": "SEVERITY:urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:ErrorERROR_CODE:XDSRegistryErrorCODE CONTEXT:Internal Error 9000",
      "workflowInstanceId": "2.16.840.1.113883.2.9.2.120.4.4.97bb3fc5bee3032679f4f07419e04af6375baafa17024527a98ede920c6812ed.22055c5985^^^^urn:ihe:iti:xdw:2013:workflowInstanceId",
      "expiringDate": "2025-10-01T06:00:43.659+00:00"
    }

Infine, ripristinando il contenuto originario di "inFulfillmentOf" ma modificando il pattern "[NRE]" con un numero di ricetta elettronica formalmente valido

`

`

Il risultato è stato il seguente

{
      "eventType": "SEND_TO_INI",
      "eventDate": "2024-10-01T06:02:38.294+00:00",
      "eventStatus": "BLOCKING_ERROR",
      "message": "SEVERITY:urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:ErrorERROR_CODE:R166CODE CONTEXT:Wrong value of referenceIdList",
      "workflowInstanceId": "2.16.840.1.113883.2.9.2.120.4.4.97bb3fc5bee3032679f4f07419e04af6375baafa17024527a98ede920c6812ed.ec18bba642^^^^urn:ihe:iti:xdw:2013:workflowInstanceId",
      "expiringDate": "2025-10-01T06:02:38.383+00:00"
    }

Restiamo a disposizione

vigliottim commented 1 month ago

Buonasera, le chiediamo gentilmente di effettuare un test usando il seguente id root: 2.16.840.1.113883.2.9.4.3.4 e darci riscontro. Grazie.

marco-volpe commented 1 month ago

Buongiorno

abbiamo inserito questo elemento

`

`

Il risultato è sempre un errore

 {
      "eventType": "SEND_TO_INI",
      "eventDate": "2024-10-02T09:09:42.477+02:00",
      "eventStatus": "BLOCKING_ERROR",
      "message": "SEVERITY:urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:ErrorERROR_CODE:XDSRegistryErrorCODE CONTEXT:Internal Error 9000",
      "workflowInstanceId": "2.16.840.1.113883.2.9.2.120.4.4.97bb3fc5bee3032679f4f07419e04af6375baafa17024527a98ede920c6812ed.a0e193cd03^^^^urn:ihe:iti:xdw:2013:workflowInstanceId",
      "expiringDate": "2025-10-02T09:09:42.487+02:00"
    }

Restiamo a disposizione

g-maugeri-sogei commented 1 month ago

Buonasera, ci servirebbe un nuovo tentativo per indagare il problema, se riuscite entro oggi. Potete effettuarlo e fornirci il timestamp e il CF relativi al tentativo ?

marco-volpe commented 1 month ago

Buongiorno

test fatto adesso, stesso CDA usato nell'ultimo esempio

CF usato SCLSCL00A55G273T

   {
      "eventType": "SEND_TO_INI",
      "eventDate": "2024-10-02T15:34:19.410+02:00",
      "eventStatus": "BLOCKING_ERROR",
      "message": "SEVERITY:urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:ErrorERROR_CODE:XDSRegistryErrorCODE CONTEXT:Internal Error 9000",
      "workflowInstanceId": "2.16.840.1.113883.2.9.2.120.4.4.97bb3fc5bee3032679f4f07419e04af6375baafa17024527a98ede920c6812ed.c4d166606a^^^^urn:ihe:iti:xdw:2013:workflowInstanceId",
      "expiringDate": "2025-10-02T15:34:19.482+02:00"
    }

A disposizione

g-maugeri-sogei commented 1 month ago

INI riceve Wed Oct 02 2024 15:34:19 [0x80e0015b][ws-proxy][info] wsgw(WSP-FSE-INS): tid(924020127)[217.175.52.34]: HTTP response code 500 for 'https://ts-cloud-interop.fsepiemonte.it/dmainimedpi/services/piFseComunicazioneMetadati'

dal vostro endpoint. In allegato la request. request.txt

marco-volpe commented 1 month ago

Buongiorno

vediamo la richiesta in ingresso Abbiamo questo errore di validazione

2024-10-02 15:34:19,260 WARN [http-nio-8080-exec-449] o.s.w.s.s.e.i.PayloadValidatingInterceptor - XML validation error on request: cvc-maxLength-valid: Value '2.16.840.1.113883.2.9.4.1.3.1135360012' with length = '38' is not facet-valid with respect to maxLength '20' for type 'stringTypeMax20'.
2024-10-02 15:34:19,260 WARN [http-nio-8080-exec-449] o.s.w.s.s.e.i.PayloadValidatingInterceptor - XML validation error on request: cvc-type.3.1.3: The value '2.16.840.1.113883.2.9.4.1.3.1135360012' of element 'ns3:StrutturaUtente' is not valid.

Secondo l'XSD della Comunica Metadati il campo Struttura non è valido

Ci verrà mandato sempre in questo modo? Potrebbe essere sufficiente solo la parte finale, ovvero il codice della struttura 1135360012

A disposizione

g-maugeri-sogei commented 1 month ago

Buongiorno, vanno aggiornati tutti gli XSD che contengono il campo strutturaUtente. Passa da stringTypeMax20 a stringTypeMax256. La modifica si rende necessaria a seguito del cambio di formato delle informazioni passate in questo campo come richiesto dal DTD. A breve vi facciamo avere gli XSD aggiornati.

marco-volpe commented 3 weeks ago

Buongiorno

a seguito della modifica dei tracciati XSD la comunica metadati è stata eseguita correttamente

Grazie

vigliottim commented 3 weeks ago

Grazie per il suo gentile feedback. Procediamo alla chiusura della presente issue e rimaniamo a disposizione per altre richieste di supporto.