Many members of the Salesforce.com community are beginning to show an interest in cloud computing, with the result that they have many queries. Their most common queries pertain to writing as well as testing and debugging triggers in salesforce. Since there is a great deal of difference between programming for a dedicated server and a multi-tenant platform, it’s important to develop triggers in Salesforce tutorial to help them programmers with a .NET or Java background to figure out how to go about it.
Unlike other tutorials however, this triggers in Salesforce tutorial does not cover each and every aspect of bulk processing or triggers. It does, however, aim to bring together all the different tutorials over the Internet into one comprehensive document so that the reader does not have to read through multiple documents or sources for the information they require. The purpose of this tutorial is to demonstrate the correct way of writing, as well as the incorrect way of writing triggers for Salesforce.com.
Starting With Triggers In Salesforce Tutorial
Before you begin, you need to understand what a trigger is in the first place. Those with an Oracle or SQL Server background have some idea about what a trigger is, but a Salesforce.com trigger is different from the triggers found in these environments. The Apex documentation describes a trigger as a script that kicks in after an event such as delete, update or insert has been executed. It can affect anything from a single record to up to 200 records, so it is highly recommended to write a script that will accommodate a large number of transactions, to take advantage of this feature.
Let’s first talk about how not to write triggers. It is very important to mention this as many novice developers begin by making quite a lot of errors so it should be pointed out first. The most obvious error, of course, is to write a trigger that would be effective for only a single record at a time instead of bulk transactions in which multiple records are queried and affected. This is particularly true of programmers who come from a .NET or Java background, where such a thing is generally considered acceptable. In a Salesforce.com environment, this is a sheer waste.
The Apex runtime engine implements a large number of governors for particular entry points and contexts, for example, tests, WSDL methods, controllers, triggers and anonymous block execution. You should make it a point to go over all documentation provided in order to understand how to develop for Force.com. Do note however that the documentation recommends that you test 25 records, but experts recommend that you test 200. This is because using 25 records without taking advantage of the testing runtime context will ensure that your trigger will run without generating any bugs. However, as soon as the triggers in Salesforce tutorial is implemented in a live environment, the 21st record will generate an exception. This is because triggers impose a 20 SQL query limit, whereas in RunTest, this limit is 100 queries.