Interfacing the EnterpriseROR™ FOM

Underlying Methodology...
The FOM is an multithreaded ISAPI application written in C++. It has a SOAP interface that client applications can use to make requests. A WSDL file describing the API is available upon request. The FOM may make requests to a clients data sources if it requires data that is not in its own internal cache. For more detailed technical documentation, please contact dailyVest.

FOM Wrapper Class (1)...
dailyVest provides .NET and Java classes (code) used to make SOAP calls to the FOM. These classes have been developed to facilitate client integration into an application such as WEB or PRINT. Use of these classes is recommended instead of making SOAP calls directly to the FOM. Following is a top-level system block diagram...

FOM Results...
In response to requests, the FOM produces an XML document. This document can then be transformed to HTML via XSLT, and thus embedded within a user interface inside the Client Application. Sample XSL files are provided and can easily be customized. As for image data, the FOM produces image data in several formats including .GIF, .JPG, .PNG, .TIFF and Encapsulated Post Script (.EPS) formats.

FOM Schema...
The FOM has a data schema consisting of tables. These tables are divided into 2 categories:

1. ACCOUNT DATA – Tables which contain data specific to an individual such as transactions of unit balances.
   
   
2. GLOBAL DATA – Tables which have global or plan level data shared by users such as Price history data for a an asset.

FOM State - Account Data Storage
The FOM can serialize its account data content. This is referred to as the FOM state and is actually an XML document. For WEB applications, this state should be stored in the users session. 

FOM Cache - Global Data Storage
Data common to many users is cached in the memory of the FOM machine. This data is not included as part of the FOM state for efficiency reasons. 

Client Data Connector (2)...
The Client Data Connector helps map customer data to the FOM data schema and uses the IClientDataInterface, an interface designed to connect a customer’s data sources to the Client Data Connector.

Client Data Connector Access Methods
Currently, the IClientDataInterface accesses requested data from a customer’s data sources using three transport methods… 

1. ODBC: This transport method is practical when a customer already has similar Stored Procedures capable of providing data in a format similar to what the FOM requires. This allows the FOM to access the customer’s database directly.
   
   
2. HTTP-XML: This transport method is recommended when it is desired to have another level of extraction on top of a data tier, or when the database administrator prefers not to directly access the database. When using HTTP-XML, the request is a set of key/value pairs sent as an HTTP POST. If the value of “_compressoutput” is set to 1, the XML returned should be deflated and base64 encoded. Values are URL encoded – special characters are escaped with a hex value. The value of “_rpc” is used by the service to determine what function is being called. Any other key/value pairs are assumed to be parameters passed to the function. The following parameters are posted to the client’s data source by the FOM. Parameters specific to each function are specified in the Overview of Function Calls. For an example of how this is accomplished in java, please contact dailyVest for sample code.
   
   
3. Custom Access Method: Alternatively, if none of the above transport methods are practical, dailyVest will work with the customer to develop an appropriate transport method.

Sequence of Events...
The following points summarize essential events during the system process flow…

1. Client App Makes Initial Request to FOM: Client application makes initial request to dailyVest FOM for performance information. Passes customer-specific Connector Parameters needed to obtain data along with request.
   
   
2. FOM Relays Request to Connector With Added Parameters: dailyVest FOM receives request from Client application. The FOM then takes these customer-specific Connector Parameters and combines them with other needed FOM Parameters (required to access specific types or ranges of account data), all of which become part of a new, subsequent request the FOM makes to the Client Data Connector.
   
   
3. Data Connector Receives Request, Returns Data to FOM: Client Data Connector receives request for data from the dailyVest FOM. Request will usually be for transactions and holdings balances, and periodically for price history and other global investment data (such as for plan investment option information, etc.). Using these customer-specific Connector Parameters and added FOM Parameters, the Client Data Connector accesses the system of records and returns data to the dailyVest FOM according to the data schema tables defined in the FOM Schema specification document.
   
   
4. FOM Calculates Performance, Renders Reqults: Once data is returned to the FOM from the Client Data Connector in the specified schema format, the FOM calculates performance and renders results.
   
   
5. FOM Returns Results to Client App in XML Format. dailyVest FOM returns calculated/rendered information to the client application (so that it can be displayed within its interface or be used for later inclusion within a statement).