G-Life Architechture

The Architecture of the G-Life System 

 

1. General Description:

 

  • The G-Life software is modular, object oriented, inheritances, and based on a standard interface between various modules. The modules are not directly exposed to one another. The modules are in different DLL's.
  • On top of this entire platform, there is an option to customize this solution for each client. The client version inherits the layered structure, and while it uploads, it applies to the BL (business logic) of the client version and creates the layers according to the client specified implementation.


2. Detailed Description:

  1. Modules:
    • The software is divided to three main layers, the UI (User Interface) layer, the BL layer and the DB (Data Base) layer. Each layer is divided to separate modules providing services to the rest of the system.
    • The entire communication between the various modules is done only using interfaces, by transferring entities.
    • The modules can be wrapped by WCF, and they can provide various services. This kind of activity was conducted in the past, following requests from various customers.
    • The various modules are in separate DLLs, in a single solution.
        
  2. New Forms:
    • The forms in the software are based on the standard format principles for adding new forms. After our forms division manually makes each form a smart form, in a uniform and fixed manner, the forms are automatically filled in by the software, without needing any intervention.
    • The forms module – the display of the forms and their fill in method is based on our own form engine, that avoids the use of the PDF Viewer, and leaves the software in full control over the PDF file. This enables far more flexibility and functionality. The engine displays pictures with pre-programmed fields, which are dynamically read out of the PDF fields, and display their content in a dynamic manner. The user can edit and change the fields and only after he clicks Save the content is written into the smart PDF file prepared in the background.
       
  3. New Products:
    All of the insurance, pension and financial products displayed by the software are built according to a template. In order to add new product types, one should follow a template, which can be modified, in order to uniquely fit a specific product.
     
  4. External Interfaces:
    The system supports two mechanisms for external interfaces:
    • Import and export – a 2Team unique format – the process of import and export is absolutely generic, and it is based on object reflection. 2Team provides mapping for developers of external systems, so they can create a client data interface or an existing client portfolio interface in 2Team's format.
    • Import and export – various systems (CRM and other Back office Systems) – In addition to providing its own format for import and export, 2Team also adapts to import and export formats of other back office systems. This process is semi-generic, since for this transfer, we add attributes, which are specific to the relevant properties, to make the system recognize of the format it should create.
     
  5. Calculation engines:
    • The engines and the calculations are data driven.
    • The tariff update, the pension codex and the addition of a new product, shall mostly entail only a table update.
    • The pension engines: the pension engines are based on one common basic engine, which inherits attributes to engines of various pension funds. For each engine, decisions about the functionality that should be changed in relation to the basic engine, and the functionality that should be maintained is made.
    • The insurance and finance engines: All of the calculations of the insurance and finances are conducted by a few shared engines.
    • There is an engine for the universal life product, for various risk products, for financial plans, for real estate, and for various types of combinations between savings and risk products type.
    • There is an engine for classic products (old kind of product).
    • All of the data required for the calculation (tariffs, allowances, risk costs, descending management fees, etc.) are kept in the database. These data are loaded into a different thread of the memory, as the software uploads (or upon demand). During the calculation, there is no access to the database, in order to improve the performance of the software.
    • The entire work of the engines is conducted with the cache memory, there is no direct work of the calculation engines with the DAL, in order to maintain the best possible performance.

Product Description
Highlights

G-Life Architechture