Home › Forums › 3rd Party Integration › What third party systems should Klok integrate with? › Reply To: What third party systems should Klok integrate with?
Sorry for the delay in responding. I have been enjoying a (well-deserved IMHO) vacation for the last half of Dec.
Thanks for all the input. This is exactly the kind of discussion I want to have. Here is the plan as of right now. Suggestions are welcome.
Klok will store all project/task (name, description, hours estimate, contact info, etc.) and time entries (date, start time, end time, comments, task, etc.) in a local SQLite database so that you can work offline as is currently possible. By downloading and “installing” (the details need to be worked out, but this will most likely be a RSL-like SWF library) a connector for a particular third party system. Each connector will be responsible for querying the 3rd party API to get projects, tasks, time entries, etc. using whatever API the system provides. The connector will also be responsible for pushing changes to the third party system that were made in Klok while offline. Because every 3rd party system is slightly different, the connectors may vary significantly. They will also have varying levels of compatibility. For example, Freshbooks does not store timestamps with time entries, they only store the date and the duration. What this means is that when pushing entries made in Klok, the connector will need to convert the timestamps into a duration. When going from Klok to Freshbooks all is fine, but if you enter time directly in Freshbooks, when you pull that entry down, the connector will have no way of determining the time at which the entry should be placed. As of now, I am resorting to placing those entries at 12:00 am.
Another point of complexity is that some systems, such as Freshbooks, have no way of returning only entries changes since a particular date. So, when you synchronize, you have to get everything which can result in a lot of data going back and forth that hasn’t actually changed. My though is for the connector API to support a Quick Sync mode which just pushes local changes up and a Full Sync mode that synchronizes in both directions.
One last hurdle is that some systems limit the number of API calls that are allowed in a certain timeframe. I believe Harvest has a limit. In the event that you have to do a Full Sync, you may exceed that number do to the way the APIs work.
So, while I plan on integrating with the most common systems online, I also expect to support integration with homegrown systems. Whether this means some generic connector that expects a specific REST API, a Flex Library (SWC) that you can use to build your own connector or something else is still up in the air.
The switch to using SQLite is likely to be pushed down into the final 1.5 version mainly because it would make my life much easier. The connectors will be the main focus for version two along with some bug fixes and the abilty to change the UI to be light vs. the existing dark color scheme.