Salta la navigazione
In particolare il componente è stato ingegnerizzato in modo tale che è in grado di realizzare tutti i metodi richiesti dal SISS , sia lato Client che Server, sia verso l'adattatore SEBC che verso l'adattatore SYSS Way della piattaforma standard regionale ed è indipendente dal formalismo del messaggio di comunicazione.
Le informazioni che vengono passate o ricevute dal componente nel dialogo da e verso il SISS attraverso i metodi del componente sono indipendenti dall'adattatore presente sulla PDL e dalla versione in uso. Inoltre il componente OMNICOM nasconde allo sviluppatore la complessità del formato XML/SOAP , che è lo standard adottato per lo scambio di informazioni con il CRS-SISS sia per quanto riguarda la stringa di comunicazione con l'adattatore ( SEBC o SYSS Way ) , sia per quanto riguarda la risposta.
Seguendo lo stesso criterio di semplificazione il componente espone un unico metodo per l'invio e la ricezione di messaggi SOAP , in modo da renderlo indipendente dagli scenari , e dalla modalità ( porta Delegata , porta Applicativa) .
Inoltre il metodo di comunicazione utilizzato dal componente OMNICOM garantisce la certezza dell'utilizzo per qualunque tipo di integrazione in quanto impiega un'interfaccia ?di rete? al posto di componenti SW pre-installati, pertanto è indipendente dal linguaggio e dall?ambiente di esecuzione dell?applicazione integrata.
In fig 1 - 2 - 3 viene mostrato un esempio in C# di istanziazione della libreria OMNICOM SISS Suite in una applicazione tipo , per attivare uno dei metodi previsti dallo scenario di identificazione del cittadino.
In fig 4 viene mostrato il flusso della comunicazione tra una applicazione e il CRS-SISS. Nell'esempio si vede come l'applicazione Client ( installato sulla PDL dove risiedono i servizi SISS ) grazie all'interoperabilità COM comunica i dati da inviare al SISS attraverso la OMNICOM SISS interface semplicemente come una struttura dati. La OMNICOM SISS Adapter si occupa di comunicare con il servizio remoto OMNICOM SISS engine che provvede alla costruzione del messaggio SOAP e alla validazione e verifica dei vincoli. Il messaggio SOAP viene inviato alla OMNICOM SISS comunicator che provvede all'inoltro all'adattatore SEBC. Il messaggio SOAP di risposta allo stesso modo viene convertito in un oggetto risposta e consegnato alla applicazione come parametro di ritorno del metodo start scenario.
Grazie ad un tools grafico , è possibile partendo dai template XML della documentazione originale dei messaggi da implementare, modellare automaticamente le classi C# che concorreranno a formare le DLL da integrare. Queste DLL sono le interfacce che instanziate nelle applicazioni esporranno attraverso le loro proprietà i tag dell'XML.
I metodi SISS a seconda dello scenario richiesto richiedono che i valori passati dalla stringa XML siano sottoposti a vincoli di validità . Mediante lo stesso Tools è possibile associare ad ogni proprietà della classe che ha una corrispondenza con un tag XML il vincolo richiesto. In questo modo i valori inviati dalla applicazione vengono validati prima di procedere alla costruzione della stringa XML da inviare all'adattatore SISS. Questa soluzione ha permesso di realizzare un sistema con un avanzato indice di aderenza alla evoluzione dei modelli informativi prolungando il ciclo di vita dello stesso.
In fig 5 viene mostrato come esempio la costruzione della libreria OMNICOM SISS interface per la implementazione dello scenario GP ( prenotazione ) partendo dai file XML della documentazione originale.
In fig 6 viene mostrato un messaggio XML prima di essere processato dal generatore della classe.
In fig 7 e in fig 8 viene mostrato come vengono attivati i vincoli o i controlli richiesti dalla documentazione SISS.
Figura 1
