Is there an automated way to set up my development account to look just like my live account? I want my development account to have all the customization of our real account so that when I test sforce operations I will be testing against a reasonable facsimile of our actual SalesForce.com account.
In a related question, what are considered best practices for testing and deploying sforce solutions to SalesForce.com accounts? I am used to working on systems that we have full control over. For these systems we have complete duplicates of the production systems dedicated for development, QC testing and acceptance testing. Only after a change or new product has passed through all three levels do we release it to production.
However, from what I have seen so far, development with sforce means working on a small development account, which may or may not duplicate the structure of the real account depending on the answer to my first question, but which certainly doesn't contain a complete copy or even a large subset of the live data. Then the next step is deployment straight to the live account. It feels like working without a net to me, so I would appreciate any advice on how others manage their development and testing cycle.
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?
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?
Is there an automated way to set up my development account to look just like my live account? I want my development account to have all the customization of our real account so that when I test sforce operations I will be testing against a reasonable facsimile of our actual SalesForce.com account.
In a related question, what are considered best practices for testing and deploying sforce solutions to SalesForce.com accounts? I am used to working on systems that we have full control over. For these systems we have complete duplicates of the production systems dedicated for development, QC testing and acceptance testing. Only after a change or new product has passed through all three levels do we release it to production.
However, from what I have seen so far, development with sforce means working on a small development account, which may or may not duplicate the structure of the real account depending on the answer to my first question, but which certainly doesn't contain a complete copy or even a large subset of the live data. Then the next step is deployment straight to the live account. It feels like working without a net to me, so I would appreciate any advice on how others manage their development and testing cycle.
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?
