Some questions you need to ask your self:

• What is the flow of control - which system calls which system?

• Which system holds the master data?

• Synchronous or asynchronous operation?

• What technology is available / feasible? Webservices (SOAP or REST)? Direct database access using SQL? Message quese? File exchange? Pros and cons?

• An application built with TOPICA should connect to / control some external synchronously.

  • Determine WHEN integration should occur - e.g. on what event in a TOPICA application, a call to the external system should occur. Some of the choices are:

    • A TOPICAmodule should run inside some other application - Integration with Context Manager.

    • Integration with external / central login provider systems ("custom login methods") - see Integration with Login Provider.

    • Integration with external National ID service - see Integration with National ID Service

    • When a configured form is displayed, data should be automatically collected from external system(s) - e.g. to be used for default values of some fields. The options are:

      • Pre-processing

      • AJAX.

    • From within a configured form, the user should be able to initiate some functionality to interact with some external system. The options are:

      • Add a button that pops up a new window containing a custom webform to disply a custom user interface.

      • Add a PostBackButton that saves the dataa entered in the form, and redirect to at custom webform to disply a custom user interface.

      • To colect data from the external system, at put this data into fields of the configured form, use AJAX.

    • When data in a configured form is saved to the database, data should be sent to some external system.

      • Post-processing.

      • PostBackButton.

      • To implement integration on the database level, you may use database triggers.

        Note
        Integration on the database level will bypass all security, rules, etc. in the TOPICA application!

• An external system must control the TOPICA application, using web services.

  • Find out which TOPICAwebservice method(s) to use.

    Check if some of the built-in or auto generated webservices may do the job. If not - you may develop your own custom webservices.

  • Write some code in the external system to call the webservice method(s) in the TOPICA application. How to do that is naturally out of scope of this documentation.

• Long running "batch" operations (e.g. to process queued tasks, nightly synconizations wiht external systems etc.) - Some obvious choices include:

  • Develop SSIS packages and use Windows' task scheduler to run these SSIS packages.

  • Develop custom executable programs (e.g. "command line programs" = .exe-files) and/or Windows batch /command filss, and use Windows' task scheduler to run this SSIS packages.

  • It is also possible to develop database jobs, that may be run in a schedule. This is typically of limited use for integrations purposes, because the datbse server typically does not have access to external ressources (for security reasons).

• It may be possible / feasible to access the database of a system (the external system or the TOPICA application) directly. In this case you may use SQL to get/modify data in that system. In some situations, this may be the easiest way to implement an interface.

  Note
  When acessing the database directly, you often circumvent some application logic (security, logging, etc.)

• A system may have some webservices defined (SOAP or REST protocol). This is a very common way to allow for integration. TOPICA exposes 3 kind of SOAP webservices:

  • Built in.

  • Auto-generated.

  • Custom.

  Future releases of TOPICA will also expose REST webservices.

  Using webservices to implement integration normally involves adhering to a certain protocol. The TOPICA webservices are no exception.

  • Any conversation must start with a call to a login method. If successful, this call will create a login session, and return an identification of this session (a GUID) to the caller.

  • Any further calls must supply this session GUID.

  • At the end of the conversation, a logout method should be called - this will terminate the session.

• Many other options exist - e.g. using message queue systems, file exchange using FTP / SFTP, etc.

Note that the above technology options are not mutually exclusive. To implement on e interface between two systems, several of the above technology options may be used.

Other Resources