In this short How-to guide we will show you with an example how to handle Financial products Markup Language (FpML). These articles assume you understand the basics of XML Schema Definition language. If you don’t there are a number of good tutorials available on the internet. For example there’s a good one here
FpML is an open source industry standard for sharing information on, and dealing in, financial derivatives and structured products. By leveraging FpML you gain from decades worth of financial modelling expertise and production use. Whether you are creating a new model from scratch or maintaining an existing model, you will benefit from FpML’s insights into the problem domain.
The XML representations of financial products are defined using XML Schema Definition (XSD). These can be downloaded from the site.
Just as characterizing designs for a wide scope of exchange types, the FpML XSDs characterize message designs for standard exchange occasions (for example affirmations, credit occasion notices). They likewise characterize standard specifications for such things as day tally shows. Subsequently this FpML is unavoidably unpredictable and hard to comprehend. Moreover there's little up to date and free documentation accessible.
The XSD characterizes various namespaces, sets our targetNamespace for the pattern, and incorporates various other XSDs from the arrangement of FpML XSDs. It characterizes one complex sort, ValuationDocument. Complex types possibly need to show up in the XML on the off chance that they are referred to as the type of an element, ValuationDocument doesn't need to show up in any XML just by being in this document.
The schema at last characterizes the one required high level component in this document, which is a component called 'FpML' which is of type 'Archive'. In the event that we grow the FpML component definition we think that its simply contains a comment. So basically this blueprint is saying is that our root component for a FpML record should be called 'FpML' and it should be a Document.
Most FpML exchange archives will have the overall design beneath, as we will see. That is, the root FpML component will contain an exchange component and various gathering components. The trade element will contain a tradeHeader element, and an element that addresses a particular item. For other item types the element will simply be substituted with some other item component.
So, in a FpML document we have a root element called 'FpML' that must be of type Document. Record is abstract, and one extension is DataDocument, which can contain an element called 'trade' of type Trade.
We have a 'swap' element in our XML report where there is a 'product' element in the XSD. We can place the swap element in there due to the replacement bunch sentence structure: we simply substitute the swap element for the product element. Be that as it may, the swap element is additionally of type Swap which broadens type Product, so it should assess the Product definition also.
Product itself is abstract, has an id quality and contains a named bunch called 'Product.model'. Be that as it may, the entirety of this is discretionary.
1. The first step is to create a console project in Visual Studio and add the FpML schemas, in my case I've manually filled a rudementary version of a data file following the main xsd file, or if you wish you could also do this on the main xsd file.
2. Then, to generate the code, choose the XML schema corresponding to the document you want to produce, in this example it is the invoice. A simple right click on the schema allows you to access the code generator settings :
3. The important options are the activation of XML attributes and the read and write method of XML serialization
4. Enjoy ! Just in case you didn't know, this will generate a class with attributes based on the xml, JSon, BSon or Messagepack data file or schema, with serialization enabled you will have the serialization and deserialization functions in the class depending on which formats you've enabled.
From there depending on what your needs are you can, through c# and the generated functions, code your program to generate the files you need in the right way following the class that has been generated from either the schema or a data file, thanks to Xsd2Code you can stick with the Xml and switch to or add other formats like JSon.
A sample implementation is available on GitHUB. We provide a set of examples based on schemas and standards such as FpML or UBL.
CodeNGine Technologies, 19 Avenue, de la gare, 34770 Gigean, France. SIRET: 85257252800010, VAT : FR 62852572528
About the company
CodeNGine Technologies is software company based in the South of France that provides an advanced productivity code generation tool to developers using XML and JSON
Copyright © 2021 CodeNGine Technologies