1. Data Synchronization Dani Beaubien dbeaubien@myballteam.ca

2. Session Overview Who am I and how am I different that a hole in the ground, “Data Synchronization” - What is it? Be Prepared, Session Article, Communication between client and server, Q & A

3. Who am I? Worked with 4D for over 15 years, Data Synchronization solution in use for 4 years with hundreds of users, Worked with commercial 4D vertical applications for the last 8 years. Reliability and low support requirements are very important, Developed 4D Web solutions, (e.g. http://portal.myballteam.ca) Developed solutions that utilized XML, HTTP, HTML, SOAP Client, SOAP Server, HL7, TCP/IP, Unix, Apache, PDF, RTF, User-Centrically focused, Published in 4D Journals.

4. “Synchronization” Defined v. intr. 1. To occur at the same time; be simultaneous. 2. To operate in unison. v. tr. 1. a To cause to occur or operate with exact coincidence in time or rate: We synchronized our watches. b To cause to occur or operate at the same time as something else: They synchronized their trip with the annual tulip festival. 2. To arrange (historical events) in a synchronism so as to indicate parallel occurrence. 3. To cause (soundtrack and action) to match exactly in a film.

5. What is it Better term - “Data Replication”, Data mirroring for free, Data recovery for free, Scalability for free, Near-Real-Time, Record level data replication, Scalable, (yes, I know that this has already been mentioned) Fault tolerant for free.

6. What it is not “Distributed Database”, Field level data replication, Trivial to implement - requires planning and awareness of users usage patterns, Something that users will appreciate.

7. Be Prepared Be clear on the pros and cons that data synchronization has to offer, Go into this with your eyes open, Understanding of client/server communications and network protocols, Have “buy in” from the decision makers.

8. Session Article The article covers the database changes necessary to track changes and know what which changes should be sent to the “other side”. This session covers the communication between the client and the server.

9. Client/Server Communication XML passed over TCP/IP, Wrote my own SAX parser (using v6.7 of 4D), 2003+ has it’s own XML parser, Classic request/response model. Client is the requestor, Most “state” information is retained by the client (easier to implement), Server does all authentication.

10. The “Login” CLIENT Open a Connection Request a seed Turn a seed into a session ID Send Login Message Get Block Sizes SERVER Open a Connection Return a seed Send Login Response Send Block Sizes

11. Login XML Message someUserID YourAppNameHere v1.3 234-543-5345-xxs x093jfgdfkjgg 20050819230503 fukjlkjdfg8

12. Possible Errors to Login Message -1: session ID doesn’t match 0: all is okay 10: user doesn't exist on server 20: different product (via name) 21: different version of product 22: SN doesn't match 23: server's GUID is same as client (very bad) 30: date and time on client is too far from server

13. Exchanging “Deletes” CLIENT Ask for Delete Count Loop: Get blocks of Deletes QUERY: Figure out how many deletes need to be sent to the server. Loop: Send blocks of deletes SERVER Return Delete Count Loop: Send blocks of Deletes Receive blocks of deletes

14. Exchanging “Client Changes” CLIENT Loop: Send dictionary block Get dictionary block Loop: Send record block SERVER Get dictionary block Examine for those that we want. Send dictionary block Get record block

15. “Dictionary Block” “Send” includes for each item: –Table No –Record GUID –Record Number –Record DTS “Response” includes for each item: –Table No –Record GUID –Record Number (from client)

16. Exchanging “Server Changes” CLIENT Ask for change count Loop: Ask for dictionary block Examine for those that we want. Send dictionary block Loop: Get record block SERVER Send change count Send dictionary block Examine for those that we want. Get dictionary block Send record block

17. Demonstration Q & A Dani Beaubien dbeaubien@myballteam.ca