Acord Standard for Insurance. ¿Alguien ha lidiado con este lío?

Question

Tenemos que implementar un servicio web WCF usando el ACORD Standard.

Sin embargo, no sé por dónde empezar con esto ya que este estándar es HUMONGOUS y muy intrincado. Un caos total para mis ojos.

Estoy tratando de usar WSCF.Blue para extraer las clases de los múltiples XSD que tengo pero hasta ahora todo lo que obtengo es un montón de basura: un archivo .cs con más de 50,000 líneas de código que congela mi VS2010 todo el hora.

¿Alguien ha caminado ya por el Valle de la Muerte (ACORD Standard) y lo logró? Realmente apreciaría algo de ayuda.

Answer 1

He trabajado con los estándares de informes de exposición de Accord PCS y sí, fue una pesadilla. También trabajé con otros estándares grandes como FPML y SportsML.

Necesita averiguar exactamente qué tipos del esquema son necesarios. Cómo lo hace depende de usted, pero el visor de esquemas VS debe poder manejarlo. Si no, prueba con XmlSpy o simplemente con la mano si es necesario. Asegúrese de tener un buen BA a mano ...

Lo más probable es que pueda cumplir con sus requisitos utilizando alrededor del 1% de los tipos disponibles en la norma.

Lo que probablemente encontrará es que puede expresar los objetos centrales con un conjunto mínimo de valores, ya que la mayoría de los nodos serán minOccurs=0 o nillable.

Luego puede usar el modificador/element en xsd.exe para generar el código solo para los tipos que necesita.

Como un comentador dice que no hay una píldora fácil de tragar aquí. La ironía es que se supone que los estándares facilitan la vida de todos.

Answer 2

Parece que va por el buen camino pero se pierde en el bosque.
El estándar ACORD es enorme e intencionalmente, ya que brinda soporte para cientos de mensajes diferentes. Del mismo modo que no descarga toda Wikipedia para obtener solo unos pocos artículos, no necesita todas las clases en el estándar ACORD para admitir una implementación de algunos mensajes. Si sabe qué mensajes necesita para respaldar, entonces puede generar un subconjunto del XSD completo que será bastante manejable.

Como se menciona en la respuesta de Hugh, para cualquier mensaje solo se usa una fracción del XSD completo. Cómo vas a hacer eso dependerá de los detalles de tu proyecto. Si está buscando ideas sobre cómo generar un subconjunto del XSD completo, intente ponerse en contacto con el personal de ACORD para obtener ayuda al PCS@acord.org. Deberían poder ofrecerle ayuda para comenzar.

Answer 3

Escribí un convertidor de biblioteca de clase ACORD to C# que luego se usó en varios productos grandes de seguros comerciales. Presentaba un mapeo muy bonito de todo el ACORD XML en agradables y concisas clases de C# extensibles. ¡Entonces sé de dónde vienes!

Una vez que profundizas en esto no es tan malo, pero mantengo que el codificador promedio no lo 'conseguirá' durante aproximadamente 3-4 meses si trabajan a tiempo completo (asumiendo cualquier cosa menos los mensajes de estilo de consulta). El verdadero problema surge cuando intentamos hacer un mapeo desde una base de datos backend y desde/hacia otro ACORD WS. Todos los operadores, proveedores y agencias tienen reglas personalizadas.

Mi mejor sugerencia es encontrar ejemplos de código de trabajo (tengo toneladas si los necesita) y tal vez incluso un proveedor o proveedor que le permita conectarse a un ACORD ws en un entorno de prueba.

Answer 4

Si está buscando leer/escribir documentos ACORD usando .NET, me encontré con "IVC Software Factory for ACORD Standards" en CodePlex al http://ivc.codeplex.com.

De la documentación limitada, parece que esta biblioteca puede convertir objetos a documentos ACORD XML, y viceversa. El código fuente viene con diferentes "proveedores", es decir, diferentes tipos de transacciones ACORD, como 103 o 121.

Espero que esto ayude.

Answer 5

Recomendaría no crear un modelo para todo el estándar. Uno podría simplemente pasar XML y no serializarlo en un modelo, sino cargarlo en XDocument/XElement y usar Linq para consultarlo y actualizar el DOM usando Linq a Xml. Entonces, uno no está cargando el XML a un modelo fuertemente tipado, sino solo cargando el XML. No hay un modelo, solo un documento XML.

A partir de ahí, se pueden extraer los datos del XML según sea necesario.

Usando este enfoque, el código será feo y tendrá poco contexto ya que XElements pasará a todas partes, y habrá toneladas de cadenas mágicas de XPaths para consultar y definir elementos, pero puede funcionar. Además, todo es una cadena así que habrá métodos de conversión de utilidades para convertir a números, fechas, etc.

Desde mi perspectiva, he modelado parte del Acord en un modelo de objetos usando el XmlSerializer pero está bastante por encima de 500 clases El modelo no fue procesado desde XSD u otro, sino que se hizo manualmente y tomó algo de tiempo. Las herramientas producirán clases monstruosas inutilizables (como usted ha mencionado) y/o falla rotunda. Como ejemplo, traté de cargar el XSD en Stylus Studio y se bloqueó varias veces.

Por lo tanto, su mejor opción si tiene problemas de tiempo es cargar un XDocument en lugar de intentar trazar todo en un modelo. Sé que eso apesta, pero Acord en general es básicamente un gran desastre de datos.