hi @jaime.bosque and @Jaime -
I’m wondering if there is a feature that I have misunderstood or am not aware of. Is it possible to collect data via the Android Capture app and transmit it via SMS? That would require the Android app to read the configured parsers, parse and transform the locally stored data, and transmit it via SMS via the gateway to DHIS2.
The use case is a large implementation using the Android app, but in some remote location there is only reliable sms, not cellular data.
Please let me know if I need to clarify my question or add more detail.
Edit: I think I’ve found what I was looking for in SMS Sync, however, I cannot find the up to date link in Github to review it’s current state. I’ve only found this deprecated document. SMS Sync (deprecated) - Google Docs
Getting closer…SMS module - DHIS2 Documentation
Thanks for your question. Please note that some documentation very technical might be placed here: Overview | DHIS2 Developer Portal which is where you could find the documents you were looking for. Unfortunately we migrated this a while ago and didn’t update that page (just request the update), in any case, the final documents can still by found (RAW) here: dhis2-android-docs/content/tech-guides at main · dhis2/dhis2-android-docs · GitHub
Now, answering your question. Android Capture App supports transmitting data (aggregate and tracker) via SMS and this is transparent to the App and would be proposed as a sync method when no wireless or data is available and a SIM/telephone services exist. When I am saying this is transparent I mean it, as the App will rely on your server (or middleware) to take care of an possible SMS scrambling/reassembling etc which might be needed depending on your SMS provider and if you are transmitting information that requires more than one SMS (usual case with tracker data).
You will need an SMS gateway, this gateway is what you will usually get from providers like clickatel, bulksms, etc and which sends an API call to your DHIS2 server. If your SMS are not arriving properly you will need this gateway to reassamble/reoder/recode (which some providers will allow you to do, or you might need to code some functions -i.e in a serverless implementation-). This is what the guide: dhis2-android-docs/SMS-Sync.md at main · dhis2/dhis2-android-docs · GitHub aims to explain and even provide functions that you could try.
A while ago I heavily tested something similar: https://docs.google.com/document/d/1zL9zlVXyMaWCCQ5u2hDAAWV1b7I8lNJOtCGVTAVioMU/edit# and you might find that doc interesting. Please note that in order to have all this SMS working you will be heavily dependant on how SMS are treated at server provider, in the example above, we found out that the provider was performing a character translation and this might vary from country to country.
Good luck and let us know if you need more help. Either @Jaime or @zubair can probably help as well.
Thanks @jaime.bosque - overall your information is good news and I understand. I will review the docs today.
Some initial thoughts/questions (Sorry if they are in the docs, I want to ask before I forget):
Does the sync send a single dataValueSet (per OU/period,etc) per message and does it send a single event or tei? That would seem pretty specific and inefficient when dealing with messaging rates.
My guess is that it sends a ALL dataValues and ALL events & TEIs since the last sync which is why it needs to be handled with middleware.
I think a serverless approach will be really helpful in this case.
The gateway is the part I understand well at this point and using the right platform will help transmit to the “unscrambling” serverless middleware. We’re thinking telerivet at this point but I will look at others, too. Their platform offers many services and it is easy to test, debug, etc.
Do you or anyone on your team have an example payload of a sync that gets split? It would really help me in architecting the solution before getting into testing an approach.
Thanks again for all your help.
Hi @chase.freeman .
AFAIK the App uses a compression library (GitHub - dhis2/sms-compression: DHIS2 sms compression library) in order to reduce as much as possible the SMS being sent. @Jasper_Timm, @jaime.bosque and @zubair can probably confirm what I am saying. But I think all the efforts were already made there and there is nothing to be done.
Regarding the examples I cannot give you much because I did some tests and did not suffer from it (because I was using a European carrier and Android SMS app recomposed the emails properly using the information coming from the metadata). This is pretty much the tricky part and it might not be straight forward if the telephony company does something awkward with the messages or the tagging. If I recall correctly, @Calle_Hedberg suffered from some providers not sending the metadata information (so messages could not be recompose easily) and a translation of specific characters in the SMS.
What I want to say with the last part is that it is going to be very likely dependent on your phone provider, and even if you go to country X, it might vary if you use provider A or B.
Let us know how this goes and/or if you need further help. I would be very interesting in learning of a big use case where SMS syncing is being used.
Thanks @jaime.bosque that is valuable information. I am hoping to implement with a global provider that will hopefully re-compose the SMS into the correct order like you describe. I think the small premium it costs to use them will offset the development, maintenance, and troubleshooting a custom “re-configuration” of the SMS
With a little luck I’ll report back with good news in a few weeks.