SOS Administrator

Back to GSoC2012 Projects page.

Child Page : Weekly Reports


Deploying SOS on a server is quite a complex process as of now. Also, data administration tasks such as Read/Update/Delete operations on database and changing configuration settings is not very user friendly. After this project has been completed, SOS will have a web-based user friendly automatic installer and a SOS administration, which will make configuring SOS very easy and intuitive and all data administrative tasks could be done at one place.

Student : Shubham Sachdeva

Mentor : Carsten Hollman

Contact Information : Find me on with nick magiclko at #52north

SVN Repo :


The complete project can be divided into two separate parts :

  • Installer
I plan to cover “5 minute install” in 5 very user-friendly screens/steps.

  • Screen I - Welcome/License screen.
  • Screen II - Database Configuration screen. Here we will take database username/password/port number and such. Also, I plan to show the connection string, for advanced users, which will be used for the database connection.
  • Depending upon the database state, user will be shown one of the following screens
    • Screen III - If database already exists and tables are populated, then redirect user to corresponding SOS setup.
    • Screen III - If database is empty then provide user a way to upload a *.sql file(custom file having user-specific data or a pre-defined data set from SOS), which we can execute.
    • Screen III - If database does not exist, then provide a way to create one and populate it with required tables.
  • Screen IV - Optional Configuration, which will write the information to corresponding files like dssos, pom.xml and such.
  • Screen V - Information Screen. Here we can show the administrators some information regarding administration account credentials(which i plan to make one during installation of SOS! So, it’ll be like admin installed SOS and after the installation wizard, admin is redirected to admin screen.)

  • SOS Administration
The last and perhaps, the most challenging, part of the project will be to implement the SOS administration. I plan to complete the administration in following baby-steps:
  1. Authentication/Login
  2. Dashboard
  3. Configuring global properties/settings.
  4. Database related tasks
  5. Dealing with non-database related data sources like WFS(if time allows!)
Mainly we’ll have following 5 screens:

1. Authentication: Normal login-username screen. As the administrator will be dealing with database directly, it is very important to restrict the use of admin-end. For secure passwords, we can either use salted passwords or we can use a strong password text encoding algorithm.
2. Dashboard : Dashboard will have following items/features :
2.1 Quick preview of Status details such as access to the log, database and memory size, or service uptime.
2.2 Quick preview of capability document template
These items will be arranged as a module/box which could be rearranged on the screen as per the ease of use.(jQuery UI’s portlet can be used here!).
3. Global settings : This screen will have following configuration tabs grouped logically:
3.1 Settings related to service identification like title, keywords, service type and such
3.2 General settings related to service provider like name, location, contact information etc.
3.3 Other services like WFS related settings. For example, in case of WFS, we can have it’s service url, version, maxFeatures and so on.
4. Database: This screen will deal with the database related tasks like updating/reading/deleting/hiding observations from table or issuing a general query to the database.
5. Other services: This screen is basically a part of data administration but will deal with non-database related sources. This screen can basically have 2 textareas and a predefined example list. One of the textarea will be for issuing a custom request to the appropriate service (WFS) and other text area will be for its response. Also, a “Save response” button will be there to store the response.(It could ask for further required information related before saving as well.) To query the service, we can send the AJAX request (GET/POST) and display/store the result.

Discussion of Ideas

(Please sign your entries.)

  • Last page of the wizard: a survey. This survey asks to fill a few optional fields (all optional) to let 52°North know about the installation for user statistics. Fields: Email, Name, Where did you hear about 52°North SOS?, Is this the first installation you do?, Feedback text field. -- DanielNuest - 2012-05-08
    • Wouldn't the admin-end be right place for such a feedback mechanism? Something like an icon on the titlebar on the right saying "Give us your feedback!", user fill the form, submits it and done! Installer should get completed as quickly as possible so that administrators can get started asap! -- ShubhamSachdeva - 2012-06-09
    • Good point. So please add a "Feedback" button to the admin page, my suggestion is to place it in the footer. The page could directly have a few items: report bug (takes you to SOS bugzilla page), report usage (an email form, which is sent to the Sensor Web community leader), and a couple of social media icons (Twitter, Facebook, Google+) which will post a message such as "I use the 52°North Sensor Observation Service: <url here>. #52north #sos" --Main.DanielNuest - 2012-06-21 * What about using an external survey tool like LimeSurvey you (Shubham) has worked for in GSoC 2011? In this case no logic is needed to send the survey results. -- CarstenHollmann - 2012-07-12
    • About Carsten's idea, i think it's perfect. No additional logic needed and a lot of features available to us. Configuring LimeSurvey isn't hard at all as well smile -- ShubhamSachdeva - 2012-07-30
  • It would be great if the install wizard is configurable in the sense that the pages/steps can be switched out or a new step put in between quite easily, like a wizard framework. Not as generic asthis (!), but maybe each step can have an Id, a previous-step, and a next-step, which are automatically put together. -- DanielNuest - 2012-06-21
  • Test data
    • It would be nice if I can choose from more than one test dataset. For example "Simple Time-Series", and "Hierachical Procedues" (demonstrating the new hierarchical procedures features). The actual test dataset is probably out of scope, but it would be great if the mechanism supported several options. -- DanielNuest - 2012-07-06
    • Would it be possible to remove the test data? I can imagine a workflow where I install a SOS, add some test data, play around with it, add my own data... and then want to get rid of the test data (and only that, NOT my own data)? --Main.DanielNuest - 2012-07-06
      • The minimum should be to be able to clear the whole database from the administration backend (after a couple of "are you sure you want to do this" alert windows, of course). -- DanielNuest - 2012-07-06
      • To clear the whole database you can run the datamodel SQL script. -- CarstenHollmann - 2012-07-12
      • That's all part of Database settings screen. -- ShubhamSachdeva - 2012-07-30
      • To clear the database/remove the test data, all we have to do is call a function like we have in Installer to insert the same. -- ShubhamSachdeva - 2012-08-22


About database screen(clearing test data/db size portlet module), they can be done along with bugfixes.


Since the administrator and installer are a very important project especially for unexperienced users, we want to thoroughly test it before releasing it to the public. Therefore we created the SOS Installer and Adminstrator Testbed, see SosInstallAdminTestbed.

Weekly Reports

Find weekly reports here !


create new tag
, view all tags
Topic revision: r11 - 2012-09-25 - 13:44:00 - DanielNuest

  • Search: 
This site is powered by the TWiki collaboration platform Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback