EUMS Architecture
Modular systems are systems that have separate components with distinct responsibilities. This separation makes the overall system easier to extend and easier to maintain. The EUMS application is one such system and is made of 3 main components namely the Backend, the Contacts Service and the Web Client. The boundaries between these components are clearly defined. The components do not share responsibilities.
Communication between the components is through clear APIs, which means that consumer components do not have to take into consideration the implementation details of the components whose services they are consuming.
Since the responsibilities of the components are non-overlapping, functionality can be added to any of the components without affecting the other components or having to alter the way the other components consume the modified one.
Following from this, the components can be used by other applications that are not necessarily part of the End User Monitoring System (EUMS) ecosystem. For instance, the Contacts Repository has been developed as an independently deployable standalone application whose contact data can be consumed through a REST API by any other UNICEF application that uses contacts for its operations.
Automated tests are written for all code before it is added to any of the applications in the EUMS ecosystem. Before a feature is considered complete, the automated tests must first pass. These tests check among other things that all the components are talking to each other properly, and the components work as expected. This gives the development team and users a great level of confidence in any features that are deployed to production.
Every change that is made to the applications by a developer is picked up by build servers and integrated into the work already done by other developers. These servers also run the automated tests against the application and ensure that it is working as expected. Once the build servers deem the application functional, it is automatically deployed to a staging instance where product owners and testers can do exploratory testing of any new features before they are deployed to production.
This component is responsible for handling all the business logic associated with monitoring the distribution and consumption of UNICEF supplies, from the UNICEF warehouses, to Implementing Partners, through to the beneficiaries. This component understands how the logistical concepts of Sales Orders, Implementing Partners etc. relate to the programmatic concepts of Distribution Reports and Distribution plans,and how these feed into the reporting necessary to keep track of the health of the supply chain within UNICEF’s programmes.
This component exposes its data through a RESTful API. It is through this API that the Web Client component connects UNICEF programme staff and Implementing Partners to the end user monitoring process and supply chain health reports.
This component also deals with importing CSV data from VISION / Data Warehouse for the purpose of keeping up to date with the procurement and supply release process that are being captured in VISION at any point in time.
Python 2.7, Django 1.7, PostgreSQL 9.3, Celery 3.1, Redis, ElasticSearch 2.0
- Django offers a significant portion of the requirements of EUMS, namely user authorization and authentication, etc.
- Django makes creation of RESTful API endpoints rather easy (through the Django Restframework plugin).
- Most UNICEF software currently runs on Python / Django, so it will be easier to maintain for UNICEF teams.
- Background tasks are handled by Celery with Redis as its backend.
- ElasticSearch is used as a search engine for more performant searching on select report pages.
The Web Client is responsible for providing an interface through which users can view and edit information about the supply chain with a web browser. Users can create, edit and delete Supply Plans, Distribution Plans, Contacts, etc through this component, as well as see quick statistics and generate reports about deliveries.
AngularJS 1.x, HTML5, Grunt (build automation), Jasmine (testing), Protractor (testing), Selenium (testing).
- The AngularJS is a tried and tested front end JavaScript framework that allows for creation of interactive and immersive user interfaces in the browser.
- Most developers are conversant with JavaScript and HTML, so the learning curve for maintainers and future developers will be greatly reduced as opposed to if the stack was based on unfamiliar languages.
- AngularJS provides a browser-based testing framework using Protractor, which uses Selenium. This allows higher level testing of functional requirements via the browser.
Browser support is limited to modern browsers (HTML5 friendly).
This is a standalone, independently deployable application that handles contact information and has flexibility to add operations on contacts for instance tagging, grouping and merging in the future. It communicates to the Backend and Web Client components (and indeed any other UNICEF applications that might need its services) through a RESTful API.
NodeJS, MongoDB, Jasmine (testing), Grunt (build automation).
- This is a standalone application because its function conceptually separate from that of the Backend, and we see a need for central management of contacts among UNICEF applications because multiple programmes share contacts. Having all the contacts in one place will streamline the contacts registry, and make sharing of contacts between applications and programmes much easier than it is at the moment. Having the Contacts Repository as a separate application is a good step in that direction.
- NodeJS is a JavaScript framework for building easy-to-scale server side applications. The ease of horizontal scalability is important because the Contacts Repository will potentially have to handle large volumes of requests if other UNICEF applications start to use its services.
- Being JavaScript, the learning curve for maintainers is reduced by a the effort required to learn a new language.
- The document based structure of MongoDB lends itself well to the nature of contacts if one considers each contact as a document that can have tags and can be searched and grouped based on these tags.
- Also, the use of a schemaless database helps accelerate development because changes to document structures are without much ceremony.