Custom Backend Advice

[Wayne Haffenden]

Hi Guys,

I have a CRM like system that has it's own contacts and events within it's own database. It also has a REST API granting access for retrieving and modifying these models.

I would like to add both carddav and caldav support to this application using SabreDAV and am not sure about how to go about this. I understand that I can implement my own AbstractBackend, however, I feel this wouldn't work correctly as the data requirements for DAV are very different from the models stored within my system. In my mind I was hoping to retrieve the data from my API and transform the objects into the correct format for SabreDAV and back again but after reading the documentation the two formats are not only very different but also requires the storage of urls, ids etc.

I'm sure this question has been asked multiple times (I couldn't find an answer to this) and just wondered what the best way to go about implementing the above would be. Any recommended practices or advice would be a massive help right now.

I look forward to hearing what you guys think.

Thanks,

Wayne

[Evert Pot]

Hi Wayne,

I've done a few implementations like this, and generally my suggestion is that it is better to adjust your CRM to the vcard/iCalendar data-model then to try do to the opposite, as you will always have an inferior datamodel from what iCalendar/vCard offers.

When customers don't want to do this, I tend to tell them that it's a risk for them to take as mapping to an inferior model means that you lose information, and I don't know how clients behave in those cases.
Another possibility is to maintain both data-models, and when a user uses your CRM system and for example updates a contacts email address, your code goes into sabre/dav and _also_ updates the associated vcard. In that scenario you basically end up with 2 datamodels that keep each other in sync when they are updated.

But yea, I've also seen customers who do actually have a translation layer between their data-model, implementing custom backends. The question you need to ask though then, what if a CalDAV or CardDAV client sets a field that doesn't map to anything in your data-model? Do you discard it? For iCalendar this will be much, much harder than vCard, especially if you want to support timezones, recursion, exceptions or scheduling. For vCard I think it's more doable, but yes, you are not getting around storing the client-provided uris and UIDs. You're required to add that to your datamodel, although I can't see why that would be an issue.

Generally I would say that in an ideal world your CRM application treats sabre/dav as its data-store. That approach might also require you to learn more about sabredav internals in case your CRM needs to do operations that are not default.

Hope this helps!
Evert

[Wayne Haffenden]

Hi Evert,

Thank you for your long detailed response that's really helpful.

Right now I'm just looking at just contacts but in the future will also be the calendar implementation. I agree with everything you've said and I think that I'll go along the second option route whereby keeping both databases in sync and keeping an external reference/id in the sabredav database for each contact/vcard. I very much doubt contacts in my system will barely ever be updated so it's really just the initial add to get them into the address book or into the CRM.

Thanks again for your help, it's very much appreciated.

Thanks,

Wayne