About Me

My photo
PLANO, Texas, United States

Saturday, January 9, 2016

Apex Design Patterns

A design pattern is a general reusable solution to a commonly occurring problem within a given context. With the help of design, we can avoid much error well in advance. Design Patter ensures the best practices of coding.

The following are a list of design patterns in Apex:
  1. Singleton
  2. Strategy
  3. Decorator 
  4. Facade
  5. Composite
  6. Bulk State Transition 

Singleton

  • Repeated execution of a class within a single transaction may lead to exceed the governor limit. This pattern is to reduce repeated instantiation of a class.
  • Problem: Developers often write inefficient code that can cause repeated instantiate of objects. This can result in inefficient, poorly performing code, and potentially the breaching of governor limits. This most commonly occurs in triggers, as they can operate against a set of records.
  • Implementation: In order to implement a Singleton pattern in apex, the class must instantiate only once. It is implemented by:
    • Creating a class with a method that creates a new instance of the class if it doesn't already exist.
    • If it already exists, then simply return a reference to the object.
    • For example, use a global static variable, before assigning it to value check if it has already a value.

Strategy:

  • The Strategy pattern (aka the policy pattern) attempts to solve the issue where you need to provide multiple solutions for the same problem so that one can be selected at run-time.
  • Use Case: You need to provide a geographical-based search engine solution where the implementing code can choose the search provider at run-time.
  • Implementation: In Order to implement a Strategy pattern in apex, you need to define a family algorithms. It is implemented by:
    • Creating the interface class with methods that will be implemented by other classes 
    • Covers use of interfaces, Aggregation (Has A) relationship, Method Overloading.

Decorator:

  • In some scenarios, we need to show the value only in UI level, but not to store that value in Database. Here we have a Decorator Design pattern to solve this kind of problem. This pattern provides the decorator class which wraps the apex class to provide the extended functionality for the sObject
  • Use Case: Whenever the user needs to select the records and process the selected records however select checkbox is not saved.
  • Implementation: In order to implement a Decorator pattern in apex, we need to aware that this is not a true implementation the intention is to add the behavior at the run time. It is implemented by:
    • Use of wrapper classes inside wrapper class and perform required operation when it is get;set; in vf page instead when the page is loading. We can say it lazy loading. Used in VF page mostly. 

Bulk State Transition:

  • The bulk state transition requires a trigger that allows only the eligible record that has changed its state and a utility class to implement the logic. The trigger needs to be framed by its events and the DML type. 
  • Use Case: Whenever a developer needs to write the trigger we always consider as bulk and we use the Bulk State Transition Pattern.
  • Implementation: In order to implement a Bulk State Transition in apex, use proper filter to check the eligible records using the Trigger Context variable and call the utility class which contacts the method that handles the operation on the bulk operation.

Facade – 

  • The intention of the facade design pattern is to convert complex Apex classes into simplified classes or interfaces where groups of classes are either wrapped into one class or only one class is used to delegate responsibilities to the other classes.
  • Use Case: Simplifying the execution of classes with complex interfaces (e.g. web service callouts)
  • Implementation: Maintainability of Apex code by simplifying the execution of one or complex classes with a facade class. For example, just create a simple class where place code to execute methods/functions of a complex class.

Thursday, January 7, 2016

Triggers and Order of Execution

When there is any DML on the Salesforce Record, Salesforce perform the following actions in order:

1. Salesforce loads the original values from the database or initialize the new values.
2. Loads the new value from the request and overwrite the old values.
3. System Validation will run. (In case of Opportunity Line Items Custom Validation will also run)
4. Salesforce executes all the before triggers.
5. Custom Validation will run.
6. Records will save to the database but will not commit
7. Executes all after trigger.
8. Assignment Rule
9. Auto Response Rule
8. Workflow rule
9. Escalation rule
10. Commits all the DML to the database.
11. Post Commit Logic such as sending mails.

Tuesday, December 29, 2015

Governor Limits

Governor limits are the apex run time limits enforced by the apex run time engine. If you write non-optimized code, your application will get slow and you will see performance issues down the line. But if you write very bad code, salesforce ensures that you will not be using the resource from other applications imposing the governor limit.


Why this is useful: As Apex runs on the shared and multi-tenant environment (Where multiple resources can use the single application at a time), governor limits ensure that code does not monopolize the resource, and each and every user can use the system with no unexpected error.


What happens when code exceeds the limit: If your code exceeds a limit, the associated governor throws the exception error and terminates the request. 


How to take care of governor limits: While writing the code, we must take care of the governor limits and should write the optimized code and should use the best practice of apex. Like avoiding the Too Many SOQL queries, we must ensure the query is not within the “for loop” or particular trigger is not getting fired multiple times. Also if you have a large number of data, we can use the asynchronous class (Batch class)


Important Governor limits:

No of SOQL Query: 100

No of query rows: 50K

No of SOSL: 20

No of DML: 150

No of DML rows:  10K

Maximum Heap Size: 6 MB

Number of future calls: 50


Sunday, August 2, 2015

ANT Tool

Prerequisites for Using the Force.com Migration Tool
  1.  JAVA (JDK latest version)  use java -version in cmd to know the version of java in your machine                             
  2. ANT (latest version) Use Ant -version in the command prompt to know the version of ANT in you machine 
  3. Migration Tool (Download latest version from the Salesforce)
Follow the below steps for using Migration Tool:

Step 1: Create the below User Variables
If you have admin right:
Create the below User Variables (Right Click My Computer -> Properties -> Advanced System Settings - > Environment Variables - > User Variables)
If you do not have admin right:
Then Control Panel -> User Accounts-> User Accounts -> Environment Variables - > User Variables

  • JAVA_HOME = <path where jdk is installed in your computer>         
    • Example - C:\Program Files\Java\jdk1.8.0_25   
  • ANT_HOME = <path where ant is installed in your computer>
    •   Example C:\Program Files (x86)\apache-ant-1.9.4
  • PATH <path where jdk bin is installed in your computer>; <path where ant is installed in your computer>
    • Example  C:\Program Files\Java\jdk1.8.0_25 \bin;C:\Program Files (x86)\apache-ant-1.9.4/bin
Step 2: Setup SFDC Migration tool

  1. Extract the Migration Tool Zip file in your local directory, available in Salesforce at :Setup-> Tools ->Force.com Migration Tool
  2. Copy the "ant-salesforce" jar file from the extracted folder and paste within lib folder where Ant is installed.
  3. Open the Build.properties file from the Migration Tool folder. In the build.properties, update the credentials:
  4. Put your package.xml in the folder Migration Tool - > unpackage
  5. Retrieve the meta data from the Source org using the below command – Please note the credentials given in build.properties are of source org.  
    ant retrieveUnpackaged 
  6. Change the credentials in build.properties and update with the Target org and run the deploy command for the validation as below:ant deployUnpackaged
Issue Faced:
Proxy Setting Issue
Proxy issue can be resolved by configure in the build.xml file as below:
     <target name="proxy">
 <property name="proxy.host" value="*.**.***.*" />
 <property name="proxy.port" value="**"/>
<property name="proxy.user" value=""/>
<property name="proxy.pwd" value=""/>
<setproxy proxyhost="${proxy.host}" proxyport="${proxy.port}" proxyuser="${proxy.user}" proxypassword="${proxy.pwd}" /></target>
Also use depends="proxy" in the target tag as below:

<target name="retrieveUnpackaged" depends="proxy">
      <!--<mkdir dir="retrieveUnpackaged"/>-->
      <!-- Retrieve the contents into another directory -->
 <sf:retrieve username="${sf.username}" password="${sf.password}" serverurl="${sf.serverurl}" maxPoll="${sf.maxPoll}" retrieveTarget="RetriveFromOGTestForbug" unpackaged="RetriveFromOGTestForbug/package.xml"/> </target>

Heap Size Issue:
If migration code is very large then we can get Heap size issue. I have faced this issue and we have resolved it as below:
  1. Go to ANT directory (Where ANT is installed) for example: in C drive as below:                   C:\apache-ant-1.9.4-bin\apache-ant-1.9.4\bin
  2. Open ANT batch file in notepade++                                                                                            Set ANT_OPTS =-Xmx2048m                                                                                    JAVA_OPTS = - Xmx2048m in the setDefaultAntHome as below:

Tuesday, July 21, 2015

Version Control

  • Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

  • The code programmers write changes often. Bugs need to be fixed, features need to be added, and content needs to be changed. Most code is stored as plain old text files, and the code is changed by editing these files. Every time a change is saved, the old version of the file is overwritten with a new one. Unfortunately, no programmer is perfect, and sometimes, mistakes are made. If you make a change to a file, save it, compile it, and find out that something went wrong, it's often helpful to be able to go back to the old version or to get a report of what was actually changed, in order to focus on what may have gone wrong.


Types of Version Control

There are many version control systems out there. Often they are divided into two groups: “centralized” and “distributed”.


Centralized Version Control
  • Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

  • “Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

  • Most modern version control systems deal with “changesets,” which simply are groups of changes (possibly too many files) that should be treated as a cohesive whole. For example, a change to a C header file and the corresponding .c file should always be kept together.

  • Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly. Some of the most common centralized version control systems you may have heard of or used are CVS, Subversion (or SVN), and Perforce.


Distributed Version Control
  • In the past five years or so a new breed of tools has appeared: so-called “distributed” version control systems (DVCS for short). The three most popular of these are Mercurial, Git, and Bazaar.

  • These systems do not necessarily rely on a central server to store all the versions of a project’s files. Instead, every developer “clones” a copy of a repository and has the full history of the project on their own hard drive. This copy (or “clone”) has all of the metadata of the original.

  • This method may sound wasteful, but in practice, it’s not a problem. Most programming projects consist mostly of plain text files (and maybe a few images), and disk space is so cheap that storing many copies of a file doesn’t create a noticeable dent in a hard drive’s free space. Modern systems also compress the files to use even less space.

  • The act of getting new changes from a repository is usually called “pulling,” and the act of moving your own changes to a repository is called “pushing”. In both cases, you move changesets (changes to files groups as coherent wholes), not single-file diffs.

  • One common misconception about distributed version control systems is that there cannot be a central project repository. This is simply not true – there is nothing stopping you from saying “this copy of the project is the authoritative one.” This means that instead of a central repository being required by the tools you use, it is now optional and purely a social issue.


Git Is a Version Control Application

Git is the application that keeps track of everything related to the changes in your project over time. Git is an open-source program for tracking changes in text files. Let’s start by defining a few key terms:

Repository
  • It refers to a storage location, often for safety or preservation. A repository contains all of the project files (including documentation), and stores each file's revision history. Repositories can have multiple collaborators and can be either public or private.

  • A repository is the most basic element of GitHub. It’s easiest to imagine it as a project folder. However, unlike an ordinary folder on your laptop, a GitHub repository also offers simple and powerful tools for collaborating with others.

  • A repository contains all of the files associated with a project (including documentation), and stores each file’s revision history.


Commit

  • A commit, or "revision", is an individual change to a file (or set of files).

  • It's like when you save a file, except with Git, every time you save it creates a unique ID (a.k.a. the "SHA" or "hash") that allows you to keep a record of what changes were made when and by who. Commits usually contain a commit message which is a brief description of what changes were made.


Fork
  • A fork is a personal copy of another user's repository that lives on your account.
  • Forks allow you to freely make changes to a project without affecting the original. Forks remain attached to the original, allowing you to submit a pull request to the original author to update with your changes.

Clone
  • A clone is a copy of a repository that lives on your computer instead of on a website's server somewhere, or the act of making that copy.

  • With your clone, you can edit the files in your preferred editor and use Git to keep track of your changes without having to be online.

Push
  • Pushing refers to sending your committed changes to a remote repository such as Bitbucket. For instance, if you change something locally, you'd want to then push those changes so that others may access them.
Pull requests
  • Pull requests let you tell others about changes you've pushed to a Bitbucket repository. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.

Fetch
  • Fetching refers to getting the latest changes from an online repository (like Bitbucket) without merging them in. Once these changes are fetched you can compare them to your local branches (the code residing on your local machine)


 Working on GitHub Versus Working Locally

  • You can make changes to your project directly on GitHub, but most people prefer to work on their local machine so they can make changes in their favorite IDE or text editor. Let’s review a couple important terms:

  • The remote repository is a copy of the repository on GitHub. All collaborators synchronize their changes with this, making it the source of truth for the group.

  • Local repositories are git repositories stored on a user's computer. If the local directory is linked to a remote repository, then the local repository is a full copy with everything on the remote repository, including all of its files, branches, and history.

The local and remote repositories only interact when you run one of the four network commands in Git: git clone, git fetch, git pull, and git push.

 

Using Git / Basic commands

Git uses a small number of commands to perform its basic operations.

 

 

Overview of the GitHub Workflow

The main steps are:

  1. Create a branch off of the master

  2. Make commits

  3. Open a pull request

  4. Collaborate

  5. Make more commits

  6. Discuss and review code with team members

  7. Deploy for final testing

  8. Merge your branch into the master branch

Wednesday, September 17, 2014

Dashboard

  • Dashboards are graphical representations of reports. 
  • Dashboards can be generated for summary or matrix reports (and not for tabular reports). 
  • Dashboards display data as per the last time the report was run.
  • A dashboard can have up to 20 components.

Dashboard Component Types

  1. Chart
  2. Gauge
  3. Metric
  4. Table
  5. Visualforce Page
  6. Custom S-Control

Data Source of Dashboard

  1. Report
  2. VisualForce Page
The chart in the Dashboard:
  1. Vertical column
  2. Horizontal bar
  3. Line
  4. Donut
  5. Funnel
  6. Pie
Important Points:
  • Dashboard also support automatic refresh and email. The refresh and email can also be scheduled at intervals - daily, weekly, monthly.
  • The folder in which dashboards are stored determines which user has access to running the dashboard. The dashboard data is based upon the reports data. When a user views the drill-down report for a dashboard component. running user's access permissions determine what data is displayed on the drilldown report. Hence it is possible that the data in the drill down report does not match the cumulative dashboard data.
  • Dashboard also support automatic refresh and email. The refresh and email can also be scheduled at intervals - daily, weekly, monthly.
  • Two things that determine access to dashboards: Dashboard Folder & Running User

Report

  • A report returns a set of records that meets certain criteria and displays it in organized rows and columns. Report data can be filtered, grouped, and displayed graphically as a chart. Reports are stored in folders, which control who has access.
  • In reports data displayed is as per running user's security access. Reports can be run on both standard and custom objects provided object must have permission for Report creation. Reports are stored in folders. Users with access to these folders can run the reports.
  • Reports data is always generated in real-time. When a report is saved, reports configuration parameters are stored - but the generated data is not stored.

Types of Report:

  1. Tabular report:  This is the most basic report. It displays just the row of records in a table-like format with grand total. Tabular reports cannot be used for generating dashboards.
  2. Summary report: This is the most commonly type of report. It allows grouping of rows of data. It supports sorting and displaying subtotals. For example in a recruiting app, a summary report could be used to display open positions classified by department name.
  3. Matrix report: Matrix report summarize information in a grid format. Matrix reports allows records to be grouped by both columns and rows.
  4. Joint Report:Use the joined report format to create multiple views of the data contained in a single report. You can add multiple report types to a joined report, create standard and cross-block custom summary formulas, add a chart, and more.
Summary and Matrix reports can be used to generate dashboards.Report display upto 2000 rows of data. Larger reports can be emailed to Excel.

Report Type:

  1. Standard Report Type:
    1. Created when an object is created
    2. Always inner joins
    3. Cannot be modified.
    4. Created when relationships between objects are created 
  2. Custom Report type
    1. Created by Admin or users with “Manager Custom Report types”.
    2. Used to streamline the reporting process.

Use of bucket field in Reports in Salesforce:

  • Bucket field in Reports in Salesforce is used to group values to the name we specify.
  • Bucketing lets you quickly categorize report records without creating a formula or a custom field.
  • When you create a bucket field, you define multiple categories (buckets) used to group report values.
  • Custom reports let the developers define which all fields should be available in a report. Custom report allows user to change field names. Custom reports allow developers to select related fields (upto four levels). The custom reports also allow developers to add sections to group fields. Once a custom report is created it is available in reports tab and user may create reports from it.

Limitations of Salesforce reports:

  • User Interface of Salesforce reports and dashboards is fixed. Salesforce does not support pixel perfect report.
  • Salesforce reports do not support importing data from other sources
  • When displaying objects and their children, Salesforce does not support reporting on objects that do not have any children.
  • If an object has two different related lists, then Salesforce reporting does not support displaying both these related lists together.

Work-around these limitations,:

Salesforce customers have the following three options.
  • Reporting as a service: Data resides on Salesforce. New Reports get generated from same data source
  • BI as a service: Data is moved to a different destination on cloud. Reporting is performed on this new data server.
  • Datawarehousing as a service: Data is exported to the customers server and reports are generated from the server located at the customers locations.
  • Use VF Page for Complex Report