Monthly Archives: March 2017

Integration via Outbound Messages-SF API Call Manager

This article is for exploring integration possibilities via outbound messages and solving below problems:

  1. Timeout issue – In salesforce there is strict limit of 120 seconds for callout. This could be solved if API calls are carried outside of salesforce like in heroku app where no such limit for callout is there.
  2. API Calls which requires polling – Polling for response becomes difficult in salesforce as in order poll for result batch is required which runs at regular interval but there cannot be more than 5 batches running simultaneously. This can be solved by implementing polling logic in heroku app where threading could be used for polling and making inbound call to salesforce when results are available.

This idea came up when I was having discussion with my colleague Tushar Kaore on integration approaches. We thought that lets try to analyze the performance and reliability of outbound messages in integration.

Here is the design of this framework:


Integration via Outbound Messages

Lets see how this would work

  1. Whenever API Call has to be made then in salesforce API Call record has to be created which would include below details
    • Endpoint
    • Request
    • Headers
  2. On create of such API Call records salesforce would initiate an outbound message call to the heroku application with all the details which would be required to make API call
  3. Actual API Call will be made by heroku app to the external system. Here an API call which takes more than 120 seconds can be made and it is required to do polling then heroku app can handle that by polling in regular intervals of time.
  4. Heroku app will receive the response.
  5. Inbound API call would be made to salesforce to pass on the response received by heroku app.
  6. Response would be updated in API Call record and on trigger of API Call record response could be processed and proper actions could be taken.

In this structure two applications are involved Salesforce App and Heroku app.

Steps to configure app:

  1. Heroku App: Install the Heroku App  : heroku-api-call by using deploy to heroku button from repository home page.
  2. Salesforce App: Insall the Salesforce App : sf-api-call by using Deploy to Salesforce button from repository home page.
  3. Configure workflow rule: Create workflow rule on API Call object with the outbound message action as per below screenshot.


    Outbound Message Action

  4. Add Remote Site setting: Add the remote configured endpoint as remote site setting.

How to test:

Create an API Call record in salesforce with the endpoint. As soon as the record gets created salesforce will make outbound message call to heroku app. Heroku app will make API call to the endpoint and it will be update the received response to salesforce via making inbound api call.

I will be be testing this for performance and will check its reliability to use in production applications. Currently only GET API calls are supported and will update the code to have below featues:

  1. Headers support
  2. POST call support

features list will go on…..

Whenever real time integration is not required and this approach could be used to solve issues of

  1. Callouts taking more than 120 seconds
  2. Whenever polling for response is required.

Result of this exercise:

I created nearly 50K API calls (thats lots of API calls) and tried to see how many API calls will get processed by this mechanism. Results are very promising


Results shows that 20K API calls are fulfilled within 3 minutes i.e. 113 fulfilled API call/second. My heroku instance was bombarded with outbound messages calls and now it is down.. 🙂

Note these are the results with free heroku instance with one dyano only. So imagine if you have a heroku app with good number of dynos to fulfill requrest then you can think of very promising results.

API Call is made to for testing.

Happy learning and keep exploring..



Disabling standard style sheets – Salesforce

Everywhere we have lightning and Salesforce is in process to provide all classic features in lightning. In this process there would be some features which would not be available in lightning. So sometimes we need to use the best of both worlds classic and lightning. Here is similar problem and its solution.

Problem : Custom click to dial functionality can be used in visualforce pages with the below code

<apex:page standardController="Account" showHeader="true">
    <support:clickToDial         number="415-555-1234"         entityId="001XB000000HFUM"         params="myparam1,myparam2"     />


As of now this only works with the visualforce page where showHeader is enabled. Now if we enable showHeader then visualforce includes standard style sheets but then such standard style sheets  could get mixed up with LDS in visualforce page and creates css conflict issues.

Solution : Lets consider what we want here-

  1. ShowHeader = true, on page level showheader has to be enabled other wise click to dial functionality from visualforce page would not work.
  2. Don’t want any impact on lightning design system css

Here solution is to dynamically remove the standard style sheets which gets loaded because of showheader set to true. The problem with that approach is that whenever any section of page is reRendered then standard style sheets are loaded back which again distorts the LDS css. There is one way to solve this is instead of removing standard stylesheets disabling it by below code:

 function disableStandardStylesheets(){ 
          if(this.href.indexOf('/sprites/')!=-1 &amp;&amp; this.href.indexOf('/CTI.css') == -1){ 
               $(this).attr("disabled", "disabled");

Advantage of disabling standard style sheets instead of removing is that after every reRender it will not get loaded back. This solution will other places in Salesforce where you want to disable effect of any standard stylesheets gets loaded by Salesforce.


Visualforce page with LDS and Standard Style Sheets


Visualforce page with LDS and disabled Standard Style Sheets

User Creation in Salesforce

This post is for the best practices to be kept in mind while loading users in the system. If client business users starts getting notification when they are not supposed to then that could create chaos. Below are the points which needs to be considered while loading users in the system.

  1. User Template: User data should be gathered before hand, to make sure that we are not missing any information which we are supposed to be asked to client. Template should be used so that no data would be missed. Attached is the user template using which we could ask client to provide all user details UsersTemplate.
  2. SSO consideration: If the salesforce org is using SSO then federation id should be asked before hand and should be part of user template.
  3. Multicurrency: If salesforce org uses multicurrency then it would be good to include that CurrencyIsoCode column in the user template.
  4. External Id: No matter how much you plan but you could have some wrong data like incorrect firstname, lastname etc. It would be a good practice to create external id in user object so that users could be upserted and data could be corrected.
  5. Email Id change: Whenever user’s email ids are changed then users gets notification for confirming the email address and also notification is sent to the email id which you are changing. If you want to change the email ids without any notification to users then you can turn of the Email Deliverability to “No Access”. This will make sure that email id is changed without creating any chaos of notifications.
  6. Reset Password: Whenver user loading process is going on it would be good to turn off Email Deliverability. When you think that now its the time to welcome users then you can reset the password. Users will get the email to set their passwords.
  7. Feature Licenses: If you want to activate some feature licenses then that could be added as a part of user template.


    Feature Licenses

  8. Welcome Email: If you want to send welcome emails to user for helping with the documents to understand salesforce and with next steps. To implement this you would need to create email template and which would be used by workflow rule on user object.

Above list could act as a checklist for your plan of creating users in salesforce.

Using Picklist in Integrations- After Spring 17 Release

In integrations mainly information is communicated to other System by passing id/code values instead of Labels. In Salesforce picklist has values and labels but before Spring 17 release there was not provision to have different value and label for picklist items.

Whenever different Label has to be shown to user and different code has to be passed to other system then some workarounds were required to be done like having code label mapping in code or keeping code values in custom object and passing those values in integrations. Such solutions were error prone and requires maintenance since in code it is required to do String comparison to get the proper code to be sent to other system.

Now we have a relief, in Sprint 17 salesforce has provided much required feature where we can have separate code and label for picklist items.


Different code and label


Apex code showing how to get Label and Code which could be used while passing data in integrations to other system

Now using this we could minimize the extra maintenance which was required initially. This is a great feature and should be considered in integrations.