Acord Standard per l'assicurazione. Qualcuno ha avuto a che fare con questo casino?

Question

È necessario implementare un servizio Web WCF utilizzando ACORD Standard.

Tuttavia, non so da dove cominciare, poiché questo standard è HUMONGOUS e molto contorto. Un caos totale ai miei occhi.

Sto cercando di utilizzare WSCF.Blue per estrarre le classi dal XSD multiplo che ho ma finora tutto ciò che ottengo è un mucchio di merda: un file .cs con oltre 50.000 righe di codice che congela il mio VS2010 tempo.

Qualcuno ha camminato già attraverso la Valle della Morte (ACORD Standard) e ce l'ha fatta? Gradirei davvero un aiuto.

Answer 1

Ho lavorato con gli standard di segnalazione di esposizione Accord PCS e sì è stato un incubo. Ho anche lavorato con altri grandi standard come FPML e SportsML.

È necessario calcolare esattamente quali tipi dello schema sono necessari. Il modo in cui lo fai dipende da te, ma VS viewer dello schema dovrebbe essere in grado di gestirlo. Se non provi XmlSpy o lo fai semplicemente a mano se devi. Assicurati di avere una buona BA a portata di mano ...

Probabilmente troverai che puoi soddisfare le tue esigenze utilizzando circa l'1% dei tipi disponibili nello standard.

Quello che probabilmente troverete è che è possibile esprimere gli oggetti core con un set minimo di valori, poiché la maggior parte dei nodi sarà minOccurs=0 o nillable.

Quindi è possibile utilizzare l'opzione/element su xsd.exe per generare il codice solo per i tipi necessari.

Come un commentatore dice che non c'è pillola facile da ingoiare qui. L'ironia è che gli standard dovrebbero rendere la vita di tutti più facile.

Answer 2

Sembra che stiate andando verso la giusta direzione ma che si perdano nella foresta.
Lo standard ACORD è enorme e intenzionale, in quanto fornisce supporto per centinaia di messaggi diversi. Proprio come non scarichi tutta la Wikipedia per ottenere solo pochi articoli, non hai bisogno di tutte le classi nello standard ACORD per supportare un'implementazione di alcuni messaggi. Se sai quali messaggi devi supportare, puoi generare un sottoinsieme di XSD completo che sarà abbastanza gestibile.

Come accennato nella risposta di Hugh, per ogni messaggio viene utilizzata solo una frazione dell'intero XSD. Il modo in cui lo fai dipende dalle specifiche del tuo progetto. Se stai cercando idee su come generare un sottoinsieme di XSD completo, contatta lo staff di ACORD per assistenza allo PCS@acord.org. Dovrebbero essere in grado di offrirti un aiuto per iniziare.

Answer 3

Ho scritto un ACORD al convertitore di libreria di classi C#, che è stato poi utilizzato in diversi grandi prodotti assicurativi commerciali. Caratterizzava una mappatura molto bella di tutto l'ACORD XML in belle classi C# concise ed estendibili. Quindi so da dove vieni!

Una volta scavato non è poi così male, ma ritengo che il programmatore medio non lo "capisca" per circa 3-4 mesi se lavora a tempo pieno (assumendo qualsiasi cosa tranne i messaggi di stile di ricerca). Il vero problema si presenta quando si prova a fare il mapping da un database di back-end e da/da un altro ACORD WS. Tutti i vettori, i fornitori e le agenzie hanno regole personalizzate.

Il mio miglior consiglio è di trovare esempi di codice funzionante (ne ho tonnellate se ne avete bisogno) e forse anche un venditore o corriere che vi permetterà di collegarvi ad un ACORD in un ambiente di test.

Answer 4

Se si sta cercando di leggere/scrivere documenti ACORD utilizzando .NET, mi sono imbattuto in "IVC Software Factory per ACORD Standard" su CodePlex al http://ivc.codeplex.com.

Dalla documentazione limitata sembra che questa libreria possa convertire oggetti in documenti XML ACORD e viceversa. Il codice sorgente viene fornito con diversi "provider", cioè diversi tipi di transazione ACORD, come 103 o 121.

Spero che questo aiuti.

Answer 5

Si consiglia di non creare un modello per l'intero standard. Si può semplicemente passare XML e non serializzare in un modello, ma invece caricarlo in XDocument/XElement e usare Linq per interrogarlo e aggiornare il DOM usando Linq per Xml. Quindi, uno non sta caricando il codice XML in un modello fortemente tipizzato, ma semplicemente caricando l'XML. Non esiste un modello, solo un documento XML.

Da lì, è possibile prelevare i dati dall'XML in base alle esigenze.

Utilizzando questo approccio, il codice sarà brutto e avrà un piccolo contesto poiché XElements verrà passato ovunque e ci saranno tonnellate di stringhe magiche di XPath per interrogare e definire gli elementi, ma può funzionare. Inoltre, tutto è una stringa quindi ci saranno metodi di conversione dell'utilità per convertire in numeri, date, ecc.

Dal mio punto di vista, ho modellato parte di Acord in un modello a oggetti usando XmlSerializer ma è ben oltre 500 classi. Il modello non è stato lavorato da XSD o altro, ma è stato realizzato manualmente e ha richiesto un po 'di tempo. La lavorazione con utensili produrrà classi mostruose inutilizzabili (come hai menzionato) e/o crash inatteso. Ad esempio, ho provato a caricare XSD in Stylus Studio e si è bloccato più volte.

Quindi, la soluzione migliore se il tuo tempo è impegnato in un XDocument anziché provare a mappare tutto in un modello. So che fa schifo, ma Acord in generale è fondamentalmente un enorme pasticcio di dati.