When loading the data from a data loader, we make an API call for the Salesforce server. The login credentials are passed through the user name + password + security token.
We can bypass the use of a security token if we white list the IP address from where the data is loaded.
The full-form of CRUD is create, read, update, and delete. Force.com provides us with all the four operations using API. Records can be inserted, updated, deleted, and extracted from the server.
The inserting process requires data to be inserted without the ID because Force.com generates the record ID when the record is created. Data is uploaded in the form of a .CSV file created using a spread sheet.
The update process is the same as insert, but since we are updating an existing record we need we need an ID or an External ID during update. The delete command only needs the ID of the record to be deleted.
Apart from the general CRUD commands Force.com provides a special upsert command. Upsert is the combination of insert and update in a single call.
Upsert uses ID or external ID to match records with existing records, if no match is found or the ID is missing, it inserts the record. The upsert command is helpful in avoiding duplicates based on ID or external ID. If more than one record is matched, an error is reported.
When we are migrating data from other systems, it is useful to have a foreign key to link data between the two systems. The external ID helps to create that link.
A custom field can be marked as an external ID to identify the primary keys of the legacy system (outside Salesforce). Text, number, e-mail, and auto-number fields can be flagged as external IDs.
Fields marked as external IDs are indexed and are available on all the objects that can have custom fields. These fields are searchable and appear in search queries.
An object can have three external ID fields. The external ID fields become the cross reference fields to the legacy systems. For example, if the following data is in the legacy spread sheets for the library system we can migrate it to Salesforce by mapping the Media Number to the Media Number External ID field.
The original data from the legacy system are given as follows:
|
Media Number |
Media Name |
Media Type |
|---|---|---|
|
1 |
Harry Potter and the chamber of secret |
Book |
|
2 |
Freakonomics |
Book |
|
3 |
Mission Impossible |
Video |
We can map this legacy data to the Force.com fields using the following mapping:
|
Media_Number__c (External ID) |
Name |
Media_Type__c |
|---|---|---|
|
1 |
Harry Potter and the chamber of secret |
Book |
|
2 |
Freakonomics |
Book |
|
3 |
Mission Impossible |
Video |
When we are migrating data from the legacy system into the Salesforce.com system, we can upsert the data using the external ID field. This way there is no need to know the Salesforce record ID. We can prevent duplication of data using the external ID.
We can also load data into related objects without using ID. Ideally, when loading data into related objects, we need to include the Salesforce ID as the field name in the data files, but we can also include an external ID and perform an upsert. Using the external ID while loading relationship is only permitted during the upsert operation.
The general library wishes to migrate the media information from the spread sheets they are using. They have a field called Media Number in the spread sheet, which is a unique identifier (primary key) in the current system. Migrate the data into the media object and avoid duplicates.
To migrate the data from the spread sheet, we first need to create an external ID field in the media object. Recollect how to create the custom field on the object from Chapter 2, Creating a Database on Force.com.
Create a Media_number field on the media object in Salesforce, the field can be a text field. Check the flag for external ID to flag it. While loading the data use the Media_number field and use upsert to load the data.