Changes

Jump to: navigation, search

Understanding Configuration Options

2,060 bytes removed, 16:37, 7 June 2021
no edit summary
{{TOC right}}__NOEDITSECTION__To determine the initial configuration of the IMSMA<sup>NG</sup> system, it is important to understand the two ways in which IMSMA<sup>NG</sup> can be set up and the basic architecture of the system. IMSMA<sup>NG</sup> is a client-/server software application designed to run in stand-alone or networked client/server mode. In a stand-alone system, both the IMSMA<sup>NG</sup> client and server are installed on the '''same''' computer. The stand-alone configuration is the simpler type of installation: it requires no additional network equipment or infrastructure and is easy to maintain.
chart
{| class==Standalone=="wikitable"|+ Comparison of Stand-alone and Client/server Configuration Options ! Configuration! Advantages! Disadvantages|-| <b>Stand-alone</b>|* Simple to set up and maintain* Limited IT knowledge required* Can be upgraded to a client/server configuration later|* One-at-a-time data access|-| <b>Client/server</b>|* Multiple concurrent data access* Redundancy|* Complicated to set up and maintain* Local Area Network infrastructure required* Multiple computers required|-|}
In a stand-alone systemclient/server configuration, one computer acts as a server and many other computers can connect to it simultaneously over a network, both enabling multiple people to access the IMSMA<sup>NG</sup> client and server are installed on same data at the same computertime. The stand-alone configuration is the simpler type of A client/server installation: it requires no additional at least two computers and a network equipment or infrastructure and is easy to maintainconnecting the computers together. Using a client/server installation, a mine action programme can have multiple data entry clerks entering data at the same time.
figure
==[[Image:Understanding Configuration Options - Networked Configuration=Config.png|center|300px|''Client/server Config'']]<div align="center">''Client/server configuration''</div>
In {{Note| Be aware of the following when running IMSMA in a networked client-/server configuration, one computer acts as a installation:* The server and many other computers can client(s) must be running the exact same version of IMSMA.* The gisServer.properties file on the server must be configured. * The client(s) must be configured to connect to it simultaneously over a network, enabling multiple people the server. * Maps only need to access be installed on the same data at server. * Data entered into the same time. A networked installation requires at least two computers and a network infrastructure connecting server or clients will be automatically rendered to all clients (as well as the computers togetherserver). Using a networked installationHowever, geospatial information (points, a mine action programme can have multiple data entry clerks entering data at polygons) will NOT be immediately rendered to all clients. To either post your geospatial updates to the server (thus making them available to other clients) or to receive updates from the same timeserver, you must log out of IMSMA and then log back in.* Fonts will need to be installed on both the server and client(s)}}
figure==Client/server Architecture==__NOEDITSECTION__
==Decentralized Information Exchange==Whether a programme uses a stand-alone installation or a client/server installation, the IMSMA<sup>NG</sup> software has two main components:
IMSMA<sup>NG</sup> is designed to support information management in a decentralized context involving many users and groups at various sites. These users can include implementing partners, mine action operators and regional or decentralized mine action authorities. Decentralizing information management within IMSMA<sup>NG</sup> is easy and allows information managers to expand * the scope and impact of information on mine action activities. While IMSMA<sup>NG</sup> supports nearly any conceivable patterns for decentralized information exchange including multilateral exchange, peer-to-peer exchange and one- and two-direction exchange, the most prevalent pattern is that of a central mine action authority (CMA) and subordinate regional mine action authorities (RMAs). Much of server* the discussion of maintaining a decentralized IMSMA<sup>NG</sup> system refers to this typical example; however, many points apply to other information exchange patterns as well.client
The centralized pattern is characterized by one or more non-overlapping regional sites or authorities that conduct data entry and data quality control for their region. Regional sites also typically perform some regional data analysis designed to support regional operations management and planning. By contrast, figure below shows the parts of the central authority manages software; the overall data set for following sections then explain the entire country, collecting all regional information in order to perform national planning and produce national statisticsfunctions that each part performs.
figure{| border="1" cellpadding="5"|- valign="top"|[[Image:stand_alone Architecture.png|center|300px|''Stand-alone architecture'']]
Establishing IMSMA<sup>NG</sup> with the correct configuration in this complicated context of multiple users and asynchronous data exchange is important to trouble-free operations and high|[[Image:Understanding Configuration Options-quality information management. The first step in ensuring the correct configuration is to document the information management flowsClient Server Architecture.png|center|600px|''Client/server architecture'']]
In the following example, mine action field reports are entered at each regional site for the ongoing operations in that region. Field reports are reconciled, linked and approved according to the regional operations needs. Using the export functionality, the regional sites export data on a regular basis (for example, monthly) and send it to the central authority. (Regional information managers can use the search functionality to export the field reports entered since the last data exchange.) The central authority then imports the maXML files from each site and resolves any issues with the imports as well as performs quality control. When the import is complete, the central authority compiles a set of national statistics and then distributes a complete dataset (in the form of a database backup) to each of the regional sites. The regional sites restore the dataset and then import any data entered since the last export was sent to the central authority. When the backup is restored, regular data entry and exchange can continue, based on a common dataset.|}
figure===Server===__NOEDITSECTION__
This straightforward approach to decentralized The IMSMA<sup>NG</sup> server stores data exchange ensures that all sites regularly receive a complete and authoritative dataset. Other variations on this pattern are possible with varying degrees manages much of increased complexity to meet specific the data exchange needsprocessing. Regardless of The server has two main parts, the datastore and the information exchange pattern selected, there are several key aspects of maintaining decentralized business layer. The datastore is where data exchange within is stored for retrieval by the IMSMA<sup>NG</sup> client. IMSMA<sup>NG</sup> that must be considereduses a PostgreSQL relational database to store data on the server. These aspects are discussed Additionally, IMSMA<sup>NG</sup> stores other data including attachments and some configuration files on the server in the following sectionsfile format. The PostgreSQL database is accessible via a variety of database access tools designed for browsing relational databases.
===Ensuring Correct Roles and Permissions are Assigned==={{warning|While the database contains many relational database constraints designed to preserve data integrity, all updates of data should be handled through the business layer rather than with direct SQL updates in order to maintain integrity. Failure to do so will likely cause data corruption or loss}}
Establishing correct roles and permissions The business layer is a key factor in managing where rules are implemented to ensure data quality and maintaining consistency. The business layer takes data exchange within from the datastore and transforms it for display in the IMSMA<sup>NG</sup>client. Using All data interaction between the client and server database is handled through the permissions structurebusiness layer, which allows for multiple clients to be connected to the information manager can carefully control access to key functions that affect database while preserving data exchange including field report template creation, CDF creation, field report approvals and auxiliary data creationintegrity in cases of multiple requests. When permissions are correctly established and roles and user accounts created, information managers can freely distribute This includes access from the IMSMA<sup>NG</sup> dataset to regional partners knowing that key data controls are in placeclient and from the reporting tool.
Using the example of the central authority and regional sites, the following principles for user account creation and permissions should be considered:===Client===__NOEDITSECTION__
* The IMSMA<bsup>Central Authority:NG</bsup> Ensure central authority has exclusive control over user accounts client is the interface through which users can connect to the server and rolesbrowse the system, field report templatesenter data and generate outputs. The client includes an integrated GIS component and reporting tools. Based on ESRI’s ArcGIS Engine, the Data Inventory Manager GIS component performs all geospatial calculations including distance/bearing calculation, coordinate conversion and reprojection. The GIS component also allows each client to load and auxiliary manage its own maps and geographic data.* which the client receives from the IMSMA<bsup>Regional Sites:NG</bsup> Ensure that regional sites have data entryserver. As a result, approval each client receives and importlocally stores a complete copy of geographic data from the IMSMA<sup>NG</export permissionssup> server when it is connected to the server. Remove permissions for user accounts This synchronized data is stored in a client ―sandbox‖ separate from the server and roles and auxiliary datacan always be updated by connecting to the server.
By establishing a set of limited permissions for JasperSoft’s iReport tool is built into each IMSMA<sup>NG</sup> client and allows users to access data from the database via the regional sitesbusiness layer. With iReport, information managers users can prevent the accidental or intentional creation generate reports containing tabular data, subreports and cross tabs as well as various types of new data elements not available at the central authority charts and graphs. These reports can easily be localized into any language that could affect IMSMA<sup>NG</sup> supports. Additional reporting options include direct connections to the ability of the central authority to import field reports IMSMA<sup>NG</sup> database via ODBC. This functionality supports tools such as Crystal Reports, Microsoft® Access®, Microsoft Excel® and cause the dataset to become fracturedvarious open-source reporting tools.
===Creating New Auxiliary Data at the Central Authority LevelMemory settings===__NOEDITSECTION__
By limiting auxiliary data permissions to the central authority, information managers can prevent complications when synchronising field reports. Because field reports often refer to auxiliary data (places, ordnance, organisations, etc.), it is important that each site have a common set of auxiliary data to facilitate exchange. If the auxiliary data is not properly synchronisedreserving memory for {{IMSMANG}}, the exchange of field reports can result in import issues which must less memory may be manually resolved. While IMSMA<sup>NG</sup> provides an interface for resolving these kinds of issues, it is recommended to reduce the occurrence of these issues used by limiting any creation of auxiliary data to the central authority who can then distribute an updated dataset as necessaryother applications. Likewise, limiting It also depends on how much memory the creation of field report templates, data elements and country structure levels computer has if is possible to the central authority improves the ease of information exchangereserve more memory for {{IMSMANG}}.
===Sending Backups to Reset to a Common Dataset===[[Image:memory_settings.png|500px]]
The easiest way If you would like to ensure that each site is working from a common dataset is to distribute a full backup of reserve more memory for the IMSMA<sup>NG</sup> dataset to each site on a regular basis. This can occur weeklyserver '''process''', monthly or quarterly, but the key is to distribute an official‖ dataset to each site regularly to ensure that auxiliary data is up to date and that any changes made to other parts of the dataset are distributededit row 3 in ''C:\IMSMAng\trayLauncher\TrayLauncher. In this way, organisations can maintain a common set of national statistics and the dataset reflects the decisions made by the central authority to resolve errors or issues in importing and exchanging field reportsproperties''.
It is important If you would like to understandreserve more memory for the IMSMA client '''process''', however, that the restoration of a backup file overwrites the data at the regional site including any locally created searches edit row 12 in ''C:\IMSMAng\trayLauncher\TrayLauncher.properties''. Start with increasing it to 1024 and reportsthen evaluate. So, the recipient sites should consider the following recommendations:
* Make a complete backup prior to restoring the central authority’s backup.{|* Export all field reports that have been entered since the last exchange with the central authority before restoring a backup.|- valign="top"* Restore only the IMSMA<sup>NG</sup> database and GIS database. This preserves local customisations of peripheral elements such as field report templates and iReport templates, which can be reimported into IMSMA<sup>NG</sup>.* Request that any searches or other non-exportable elements that are important for regional site use be created in the central authority’s dataset prior to distribution so they do not need to be recreated regionally each time a new backup is distributed.|
{| class="wikitable" ! Value !! Meaning |- align="right"| 512 || 0.5 GB |- align=Collecting Regular Feedback"right"| 1024 || 1 GB |- align="right"| 2048 || 2 GB |- align="right"| 3072 || 3 GB |- align="right"| 4096 || 4 GB |- align="right"|}The values should be increased step-by-step and evaluated after each change.
In any information exchange activity, it {{Note | * Since IMSMA NG is a 32-bit application there is important to have regular sessions or meetings to collect feedback and discuss issues or improvements to no effect by reserving more than total 4 GB. * On the information exchange process. One recommendation physical server in a client/server configuration there is need to establish a feedback forum where organisations can address data quality issues start the client, take backup and make adjustments to restore so do not set the information exchange client processmemory to less than 512. Topics to address in such a forum include:}}
* frequency of data exchange{{NavBox Information Management}}* standardization of reports and searches included in the central dataset* permissions and role changes* creation or modification of auxiliary data* form template changes By collecting feedback on these issues, information managers can help ensure that decentralized information exchange works as expected and set up a quality assurance mechanism to prevent data quality issues from affecting the programme’s information management.[[Category:NAA]]
6,632
edits

Navigation menu