Liberating data, measuring progress, inspiring strategy.
A few months ago, we began the implementation of the first phase of a submission notification trigger mechanism. This new functionality allows third party applications of your choice to be notified when a response to a survey is received – allowing the data to be immediately processed by your application.
Until recently, the trigger mechanism only supported notifications of newly received submissions, however, we have now implemented the ability to notify your custom application(s) when a submission is edited in your research console as well – thereby maintaining data integrity between our systems and yours.
In both cases we have also improved the processing mechanism in terms of dealing with failed delivery. The submission trigger mechanism will now reprocess a trigger in the event of a delivery failure (such as network failure or your server being offline). This ultimately means you are always ensured of receiving a notification of a submission even if your processing application is down while a submission is received. The new processing mechanism will make up to 6 attempts to notify your application as per the following schedule (assuming failure of the first and subsequent requests):
If the result of the 6th attempt is a failure, we will notify you via email and wait on a resolution before re-processing the undelivered notification(s).
A successful notification delivery is defined as an attempt that results in a “200 OK” HTTP status code being returned by the relevant web server. If any other code is returned our system will deem the delivery a failure and enter the reprocessing workflow as described above. Furthermore, if a “500 Internal Server Error” code is returned we will record the error message returned and supply this information to you in the event the notification is not delivered after 6 successive attempts.
In terms of the requirements for setting up a create/update notification trigger, we simply require the URL endpoint of your service and the survey ID you wish to setup the trigger(s) for. Once setup, the notification to your URL endpoint is simply made via a GET request with the following query string parameters.
On submission created notification:
|
KEY |
Type |
VALUE |
|
surveyid |
Integer |
ID of the survey the submission received is relevant to. |
|
submissionid |
Guid |
The unique ID of the submission record. |
|
createdon |
DateTime |
The date and time the submission was received. |
|
createdby |
String |
The name of the fieldworker who captured the submission. |
On submission modified notification:
|
KEY |
Type |
VALUE |
|
surveyid |
Integer |
ID of the survey the submission updated is relevant to. |
|
submissionid |
Guid |
The unique ID of the submission record. |
|
modifiedon |
DateTime |
The date and time the submission was modified. |
|
modifiedby |
String |
The name of the user who modified the submission. |
If you have any comments, questions or suggestions, please feel free to post them here, alternatively, please contact support.
We hope you find these new features useful.
Powered by the Populi.net platform, Mobile Researcher transforms the ubiquitous mobile phone into a cutting-edge research tool.
Surveys are designed and deployed from an online console where your research team log-in to collaborate on survey design, manage fieldworkers, analyse responses and export data.
Using an appropriate mobile channel, fieldworkers and respondents access their survey assignments and submit responses to them.