Difference between revisions of "Understanding Configuration Options"

From IMSMA Wiki
Jump to: navigation, search
Line 1: Line 1:
*[[Standalone]]
+
{{TOC right}}
*[[Networked Configuration]]
+
__NOEDITSECTION__
*[[Decentralized Information Exchange]]
+
==Standalone versus Networked Configuration==
*[[Managing IMSMA Roles and Permissions]]
 
 
 
 
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 mode.
 
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 mode.
  
Line 31: Line 29:
 
|-
 
|-
 
|}
 
|}
 +
 +
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 installation requires at least two computers and a network infrastructure connecting the computers together. Using a networked 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 Config'']]
 +
<div align="center">
 +
''Networked Configuration''
 +
</div>
 +
 +
==Decentralized Information Exchange==
 +
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 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.
 +
 +
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.
 +
 +
 +
[[Image:Understanding Configuration Options - Decentralized Info Exchange.png|center|''Decentralized Info Exchange'']]
 +
<div align="center">
 +
''Decentralized Info Exchange''
 +
</div>
 +
 +
 +
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-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.
 +
 +
 +
[[Image:Understanding Configuration Options - Decentralized Info Management Flow.png|center|''Decentralized Info Management Flow'']]
 +
<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. 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</sup> that must be considered. These aspects are discussed in the following sections.
 +
 +
===Ensuring Correct Roles and Permissions are Assigned===
 +
Establishing correct roles and permissions is a key factor in managing and maintaining data exchange within IMSMA<sup>NG</sup>. Using the permissions structure, the information manager can carefully control access to key functions that affect data exchange including field report template creation, CDF creation, field report approvals and auxiliary data creation. When permissions are correctly established and roles and user accounts created, information managers can freely distribute the IMSMA<sup>NG</sup> dataset to regional partners knowing that key data controls are in place.
 +
 +
Using the example of the central authority and regional sites, the following principles for user account creation and permissions should be considered:
 +
 +
* <b>Central Authority:</b> Ensure central authority has exclusive control over user accounts and roles, field report templates, the Data Inventory Manager and auxiliary data.
 +
* <b>Regional Sites:</b> Ensure that regional sites have data entry, approval and import/export permissions. Remove permissions for user accounts and roles and auxiliary data.
 +
 +
By establishing a set of limited permissions for the regional sites, information managers can prevent the accidental or intentional creation of new data elements not available at the central authority that could affect the ability of the central authority to import field reports and cause the dataset to become fractured.
 +
 +
===Creating New Auxiliary Data at the Central Authority Level===
 +
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 synchronised, the exchange of field reports can result in import issues which must 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 by limiting any creation of auxiliary data to the central authority who can then distribute an updated dataset as necessary. Likewise, limiting the creation of field report templates, data elements and country structure levels to the central authority improves the ease of information exchange.
 +
 +
===Sending Backups to Reset to a Common Dataset===
 +
The easiest way to ensure that each site is working from a common dataset is to distribute a full backup of the IMSMA<sup>NG</sup> dataset to each site on a regular basis. This can occur weekly, 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 distributed. 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 reports.
 +
 +
It is important to understand, however, that the restoration of a backup file overwrites the data at the regional site including any locally created searches and reports. 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<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.
 +
 +
===Collecting Regular Feedback===
 +
In any information exchange activity, it is important to have regular sessions or meetings to collect feedback and discuss issues or improvements to the information exchange process. One recommendation is to establish a feedback forum where organisations can address data quality issues and make adjustments to the information exchange process. Topics to address in such a forum include:
 +
 +
* frequency of data exchange
 +
* 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.
 +
 +
==Managing IMSMA Roles and Permissions==
 +
__FORCETOC__
 +
{{TOC right}}
 +
 +
{{HowTo's
 +
|[[HowTo:Access and Use the Role List Window|Access and Use the Role List Window]]
 +
|[[HowTo:Use the Role Editor Window|Use the Role Editor Window]]
 +
}}
 +
 +
{| class="wikitable"
 +
! Role
 +
! Description
 +
|-
 +
| Data Entry
 +
| Users whose primary function is to enter field reports and other data into the system. This role may or may not include the ability to approve field reports.
 +
|-
 +
| Data Verification
 +
| Users who typically perform quality checks on the data entered by Data Entry users. This role is often responsible for verifying the accuracy of the data entered and approving field reports.
 +
|-
 +
| Operations
 +
| Users who typically browse for information within IMSMA<sup>NG</sup> to make operational decisions. Operations users may sometimes be grouped by function (for example, MRE, clearance or victim assistance). These users often perform searches for data, generate reports and analyze the data to support operational needs.
 +
|-
 +
| Systems Administrator
 +
| Users who perform information management-specific functions such as creating field report templates, designing reports, backing up and restoring data and other technical functions.
 +
|-
 +
| Guest
 +
| Users with essentially read-only access to browse data.
 +
|-
 +
|}
 +
  
  

Revision as of 17:47, 27 November 2012

Standalone versus Networked Configuration

To determine the initial configuration of the IMSMANG system, it is important to understand the two ways in which IMSMANG can be set up and the basic architecture of the system. IMSMANG is a client-server software application designed to run in stand-alone or networked mode.


Comparison of Standalone and Networked Configuration Options
Configuration Advantages Disadvantages
Standalone
  • Simple to set up and maintain
  • Limited IT knowledge required
  • Can be upgraded to a networked configuration later
  • One-at-a-time data access
Networked
  • Multiple concurrent data access
  • Redundancy
  • Complicated to set up and maintain
  • Networked infrastructure required
  • Multiple computers required

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 installation requires at least two computers and a network infrastructure connecting the computers together. Using a networked installation, a mine action programme can have multiple data entry clerks entering data at the same time.


Networked Config

Networked Configuration

Decentralized Information Exchange

IMSMANG 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 IMSMANG is easy and allows information managers to expand the scope and impact of information on mine action activities. While IMSMANG 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 IMSMANG 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.


Decentralized Info Exchange

Decentralized Info Exchange


Establishing IMSMANG with the correct configuration in this complicated context of multiple users and asynchronous data exchange is important to trouble-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.


Decentralized Info Management Flow


This straightforward approach to decentralized data exchange ensures that all sites regularly receive a complete and authoritative dataset. 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 IMSMANG that must be considered. These aspects are discussed in the following sections.

Ensuring Correct Roles and Permissions are Assigned

Establishing correct roles and permissions is a key factor in managing and maintaining data exchange within IMSMANG. Using the permissions structure, the information manager can carefully control access to key functions that affect data exchange including field report template creation, CDF creation, field report approvals and auxiliary data creation. When permissions are correctly established and roles and user accounts created, information managers can freely distribute the IMSMANG dataset to regional partners knowing that key data controls are in place.

Using the example of the central authority and regional sites, the following principles for user account creation and permissions should be considered:

  • Central Authority: Ensure central authority has exclusive control over user accounts and roles, field report templates, the Data Inventory Manager and auxiliary data.
  • Regional Sites: Ensure that regional sites have data entry, approval and import/export permissions. Remove permissions for user accounts and roles and auxiliary data.

By establishing a set of limited permissions for the regional sites, information managers can prevent the accidental or intentional creation of new data elements not available at the central authority that could affect the ability of the central authority to import field reports and cause the dataset to become fractured.

Creating New Auxiliary Data at the Central Authority Level

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 synchronised, the exchange of field reports can result in import issues which must be manually resolved. While IMSMANG provides an interface for resolving these kinds of issues, it is recommended to reduce the occurrence of these issues by limiting any creation of auxiliary data to the central authority who can then distribute an updated dataset as necessary. Likewise, limiting the creation of field report templates, data elements and country structure levels to the central authority improves the ease of information exchange.

Sending Backups to Reset to a Common Dataset

The easiest way to ensure that each site is working from a common dataset is to distribute a full backup of the IMSMANG dataset to each site on a regular basis. This can occur weekly, 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 distributed. 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 reports.

It is important to understand, however, that the restoration of a backup file overwrites the data at the regional site including any locally created searches and reports. 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 IMSMANG database and GIS database. This preserves local customisations of peripheral elements such as field report templates and iReport templates, which can be reimported into IMSMANG.
  • 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.

Collecting Regular Feedback

In any information exchange activity, it is important to have regular sessions or meetings to collect feedback and discuss issues or improvements to the information exchange process. One recommendation is to establish a feedback forum where organisations can address data quality issues and make adjustments to the information exchange process. Topics to address in such a forum include:

  • frequency of data exchange
  • 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.

Managing IMSMA Roles and Permissions

Role Description
Data Entry Users whose primary function is to enter field reports and other data into the system. This role may or may not include the ability to approve field reports.
Data Verification Users who typically perform quality checks on the data entered by Data Entry users. This role is often responsible for verifying the accuracy of the data entered and approving field reports.
Operations Users who typically browse for information within IMSMANG to make operational decisions. Operations users may sometimes be grouped by function (for example, MRE, clearance or victim assistance). These users often perform searches for data, generate reports and analyze the data to support operational needs.
Systems Administrator Users who perform information management-specific functions such as creating field report templates, designing reports, backing up and restoring data and other technical functions.
Guest Users with essentially read-only access to browse data.


Client-Server Architecture

Whether a programme uses a stand-alone installation or a networked installation, the IMSMANG software has two main components:

  • the IMSMANG server
  • the IMSMANG client

The figure below shows the parts of the software; the following sections then explain the functions that each part performs.


Client Server Architecture

Client-Server Architecture


Server

The IMSMANG server stores data and manages much of the data processing. The server has two main parts, the datastore and the business layer. The datastore is where data is stored for retrieval by the IMSMANG client. IMSMANG uses a MySQL relational database to store data on the server. Additionally, IMSMANG stores other data including attachments and some configuration files on the server in file format. The MySQL database is accessible via a variety of database access tools designed for browsing relational databases.

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 IMSMANG client. All data interaction between the client and server database is handled through the business layer, which allows for multiple clients to be connected to the database while preserving data integrity in cases of multiple requests. This includes access from the IMSMANG client and from the reporting tool.

Client

The IMSMANG client is the interface through which users can connect to the server and browse the system, enter data and generate outputs. The client includes an integrated GIS and reporting tools. Based on ESRI’s ArcGIS Engine, the GIS performs all geospatial calculations including distance/bearing calculation, coordinate conversion and reprojection. The GIS also allows each client to load and manage its own maps and geographic data which the client receives from the IMSMANG server. As a result, each client receives and locally stores a complete copy of geographic data from the IMSMANG server when it is connected to the server. This synchronized data is stored in a client ―sandbox‖ separate from the server and can always be updated by connecting to the server.

JasperSoft’s iReport tool is built into each IMSMANG client and allows users to 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 IMSMANG supports. Additional reporting options include direct connections to the IMSMANG database via ODBC. This functionality supports tools such as Crystal Reports, Microsoft® Access®, Microsoft Excel® and various open-source reporting tools.