Changes

[[Image:Understanding Configuration Options - Standalone Vs Networked Config Comparison.png|center|500px|''Comparison'']]<div align="center">''Comparison of Standalone and Networked Configuration Options''</div>  ===Standalone=== In a stand-alone system, both the IMSMA^NG 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.  [[Image:Understanding Configuration Options - Standalone Config.png|center|300px|''Standalone Config'']]<div align="center">''Standalone Configuration''</div>  ===Networked Configuration=== In a networked client-server configuration, one computer acts as a server and many other computers can connect to it simultaneously over a network, enabling multiple people to access the same data at the same time. A networked client/server installation requires at least two computers and a network infrastructure connecting the computers together. Using a networked client/server installation, a mine action programme can have multiple data entry clerks entering data at the same time.

[[Image:Understanding Configuration Options - Networked Config.png|center|300px|''Networked Client/server Config'']]

''Networked ConfigurationClient/server configuration''

==Decentralized Information ExchangeClient/server Architecture== IMSMA^NG 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^NG is easy and allows information managers to expand the scope and impact of information on mine action activities. While IMSMA^NG 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 the discussion of maintaining a decentralized IMSMA^NG system refers to this typical example; however, many points apply to other information exchange patterns as well. 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, the central authority manages the overall data set for the entire country, collecting all regional information in order to perform national planning and produce national statistics.__NOEDITSECTION__

[[Image:Understanding Configuration Options - Decentralized Info Exchange.png|center|''Decentralized Info Exchange'']]* the IMSMA^NG server* the IMSMA<div align="center"sup>''Decentralized Info Exchange''NG</divsup>client

Establishing IMSMA^NG with the correct configuration in this complicated context of multiple users and asynchronous data exchange is important to trouble{| border="1" cellpadding="5"|-free operations and high-quality information management. The first step in ensuring the correct configuration is to document the information management flows. 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.valign="top"|[[Image:Understanding Configuration Options - Decentralized Info Management Flowstand_alone Architecture.png|center|300px|''Decentralized Info Management FlowStand-alone architecture'']]<div align="center">''Decentralized Info Management Flow</div> 

This straightforward approach to decentralized data exchange ensures that all sites regularly receive a complete and authoritative dataset|[[Image:Understanding Configuration Options- Client Server Architecture. Other variations on this pattern are possible with varying degrees of increased complexity to meet specific data exchange needs. Regardless of the information exchange pattern selected, there are several key aspects of maintaining decentralized data exchange within IMSMA<sup>NG<png|center|600px|''Client/sup> that must be considered. These aspects are discussed in the following sections.server architecture'']]

Using The IMSMA^NG server stores data and manages much of the example of data processing. The server has two main parts, the central authority datastore and regional sitesthe business layer. The datastore is where data is stored for retrieval by the IMSMA^NG client. IMSMA^NG uses a PostgreSQL relational database to store data on the server. Additionally, IMSMA^NG stores other data including attachments and some configuration files on the following principles server in file format. The PostgreSQL database is accessible via a variety of database access tools designed for user account creation and permissions should be considered:browsing relational databases.

* <b>Central Authority:</b> Ensure central authority has exclusive control over user accounts and roles, field report templates, {{warning|While the Data Inventory Manager and auxiliary database contains many relational database constraints designed to preserve data.* <b>Regional Sites:</b> Ensure that regional sites have integrity, all updates of data entry, approval and import/export permissionsshould be handled through the business layer rather than with direct SQL updates in order to maintain integrity. Remove permissions for user accounts and roles and auxiliary Failure to do so will likely cause data.corruption or loss}}

By establishing a set of limited permissions The business layer is where rules are implemented to ensure data quality and consistency. The business layer takes data from the datastore and transforms it for display in the regional sitesIMSMA^NG client. All data interaction between the client and server database is handled through the business layer, information managers can prevent which allows for multiple clients to be connected to the accidental or intentional creation of new database while preserving data elements not available at the central authority that could affect the ability integrity in cases of multiple requests. This includes access from the central authority to import field reports IMSMA^NG client and cause from the dataset to become fracturedreporting tool.

===Creating New Auxiliary Data at the Central Authority LevelClient===__NOEDITSECTION__

By limiting auxiliary The IMSMA^NG client is the interface through which users can connect to the server and browse the system, enter data permissions to and generate outputs. The client includes an integrated GIS component and reporting tools. Based on ESRI’s ArcGIS Engine, the central authorityGIS component performs all geospatial calculations including distance/bearing calculation, information managers can prevent complications when synchronising field reportscoordinate conversion and reprojection. Because field reports often refer The GIS component also allows each client to auxiliary load and manage its own maps and geographic data (places, ordnance, organisations, etcwhich the client receives from the IMSMA^NG server.)As a result, it is important that each site have client receives and locally stores a common set complete copy of auxiliary geographic data to facilitate exchange. If from the auxiliary data is not properly synchronised, the exchange of field reports can result in import issues which must be manually resolved. While IMSMA^NG provides an interface for resolving these kinds of issues, server when it is recommended connected to reduce the occurrence of these issues by limiting any creation of auxiliary server. This synchronized data to is stored in a client ―sandbox‖ separate from the central authority who server and can then distribute an always be updated dataset as necessary. Likewise, limiting the creation of field report templates, data elements and country structure levels by connecting to the central authority improves the ease of information exchangeserver.

===Sending Backups JasperSoft’s iReport tool is built into each IMSMA^NG client and allows users to Reset access data from the database via the business layer. With iReport, users can generate reports containing tabular data, subreports and cross tabs as well as various types of charts and graphs. These reports can easily be localized into any language that IMSMA^NG supports. Additional reporting options include direct connections to a Common Dataset===the IMSMA^NG database via ODBC. This functionality supports tools such as Crystal Reports, Microsoft® Access®, Microsoft Excel® and various open-source reporting tools.

By reserving memory for {{IMSMANG}}, less memory may be used by other applications. It also depends on how much memory the computer has if is important possible to understand, however, that the restoration of a backup file overwrites the data at the regional site including any locally created searches and reportsreserve more memory for {{IMSMANG}}. 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.* Restore only the IMSMA^NG 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^NG.* 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[[Image:memory_settings.png|500px]]

In any information exchange activity, it is important to have regular sessions or meetings to collect feedback and discuss issues or improvements If you would like to reserve more memory for the information exchange IMSMA client '''process''', edit row 12 in ''C:\IMSMAng\trayLauncher\TrayLauncher.properties''. One recommendation is Start with increasing it to establish a feedback forum where organisations can address data quality issues 1024 and make adjustments to the information exchange processthen evaluate. Topics to address in such a forum include:

{{Note | * frequency of data exchangeSince IMSMA NG is a 32-bit application there is no effect by reserving more than total 4 GB. * standardization of reports and searches included On the physical server in a client/server configuration there is need to start the central dataset* permissions client, take backup and role changes* creation or modification of auxiliary data* form template changesrestore so do not set the client process memory to less than 512. }}