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:
   

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

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

ETL Tools

ETL - Extract, Transform, Load: ETL is used to migrate data from one database to another, to form data marts and data warehouses, and also to convert databases from one format or type to another.

• ETL is short for extract, transform, load, three database functions that are combined into one tool to pull data out of one database and place it into another database.
• Extract is the process of reading data from a database.
• Transform is the process of converting the extracted data from its previous form into the form it needs to be in so that it can be placed into another database. Transformation occurs by using rules or lookup tables or by combining the data with other data.
• Load is the process of writing the data into the target database.

List of the most popular ETL tools:

• Informatica - Power Center
• Pervasive - Data Integrator
• IBM - Websphere DataStage(Formerly known as Ascential DataStage)
• SAP - BusinessObjects Data Integrator
• IBM - Cognos Data Manager (Formerly known as Cognos DecisionStream)
• Microsoft - SQL Server Integration Services
• Oracle - Data Integrator (Formerly known as Sunopsis Data Conductor)
• SAS - Data Integration Studio
• AB Initio
• Information Builders - Data Migrator
• Pentaho - Pentaho Data Integration
• Embarcadero Technologies - DT/Studio
• IKAN - ETL4ALL
• IBM - DB2 Warehouse Edition
• ETL Solutions Ltd. - Transformation Manager
• Group 1 Software (Sagent) - DataFlow
• Sybase - Data Integrated Suite ETL
• Talend - Talend Open Studio
• Expressor Software - Expressor Semantic Data Integration System
• Elixir - Elixir Repertoire
• OpenSys - CloverETL

Apex test Class

Unit testing is the software development practice of writing additional code, called unit tests. These tests execute your business logic code with known input parameters and evaluate the output for expected results.

What are the common facts for apex test Classes?

• isTest Annotation is used to define the Apex Test class.

• Classes defined with the isTest annotation do not count against your organization limit of 2 MB for all Apex code.

• Classes annotated with isTest can be declared as private or public otherwise Top-level type must have public or global visibility.

• At least 75% of your Apex code must be covered by unit tests, and all of those tests must complete successfully.

• Every trigger must have some test coverage.

• All classes and triggers must compile successfully.

What are some Best Practices while writing Test Classes?

Whenever we are creating the test class, we must be following below best practices:

• Though we need 75% code coverage to deploy the class from Sandbox to Production, still test Coverage Target Should not be limited to 75%, we should try to make it 100%.

• If possible don’t use seeAllData=true, Create your Own Test Data.

• Create a Common class for Dummy Data for testing, and use it everywhere.

• If you’re Object’s Schema is not changing frequently, you can create a CSV file of records and load in a static resource. This file will act as Test data for your Test Classes.

• Use As much as Assertions like System.AssertEquals or System.AssertNotEquals to verify the test result.

• Use Test.startTest() to reset Governor limits in Test methods and close it with Test.stopTest().

• End your test class with “_Test”. So that in the Apex Class list view, the Main class and Test class will come together, resulting in easy navigation and time saver.

• Always test the Batch Capabilities of your code by passing 20 to 100 records.

• Use the runAs method to test your application in different user contexts.

• If there is a unique field then use System. currentTimeMillis() method with the name

• Test Negative scenario in the test class.

What are the methods used for test class?

1. Test.getStandardPricebookId() - Returns the ID of the standard price book in the organization.

2. Test.isRunningTest() -Returns true if the currently executing code was called by code contained in a test method, false otherwise. Use this method if you need to run different code depending on whether it was being called from a test.

3. Test.startTest()-Marks the point in your test code when your test actually begins. Use this method when you are testing governor limits.

4. Test.stopTest()-Marks the point in your test code when your test ends. Use this method in conjunction with the startTest method.

5. Test.loadData(Schema.SObjectType, String)-Inserts test records from the specified static resource .csv file and for the specified sObject type, and returns a list of the inserted sObjects.

Apart from the above, there are below methods used in Apex test Class:

1. System.Assert 

2. System.AssertEquals

3. System.AssertNotEquals

4. System.runAs(User)

What is the difference between System.Assert and System.AssertEquals()?

Basically, both methods are used to prove that code behaves properly.

System.Assert accepts two parameters, one (mandatory) which is the condition to test for, and the other a message (optional) to display should that condition be false.

Syntax:

System.assert(var1 == var2, "The value of var1 is: " +var1 + " and the value of... oh hell I don't care I mean it's just a variable");

System.AssertEquals and System.AssertNotEquals both accepts three parameters; the first two (mandatory) are the variables that will be tested for in/equality and the third (optional) is the message to display if the assert results in false.

Syntax:

System.assertEquals(var1, var2,<Optional Message>);

The advantage of System.AssertEquals over System.Assert is that the AssertEquals method shows the exact error without using the optional parameters. However, in the Assert method, we cannot be able to see the error until unless we will pass some message in the optional parameter.

To understand this, let's take an example, I am creating an Account in below two test classes. In one class, I am using the Assert method and in another class, I am using the assertEquals method.  

Test Class using AssertEquals 

Result 

When we will run the class, the below fail result will come. So, in this case, we don’t know what should be the result. 

How we create a fake response in the Test class?

Apex provides the built-in WebServiceMock interface and the Test.setMock method that you can use to receive fake responses in a test method.

How to write Test method of Controller Extension for StandardController?

Create the Object for which you are writing the Extension and pass the object instance in the ApexPages.StandardController as below: 

How to write Test method of Controller Extension for StandardSetController?

TestSetup Methods

Multiple test methods in the same class often have similar data requirements. Because of this, the Lightning Platform offers a way for you to annotate methods in your test class as @testSetup methods. The platform calls these methods automatically before every individual test method.

@isTest

private class myDataGenerationTests {

   @testSetup

   static void myDataGenerationTests() {

       List<sObject> accounts = Test.loadData(Account.SObjectType, 'Mock_Data');

   }

   @isTest

   static void testLoadAccountsFromStaticResource(){

       Test.startTest();

       List<Account> lstAccount =[Select Id from Account];

       Test.stopTest();

       system.assert(lstAccount.size() == 15, 'expected 15 accounts');

   }

}

Data Import/Export Tool in Salesforce

Below are the tools used in salesforce to import and export the data:

1. Import Wizard
2. Data Loader 
3. Data loader.io
4. Workbench
5. Export Wizard
6. Jitterbit Data

Import Wizard:

• An in-browser wizard.
• You can import up to 50,000 records into Salesforce from an existing data source.
• The following objects can be imported using import wizard.

1. Account
2. Contact
3. Lead
4. Solution
5. Custom Object

• Have Option to turn of WorkFlow Rule
• Can prevent duplicate record
• You can use only for importing data. Do not allow for export data

Data loader

• Data Loader is a client application for the bulk import or export of data.
• Can import more than 50,000 records. 
• You can achieved below action by data loader:

1. Insert
2. Export (Include data from recycle bin)
3. Export (Exclude data from recycle bin)
4. Update
5. Upsert
6. Delete

Data loader.io

• Web-based suite of tools
• Support all the standard things – insert, upsert, update, export and delete of data from production and sandbox Salesforce orgs.
• No signup or security tokens: simply log in with your Salesforce production or sandbox credentials using OAuth unlike data loader
• Task history: We keep a 30 day history of all your activity, making it easy to go back in time and see what happened, as well as view archived data of your data exports.
• Can schedule the task
• Can send the notification after completing the task
• Can save directly on specific folder (Dropbox,FTP etc.)

Workbench

• Web-based suite of tools
• Can be accessed by https://workbench.developerforce.com/login.php
• Workbench uses OAuth 2.0 login (meaning single sign-on)
• Can import, export,delete and update the data
• Can fetch the meta data
• Provide REST Explorer

Export Wizard

• An in-browser wizard that exports data in .zip files that are up to 128 MB.
• We can schedule it
• Cannot import the data

Jitterbit Data

• Jitterbit Data Loader for Salesforce is an installable application for Windows and OS X.
• Data operations are performed as a combination of modules, where sources, targets, file formats, and operations are created as separate components.
• Jitterbit’s best feature allows users to schedule operations to run and perform features like a barebones ETL tool
• Best use: repetitive data operations or light integration