Click or drag to resize
* Operations Architecture

[This is preliminary documentation and is subject to change.]

Requirements and recommendations for establishing a production environment for applications built with TOPICA.

Sections:

Required software
  • Operating system (for all types of servers):

    • For production use, Windows 2008 R2 Server is recommended. System will also run on Windows 2008 R2 Server and Windows 2003 Server.

    • For development use, Windows 7 Enterprise is recommend. System will also run on Windows XP Professional and (probably) Windows Vista Professional and Windows 10 Professional

  • Web server software:

    • Internet Information Services (IIS) is required. IIS version 7.5 is preferred. TOPICA will also run on versions 6, 7 and (probaly) version 8.

    • Depending on the version of the TOPICA framework, difterent versions of the .NET framework (runtime) must be installed.

      TOPICA versions

      Required .NET version

      ??? -> ???

      2.0

      ??? -> 4.14

      3.5

      4.15 -> 4.23

      4.0

      4.24 -> ...

      4.5

    • Note Note

      Releases 4.23 and older require installation of ReportViewer version 9. This component enables TOPICA to run Reporting Services reports. Note that it MUST be installed on the web server, even if Reporting Services reports are not used in any the configurations!

      In releases 4.24 and newer, the ReportViewer components are distributed with the TOPICA, - no further installation is necessary.

  • Database server software:

    • SQL Server versions

      • SQL Server 2008 R2 is recommended. Relational engine, SSRS, and SSIS have been tested in production environments.

      • SQL Server 2008 may be used, too. Relational engine, SSRS, and SSIS have been tested in production environments.

      • SQL Server 2012 Relational engine has been tested in development environments, not production. SSRS and SSIS have not been tested.

      • SQL Server 2014 Relational engine has been tested in development environment (using the Express Edition), not production. SSRS and SSIS have not been tested.

      For development purposes, the Express versions of the above mentioned DBMS'es may be used locally.

  • Reporting Services

    • SQL Server 2008 R2 Reporting Services (part of the SQL Server 2008 R2 distribution) is recommended.

      SQL Server 2008 Reporting Services and SQL Server 2005 Reporting Services may be used, too (with some limitations).

      Reports developed in SQL Server 2005 Reporting Services format will obviously run on SQL Server 2005 Reporting Services.

      Reports developed in SQL Server 2005 Reporting Services may be deployed on SQL Server 2008 Reporting (R2) Services - such reports are converted to SQL Server 2008 Reporting Services format in the process. I.e. "backward compatibility" exists.

      Reports developed on SQL Server 2008 (R2) Reporting Services cannot be deployed on SQL Server 2005 Reporting Services. I.e. there is no "forward compatibility"!

      It is possible - although not advisable - to mix SQL Server versions: use SQL Server 2008 Relational Engine for the database, and use SQL Server 2005 Reporting Services for reports - or vice versa.

Configuration requirements
  • In one instance of the framework, is is possible to install several configurations. See Configuration Folder Structure.

  • Each configuration should connect to its own database. In theory it is possible to let multiple configurations refer to the same database, provided the configuration items (especially forms and the structure file) in these configurations are exactly equal. This is important, because these configuration items define the dynamic data model. Obviously two configurations connecting to the same database must specify the same dynamic data model.

Server configuration options
  • It is possible to install IIS and SQL Server on one server - this is a typical setup for development and test.

  • For production use, where performance and security is important, it is recommended to install these components on separate machines (servers). I.e. designate one server as a web server, and a different server as a database server.

    This heightens security, because only the web server needs to be accessible from the outside (internet or protected net). The database server may be completely hidden from the outside (behind a firewall) - it only needs to be accessible from the web server.

  • An instance of the framework must be installed in a website or virtual directory in IIS. It is possible to have several instances of the framework in one IIS. For example, this may be used to run different versions of the framework on one web server.

  • Apart from disk space constraints, there are no constraints on how many databases may be put on a database server. It is normal practice to host several databases on one database server.

  • It is perfectly legal to install several copies of the same configuration (application). Configure each configuration to refer to its own database, and you have the same application running in separate environments.

    Suppose you have constructed 2 applications X and Y, and you want to run each in both production and a test environment. In this case you end up with 4 environments, that you could call Xprod, Xtest, Yprod, Ytest - each connecting to its own database.

  • Most (well-designed) TOPICA applications do not require much processing power on the server(s). If you follow the recommendations to install SQL Server and IIS on different servers, you may run several configurations (applications / environments) on only 2 servers. If for example you should run 20 configurations, you may have 20 websites on a web server running IIS, each referring to a database in one SQL Server instance.

Reporting Services
  • Reporting Services is an optional component. It is required only if the applications/configurations contain reports in Reporting Services format.

  • Reporting Services may be installed on a server of its own (a server dedicated to Reporting Services), or it may be installed on one of the servers already used as web or database server (see above).

    The server running Reporting Services is called "report server" below.

  • For development/test environments, it is possible to use same (physical or virtual) server as web server, database sever and report server - i.e. it is possible to run IIS, SQL Server Relational Services and SQL Server Reporting Services on the same box.

  • Reporting Services is constructed for web access. Reporting Services 2008 contains its own web server - the 2005 version relies on IIS. Each Reporting Services instance contains two web homes:

    • A web user interface for running reports ("Report Manager").

    • A web home containing webservices ("Report Server") - this is used for the following purposes:

      • Used internally by Report Manager.

      • Programmatic launching of reports from other applications (TOPICA is an example of such an application).

      • Deployment of reports from the development environment (Visual Studio).

    Launching of Reporting Services reports is integrated into TOPICA. This means, that end users should never use Report Manager to launch reports. So in theory Reporting Services does not have to be accessible from the outside.

    However, configurators configuring and deploying reports will need to use Report Manager for configuring report folder structure, database connections, etc. Thus Report Manager should be accessible form the outside. Therefore, it is advisable to set up Reporting= Services so that it is accessible from the outside.

  • So, in production settings, where the web server is accesible form the outside and the database server is not, it is recommended to install Reporting Services on the web server - or on a separate server (that is accessible from the outside).

  • Reporting Services manages its own database connections (using DataSources). When running one application in N environments, each report must access N different databases. This may be solved in one of these ways:

    1. Set up one Reporting Services instance per environment (database).

      • Deploy reports in the application to each Reporting= Services instance.

      • Configure the data sources (using Report Manager) in each Reporting Services instance to connect to different databases.

      • Configure each TOPICA environment (in the Server.config file) to connect to each Reporting Services instance.

    2. Set up one common Reporting= Services instance for all environments (databases).

      • Construct all reports with parameters, so that they may construct connection strings dynamically.

      • Note: there may be security issuses involved in passing database passwords as parameters to reports.

      • Configure all TOPICA environments (in the Server.config file) to connect to the same, common Reporting= Services instance.

Example configurations
  • Development / test scenario:

    • 1 common server.

    • 2 framework versions (instances) - one instance runs 1 configuration, the other runs 2 configurations.

    • All configurations use Reporting Services (separate instances).

    TOPICA Operations - 1 server scenario
    Topica drift 1 server
  • Production scenario:

    • Separate web and database servers.

    • 2 framework versions (instances) - one instance runs 1 configuration, the other runs 2 configurations.

    • All configurations use Reporting= Services (separate instances - installed on the web server).

    Topica Operations - 2 server scenario
    Topica drift 2 server
IIS setup

When running N environments on one web server, you have the following choice:

  • One framework instance (= one web home) running several configurations / environments.

    • Advantage: Only one web home makes updating to newer framework versions easier.

    • Disadvantages: All environments run in same Application Pool (because they run in same web home). An error may require "recycling" of the Application Pool - so an error in one environment will requiere "recycling" of all environments. Since there is only one web home, all environments will have to run same version of the framework.

  • N framework instances, each running one environment.

    • Advantage: Each environment runs in its own web home, and may then run in each's own Application Pool. An error in one environment will not influence the other environments. The environments may run different versions of the framework.

    • Disadvantage: When upgrading to new framework version, each web home must be upgraded.