A trigger is an Apex script that executes before or after specific data manipulation language (DML) events occur, such as before object records are inserted into the database, or after records have been deleted.
Triggers are stored as metadata in Salesforce.com. A list of all triggers in your organization is located at Setup | Develop | Apex Triggers. In addition to this list, triggers are associated and stored with specific objects.
To define a trigger:
- For a standard object, click Setup | Customize, click the name of the object, then click Triggers.For a custom object, click Setup | Create | Objects and click the name of the object.For campaign members, click Setup | Customize | Campaigns | Campaign Member | Triggers.For case comments, click Setup | Cases | Case Comments| Triggers.
For email messages, click Setup | Cases | Email Messages | Triggers.
- In the Triggers related list, click New.
- Click Version Settings to specify the version of Apex and the API used with this trigger. If your organization has installed managed packages from the AppExchange, you can also specify which version of each managed package to use with this trigger. Generally, you should use the default values for all versions. This associates the trigger with the most recent version of Apex and the API, as well as each managed package. You can specify an older version of a managed package if you want to access components or functionality that differs from the most recent package version. You can specify an older version of Apex and the API to maintain specific behavior.
- Select the Is Active checkbox if the trigger should be compiled and enabled. Leave this checkbox deselected if you only want to store the script in your organization’s metadata. This checkbox is selected by default.
- In the Body text box, enter the Apex for the trigger. A single trigger can be up to “1 million” characters in length.
To define a trigger, use the following syntax:
trigger triggerName on ObjectName (trigger_events) {
code_block
}
where trigger_events can be a comma-separated list of one or more of the following events:
- before insert
- before update
- before delete
- after insert
- after update
- after delete
- after undelete
So, lets start with creating trigger.
I want that duplicate student should not be created on the basis of Email id. we can achieve this by other way also, like during creation of email field, we can specify it as unique field.
Open eclipse and right click on salesforce project and select Create new Trigger, as shown in below image
Creating Trigger in Salesforce using force.com IDE
As you can see, to create trigger we have to select the Apex version and operations in wizard.
During Trigger creation, keep in mind that it may be required in bulk operations so governor limit may be problem.
So instead of getting query for all triggers individually, I created an array and after that created a set of email entered for all records, and loop through all records invidually and checked for duplicity.
Only one SOQL is fired instead of all triggers individually and thus can work for bulk insert.
1 | trigger DuplicateStudentCheck on Student__c (before insert) { |
4 | Student__c[] studentsList = Trigger.new; |
5 | Set emailSet = new Set(); |
6 | for(Student__c s : studentsList) |
8 | emailSet.add(s.Email__c); |
12 | List duplicateStudentList = [Select s.Name, s.Email__c From Student__c s |
13 | where s.Email__c IN :emailSet]; |
15 | Set duplicateEmailIds = new Set(); |
17 | for(Student__c s : duplicateStudentList) |
19 | duplicateEmailIds.add(s.Email__c); |
22 | for(Student__c s : studentsList) |
24 | if(duplicateEmailIds.contains(s.Email__c)) |
26 | s.Email__c.addError('Record already exist with same email Id'); |
Note: You can add, edit, or delete Apex using the Salesforce.com user interface only in a Developer Edition organization, a Salesforce.com Enterprise Edition trial organization, or sandbox organization. In a Salesforce.com production organization, you can only make changes to Apex by using the Metadata API deploy call, the Force.com IDE, or theForce.com Migration Tool. The Force.com IDE and Force.com Migration Tool are free resources provided by salesforce.com to support its users and partners, but are not considered part of our Services for purposes of the salesforce.com Master Subscription Agreement.
Test Cases in Salesforce :
Test case integral part of code developement.
- You must have at least 75% of your Apex scripts covered by unit tests to deploy your scripts to production environments. In addition, all triggers should have some test coverage.
- Salesforce.com recommends that you have 100% of your scripts covered by unit tests, where possible.
- Calls to
System.debug are not counted as part of Apex code coverage in unit tests.
So, here we are going to create Test Case for trigger which we have written:
2 | private class TestTriggers { |
4 | static testMethod void myUnitTest() { |
5 | Student__c s = new Student__c(); |
7 | s.l_Name__c = 'LastName'; |
9 | Course__c c = new Course__c(); |
15 | s.Installment_1__c = 2000; |
16 | s.Email__c = 'admin@shivasoft.in'; |
21 | catch(System.DMLException e) |
23 | System.assert(e.getMessage().contains('Record already exist with same email Id')); |
To run the test case from Eclipse, right click on test class as shown in below image:
Run Test Case using Eclipse in Salesforce
The output of the test case, Test coverage result:
Test Coverage result Eclipse in Salesforce
Run test cases from salesforce.com browser:
click Setup | Develop | Apex Classes, click the name of the class, then click Run Test. If your class calls another class or causes a trigger to execute, those Apex scripts are included in the total amount used for calculating the percentage of code covered.
To run all the unit tests in your organization, click Setup | Develop | Apex Classes, then click Run All Tests.
Post a Comment