I'm a developer and I have just been tasked with implementing the ability to upload forms and get data back in to our own database in an automated fashion. Basically they just want to be able to click a button, have it upload the form and have submission data flow back into our database with no additional human input aside from people using the collector. Of course they want this done yesterday as well.
I see that ODK supports the OpenROSA API but I've never used that before. I'm sure i can figure it out but in the interest of time I was hoping there was a primer on how to upload forms and get submissions back. I'm sure I'm not the first person to do this but Google has not really been yielding much in the way of results. Does such a thing exist? Does anyone have any advice for me?
Any thoughts at all would be appreciated as I'm suddenly finding myself under and epic time crunch.
You might consider publishing from Aggregate to google fusion tables then
using available api to pull into your database. PHP examples are given on
Google site and rails gem is also available.
On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net> wrote:
> I'm a developer and I have just been tasked with implementing the ability
> to upload forms and get data back in to our own database in an automated
> fashion. Basically they just want to be able to click a button, have it
> upload the form and have submission data flow back into our database with
> no additional human input aside from people using the collector. Of course
> they want this done yesterday as well.
> I see that ODK supports the OpenROSA API but I've never used that before.
> I'm sure i can figure it out but in the interest of time I was hoping there
> was a primer on how to upload forms and get submissions back. I'm sure I'm
> not the first person to do this but Google has not really
> been yielding much in the way of results. Does such a thing exist? Does
> anyone have any advice for me?
> Any thoughts at all would be appreciated as I'm suddenly finding myself
> under and epic time crunch.
Using Aggregate -> Fusion Tables -> your app is potentially more
fragile because there are more pieces that could go wrong. Changing
Collect has less pieces, but then you have your own version of Collect
to maintain.
As far as automating transmission, that's pretty straightforward if
you are familiar with Android. You need a background service that
watches for a network connection and calls the InstanceUploaderTask.
Said service could also send on form save.
On Wed, May 9, 2012 at 2:36 PM, James Dailey <jamespdai...@gmail.com> wrote:
> You might consider publishing from Aggregate to google fusion tables then
> using available api to pull into your database. PHP examples are given on
> Google site and rails gem is also available.
> On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net> wrote:
>> Hello ODK Community,
>> I'm a developer and I have just been tasked with implementing the ability
>> to upload forms and get data back in to our own database in an automated
>> fashion. Basically they just want to be able to click a button, have it
>> upload the form and have submission data flow back into our database with no
>> additional human input aside from people using the collector. Of course they
>> want this done yesterday as well.
>> I see that ODK supports the OpenROSA API but I've never used that before.
>> I'm sure i can figure it out but in the interest of time I was hoping there
>> was a primer on how to upload forms and get submissions back. I'm sure I'm
>> not the first person to do this but Google has not really been yielding much
>> in the way of results. Does such a thing exist? Does anyone have any advice
>> for me?
>> Any thoughts at all would be appreciated as I'm suddenly finding myself
>> under and epic time crunch.
However that is not an option in my Aggregate. It just lists fusion
tables and google docs. JSON would be the perfect answer to getting
the data back into my database. Any idea why I'm not getting that
option?
--Trevor
___________________________
Trevor R. Ellermann
@trevorellermann
K0DMA
On Wed, May 9, 2012 at 2:36 PM, James Dailey <jamespdai...@gmail.com> wrote:
> You might consider publishing from Aggregate to google fusion tables then
> using available api to pull into your database. PHP examples are given on
> Google site and rails gem is also available.
> On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net> wrote:
>> Hello ODK Community,
>> I'm a developer and I have just been tasked with implementing the ability
>> to upload forms and get data back in to our own database in an automated
>> fashion. Basically they just want to be able to click a button, have it
>> upload the form and have submission data flow back into our database with no
>> additional human input aside from people using the collector. Of course they
>> want this done yesterday as well.
>> I see that ODK supports the OpenROSA API but I've never used that before.
>> I'm sure i can figure it out but in the interest of time I was hoping there
>> was a primer on how to upload forms and get submissions back. I'm sure I'm
>> not the first person to do this but Google has not really been yielding much
>> in the way of results. Does such a thing exist? Does anyone have any advice
>> for me?
>> Any thoughts at all would be appreciated as I'm suddenly finding myself
>> under and epic time crunch.
That form Submission API looks like exactly what I need for uploading
forms. Thanks.
As to changing the Collect code, It's actually part of the
requirements that we don't do that. If I can just get publishing to
JSON to work then I think I have all the pieces I need to get this
working.
Thanks again,
--Trevor
___________________________
Trevor R. Ellermann
@trevorellermann
K0DMA
> Using Aggregate -> Fusion Tables -> your app is potentially more
> fragile because there are more pieces that could go wrong. Changing
> Collect has less pieces, but then you have your own version of Collect
> to maintain.
> As far as automating transmission, that's pretty straightforward if
> you are familiar with Android. You need a background service that
> watches for a network connection and calls the InstanceUploaderTask.
> Said service could also send on form save.
> On Wed, May 9, 2012 at 2:36 PM, James Dailey <jamespdai...@gmail.com> wrote:
>> You might consider publishing from Aggregate to google fusion tables then
>> using available api to pull into your database. PHP examples are given on
>> Google site and rails gem is also available.
>> On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net> wrote:
>>> Hello ODK Community,
>>> I'm a developer and I have just been tasked with implementing the ability
>>> to upload forms and get data back in to our own database in an automated
>>> fashion. Basically they just want to be able to click a button, have it
>>> upload the form and have submission data flow back into our database with no
>>> additional human input aside from people using the collector. Of course they
>>> want this done yesterday as well.
>>> I see that ODK supports the OpenROSA API but I've never used that before.
>>> I'm sure i can figure it out but in the interest of time I was hoping there
>>> was a primer on how to upload forms and get submissions back. I'm sure I'm
>>> not the first person to do this but Google has not really been yielding much
>>> in the way of results. Does such a thing exist? Does anyone have any advice
>>> for me?
>>> Any thoughts at all would be appreciated as I'm suddenly finding myself
>>> under and epic time crunch.
There are two files JsonServer.java and OhmageJsonServer.java because
of people losing interest those never got finished. If you would like
to finish them we accept patches :) Basically people who were
interested were discussing different API options.
Aggregate actually manages the sending, and resending of data. It just
doesn't know how to post to your desired server so Aggregate needs a
class that implements the ExternalService interface that posts the
submissions to the remote server.
http://code.google.com/p/opendatakit/source/browse/src/main/java/org/...
On Wed, May 9, 2012 at 3:00 PM, Trevor Ellermann <tre...@ellermann.net> wrote:
> That form Submission API looks like exactly what I need for uploading
> forms. Thanks.
> As to changing the Collect code, It's actually part of the
> requirements that we don't do that. If I can just get publishing to
> JSON to work then I think I have all the pieces I need to get this
> working.
> Thanks again,
> --Trevor
> ___________________________
> Trevor R. Ellermann
> @trevorellermann
> K0DMA
> On Wed, May 9, 2012 at 2:49 PM, Yaw Anokwa <yano...@gmail.com> wrote:
>> Another option is to go at it from the phone side of things.
>> Using Aggregate -> Fusion Tables -> your app is potentially more
>> fragile because there are more pieces that could go wrong. Changing
>> Collect has less pieces, but then you have your own version of Collect
>> to maintain.
>> As far as automating transmission, that's pretty straightforward if
>> you are familiar with Android. You need a background service that
>> watches for a network connection and calls the InstanceUploaderTask.
>> Said service could also send on form save.
>> On Wed, May 9, 2012 at 2:36 PM, James Dailey <jamespdai...@gmail.com> wrote:
>>> You might consider publishing from Aggregate to google fusion tables then
>>> using available api to pull into your database. PHP examples are given on
>>> Google site and rails gem is also available.
>>> On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net> wrote:
>>>> Hello ODK Community,
>>>> I'm a developer and I have just been tasked with implementing the ability
>>>> to upload forms and get data back in to our own database in an automated
>>>> fashion. Basically they just want to be able to click a button, have it
>>>> upload the form and have submission data flow back into our database with no
>>>> additional human input aside from people using the collector. Of course they
>>>> want this done yesterday as well.
>>>> I see that ODK supports the OpenROSA API but I've never used that before.
>>>> I'm sure i can figure it out but in the interest of time I was hoping there
>>>> was a primer on how to upload forms and get submissions back. I'm sure I'm
>>>> not the first person to do this but Google has not really been yielding much
>>>> in the way of results. Does such a thing exist? Does anyone have any advice
>>>> for me?
>>>> Any thoughts at all would be appreciated as I'm suddenly finding myself
>>>> under and epic time crunch.
To clarify a bit more JSON was in the 0.9.x versions and when being
brought over to 1.x version of Aggregate. Changes to the protocols
were requested and in the end the people requesting it didn't finish
up the protocol specs. If you want to complete the protocol
specification and provide the translation work to your protocol then
we will be happy to include it.
On Wed, May 9, 2012 at 3:30 PM, W. Brunette <wbrune...@gmail.com> wrote:
> (please respond with anymore indepth questions to the developers email list).
> The publishing to JSON was put on hold while we worked on a new server
> to server communication specification in JSON.
> There are two files JsonServer.java and OhmageJsonServer.java because
> of people losing interest those never got finished. If you would like
> to finish them we accept patches :) Basically people who were
> interested were discussing different API options.
> Aggregate actually manages the sending, and resending of data. It just
> doesn't know how to post to your desired server so Aggregate needs a
> class that implements the ExternalService interface that posts the
> submissions to the remote server.
> http://code.google.com/p/opendatakit/source/browse/src/main/java/org/...
> Waylon
> On Wed, May 9, 2012 at 3:00 PM, Trevor Ellermann <tre...@ellermann.net> wrote:
>> That form Submission API looks like exactly what I need for uploading
>> forms. Thanks.
>> As to changing the Collect code, It's actually part of the
>> requirements that we don't do that. If I can just get publishing to
>> JSON to work then I think I have all the pieces I need to get this
>> working.
>> Thanks again,
>> --Trevor
>> ___________________________
>> Trevor R. Ellermann
>> @trevorellermann
>> K0DMA
>> On Wed, May 9, 2012 at 2:49 PM, Yaw Anokwa <yano...@gmail.com> wrote:
>>> Another option is to go at it from the phone side of things.
>>> Using Aggregate -> Fusion Tables -> your app is potentially more
>>> fragile because there are more pieces that could go wrong. Changing
>>> Collect has less pieces, but then you have your own version of Collect
>>> to maintain.
>>> As far as automating transmission, that's pretty straightforward if
>>> you are familiar with Android. You need a background service that
>>> watches for a network connection and calls the InstanceUploaderTask.
>>> Said service could also send on form save.
>>> On Wed, May 9, 2012 at 2:36 PM, James Dailey <jamespdai...@gmail.com> wrote:
>>>> You might consider publishing from Aggregate to google fusion tables then
>>>> using available api to pull into your database. PHP examples are given on
>>>> Google site and rails gem is also available.
>>>> On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net> wrote:
>>>>> Hello ODK Community,
>>>>> I'm a developer and I have just been tasked with implementing the ability
>>>>> to upload forms and get data back in to our own database in an automated
>>>>> fashion. Basically they just want to be able to click a button, have it
>>>>> upload the form and have submission data flow back into our database with no
>>>>> additional human input aside from people using the collector. Of course they
>>>>> want this done yesterday as well.
>>>>> I see that ODK supports the OpenROSA API but I've never used that before.
>>>>> I'm sure i can figure it out but in the interest of time I was hoping there
>>>>> was a primer on how to upload forms and get submissions back. I'm sure I'm
>>>>> not the first person to do this but Google has not really been yielding much
>>>>> in the way of results. Does such a thing exist? Does anyone have any advice
>>>>> for me?
>>>>> Any thoughts at all would be appreciated as I'm suddenly finding myself
>>>>> under and epic time crunch.
Copy that Waylon. Thanks for all of this information. I've joined the
dev list and will bring any further discussion on the JSON topic over
there.
I really appreciate you taking the time to let me know what is going
on with JSON. Now I just need to spend some time to figure out what is
the shortest path to getting data pushed back to my database.
--Trevor
___________________________
Trevor R. Ellermann
@trevorellermann
K0DMA
On Wed, May 9, 2012 at 3:34 PM, W. Brunette <wbrune...@gmail.com> wrote:
> To clarify a bit more JSON was in the 0.9.x versions and when being
> brought over to 1.x version of Aggregate. Changes to the protocols
> were requested and in the end the people requesting it didn't finish
> up the protocol specs. If you want to complete the protocol
> specification and provide the translation work to your protocol then
> we will be happy to include it.
> Waylon
> On Wed, May 9, 2012 at 3:30 PM, W. Brunette <wbrune...@gmail.com> wrote:
>> (please respond with anymore indepth questions to the developers email list).
>> The publishing to JSON was put on hold while we worked on a new server
>> to server communication specification in JSON.
>> There are two files JsonServer.java and OhmageJsonServer.java because
>> of people losing interest those never got finished. If you would like
>> to finish them we accept patches :) Basically people who were
>> interested were discussing different API options.
>> Aggregate actually manages the sending, and resending of data. It just
>> doesn't know how to post to your desired server so Aggregate needs a
>> class that implements the ExternalService interface that posts the
>> submissions to the remote server.
>> http://code.google.com/p/opendatakit/source/browse/src/main/java/org/...
>> Waylon
>> On Wed, May 9, 2012 at 3:00 PM, Trevor Ellermann <tre...@ellermann.net> wrote:
>>> That form Submission API looks like exactly what I need for uploading
>>> forms. Thanks.
>>> As to changing the Collect code, It's actually part of the
>>> requirements that we don't do that. If I can just get publishing to
>>> JSON to work then I think I have all the pieces I need to get this
>>> working.
>>> Thanks again,
>>> --Trevor
>>> ___________________________
>>> Trevor R. Ellermann
>>> @trevorellermann
>>> K0DMA
>>> On Wed, May 9, 2012 at 2:49 PM, Yaw Anokwa <yano...@gmail.com> wrote:
>>>> Another option is to go at it from the phone side of things.
>>>> Using Aggregate -> Fusion Tables -> your app is potentially more
>>>> fragile because there are more pieces that could go wrong. Changing
>>>> Collect has less pieces, but then you have your own version of Collect
>>>> to maintain.
>>>> As far as automating transmission, that's pretty straightforward if
>>>> you are familiar with Android. You need a background service that
>>>> watches for a network connection and calls the InstanceUploaderTask.
>>>> Said service could also send on form save.
>>>> On Wed, May 9, 2012 at 2:36 PM, James Dailey <jamespdai...@gmail.com> wrote:
>>>>> You might consider publishing from Aggregate to google fusion tables then
>>>>> using available api to pull into your database. PHP examples are given on
>>>>> Google site and rails gem is also available.
>>>>> On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net> wrote:
>>>>>> Hello ODK Community,
>>>>>> I'm a developer and I have just been tasked with implementing the ability
>>>>>> to upload forms and get data back in to our own database in an automated
>>>>>> fashion. Basically they just want to be able to click a button, have it
>>>>>> upload the form and have submission data flow back into our database with no
>>>>>> additional human input aside from people using the collector. Of course they
>>>>>> want this done yesterday as well.
>>>>>> I see that ODK supports the OpenROSA API but I've never used that before.
>>>>>> I'm sure i can figure it out but in the interest of time I was hoping there
>>>>>> was a primer on how to upload forms and get submissions back. I'm sure I'm
>>>>>> not the first person to do this but Google has not really been yielding much
>>>>>> in the way of results. Does such a thing exist? Does anyone have any advice
>>>>>> for me?
>>>>>> Any thoughts at all would be appreciated as I'm suddenly finding myself
>>>>>> under and epic time crunch.
Or, if you host Aggregate on your own Tomcat instance, you can set up a
database trigger on the Aggregate database tables and push the data to your
own schema. This would require a public IP address so the phones can
publish to the server, and you have the SSL certificate process to wade
through if you need https connectivity.
Setting up a trigger would be part of the "upload form". You could script
this (so you could upload the form, then delve into the Aggregate database
structures and establish the trigger).
The database trigger isolates your app from the table structures used by
Aggregate. I recommend not using those tables directly, as that would make
your app very difficult to migrate to newer versions. Going forward, the
MODEL_VERSION and UI_VERSION fields will be consolidated into a VERSION
string, for example.
Mitch
On Wed, May 9, 2012 at 3:46 PM, Trevor Ellermann <tre...@ellermann.net>wrote:
> Copy that Waylon. Thanks for all of this information. I've joined the
> dev list and will bring any further discussion on the JSON topic over
> there.
> I really appreciate you taking the time to let me know what is going
> on with JSON. Now I just need to spend some time to figure out what is
> the shortest path to getting data pushed back to my database.
> --Trevor
> ___________________________
> Trevor R. Ellermann
> @trevorellermann
> K0DMA
> On Wed, May 9, 2012 at 3:34 PM, W. Brunette <wbrune...@gmail.com> wrote:
> > To clarify a bit more JSON was in the 0.9.x versions and when being
> > brought over to 1.x version of Aggregate. Changes to the protocols
> > were requested and in the end the people requesting it didn't finish
> > up the protocol specs. If you want to complete the protocol
> > specification and provide the translation work to your protocol then
> > we will be happy to include it.
> > Waylon
> > On Wed, May 9, 2012 at 3:30 PM, W. Brunette <wbrune...@gmail.com> wrote:
> >> (please respond with anymore indepth questions to the developers email
> list).
> >> The publishing to JSON was put on hold while we worked on a new server
> >> to server communication specification in JSON.
> >> There are two files JsonServer.java and OhmageJsonServer.java because
> >> of people losing interest those never got finished. If you would like
> >> to finish them we accept patches :) Basically people who were
> >> interested were discussing different API options.
> >> Aggregate actually manages the sending, and resending of data. It just
> >> doesn't know how to post to your desired server so Aggregate needs a
> >> class that implements the ExternalService interface that posts the
> >> submissions to the remote server.
> >> On Wed, May 9, 2012 at 3:00 PM, Trevor Ellermann <tre...@ellermann.net>
> wrote:
> >>> That form Submission API looks like exactly what I need for uploading
> >>> forms. Thanks.
> >>> As to changing the Collect code, It's actually part of the
> >>> requirements that we don't do that. If I can just get publishing to
> >>> JSON to work then I think I have all the pieces I need to get this
> >>> working.
> >>>> Using Aggregate -> Fusion Tables -> your app is potentially more
> >>>> fragile because there are more pieces that could go wrong. Changing
> >>>> Collect has less pieces, but then you have your own version of Collect
> >>>> to maintain.
> >>>> As far as automating transmission, that's pretty straightforward if
> >>>> you are familiar with Android. You need a background service that
> >>>> watches for a network connection and calls the InstanceUploaderTask.
> >>>> Said service could also send on form save.
> >>>> On Wed, May 9, 2012 at 2:36 PM, James Dailey <jamespdai...@gmail.com>
> wrote:
> >>>>> You might consider publishing from Aggregate to google fusion tables
> then
> >>>>> using available api to pull into your database. PHP examples are
> given on
> >>>>> Google site and rails gem is also available.
> >>>>> On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net>
> wrote:
> >>>>>> Hello ODK Community,
> >>>>>> I'm a developer and I have just been tasked with implementing the
> ability
> >>>>>> to upload forms and get data back in to our own database in an
> automated
> >>>>>> fashion. Basically they just want to be able to click a button,
> have it
> >>>>>> upload the form and have submission data flow back into our
> database with no
> >>>>>> additional human input aside from people using the collector. Of
> course they
> >>>>>> want this done yesterday as well.
> >>>>>> I see that ODK supports the OpenROSA API but I've never used that
> before.
> >>>>>> I'm sure i can figure it out but in the interest of time I was
> hoping there
> >>>>>> was a primer on how to upload forms and get submissions back. I'm
> sure I'm
> >>>>>> not the first person to do this but Google has not really
> been yielding much
> >>>>>> in the way of results. Does such a thing exist? Does anyone have
> any advice
> >>>>>> for me?
> >>>>>> Any thoughts at all would be appreciated as I'm suddenly finding
> myself
> >>>>>> under and epic time crunch.
You and I think a lot alike. I've spent the rest of the afternoon
installing the aggregate server on my own machine so I could look
directly at the database tables and upload scripts. I've been trying
really hard to avoid mucking with the ODK code but it's looking like
adding a hook to forward my database any copy of submissions might be
the way to go.
Thanks for the thoughts,
--Trevor
___________________________
Trevor R. Ellermann
@trevorellermann
K0DMA
On Wed, May 9, 2012 at 5:37 PM, Mitch S <mitchellsu...@gmail.com> wrote:
> Or, if you host Aggregate on your own Tomcat instance, you can set up a
> database trigger on the Aggregate database tables and push the data to your
> own schema. This would require a public IP address so the phones can
> publish to the server, and you have the SSL certificate process to wade
> through if you need https connectivity.
> Setting up a trigger would be part of the "upload form". You could script
> this (so you could upload the form, then delve into the Aggregate database
> structures and establish the trigger).
> The database trigger isolates your app from the table structures used by
> Aggregate. I recommend not using those tables directly, as that would make
> your app very difficult to migrate to newer versions. Going forward, the
> MODEL_VERSION and UI_VERSION fields will be consolidated into a VERSION
> string, for example.
> Mitch
> On Wed, May 9, 2012 at 3:46 PM, Trevor Ellermann <tre...@ellermann.net>
> wrote:
>> Copy that Waylon. Thanks for all of this information. I've joined the
>> dev list and will bring any further discussion on the JSON topic over
>> there.
>> I really appreciate you taking the time to let me know what is going
>> on with JSON. Now I just need to spend some time to figure out what is
>> the shortest path to getting data pushed back to my database.
>> --Trevor
>> ___________________________
>> Trevor R. Ellermann
>> @trevorellermann
>> K0DMA
>> On Wed, May 9, 2012 at 3:34 PM, W. Brunette <wbrune...@gmail.com> wrote:
>> > To clarify a bit more JSON was in the 0.9.x versions and when being
>> > brought over to 1.x version of Aggregate. Changes to the protocols
>> > were requested and in the end the people requesting it didn't finish
>> > up the protocol specs. If you want to complete the protocol
>> > specification and provide the translation work to your protocol then
>> > we will be happy to include it.
>> > Waylon
>> > On Wed, May 9, 2012 at 3:30 PM, W. Brunette <wbrune...@gmail.com> wrote:
>> >> (please respond with anymore indepth questions to the developers email
>> >> list).
>> >> The publishing to JSON was put on hold while we worked on a new server
>> >> to server communication specification in JSON.
>> >> There are two files JsonServer.java and OhmageJsonServer.java because
>> >> of people losing interest those never got finished. If you would like
>> >> to finish them we accept patches :) Basically people who were
>> >> interested were discussing different API options.
>> >> Aggregate actually manages the sending, and resending of data. It just
>> >> doesn't know how to post to your desired server so Aggregate needs a
>> >> class that implements the ExternalService interface that posts the
>> >> submissions to the remote server.
>> >> On Wed, May 9, 2012 at 3:00 PM, Trevor Ellermann <tre...@ellermann.net>
>> >> wrote:
>> >>> That form Submission API looks like exactly what I need for uploading
>> >>> forms. Thanks.
>> >>> As to changing the Collect code, It's actually part of the
>> >>> requirements that we don't do that. If I can just get publishing to
>> >>> JSON to work then I think I have all the pieces I need to get this
>> >>> working.
>> >>>> Using Aggregate -> Fusion Tables -> your app is potentially more
>> >>>> fragile because there are more pieces that could go wrong. Changing
>> >>>> Collect has less pieces, but then you have your own version of
>> >>>> Collect
>> >>>> to maintain.
>> >>>> As far as automating transmission, that's pretty straightforward if
>> >>>> you are familiar with Android. You need a background service that
>> >>>> watches for a network connection and calls the InstanceUploaderTask.
>> >>>> Said service could also send on form save.
>> >>>> On Wed, May 9, 2012 at 2:36 PM, James Dailey <jamespdai...@gmail.com>
>> >>>> wrote:
>> >>>>> You might consider publishing from Aggregate to google fusion tables
>> >>>>> then
>> >>>>> using available api to pull into your database. PHP examples are
>> >>>>> given on
>> >>>>> Google site and rails gem is also available.
>> >>>>> On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net>
>> >>>>> wrote:
>> >>>>>> Hello ODK Community,
>> >>>>>> I'm a developer and I have just been tasked with implementing the
>> >>>>>> ability
>> >>>>>> to upload forms and get data back in to our own database in an
>> >>>>>> automated
>> >>>>>> fashion. Basically they just want to be able to click a button,
>> >>>>>> have it
>> >>>>>> upload the form and have submission data flow back into our
>> >>>>>> database with no
>> >>>>>> additional human input aside from people using the collector. Of
>> >>>>>> course they
>> >>>>>> want this done yesterday as well.
>> >>>>>> I see that ODK supports the OpenROSA API but I've never used that
>> >>>>>> before.
>> >>>>>> I'm sure i can figure it out but in the interest of time I was
>> >>>>>> hoping there
>> >>>>>> was a primer on how to upload forms and get submissions back. I'm
>> >>>>>> sure I'm
>> >>>>>> not the first person to do this but Google has not really
>> >>>>>> been yielding much
>> >>>>>> in the way of results. Does such a thing exist? Does anyone have
>> >>>>>> any advice
>> >>>>>> for me?
>> >>>>>> Any thoughts at all would be appreciated as I'm suddenly finding
>> >>>>>> myself
>> >>>>>> under and epic time crunch.
You'll want to pay attention to the IS_COMPLETE column in the top level
table for a submission. Until that is set to true, the record is not
complete and may be missing one or more audio, video or image attachments.
Mitch
On Wed, May 9, 2012 at 6:22 PM, Trevor Ellermann <tre...@ellermann.net>wrote:
> You and I think a lot alike. I've spent the rest of the afternoon
> installing the aggregate server on my own machine so I could look
> directly at the database tables and upload scripts. I've been trying
> really hard to avoid mucking with the ODK code but it's looking like
> adding a hook to forward my database any copy of submissions might be
> the way to go.
> On Wed, May 9, 2012 at 5:37 PM, Mitch S <mitchellsu...@gmail.com> wrote:
> > Or, if you host Aggregate on your own Tomcat instance, you can set up a
> > database trigger on the Aggregate database tables and push the data to
> your
> > own schema. This would require a public IP address so the phones can
> > publish to the server, and you have the SSL certificate process to wade
> > through if you need https connectivity.
> > Setting up a trigger would be part of the "upload form". You could
> script
> > this (so you could upload the form, then delve into the Aggregate
> database
> > structures and establish the trigger).
> > The database trigger isolates your app from the table structures used by
> > Aggregate. I recommend not using those tables directly, as that would
> make
> > your app very difficult to migrate to newer versions. Going forward, the
> > MODEL_VERSION and UI_VERSION fields will be consolidated into a VERSION
> > string, for example.
> > Mitch
> > On Wed, May 9, 2012 at 3:46 PM, Trevor Ellermann <tre...@ellermann.net>
> > wrote:
> >> Copy that Waylon. Thanks for all of this information. I've joined the
> >> dev list and will bring any further discussion on the JSON topic over
> >> there.
> >> I really appreciate you taking the time to let me know what is going
> >> on with JSON. Now I just need to spend some time to figure out what is
> >> the shortest path to getting data pushed back to my database.
> >> On Wed, May 9, 2012 at 3:34 PM, W. Brunette <wbrune...@gmail.com>
> wrote:
> >> > To clarify a bit more JSON was in the 0.9.x versions and when being
> >> > brought over to 1.x version of Aggregate. Changes to the protocols
> >> > were requested and in the end the people requesting it didn't finish
> >> > up the protocol specs. If you want to complete the protocol
> >> > specification and provide the translation work to your protocol then
> >> > we will be happy to include it.
> >> > Waylon
> >> > On Wed, May 9, 2012 at 3:30 PM, W. Brunette <wbrune...@gmail.com>
> wrote:
> >> >> (please respond with anymore indepth questions to the developers
> email
> >> >> list).
> >> >> The publishing to JSON was put on hold while we worked on a new
> server
> >> >> to server communication specification in JSON.
> >> >> There are two files JsonServer.java and OhmageJsonServer.java because
> >> >> of people losing interest those never got finished. If you would like
> >> >> to finish them we accept patches :) Basically people who were
> >> >> interested were discussing different API options.
> >> >> Aggregate actually manages the sending, and resending of data. It
> just
> >> >> doesn't know how to post to your desired server so Aggregate needs a
> >> >> class that implements the ExternalService interface that posts the
> >> >> submissions to the remote server.
> >> >> On Wed, May 9, 2012 at 3:00 PM, Trevor Ellermann <
> tre...@ellermann.net>
> >> >> wrote:
> >> >>> That form Submission API looks like exactly what I need for
> uploading
> >> >>> forms. Thanks.
> >> >>> As to changing the Collect code, It's actually part of the
> >> >>> requirements that we don't do that. If I can just get publishing to
> >> >>> JSON to work then I think I have all the pieces I need to get this
> >> >>> working.
> >> >>> On Wed, May 9, 2012 at 2:49 PM, Yaw Anokwa <yano...@gmail.com>
> wrote:
> >> >>>> Another option is to go at it from the phone side of things.
> >> >>>> Using Aggregate -> Fusion Tables -> your app is potentially more
> >> >>>> fragile because there are more pieces that could go wrong. Changing
> >> >>>> Collect has less pieces, but then you have your own version of
> >> >>>> Collect
> >> >>>> to maintain.
> >> >>>> As far as automating transmission, that's pretty straightforward if
> >> >>>> you are familiar with Android. You need a background service that
> >> >>>> watches for a network connection and calls the
> InstanceUploaderTask.
> >> >>>> Said service could also send on form save.
> >> >>>> On Wed, May 9, 2012 at 2:36 PM, James Dailey <
> jamespdai...@gmail.com>
> >> >>>> wrote:
> >> >>>>> You might consider publishing from Aggregate to google fusion
> tables
> >> >>>>> then
> >> >>>>> using available api to pull into your database. PHP examples are
> >> >>>>> given on
> >> >>>>> Google site and rails gem is also available.
> >> >>>>> On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net>
> >> >>>>> wrote:
> >> >>>>>> Hello ODK Community,
> >> >>>>>> I'm a developer and I have just been tasked with implementing the
> >> >>>>>> ability
> >> >>>>>> to upload forms and get data back in to our own database in an
> >> >>>>>> automated
> >> >>>>>> fashion. Basically they just want to be able to click a button,
> >> >>>>>> have it
> >> >>>>>> upload the form and have submission data flow back into our
> >> >>>>>> database with no
> >> >>>>>> additional human input aside from people using the collector. Of
> >> >>>>>> course they
> >> >>>>>> want this done yesterday as well.
> >> >>>>>> I see that ODK supports the OpenROSA API but I've never used that
> >> >>>>>> before.
> >> >>>>>> I'm sure i can figure it out but in the interest of time I was
> >> >>>>>> hoping there
> >> >>>>>> was a primer on how to upload forms and get submissions back. I'm
> >> >>>>>> sure I'm
> >> >>>>>> not the first person to do this but Google has not really
> >> >>>>>> been yielding much
> >> >>>>>> in the way of results. Does such a thing exist? Does anyone have
> >> >>>>>> any advice
> >> >>>>>> for me?
> >> >>>>>> Any thoughts at all would be appreciated as I'm suddenly finding
> >> >>>>>> myself
> >> >>>>>> under and epic time crunch.
> You'll want to pay attention to the IS_COMPLETE column in the top level
> table for a submission. Until that is set to true, the record is not
> complete and may be missing one or more audio, video or image attachments.
> Mitch
> On Wed, May 9, 2012 at 6:22 PM, Trevor Ellermann <tre...@ellermann.net>
> wrote:
>> Hey Mitch,
>> You and I think a lot alike. I've spent the rest of the afternoon
>> installing the aggregate server on my own machine so I could look
>> directly at the database tables and upload scripts. I've been trying
>> really hard to avoid mucking with the ODK code but it's looking like
>> adding a hook to forward my database any copy of submissions might be
>> the way to go.
>> On Wed, May 9, 2012 at 5:37 PM, Mitch S <mitchellsu...@gmail.com> wrote:
>> > Or, if you host Aggregate on your own Tomcat instance, you can set up a
>> > database trigger on the Aggregate database tables and push the data to
>> > your
>> > own schema. This would require a public IP address so the phones can
>> > publish to the server, and you have the SSL certificate process to wade
>> > through if you need https connectivity.
>> > Setting up a trigger would be part of the "upload form". You could
>> > script
>> > this (so you could upload the form, then delve into the Aggregate
>> > database
>> > structures and establish the trigger).
>> > The database trigger isolates your app from the table structures used by
>> > Aggregate. I recommend not using those tables directly, as that would
>> > make
>> > your app very difficult to migrate to newer versions. Going forward,
>> > the
>> > MODEL_VERSION and UI_VERSION fields will be consolidated into a VERSION
>> > string, for example.
>> > Mitch
>> > On Wed, May 9, 2012 at 3:46 PM, Trevor Ellermann <tre...@ellermann.net>
>> > wrote:
>> >> Copy that Waylon. Thanks for all of this information. I've joined the
>> >> dev list and will bring any further discussion on the JSON topic over
>> >> there.
>> >> I really appreciate you taking the time to let me know what is going
>> >> on with JSON. Now I just need to spend some time to figure out what is
>> >> the shortest path to getting data pushed back to my database.
>> >> On Wed, May 9, 2012 at 3:34 PM, W. Brunette <wbrune...@gmail.com>
>> >> wrote:
>> >> > To clarify a bit more JSON was in the 0.9.x versions and when being
>> >> > brought over to 1.x version of Aggregate. Changes to the protocols
>> >> > were requested and in the end the people requesting it didn't finish
>> >> > up the protocol specs. If you want to complete the protocol
>> >> > specification and provide the translation work to your protocol then
>> >> > we will be happy to include it.
>> >> > Waylon
>> >> > On Wed, May 9, 2012 at 3:30 PM, W. Brunette <wbrune...@gmail.com>
>> >> > wrote:
>> >> >> (please respond with anymore indepth questions to the developers
>> >> >> email
>> >> >> list).
>> >> >> The publishing to JSON was put on hold while we worked on a new
>> >> >> server
>> >> >> to server communication specification in JSON.
>> >> >> There are two files JsonServer.java and OhmageJsonServer.java
>> >> >> because
>> >> >> of people losing interest those never got finished. If you would
>> >> >> like
>> >> >> to finish them we accept patches :) Basically people who were
>> >> >> interested were discussing different API options.
>> >> >> Aggregate actually manages the sending, and resending of data. It
>> >> >> just
>> >> >> doesn't know how to post to your desired server so Aggregate needs a
>> >> >> class that implements the ExternalService interface that posts the
>> >> >> submissions to the remote server.
>> >> >> On Wed, May 9, 2012 at 3:00 PM, Trevor Ellermann
>> >> >> <tre...@ellermann.net>
>> >> >> wrote:
>> >> >>> That form Submission API looks like exactly what I need for
>> >> >>> uploading
>> >> >>> forms. Thanks.
>> >> >>> As to changing the Collect code, It's actually part of the
>> >> >>> requirements that we don't do that. If I can just get publishing to
>> >> >>> JSON to work then I think I have all the pieces I need to get this
>> >> >>> working.
>> >> >>> On Wed, May 9, 2012 at 2:49 PM, Yaw Anokwa <yano...@gmail.com>
>> >> >>> wrote:
>> >> >>>> Another option is to go at it from the phone side of things.
>> >> >>>> Using Aggregate -> Fusion Tables -> your app is potentially more
>> >> >>>> fragile because there are more pieces that could go wrong.
>> >> >>>> Changing
>> >> >>>> Collect has less pieces, but then you have your own version of
>> >> >>>> Collect
>> >> >>>> to maintain.
>> >> >>>> As far as automating transmission, that's pretty straightforward
>> >> >>>> if
>> >> >>>> you are familiar with Android. You need a background service that
>> >> >>>> watches for a network connection and calls the
>> >> >>>> InstanceUploaderTask.
>> >> >>>> Said service could also send on form save.
>> >> >>>> On Wed, May 9, 2012 at 2:36 PM, James Dailey
>> >> >>>> <jamespdai...@gmail.com>
>> >> >>>> wrote:
>> >> >>>>> You might consider publishing from Aggregate to google fusion
>> >> >>>>> tables
>> >> >>>>> then
>> >> >>>>> using available api to pull into your database. PHP examples
>> >> >>>>> are
>> >> >>>>> given on
>> >> >>>>> Google site and rails gem is also available.
>> >> >>>>> On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net>
>> >> >>>>> wrote:
>> >> >>>>>> Hello ODK Community,
>> >> >>>>>> I'm a developer and I have just been tasked with implementing
>> >> >>>>>> the
>> >> >>>>>> ability
>> >> >>>>>> to upload forms and get data back in to our own database in an
>> >> >>>>>> automated
>> >> >>>>>> fashion. Basically they just want to be able to click a button,
>> >> >>>>>> have it
>> >> >>>>>> upload the form and have submission data flow back into our
>> >> >>>>>> database with no
>> >> >>>>>> additional human input aside from people using the collector. Of
>> >> >>>>>> course they
>> >> >>>>>> want this done yesterday as well.
>> >> >>>>>> I see that ODK supports the OpenROSA API but I've never used
>> >> >>>>>> that
>> >> >>>>>> before.
>> >> >>>>>> I'm sure i can figure it out but in the interest of time I was
>> >> >>>>>> hoping there
>> >> >>>>>> was a primer on how to upload forms and get submissions back.
>> >> >>>>>> I'm
>> >> >>>>>> sure I'm
>> >> >>>>>> not the first person to do this but Google has not really
>> >> >>>>>> been yielding much
>> >> >>>>>> in the way of results. Does such a thing exist? Does anyone have
>> >> >>>>>> any advice
>> >> >>>>>> for me?
>> >> >>>>>> Any thoughts at all would be appreciated as I'm suddenly finding
>> >> >>>>>> myself
>> >> >>>>>> under and epic time crunch.
hi guys, so am writing a django app intended to run a celery-task that pulls data from ODK Aggregate server. does this mean that its impossible for now ?? if not any ideas i can use??(forgive me if this sounds silly but cant i even create a socket to do the job??)
On Thursday, May 10, 2012 1:34:45 AM UTC+3, waylon wrote:
> To clarify a bit more JSON was in the 0.9.x versions and when being > brought over to 1.x version of Aggregate. Changes to the protocols > were requested and in the end the people requesting it didn't finish > up the protocol specs. If you want to complete the protocol > specification and provide the translation work to your protocol then > we will be happy to include it.
> Waylon
> On Wed, May 9, 2012 at 3:30 PM, W. Brunette <wbrune...@gmail.com> wrote: > > (please respond with anymore indepth questions to the developers email > list).
> > The publishing to JSON was put on hold while we worked on a new server > > to server communication specification in JSON.
> > There are two files JsonServer.java and OhmageJsonServer.java because > > of people losing interest those never got finished. If you would like > > to finish them we accept patches :) Basically people who were > > interested were discussing different API options.
> > Aggregate actually manages the sending, and resending of data. It just > > doesn't know how to post to your desired server so Aggregate needs a > > class that implements the ExternalService interface that posts the > > submissions to the remote server.
> > On Wed, May 9, 2012 at 3:00 PM, Trevor Ellermann <tre...@ellermann.net> > wrote: > >> That form Submission API looks like exactly what I need for uploading > >> forms. Thanks.
> >> As to changing the Collect code, It's actually part of the > >> requirements that we don't do that. If I can just get publishing to > >> JSON to work then I think I have all the pieces I need to get this > >> working.
> >>> Using Aggregate -> Fusion Tables -> your app is potentially more > >>> fragile because there are more pieces that could go wrong. Changing > >>> Collect has less pieces, but then you have your own version of Collect > >>> to maintain.
> >>> As far as automating transmission, that's pretty straightforward if > >>> you are familiar with Android. You need a background service that > >>> watches for a network connection and calls the InstanceUploaderTask. > >>> Said service could also send on form save.
> >>> On Wed, May 9, 2012 at 2:36 PM, James Dailey <jamespdai...@gmail.com> > wrote: > >>>> You might consider publishing from Aggregate to google fusion tables > then > >>>> using available api to pull into your database. PHP examples are > given on > >>>> Google site and rails gem is also available.
> >>>> On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net> > wrote:
> >>>>> Hello ODK Community,
> >>>>> I'm a developer and I have just been tasked with implementing the > ability > >>>>> to upload forms and get data back in to our own database in an > automated > >>>>> fashion. Basically they just want to be able to click a button, have > it > >>>>> upload the form and have submission data flow back into our database > with no > >>>>> additional human input aside from people using the collector. Of > course they > >>>>> want this done yesterday as well.
> >>>>> I see that ODK supports the OpenROSA API but I've never used that > before. > >>>>> I'm sure i can figure it out but in the interest of time I was > hoping there > >>>>> was a primer on how to upload forms and get submissions back. I'm > sure I'm > >>>>> not the first person to do this but Google has not really > been yielding much > >>>>> in the way of results. Does such a thing exist? Does anyone have any > advice > >>>>> for me?
> >>>>> Any thoughts at all would be appreciated as I'm suddenly finding > myself > >>>>> under and epic time crunch.
Lots of options here. You can stream to Fusion Tables and pull the
data using those APIs. You can look at ODK Briefcase code -- it pulls
data from Aggregate. You can also help finish the JSON export and use
that.
On Mon, May 14, 2012 at 7:36 AM, Kisitu Augustine <austiin...@gmail.com> wrote:
> hi guys, so am writing a django app intended to run a celery-task that pulls
> data from ODK Aggregate server. does this mean that its impossible for now
> ?? if not any ideas i can use??(forgive me if this sounds silly but cant i
> even create a socket to do the job??)
> On Thursday, May 10, 2012 1:34:45 AM UTC+3, waylon wrote:
>> To clarify a bit more JSON was in the 0.9.x versions and when being
>> brought over to 1.x version of Aggregate. Changes to the protocols
>> were requested and in the end the people requesting it didn't finish
>> up the protocol specs. If you want to complete the protocol
>> specification and provide the translation work to your protocol then
>> we will be happy to include it.
>> Waylon
>> On Wed, May 9, 2012 at 3:30 PM, W. Brunette <wbrune...@gmail.com> wrote:
>> > (please respond with anymore indepth questions to the developers email
>> > list).
>> > The publishing to JSON was put on hold while we worked on a new server
>> > to server communication specification in JSON.
>> > There are two files JsonServer.java and OhmageJsonServer.java because
>> > of people losing interest those never got finished. If you would like
>> > to finish them we accept patches :) Basically people who were
>> > interested were discussing different API options.
>> > Aggregate actually manages the sending, and resending of data. It just
>> > doesn't know how to post to your desired server so Aggregate needs a
>> > class that implements the ExternalService interface that posts the
>> > submissions to the remote server.
>> > On Wed, May 9, 2012 at 3:00 PM, Trevor Ellermann <tre...@ellermann.net>
>> > wrote:
>> >> That form Submission API looks like exactly what I need for uploading
>> >> forms. Thanks.
>> >> As to changing the Collect code, It's actually part of the
>> >> requirements that we don't do that. If I can just get publishing to
>> >> JSON to work then I think I have all the pieces I need to get this
>> >> working.
>> >>> Using Aggregate -> Fusion Tables -> your app is potentially more
>> >>> fragile because there are more pieces that could go wrong. Changing
>> >>> Collect has less pieces, but then you have your own version of Collect
>> >>> to maintain.
>> >>> As far as automating transmission, that's pretty straightforward if
>> >>> you are familiar with Android. You need a background service that
>> >>> watches for a network connection and calls the InstanceUploaderTask.
>> >>> Said service could also send on form save.
>> >>> On Wed, May 9, 2012 at 2:36 PM, James Dailey <jamespdai...@gmail.com>
>> >>> wrote:
>> >>>> You might consider publishing from Aggregate to google fusion tables
>> >>>> then
>> >>>> using available api to pull into your database. PHP examples are
>> >>>> given on
>> >>>> Google site and rails gem is also available.
>> >>>> On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net>
>> >>>> wrote:
>> >>>>> Hello ODK Community,
>> >>>>> I'm a developer and I have just been tasked with implementing the
>> >>>>> ability
>> >>>>> to upload forms and get data back in to our own database in an
>> >>>>> automated
>> >>>>> fashion. Basically they just want to be able to click a button, have
>> >>>>> it
>> >>>>> upload the form and have submission data flow back into our database
>> >>>>> with no
>> >>>>> additional human input aside from people using the collector. Of
>> >>>>> course they
>> >>>>> want this done yesterday as well.
>> >>>>> I see that ODK supports the OpenROSA API but I've never used that
>> >>>>> before.
>> >>>>> I'm sure i can figure it out but in the interest of time I was
>> >>>>> hoping there
>> >>>>> was a primer on how to upload forms and get submissions back. I'm
>> >>>>> sure I'm
>> >>>>> not the first person to do this but Google has not really
>> >>>>> been yielding much
>> >>>>> in the way of results. Does such a thing exist? Does anyone have any
>> >>>>> advice
>> >>>>> for me?
>> >>>>> Any thoughts at all would be appreciated as I'm suddenly finding
>> >>>>> myself
>> >>>>> under and epic time crunch.
On Monday, May 14, 2012 5:43:18 PM UTC+3, Yaw Anokwa wrote:
> Lots of options here. You can stream to Fusion Tables and pull the > data using those APIs. You can look at ODK Briefcase code -- it pulls > data from Aggregate. You can also help finish the JSON export and use > that.
> On Mon, May 14, 2012 at 7:36 AM, Kisitu Augustine <austiin...@gmail.com> > wrote: > > hi guys, so am writing a django app intended to run a celery-task that > pulls > > data from ODK Aggregate server. does this mean that its impossible for > now > > ?? if not any ideas i can use??(forgive me if this sounds silly but cant > i > > even create a socket to do the job??)
> > On Thursday, May 10, 2012 1:34:45 AM UTC+3, waylon wrote:
> >> To clarify a bit more JSON was in the 0.9.x versions and when being > >> brought over to 1.x version of Aggregate. Changes to the protocols > >> were requested and in the end the people requesting it didn't finish > >> up the protocol specs. If you want to complete the protocol > >> specification and provide the translation work to your protocol then > >> we will be happy to include it.
> >> Waylon
> >> On Wed, May 9, 2012 at 3:30 PM, W. Brunette <wbrune...@gmail.com> > wrote: > >> > (please respond with anymore indepth questions to the developers > email > >> > list).
> >> > The publishing to JSON was put on hold while we worked on a new > server > >> > to server communication specification in JSON.
> >> > There are two files JsonServer.java and OhmageJsonServer.java because > >> > of people losing interest those never got finished. If you would like > >> > to finish them we accept patches :) Basically people who were > >> > interested were discussing different API options.
> >> > Aggregate actually manages the sending, and resending of data. It > just > >> > doesn't know how to post to your desired server so Aggregate needs a > >> > class that implements the ExternalService interface that posts the > >> > submissions to the remote server.
> >> > On Wed, May 9, 2012 at 3:00 PM, Trevor Ellermann < > tre...@ellermann.net> > >> > wrote: > >> >> That form Submission API looks like exactly what I need for > uploading > >> >> forms. Thanks.
> >> >> As to changing the Collect code, It's actually part of the > >> >> requirements that we don't do that. If I can just get publishing to > >> >> JSON to work then I think I have all the pieces I need to get this > >> >> working.
> >> >>> Using Aggregate -> Fusion Tables -> your app is potentially more > >> >>> fragile because there are more pieces that could go wrong. Changing > >> >>> Collect has less pieces, but then you have your own version of > Collect > >> >>> to maintain.
> >> >>> As far as automating transmission, that's pretty straightforward if > >> >>> you are familiar with Android. You need a background service that > >> >>> watches for a network connection and calls the > InstanceUploaderTask. > >> >>> Said service could also send on form save.
> >> >>> On Wed, May 9, 2012 at 2:36 PM, James Dailey < > jamespdai...@gmail.com> > >> >>> wrote: > >> >>>> You might consider publishing from Aggregate to google fusion > tables > >> >>>> then > >> >>>> using available api to pull into your database. PHP examples are > >> >>>> given on > >> >>>> Google site and rails gem is also available.
> >> >>>> On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net> > >> >>>> wrote:
> >> >>>>> Hello ODK Community,
> >> >>>>> I'm a developer and I have just been tasked with implementing the > >> >>>>> ability > >> >>>>> to upload forms and get data back in to our own database in an > >> >>>>> automated > >> >>>>> fashion. Basically they just want to be able to click a button, > have > >> >>>>> it > >> >>>>> upload the form and have submission data flow back into our > database > >> >>>>> with no > >> >>>>> additional human input aside from people using the collector. Of > >> >>>>> course they > >> >>>>> want this done yesterday as well.
> >> >>>>> I see that ODK supports the OpenROSA API but I've never used that > >> >>>>> before. > >> >>>>> I'm sure i can figure it out but in the interest of time I was > >> >>>>> hoping there > >> >>>>> was a primer on how to upload forms and get submissions back. I'm > >> >>>>> sure I'm > >> >>>>> not the first person to do this but Google has not really > >> >>>>> been yielding much > >> >>>>> in the way of results. Does such a thing exist? Does anyone have > any > >> >>>>> advice > >> >>>>> for me?
> >> >>>>> Any thoughts at all would be appreciated as I'm suddenly finding > >> >>>>> myself > >> >>>>> under and epic time crunch.
I am investigating a totally different method. I am also trying to save ODK form submissions to a SQL database, and then use a Web GUI for the SQL database to view and analyse the submission data. So, much of the ODK Aggregate functionality is not actually needed. I found this old project:
This is a very simple python-based ODK Aggregate server (essentially). It can host forms, and accept submissions from ODK Collect. It currently writes the submissions to the file system, so I thought of modifying it to write the submissions to a database as well (and maybe re-submit the submission to an actual ODK Aggregate server or Fusion tables, if needed). I cloned it and modified it to work with ODK Collect v1.1.7. The project is here:
On Wednesday, 9 May 2012 23:29:59 UTC+2, Trevor Ellermann wrote:
> Hello ODK Community,
> I'm a developer and I have just been tasked with implementing the ability > to upload forms and get data back in to our own database in an automated > fashion. Basically they just want to be able to click a button, have it > upload the form and have submission data flow back into our database with > no additional human input aside from people using the collector. Of course > they want this done yesterday as well.
> I see that ODK supports the OpenROSA API but I've never used that before. > I'm sure i can figure it out but in the interest of time I was hoping there > was a primer on how to upload forms and get submissions back. I'm sure I'm > not the first person to do this but Google has not really > been yielding much in the way of results. Does such a thing exist? Does > anyone have any advice for me?
> Any thoughts at all would be appreciated as I'm suddenly finding myself > under and epic time crunch.
