Monday, August 24, 2015

salesforce trigger error message

Salesforce provides validation rules in configuration for standard as well as custom objects. Validation rule for standard object can be written by navigating to following:
set up --> customise --> standard object name --> validation rule

similarly for custom object you can write validation rule by navigating to following:
set up --> create --> objects --> click on the custom object --> scroll down and click on new(next to validation Rules)

Although, you can write validation using simple configuration, sometimes your requirements may not be fullfilled using validation rule especially when your validation criteria is bit complex or need querying in database to check previously created data. In such a case you can write your logic in trigger.

Lets write down a very basic trigger that will throw a validation errror message.

Scenario : Show error message on account if annual revenue is less than 2000.

The error message can be shown using adderror method as shown in the example below:

trigger validation_using_Trigger on Account (before insert, before update) {
 for(Account acc:trigger.new){
    if(acc.AnnualRevenue < 2000){
       acc.adderror('Annual revenue cannot be less than 2000');
    }
 }
}












message at the top of the page. You can also display your message at a particular field, you only have to mention the field name in the adderror method as in the below example:

trigger validation_using_Trigger on Account (before insert, before update) {
 for(Account acc:trigger.new){
    if(acc.AnnualRevenue < 2000){
       acc.AnnualRevenue.adderror('Annual revenue cannot be less than 2000');
    }
 }
}





Above triggers will also throw validation errors while inserting/updating records using data loader. 

While writing validation you have to make sure that your trigger is bulkified; that is you are properly iterating over for loop(trigger.new)

Also your trigger should run over before insert and before update contexts as you want the message be displayed before the record is created or updated. 

Also the adderror method should always be written in the trigger new context. Trigger will not show error message if you are iterating over some other collection which is not trigger.new 


Thursday, August 13, 2015

Salesforce Triggers

Trigger is piece of code that is executes before and after a record is Inserted/Updated/Deleted from the force.com database.
Syntax:
Trigger <trigger name> on <Object name> (trigger Events) {
// Implement the Logic here
}
Types of Triggers:
– Before Triggers
– After Triggers

Before Trigger: Before triggers are used to perform the logic on the same object and specifically we cannot use the DML operation (Insert, update, delete) on these triggers.
These triggers are fired before the data is saved into the database.
After Trigger: After triggers are used to perform the logic on the related objects and these triggers are used access the fields values that are created by system (Ex: CreatedBy, LasteModifiedBy , Record Id etc..).
Bulk Triggers:
By default every trigger is a bulk trigger which is used to process the multiple records at a time as a batch. For each batch of 200 records.
Trigger Context Variables:
All the trigger context variables are prefixed with “Trigger.” (Ex: Trigger.isInsert, etc..)
isInsert: Returns true if the trigger was fired due to insert operation.
isUpdate: Returns true if the trigger was fired due to update operation.
isDelete: Returns true if the trigger was fired due to delete operation.
isBefore: Returns true if the trigger was fired before record is saved.
isAfter: Returns true if the trigger was fired after record is saved.
New: Returns a list of new version of sObject records.
Old: Returns a list of old version of sObject records.
NewMap: Returns a map of new version of sObject records. (map is stored in the form of map<id,newRecords>)
OldMap: Returns a map of old version of sObject records. (map is stored in the form of map<id,oldRecords>)
Size: Returns a integer (total number of records invoked due to trigger invocation for the both old and new)
isExecuting: Returns true if the current apex code is a trigger.
The below table is tells what are the events we can use in the new trigger and old trigger
Trigger EventTrigger.NewTrigger.Old
Before InsertYesNo
Before UpdateYesYes
Before DeleteNoYes
Before UnDeleteNoYes
After InsertYesNo
After UpdateYesYes
After DeleteNoYes
Trigger Context Variable considerations:
– Trigger.Old is always readOnly
– We cannot delete trigger.new
– In before triggers, trigger.new can be used to update the fields on the same object.
– In After trigger, we get run time exception is thrown when user try to modify the fields in the same object.

Error codes for http requests

HTTP response codeDescription
200“OK” success code, for GET or HEAD request.
201“Created” success code, for POST request.
204“No Content” success code, for DELETE request.
300The value returned when an external ID exists in more than one record. The response body contains the list of matching records.
304The request content has not changed since a specified date and time. The date and time is provided in a If-Modified-Since header. See Get Object Metadata Changes for an example.
400The request couldn’t be understood, usually because the JSON or XML body contains an error.
401The session ID or OAuth token used has expired or is invalid. The response body contains the message anderrorCode.
403The request has been refused. Verify that the logged-in user has appropriate permissions.
404The requested resource couldn’t be found. Check the URI for errors, and verify that there are no sharing issues.
405The method specified in the Request-Line isn’t allowed for the resource specified in the URI.
415The entity in the request is in a format that’s not supported by the specified method.
500An error has occurred within Force.com, so the request couldn’t be completed. Contact Salesforce Customer Support.

Friday, July 31, 2015

Status=Length Required, StatusCode=411 error in Apex callout

HttpRequest request = new HttpRequest();request.setHeader('Content-Length', '512'); 

Generate Json Data



Here is Simple classs to form json data..

public class ParentRecord {
    public String recordType, entity, job;
    public ChildRecord[] item;
    public ParentRecord(String recordType, String entity, String job) {
        this.recordType = recordType;
        this.entity = entity;
        this.job = job;
        item = new ChildRecord[0];
    }
}

public class ChildRecord {
    public String item;
    public Decimal quantity, amount;
    public ChildRecord(String item, Decimal quantity, Decimal amount) {
        this.item = item;
        this.quantity = quantity;
        this.amount = amount;
    }
}


pass paramenters to the above class using below code.



// Query parent and children, you can do both at once.
// Replace object names, relationship names, and field names.
Parent record = [SELECT Id, recordType, entity, job, (SELECT Id, Item, quantity, amount FROM Children) FROM Parent WHERE Id = :someId];

// Create a parent record entry from the utility class
ParentRecord parent = new ParentRecord(record.recordType, record.Entity, record.job);
// Loop through and build the item list
for(Child lineItem: record.Children) {
    parent.item.add(new ChildRecord(lineItem.Item, lineItem.quantity, lineItem.Amount));
}



Now convert the data into json using JSON.serialize() method
String jsondatagen= JSON.serialize(parent);


Tuesday, June 2, 2015

integration ,salesforce and .Net

Multiple integration ways with salesforce

Real-time mashups – Real-time mashups involve a custom built Visualforce UI in Salesforce.  This UI
is similar to a traditional web app built with HTML in that custom branding can be implemented, complex user flows can be built and the web page can perform web service callouts to external systems to retrieve data.  Real-time mashups are great for situations when data is not stored in salesforce.com but needs to be accessed immediately.  An example of a real-time mashup would be an Agent screen that also needs to pull in related documents from multiple external document management systems for access by the Salesforce user.


//--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Non-Visualforce mashups – In addition to developing Visualforce pages, Salesforce also offers the ability to embed third-party web pages directly within the UI – either directly or using Force.com Canvas. Both of these options integrate already built web applications, developed in other technologies and hosted in other locations, directly into the Salesforce user interface.  SSO Web Tabs allow an administrator to create a new tab that passes user credentials to another web page, seamlessly authenticating the user. This is an extremely common use case to integrate a BI application that extends Salesforce’s reporting capabilities.


//--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



Force.com Canvas – This allows developers to embed an already built web application, utilizing a salesforce.com-developed JavaScript SDK, directly into existing Salesforce page layouts. For example: If you want to integrate a “Sales Actuals” component from your ERP system directly on your Account screen and you do not want to bother with Visualforce and Apex, you can use Force.com Canvas to display the web app and pass appropriate credentials and record IDs. Force.com Canvas allows for seamless interaction between Salesforce and the embedded web page to allow for dynamic web apps with full UI interactivity.

//--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Real-time data integration – Real-time interfaces are typically required when a Salesforce user performs an action and expects an immediate response, whether it be a calculation result, an “order processed” message or something similar.  Real-time integrations have higher risk and require complicated queuing mechanisms and error handling mechanisms to account for system outage and data errors.  Often, a near real-time alternative is acceptable in the cases of “fire and forget” patterns (e.g. a user submits a record for processing and will receive an email notification once it has been processed successfully).  This type of integration will utilize Salesforce Apex Callouts to call remote web services.


//--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Near real-time data integrations – Near real-time interfaces can involve transactions within seconds or minutes, depending on need.  In reality, many interfaces fall into this category.  If a user wants to simply mark a record for processing and know that it will be sent within a couple of minutes and that they will be notified upon completion, near real-time is an optimal solution.  It is more reliable than real-time because it has built-in queuing and reprocessing out of the box.  Options for implementing this are outbound messages, which are a 100% declarative functionality within salesforce.com, and rapid polling (30 sec-5 min batching) by an ETL tool, utilizing the salesforce.com SOAP or REST APIs.



//--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



Batch data integrations – Batch data integrations are one of the most common forms of integrations.  Batch is an excellent pattern for data that must reside in Salesforce (or be transferred out of, e.g. to a DW) for reporting or workflow purposes, that does not change that often and that is generally in large quantities.  Batches can occur with time ranges from seconds to weeks if needed.  Batches are the simplest type of interface to implement, with the majority of the development occurring in the ETL tool, not Apex code.  Batch is also the ideal solution for handling flat files.