1. Physical model of integration

    Article: AN0001593Updated:

    1. Sending email by means of SMTP server

    ObjectGears system sends emails be means of .Net functions. It enables to store the email before sending out into the database for future audit. At the same time it is possible to send all the outgoing emails to a blind copy for future check, wheather the email was really sent. These two simple audit mechanisms are proven at solving disputes, wheather the email was sent or not.

     

    2. Reading email from MS Exchange mailbox and storing obtained data into ObjectGears class

    ObjectGears system enables to read emails from Microsoft Exchange server and storing them into the database. The corresponding record can be adapted by a script before saving. After saving into a class it is possible to start workflow or script by means of rules and respond further to the input email. This functionality can be in case of need implemented for whatever email server.

    3. Event in an external system

    External system can:

    1. Call ObjectGears web service
    2. Call ObjectGears URL
    3. Read ObjectGears API view
    4. Use another form of database integration

    3.1 - Calling OG web service

    You can read class or query data by means of web services. You can insert data into classes, change or delete these data. Access rights of the account, under which the web service is called, are fully reflected same like in case of user working with ObjectGears web interface - roles, granted to the account, and position of the account in organization structures.

    3.2 - Calling OG URL

    You can display whatever system page by means of URL. Data pages can be set up in such a way that they take over values from URL and fill in the detailed form by them. This scenario is suitable e.g. for click on link from email, when there is a filled in form displayed to the user. The user can then only fill in further information and save the record.

    By means of URL it is also possible to execute a previously defined script or raise event, that ensure continuation of workflow, that waits for this event. These workflow events are used for synchronization between more systems.

    3.3 - Reading API view

    On the database level you can read data directly from system tables. However, these tables are called in the internal convention, which is not very transparent. These names also differ between develop, test and production instance. This is why there are API Views, which are views build over system tables, but called by class and coloumn codes. These codes are same in all system instances, which increases portability of your database extensions and integrations.

    3.4 - Another DB integration

    ObjectGears system does not hide anything and therefore integration can be done also on the database level. It is possible to read data from or write to class tables (tables DataRow...), replicate tables between more system instances, use triggers in tables etc.

    When using these extensions take care of not violating system functionality.

    4. ObjectGears event

    User can trigger call of an external system or other actions displayed in the picture. The user interacts with ObjectGears application server.

    ObjectGears Windows service performs regular starting of jobs and workflow and reading data from mailboxes. By means of jobs and workflow the windows service can write to the file system, start imports and exports, call web services, URL or external .Net code.

    There can be a trigger placed on ObjectGears table, that can lead to integration on database level.

     

    5. Batch integration

    Mass data exchange can take place between:

    1. ObjectGears and filesystem by means of imports and exports.
    2. ObjectGears and external system (database) by means of synchronization on database level.

     

×