Acord standard for insurance. Has anyone dealt with this disorder?

Question

We need to implement the WCF web service using ACORD Standard .

However, I do not know where to start, since this HUMONTUR standard is very confusing. Complete chaos for my eyes.

I'm trying to use WSCF.Blue to extract classes from the many XSDs that I have, but so far all I get is a bunch of crap: a .cs file with 50,000 + lines of code that freezes my VS2010 all the time.

Has anyone already walked through the Death Valley (ACORD Standard) and done this? I would really appreciate help.

Answer 1

It looks like you are on the right track, but are lost in the forest.
The ACORD standard is huge and deliberate, as it supports hundreds of different messages. Just as you do not download the entire Wikipedia to get just a few articles, you do not need all the classes in the ACORD standard to support the implementation of multiple posts. If you know what messages you need for support, you can create a subset of the full XSD that will be completely manageable.

As mentioned in Hughes' answer, for any one message only part of the full XSD is used. How you do this will depend on the features of your project. If you are looking for ideas on how to create a subset of full XSD, try contacting ACORD staff for help in [e-mail] . They should be able to offer you some help getting started.

Answer 2

I wrote ACORD for the C # class library converter, which was then used in several large commercial insurance products. It showed a very good mapping of all ACORD XML to beautiful, compressed, extensible C # classes. So I know where you came from!

As soon as you delve into it, it’s not so bad, but I affirm that the average encoder will not “receive” it for about 3-4 months if they work on it full time (provided that there is something other than messages request style). The real problem arises when trying to make a mapping from a database database and / from another ACORD WS. All carriers, suppliers and agencies have their own rules.

My best suggestion is to find working code examples (I have tons if you need them) and maybe even a provider or operator who will let you connect to ACORD ws in a test environment.

Answer 3

I worked with Accord PCS reporting standards and yes, it was a nightmare. I have also worked with other major standards such as FPML and SportsML.

You need to determine exactly which types from the required circuit. How you do this is up to you, but the viewer of the VS circuit should be able to handle this. If you do not try XmlSpy or just go through it manually if you need to. Make sure you have a good ba ...

Most likely, you will find that you can satisfy your requirements using about 1% of the types available in the standard.

What you are likely to find is that you can express basic objects with a very minimal set of values, since most nodes will be minOccurs=0 or nillable .

Then you can use the / element switch on xsd.exe to generate code only for the types you need.

As one commenter noted, there is no easy pill to digest here. The irony is that standards should make life easier for everyone.

Answer 4

If you want to read / write ACORD documents using .NET, I just stumbled upon the "IVC Factory Software for ACORD Standards" on CodePlex at http://ivc.codeplex.com .

From the limited documentation, it seems that this library can convert objects to ACORD XML documents and vice versa. The source code comes with different "providers", that is, different types of ACORD transactions, such as 103 or 121.

Hope this helps.

Answer 5

I would recommend not creating a model for the whole standard. You can simply pass the XML, rather than being serialized into a model, and instead load it into XDocument / XElement and use Linq to query it and update the DOM using Linq for Xml. Thus, one does not load XML into a strongly typed model, but simply loads XML. There is no model, only an XML document.

From there, you can select data from XML as needed.

Using this approach, the code will be ugly and not have much context, since XElements will be passed everywhere, and there will be a lot of XPaths magic strings for querying and defining elements, but it can work. In addition, everything is a string, so for converting to numbers, dates, etc. Utility conversion methods will be used.

From my perspective, I modeled the Acord part in the object model using the XmlSerializer, but these are over 500 classes. The model was not equipped with XSD or another, but was created manually and took some time. The tool will produce monsters of unusable classes (as you already mentioned) and / or because of collapse. As an example, I tried loading XSD into Stylus Studio, and it crashed several times.

So, your best bet, if you are time-bound, is loaded into an XDocument, rather than trying to display everything in the model. I know this sucks, but Acord as a whole is essentially a huge mess of data.