@mksd ,
I stand to be corrected , it looks to me DbSync is only limited to Synchronize between two openmrs MySQL databases .
with OpenMRS → OpenHIM mecahanism , theres more flexibility as in to the final destination server requirements. theres control over the payload ,it can be modified and validated as per the final destination server requirements .
i dont see that flexibility with DB Sync
Within DB Sync lies the OpenMRS Camel Component, you can extract data from OpenMRS using it (through openmrs:extract), and wire those payloads into Camel routes that go speak REST to OpenHIM.
We do exactly that with other systems than OpenHIM, but it’s very much exactly the same principle.
In Maputo we only showcased a very specific use case which was OpenMRS-OpenMRS sync, perhaps that showcase is the source of some confusion about what DB Sync is in fact not limited to.
Thanks @mksd for the clarification , 
Thas more clear.
Does the OpenMRS Camel Component provide some extra functionalities of a Reverse Proxy server like Transaction logging and auditing ??
What do you mean by auditing?
Camel is typically a pretty agnostic and versatile middleware-minded software, you can make it do pretty much what you want, including directing logging to special routes designed to just handle logs. As well as generating its own log messages about what it is doing and push those messages wherever appropriate.
@mozzy and @mksd Thanks for this insightful post…Am now wondering if there is relevance of sync2 if we have such a powerful module of DB Sync…All am asking to know is what does SYNC2 offer superior to DB Sync and what could be the downsides of DB Sync in light of SYNC2.
@reagan . Well ,what i would think SynC2 offers differently is the idea of Sending the payload as FHIR resources and probably the Concept of reading atomfeeds before any transaction is done where by Sync knows what resources to pull or push without duplication
My corncern about DBSYnc would be that, data is Synchronised at a Database level , all the Service level API validations are skipped.
That seems to rise an issue with Data Quality , in case the Source Db contains corrupted data in some way or another
One of the major issues of Sync2 is that it ended up not handling disorder properly. Aka you needed to send entities in order in regards to their relationships: visit before encounter, encounter before obs… etc. When we assessed it this was a big killer, among other things.
DB Sync was developed out of Sync2 being assessed not suitable. Just to clarify, it wasn’t like we didn’t know that Sync2 was out there, we did choose to design an alternative.
