:::: MENU ::::
Posts tagged with: force.com


Sometimes you can face a very bad situation when you got REQUEST_LIMIT_EXCEEDED exception. You can find this exception in your debug logs, in the logs of any external applications which use API for integration, in developer console, etc.

REQUEST_LIMIT_EXCEEDED -Force.com Developer Console

and in the System Overview

REQUEST_LIMIT_EXCEEDED ~ Salesforce - Enterprise Edition

It means that you’re blocked for any API calls. In the worst case you must wait for a 24 hours for resetting this limit. But usually all requests were not sent in the same time period thus limit will gone early. In this point you have to analyze what was the reason of the limit. Sometimes it’d be a single data loading operation and you’ll not face it in the future. But  sometime you code reaches this limit everyday and you have to consider a code optimization or obtaining an additional API requests from Salesforce.

Emulation of date and time on Force.com

The one of the most significant things in testing is an ability to repeat your tests any number of times with the same state of environment. What is an environment state and how can we provide an ability to emulate the same state each time?

 Test environment includes the following components:
  • Configuration (The state of the configuration and system parameters should be the same)
  • Data level (it’s all data which needed for tests)
  • Time (many operations depend on a time)
Sure, it’s pretty simple if we’re talking about a data level as well as a configuration. In these areas we can reload a new data set each time if old data set will be broken. But what about a time? Here we have a strongly limitation but it might be avoided. So, we can implement the following solution on the top of system date/time. Such approach will be extremely useful for QA team. We’ll create a custom setting which will allow us to enable the time emulation, set a time shift and a fixed current time. So, let’s go ahead.
Go to Setup –> Develop –> Custom Settings –> Create and create a new custom setting with hierarchy type. In my example I named it “Date Time Configuration” (DateTimeConfiguration__c) but you can name it as you want. But be aware that you need to change the code below for using your setting name.
Ok, let’s add a few fields. I created fields:
Boolean isEmulationEnabled__c,
DateTime emulatedDT__c,
Integer dateShift__c.
It’s enough for our purposes.
So, we’ve finished with the creation of needed config and now we can implement a code.

[code language=”java”]
public class EDateTime {
private static DateTimeConfiguration__c dtConfig;
private static DateTime currentDateTime {
get {
currentDateTime = System.now();
// on Production we always use real time
if (!Utils.isProduction) {
// Caching DateTime configuration
if (dtConfig == null) {
dtConfig = DateTimeConfiguration__c.getInstance();
// if configuration exists and emulation is enabled we define new date and time
if (dtConfig != null && dtConfig.isEmulationEnabled__c) {
if (dtConfig.dateShift__c != null ) {
currentDateTime = System.now().addDays(dtConfig.dateShift__c.intValue());
} else {
currentDateTime = dtConfig.emulatedDT__c;
return currentDateTime;

public static Date today() {
return currentDateTime.date();

public static DateTime now() {
return currentDateTime;




[code language=”java”]
public static Boolean isProduction {
get {
// The Prod Org Id is permanent and can be hardcoded
return (UserInfo.getOrganizationId() == ’00DE0000000bplPMAX’ );
private set ;

Now you need to replace all invocation of System.now() in your code by a new one method EDateTime.now(), as well as System.today() by EDateTime.today().
Now you can reproduce your tests with the same date and time as many times as you want. It might be extremely useful if you’re testing a time-based solutions.
That’s it.

Development process for enterprise Force.com applications

Development of Enterprise level applications is a complex process which includes many phases: requirement analysis, technical design, development, QA, Security testing, UAT, production deployment and support. In your particular case some phases might exist when other ones will be excluded, but one phase would be exist anyway. It’s a development phase which might be infinite complicated. I have been involved to many enterprise projects on Salesforce.com platform and as a result I have formed the following process flow especially for such projects.

Below you can find a common development process for Force.com platform


Force.com development process for enterprise applications

So, on the diagram above you can see that each developer works on their own sandbox(or Developer Edition). This’s a must have practice for your project. Many times I saw a real paint in teams which didn’t follow this simple rule. The first trouble will be a fact that developers can’t working on a different tasks simultaneously because they can override they changes in the environment. Using a version control is a extremely needed for success project. You can find many options on the AppExchange which provide a metadata backup functionality. In the most case it’s a pretty good and simple solutions but really version control provides much more convenient and flexible way to manage your code and project metadata. I prefer Git but also have experience with svn and tfs. If you do not use such tools I highly recommend to start using it ASAP. The next step is to configure Continuous Integration (CI) server. I believe that you want to automate your processes as much as you can. Therefore I suggest to configure CI. CI lets you to configure a build automation for your environments. And first step is checking a repository stability. I assured that you want to be sure that your repository is stable and ready to deploy. Usually developers might broke repository by adding unstable code. Another issue with stability is forgetting necessary components. For example you can add apex class without meta file and it will broke the build. For detecting such commits you need to run auto-build after each commit. It’s a most common practice.


Salesforce team roles:

  • Development team leader / Technical Architect – works on global architecture, converts requirements into technical tasks for development team, coordinate Lead developers, coordinates releases/deployments
  • Lead developer works on architecture of dedicated parts, performs code review, coordinates development and QA teams
  • Developer implements features, fixes bugs, implements automated test cases
  • QA team leader works on test architecture, coordinate development and QA team
  • Lead QA works on test documentation, prepares test suites, controls QAs
  • QA engineer performs test suites.
  • Build engineer – responsible for a builds for all general environments, monitors version control stability.


Principles and best practices:

  • Nobody have a direct access to CI sandbox exclude a build engineer, but all can see a build result on CI server. Sometime developers can quickly fix broken build to CI by performing some changes directly on sandbox. But after that they can forget to check in these changes into version control.
  • A build to CI sandbox runs by changes into a version control.
  • QA team perform any verification only on QA sandbox. Developers does not perform any changes on this environment.
  • Build to QA sandbox runs by scheduler nightly. QA team have ability to request a build to QA sandbox anytime, for cases when significant things has been committed into version control and should be tested ASAP.
  • Development team provides a build to UAT sandbox at least once a week for testing by users. User feedback is incredible useful. Thus you need to start getting it ASAP.
  • Only product owner from business side can make a decision about a build stability. Also only this person can provide approval for build to SEC sandbox for security scan by third-party company.
  • Perform production builds on weekend. If you already have production org with active users you’d be happy to have some additional time without business user pressure in case of some bugs in production. Especially for regression bugs.
  • Have a roll-back plan. You need to have a prepared destructiveChanges.xml and a proved procedure of roll-back for any troubles.
  • Use a short sprints and deploy your code as often as possible.