Structured messages (Malaria)
Reading messages like NTF TRG.MA.NC.5 with a pattern ladder.
Most Impuruza signals are a single code, such as MS03. Malaria reports are different: one SMS carries a trigger and sometimes a number, such as NTF TRG.MA.NC.5 (five malaria cases), NTF TRG.SO (stock-out) or NTF TRG.RSO (risk of stock-out). A flow reads these with the Pattern ladder grammar.
How a message is read
The message is checked one part at a time, like climbing a ladder:
- the first word (
NTF); - the section (
TRG), joined to the rest by the separator (.); - the trigger (
MA,SO,RSO); - the trigger's parameters, in order: a word and a whole number of at least 1 (
NC.5); - nothing left over.
The first part that fails decides the reply, so a reporter who forgets NC is told exactly that, and one who adds NC to SO is told SO takes none. Upper and lower case and extra spaces do not matter.
Setting it up
In the Grammar step, choose Pattern ladder, then:
- keep the first word, section and separator (
NTF,TRG,.) unless the message format changes; - choose the trigger option set — on production, Event trigger;
- add one trigger per kind of report and pick its DHIS2 option. The option's name is what the reporter types (
MA); its code is what DHIS2 stores (Malaria). Both are kept on the flow; - give
MAone required parameter: wordNC, value namecases.
The preview under the editor sends the sample to the backend's own parser, so what it shows is exactly what an SMS gets. Each trigger has a ready-made example button.
Mapping and replies
In the Mapping step a ladder flow offers two extra sources: Trigger option code (for the trigger field: Malaria, Stock_out, Risk_stock_out) and Captured cases (for the case-count field). A value the message did not carry — SO has no count — is simply left out of the event. The reference number keeps the short trigger, such as MA26123456.
The Replies step lists one reply for each way a message can be badly written. Any left empty falls back to the general Unknown code reply.
Check before publishing
The Publish step's Check against DHIS2 reads the program, stage, fields, trigger options, rules and user groups the flow uses, and lists anything DHIS2 would reject. Publishing runs the same check and refuses a flow that fails it. Nothing in DHIS2 is changed by the check.