Apex Code Development You need to sign in to do that
Don't have an account?
zrxc77 Work-arounds for lack of event-driven interface
I have been tasked to utilize salesforce as the main repository for all our business information, but at the same time have changes made in salesforce propagate in real time to various external back-end systems within our company. Since salesforce doesn't yet support an event-driven programming model, I have been thinking about work-arounds:
1. Polling - use the timestamp feature to look for items that have changed since the last poll and update accordingly. Polling is somewhat cumbersome, and only partially real time at best, particularly with the 5-minute polling interval that salesforce enforces.
2. Workflow Alert - set up a workflow alert to email my back-end system when changes of interest are made to salesforce, then have my back-end system call back into sforce to get the update. This seems pretty hokey to me. Email was never meant to be used in a mission-critical manner like this. At the very least I would also have to implement polling to pick up any changes missed from lost email.
3. Web Integration Link - rather than having changes made directly to salesforce, have the user access a custom web integration link (URL or control) that accesses my back-end system and then, either directly through a control or indirectly through my back-end system, calls the sforce API to commit the changes to salesforce.
Right now I am leaning towards option three.
Has anyone else faced a similar problem and, if so, how did you approach it? Have I missed any alternatives or failed to consider an important consequence of any of the alternatives I did list?
Thanks
1. Polling - use the timestamp feature to look for items that have changed since the last poll and update accordingly. Polling is somewhat cumbersome, and only partially real time at best, particularly with the 5-minute polling interval that salesforce enforces.
2. Workflow Alert - set up a workflow alert to email my back-end system when changes of interest are made to salesforce, then have my back-end system call back into sforce to get the update. This seems pretty hokey to me. Email was never meant to be used in a mission-critical manner like this. At the very least I would also have to implement polling to pick up any changes missed from lost email.
3. Web Integration Link - rather than having changes made directly to salesforce, have the user access a custom web integration link (URL or control) that accesses my back-end system and then, either directly through a control or indirectly through my back-end system, calls the sforce API to commit the changes to salesforce.
Right now I am leaning towards option three.
Has anyone else faced a similar problem and, if so, how did you approach it? Have I missed any alternatives or failed to consider an important consequence of any of the alternatives I did list?
Thanks
Hi zrxc77,
I would recommend option 1 and test the 5 minute interval
.
The getUpdated and getDeleted are built specifically for this but are applicable to a subset of available tables. All records have the systemModStamp that you can use to accomplish the same thing using queries.
You will not be able to do "real time" change propagation (unless your definition of real time changes). Events are on our long term road map, but in the mean time, near real time will be the best you can achieve.
Hi zrxc77,
I think that DataJunction by Imperative is the most widely used, but it is more of a data loader than sychronizer. Other than that, I don't know of any that are specifically aimed at SQL Server.
We are starting two of these same type projects. Will let you know if we find a way better than #1 (polling).
I'm glad to see someone else looking for response times better than 5 minutes, but I'm curious, what business scenario do you face that drives the need for real-time over 'near real-time'?
Regards,
Often times a sale is completed while the customer is on the phone with a salesperson. In this scenario we would like that customer to be able to log in while on the phone with the salesperson. If we had to, we could tell the customer his or her account will be active in five minutes and hang up, but it would be nicer if the salesperson could just chit-chat for 30 seconds or so and then have the customer log in and verify that everything is okay while speaking with the salesperson.
In addtion, my request for an event-driven interface wasn't just based on response time. I find that event-driven models work well for many business processes. "When this happens, do that..." I think SalesForce.com may also see the value of event-driven models as evidenced by their inclusion of Workflow Rules/Tasks/Alerts. Let's hope they expand on this good start.