Innovyze Workgroup Products - Product Architecture

Transcription

1 Workgroup Products Product Architecture InfoWorks ICM V5.0 InfoNet V15.0 May

2 Table of Contents OVERVIEW 3 WORKGROUP PRODUCTS ARCHITECTURE 4 Key Components 4 Workgroup Client 4 Workgroup Data (optional) 4 Network License (optional) 4 InfoWorks ICM Simulation Agent (InfoWorks ICM only) 4 InfoNet Exchange (optional InfoNet only) 4 InfoNet Mobile (optional InfoNet only) 4 Key Concepts for Workgroup Clients 5 Master Database 5 Transportable Databases 6 Local Working Folder 6 Local Results Folder 6 Remote Files Root 6 Remote Results Root 6 InfoWorks ICM Agent Working Folder 7 Typical Workgroup Configurations 8 Standalone Database 8 Workgroup Database Standard 10 Workgroup Database Oracle / SQL 11 Workgroup Database Citrix / Terminal Setup 12 INFOWORKS ICM SIMULATION AGENT 13 INFONET MOBILE 16 Key InfoNet Mobile Components 16 ISRM_S - Routing Service 16 MDS_S - Mobile Data 16 WIA_S - InfoNet Adapter Service 16 Databases 16 Service Interface 16 INMSC 16 Operational Overview

3 Overview Workgroup products are composed of several inter-related parts. These parts may be used independently or together. The particular IT architecture which is used will depend on the needs of the organisation and its users. This documents some of the common configurations which could be considered. Note that while the diagrams in this document shows the separate components of the Workgroup product, this does not imply that each component is required to be run on a separate computer. The decision on how to distribute the components across machines will depend on the particular requirements of the system

4 Workgroup Products Architecture Key Components Workgroup Client The Workgroup Client provides the user interface for both InfoWorks ICM and InfoNet. The behaviour of the client and the data which it is able to manipulate will depend on whether the client is run in InfoWorks ICM mode or InfoNet mode. This mode is controlled by starting the application via the appropriate shortcut under the start menu. Workgroup Data (optional) The Workgroup Data is a required component for all Workgroup database configurations. The Coordinator runs as a Windows service and manages access for all data in the Master database. See the Workgroup Data Administration document for details on configuring this component. Network License (optional) Manages the licenses for Workgroup Desktop Clients, Simulation Engines, InfoNet Mobile, InfoNet Mobile Office and InfoNet Exchange. The server may be run on a separate machine. The server must be visible to all InfoNet Desktop Clients which are not using a local license dongle. InfoWorks ICM Simulation Agent (InfoWorks ICM only) The InfoWorks ICM Simulation Agent runs as a Windows service and manages communication between the Workgroup Client and the InfoWorks ICM Simulation Engine. The simulation agent (and hence the simulation engine) may be running on the same machine as the workgroup client or on a completely independent machine. This allows simulations to be carried out on standalone machines or shared workstations/servers as desired. InfoNet Exchange (optional InfoNet only) InfoNet Exchange provides a Ruby Scripting API for automation of data transfers between the InfoNet networks and 3 rd Party systems. This component is required by InfoNet Mobile for communication between the Mobile and Desktop environments. InfoNet Exchange acts as a UI-less client, usually under a separate login from normal users. InfoNet Mobile (optional InfoNet only) The InfoNet Mobile acts as the point of contact for InfoNet Mobile Client devices. It monitors the InfoNet Master Database for new scheduled tasks and other data that should be passed to InfoNet Mobile devices in the field. It also responds to data uploaded from client devices and updates the InfoNet Master Database with the latest information generated by Mobile users

5 Key Concepts for Workgroup Clients Master Database The Master Database is the name given within the Workgroup Client application to the primary database in use at any given time. It is possible to access other Guest databases in order to enable data transfer between the databases, but editing of the contents of database objects is restricted to objects within the Master Database. There are four types of Master Database supported within the workgroup architecture: Standalone Database This database is intended for use by individual users or very small groups of users. Data transfer between the Workgroup Client application and the database utilises the Windows File Sharing protocol, with none of the performance benefits available when using the other database types. The use of the Windows File Sharing protocol makes this database type appropriate for use only on a stand-alone machine, or over a reliable and low latency Local Area Network (LAN). Standard (Workgroup) Database The Standard Database is intended for use with large numbers of users. This database configuration requires the use of the Workgroup Data software, running as a service on the machine hosting the database. All communication between the client and the Workgroup Data uses the TCP/IP protocol, providing a robust communication mechanism appropriate for use over Local Area Networks, or via Wide Area Networks. In addition, data is transferred in a compressed format, enhancing the performance for communications with the database. Oracle (Workgroup) Database If desired, it is possible to host Master Database information within an Oracle database. This configuration also requires the use of the Workgroup Data running as a service on a machine local to the Oracle database. Once the Workgroup Data is configured, the use of the software and the benefits of the configuration for the end user are the same as for the Standard database. The ability to make use of Oracle s administration and backup tools can provide additional administrative advantages for an organisation. Note that the Oracle client software will need to be installed on the machine running the Workgroup Data for access to the Oracle database. For details of hosting an InfoNet database in an Oracle environment see the Workgroup Data Administration guide. SQL (Workgroup) Database It is also possible to host Master Database information within a SQL database. This configuration also requires the use of the Workgroup Data running as a service on a machine local to the Oracle database. Once the Workgroup Data is configured, the use of the software and the benefits of the configuration for the end user are the same as for the Standard database. The ability to make use of SQL s administration and backup tools can provide additional administrative advantages for an organisation

6 For details of hosting an InfoNet database in a SQL environment see the Workgroup Data Administration guide. Transportable Databases Transportable Databases allow data to be moved between independent Master Databases. Databases objects may be copied from a Master Database into a transportable database for transfer to a remote Master Database where they can be copied into the new Master database. Transportable databases can only be used for data transfer. It is not possible to open objects directly from a transportable database using the Workgroup Client. Local Working Folder Each Workgroup Client requires local storage for working files. This is allocated on a per user basis. In a set up where each client runs on a separate machine the default location for this storage will be the user s local application data directory. Although this location may be changed (for example to allow backups) the location must stay local to the machine running the client or serious performance issues will ensue. In a Citrix/Terminal environment, each user s Local Working Folder should be configured in a location such that a Workgroup Client running on any Citrix /Terminal will have fast access to the data in this folder. The details of this configuration will depend on the particular Citrix/Terminal Services configuration. Local Results Folder In addition to the Local Working Folder, each user of InfoWorks ICM has a Local Results Folder which provides storage for simulation results. Like the Local Working Folder, the default location for this storage will be the user s local application data directory and all the comments above in regard to the Local Working Folder apply also to the Local Results Folder. The separation between the two is because results files tend to be very much larger than working files and so it is useful to allow them to be stored in a different location with different backup criteria. Remote Files Root The Remote Files Root defines an optional storage area for data which is not stored within the database but is referred to by the software. If GIS Layer files and hyperlinked files are stored in the Remote Files Root, Layer List and Hyperlink paths will be saved relative to the Remote Files Root. This allows the location for these items to be changed without breaking links to the files within the software. Remote Results Root The Remote Results Root defines a storage area for InfoWorks ICM simulation results that is shared between all users. Use of this area is optional (the default is to store each user s simulation results in their Local Results Folder) and requires appropriate configuration of the InfoWorks ICM Simulation Agent

7 InfoWorks ICM Agent Working Folder The InfoWorks ICM Agent requires a folder in which to keep working files for managing jobs, input files for the simulation engine and simulation results files awaiting transfer to a different agent. The default location is the standard location for Program Data on the machine that the agent is running on (this location varies according to the version of Windows on Windows 7 and Windows Vista it would be C:\ProgramData\\InfoWorksAgent). The agent automatically deletes results files after they have been downloaded and other files are removed after the job has completed or as part of a housekeeping process if they are older than a certain age (by default, 14 days). On remote agents there is potential for results files to build up if agents that request jobs do not connect and download the results in a timely manner. In this case, it may be desirable to choose a non-default location for the agent working folder in order to increase storage and/or manage backup (backup of the working folder is not recommended, due to the large and transitory nature of the files stored in it.) - 7 -

8 Typical Configurations Four typical workgroup configurations are described below. These are: Standalone database (no Workgroup Data ) Workgroup database with standard database Workgroup database using Oracle/SQL database Workgroup database (any type) with Citrix/Terminal clients These typical configurations include optional InfoNet components but not the InfoWorks ICM Simulation Agent. Configuration of InfoWorks ICM Simulation Agents is largely independent of database configuration and is described in a separate section of this document. Standalone Database Standalone databases are designed for use by a single user, they are not recommended for concurrent use by multiple users. Standalone databases may be located on the hard drive of the client PC or maybe located on a file server provided that the network connection to the file server is fast and reliable. Standalone databases should not be used where the link between the client PC and the file server is via a WAN connection i.e. where the client PC and the file server are not in the same location. In this circumstance a workgroup data server should be used, even if only one user is using the software. The diagram below shows the relationship between the key elements of a standalone database configuration using a Local Area Network. Optional elements are shown with a dashed border. Communications made using the TCP/IP protocol are shown as solid lines. Communications using the Windows File Sharing protocol are shown as dashed lines. Note that if the database is to be used by only a single client, it is possible for the database to be located on the client machine rather than on a network drive

9 Network License Workgroup Desktop Clients(s) InfoNet Exchange InfoNet Mobile File server WGC Data Store Remote Files/Result Root TCP/IP File Sharing - 9 -

10 Workgroup Database Standard The diagram below shows the relationship between the key elements of a standard InfoNet setup using a Local Area Network. Optional elements are shown with a dashed border. Communications made using the TCP/IP protocol are shown as solid lines. Communications using the Windows File Sharing protocol are shown as dashed lines. Network License Workgroup Desktop Clients(s) InfoNet Exchange Workgroup Data InfoNet Mobile WGC Data Store Database File server Remote Files/Result Root TCP/IP File Sharing

11 Workgroup Database Oracle / SQL The diagram below shows the relationship between the key elements of a standard InfoNet setup using a Local Area Network. Optional elements are shown with a dashed border. Communications made using the TCP/IP protocol are shown as solid lines. Communications using the Windows File Sharing protocol are shown as dashed lines. Network License Workgroup Desktop Clients(s) InfoNet Exchange Workgroup Data InfoNet Mobile Oracle/ SQL Database WGC Data Store Remote Files/Result Root TCP/IP File Sharing Database File server

12 Workgroup Database Citrix / Terminal Setup The diagram below shows the relationship between the key elements of a Citrix or Terminal based InfoNet setup. Optional elements are shown with a dashed border. Communications made using the TCP/IP protocol are shown as solid lines. Communications using the Windows File Sharing protocol are shown as dashed lines. Note that unlike other configurations, a network dongle is required for use within a CITRIX or Terminal Services environment. Desktop Clients Workgroup Client Workgroup Client Network License Citrix/Terminal InfoNet Exchange Workgroup Data InfoNet Mobile Data Store/ Oracle/ SQL Database Database server File server Remote Files/Result Root TCP/IP File Sharing

13 InfoWorks ICM Simulation Agent The InfoWorks ICM simulation agent (InfoWorksAgent.exe) manages the execution of simulation jobs on the client machine and/or on remote workstations or servers. It runs as a Windows service under the Local System account (by default) and so an agent on a client machine (a Local Agent) can continue to prepare and run simulation jobs even after the Workgroup Client has disconnected and the user has logged off. Similarly, agents running on non-client machines (Remote Agents) do not require a logged-in user in order to carry out simulation jobs as directed by a single, central agent (the Simulation Agent Coordinator). The following diagram shows the principal processes, user accounts, storage areas and communication protocols involved in carrying out simulations using a single client machine communicating with remote machines running a Simulation Agent Coordinator and a Remote Agent. A Workgroup Data is optional (a standalone database can also be used). The use of Remote Agents and/or the Result Files Root is also optional but, if used, one of the agents must be configured as the Simulation Agent Coordinator. File Sharing refers to both local and network file storage. Client machine Network License User Account Workgroup Client Local Results Folder Local System Account Local Agent Remote Agent Agent Working Folder Agent Working Folder Simulation Agent Coordinator Workstation or Agent Working Folder Standalone or Workgroup Database Database server File server Remote Results Root TCP/IP File Sharing Pipe

14 When launching a simulation job, the user selects which agent (or group of agents) the job will be submitted to and the agents do the rest, placing the results in either the Local Results Folder or the Remote Results Root as specified by the user. The full sequence of events involved in running a job is shown in the boxed text below. Steps involved in running a simulation job The user, logged-in under a user account and running the Workgroup Client, creates a Run object in the Master Database and uses this to schedule one or more simulation jobs on either the same computer or on a selected group of agents. The Workgroup client passes the job details to the Local Agent via a pipe and the agent places the job in its job queue. For each job in the queue, in turn, the Local Agent runs the Simulation Preprocessor, which extracts the necessary data from the Master Database and prepares the input files needed by the Simulation Engine. If the job is to run locally, it waits in the queue for a simulation slot to become available. If it is to run remotely, the Local Agent passes the job details to the Simulation Agent Coordinator. For a remote job, the Simulation Agent Coordinator checks whether any of the agents in the specified group is ready to run a simulation. If so, it instructs the Local Agent to upload the input files directly to the Remote Agent. Otherwise, the input files are uploaded to the Coordinator, where they wait in a queue for a Remote Agent to become available. When it does, the Coordinator uploads the input files to that agent. When a job, local or remote, is ready to run on an agent, the agent runs the Simulation Engine, which acquires a licence from the local or network dongle, reads the input files and starts producing results. Progress information is sent to the agent(s) and if the Workgroup Client is still connected, the user can monitor the progress of the simulation, pause it and step through it as required. Otherwise the job simply runs to completion and notifies the agent(s) and client that it has finished. For a local job with local results, the results files are written directly to the Local Results Folder and are available immediately for viewing by the user. For any other jobs, the results files are automatically downloaded from their initial location (the agent s working folder) to their final location (the Local Results Folder or Remote Results Root as appropriate). The Simulation Agent Coordinator manages downloads to the Remote Results Root and the Local Agent manages downloads to the Local Results Root. Once these downloads have completed, the results are available for viewing by the user. The computers involved in running a simulation job can disconnect from one another at any time without disrupting the simulation process if necessary, the agents simply wait for the connection to be remade in order to resume the job and can continue to process other jobs in the meantime. Likewise, if a computer is shut down it will resume processing jobs when it restarts (although any simulation already running in the engine will have to start again from the beginning)

15 For simplicity, the above diagram shows a Local Agent, Simulation Agent Coordinator and Remote Agents running on separate machines. However, any agent can act in any of these roles if appropriately configured (although only one can be Coordinator). Thus an agent can be a Local Agent for clients on the same machine and at the same time act as a Remote Agent for clients on other machines. Simulation agents can manage multiple simulation jobs from the same or different Master Databases at the same time. The only components that need to access a Master Database directly are the Workgroup Client and the Simulation Pre-processor (simprep.exe). The latter is required for any agent that is to be a Local Agent and is included in a full install of InfoWorks ICM. It is not required for an agent that is to be used only as a Remote Agent or Coordinator and so is not included in the smaller and simpler Agent-only install of InfoWorks ICM. Note that the Simulation Agent Coordinator (which coordinates simulations across agents) should not be confused with the Workgroup Data (which manages access to the Master Database from Workgroup Clients). For details of installation and configuration options refer to the document InfoWorks ICM Simulation Agents Installation and Configuration Guide

16 InfoNet Mobile Key InfoNet Mobile Components ISRM_S - Routing Service This is a soft router and has one port exposed typically to the internet. ISRM_S then decides whether a received message is valid and will try to forward the message to the relevant service if deemed to be valid, otherwise the message will be ignored. MDS_S - Mobile Data Processes requests and streams data for all InfoNetMobile and image based requests. Also handles login requests etc. Writes versioned files and streams files to/from InfoNet extras directory. WIA_S - InfoNet Adapter Service Manages and controls all interaction with InfoNet by invoking Infolite/IExchange and creating/processing supporting and resultant files. Controls all work builds / report generation etc. Commands are processed in a queue Databases These are interacted / connected to only by MDS and WIA_S. Client applications make no direct contact to the SQL databases. Main databases are the User database, MeterStream and ISInfonet. Service Interface Monitor the status and some control of the services MDS_S and WIA_S. Communicates through ISRM_S so remote connection through existing ports is established. INMSC Configuration utility for configuring ISRM_S, MDS_S and WIA_S. Also used for configuring dongle setup for InfoNet mobile server side components. Important Note The constituent components to run InfoNet Mobile as a standalone system (i.e. not integrated with InfoNet) are ISRM_S and MDS_S with the SQL databases. For an integrated system then WIA_S is also required. The system is designed to be modular and so each component may reside on the same or different machines

17 Communications All data transfer between client applications and ISRM_S, and ISRM_S to MDS_S and WIA_S are tcp/ip. The payload of the data is encrypted (typically Rijndael on Windows devices) to protect the contents and data message integrity is provided by a checksum. Data connectivity to the SQL system is typically tcp/ip connected. Only the services MDS_S and WIA_S connect directly to the SQL databases. External / Mobile Devices DMZ ISRM_S WGC Data Store MDS_S WIA_S InfoNet Exchange Network License Stored Procedures ISInfoNet User Database MeterStream SQL Databases Operational Overview Scenario - A work order is created in InfoNet. In order for a report to be created in InfoNet Mobile a form must exist that is a template for the report, i.e. we are to create a report with information from InfoNet. A decision must therefore be made as to which form should be used for this information to create a pre-filled-out report? Assuming we have a template, then a report is created and as much data as is exported from InfoNet will be entered into the data fields of that report. The report would then be downloaded by a mobile client application, where the filled in data would be visible. The remaining data required can then be entered and the report

18 saved/finished. Until the report is uploaded from the client to the server, the server and any other users do not know of the newly entered data. Once uploaded, the report data can be acted upon and formatted into csv data files and imported into InfoNet. Following this an export of the changes (or a specified export if no changes occurred) can be instigated and the resulting exported data compared to the data that was imported. This is termed the validation of the report. Mismatches / truncations of the data are noted and can be reported back to the server administrator. Report Versions in InfoNet Mobile Report versions start at version 1 whether originating from InfoNet or from the mobile application. Consider a report created in InfoNet and subsequently created in InfoNet Mobile. If user A downloaded the report and user B downloaded the report, they would both have version 1 of the report. Assume now that user A fills out some data and uploads the report creating version 2. Now user B fills out some data and uploads the report, this would create version 3 and overwrite any data in InfoNet. Consider a report created in Infonet and then in InfoNet Mobile as version 1. Then the data in InfoNet was changed; if the report version 1 had not been downloaded by any end user then the version 1 content would be updated. If however a user had downloaded the report version 1 then a version 2 would be created