Tuesday, 25 November 2014

Uploading Content with the Data Loader

Uploading Content with the Data Loader

Available in: EnterprisePerformanceUnlimited, and Developer Editions
You can use Data Loader to bulk upload documents and links into libraries in Salesforce CRM Content. Before uploading documents or links, note the following:
  • If you intend to upload via the Bulk API, verify that Upload Bulk API Batch as Zip File on the Settings | Settingspage is enabled.
  • When you upload a document from your local drive using Data Loader, you must specify the actual path in the VersionDataand PathOnClient fields in the CSV file. VersionData identifies the location and extracts the format andPathOnClient identifies the type of document being uploaded.
  • When you upload a link using the Data Loader, you must specify the URL in ContentUrl. Do not use PathOnClient orVersionData to upload links.
  • You can't export content using the Data Loader.
  1. Create a CSV file with the following fields:
    • Title - file name.
    • Description - (optional) file or link description.
      Note
      If there are commas in the description, use double quotes around the text.
    • VersionData - complete file path on your local drive (for uploading documents only).
      Note
      Files are converted to base64 encoding on upload. This adds approximately 30% to the file size.
    • PathOnClient - complete file path on your local drive (for uploading documents only).
    • ContentUrl - URL (for uploading links only).
    • OwnerId - (optional) file owner, defaults to the user uploading the file.
    • FirstPublishLocationId - library ID.
    • RecordTypeId - content type ID.
      Note
      If you publish to a library that has restricted content types, you must specify RecordTypeId.
      To determine the RecordTypeId values for your organization using Data Loader, follow the steps in Exporting Data. Your SOQL query might look like this:
      Select Id, Name FROM RecordType WHERE SobjectType = 'ContentVersion'
      To determine the RecordTypeId values for your organization using the AJAX Toolkit:
      1. Log in to Salesforce.
      2. Enter this URL in your browser:http://instanceName.salesforce.com/soap/ajax/32.0/debugshell.html. Enter theinstanceName, such as na1, for your organization. You can see the instanceName in the URL field of your browser after logging in to Salesforce.
      3. In the AJAX Toolkit Shell page type:
        sforce.connection.describeSObject("ContentVersion")
      4. Press Enter.
      5. Click on the arrows for recordTypeInfos.
        All of the RecordTypeId values for your organization are listed.
    • TagsCsv - (optional) tag.
    A sample CSV file is:
    Title,Description,VersionData,PathOnClient,OwnerId,FirstPublishLocationId,RecordTypeId,TagsCsv
    testfile,"This is a test file, use for bulk upload",c:\files\testfile.pdf,c:\files\testfile.pdf,005000000000000,058700000004Cd0,012300000008o2sAQG,one
  2. Upload the CSV file for the ContentVersion object; see Inserting, Updating, or Deleting Data Using Data Loader. All documents and links will be available in the specified library.

Friday, 23 May 2014

SOQL vs SOSL - Which one to use and when?

Definition
Use the Salesforce Object Query Language (SOQL) to construct simple but powerful query strings in the queryString parameter in the query() call, in Apex statements, in Visualforce controllers and getter methods, or in the Schema Explorer of the Force.com IDE.
Similar to the SELECT command in Structured Query Language (SQL), SOQL allows you to specify the source object (such as Account), a list of fields to retrieve, and conditions for selecting rows in the source object. SOQL uses the SELECT statement combined with filtering statements to return sets of data, which may optionally be ordered.
Use the Salesforce Object Search Language (SOSL) to construct text searches in the search() call, in Apex statements, in Visualforce controllers and getter methods, or the Schema Explorer of the Eclipse Toolkit.
Unlike SOQL, which can only query one object at a time, SOSL enables you to search text, email, and phone fields for multiple objects simultaneously.

Speed
SOQL and SOSL have different indexes. An index makes it much faster to filter queries.
  • Primary keys (Id, Name and Owner fields)
  • Foreign keys (lookup or master-detail relationship fields)
  • Audit dates (such as LastModifiedDate)
  • Custom fields marked as External ID or Unique.
Fields that can't be indexed in SOQL are:
  • Multi-select picklists
  • Currency fields in a multicurrency organization
  • Long text fields
  • Some formula fields
  • Binary fields (fields of type blob, file, or encrypted text.)
Note that new data types, typically complex ones, may be added to Salesforce and fields of these types may not allow custom indexing.
SOSL indexes are:
This is the one point where my discussion is weak. I simply can't seem to find Salesforce documentation on the SOSL indexes. I know there are standard fields like Name that are indexed, but I can't find the documentation for all of it. If anyone can post a comment and/or edit the post here to include that info, I would really appreciate it.

Limits
SOQL and SOSL generally have the same limitations, however according to the Governer Limit documentation:
**Description**                                                        **Limit**
Total number of SOQL queries issued                                    100
Total number of SOQL queries issued for Batch Apex and future methods  200
Total number of records retrieved by SOQL queries                      50,000
Total number of records retrieved by Database.getQueryLocator          10,000
Total number of SOSL queries issued                                    20
Total number of records retrieved by a single SOSL query               200
In addition:
  • If a SOQL query runs more than 120 seconds, the request can be canceled by Salesforce.

Syntax
SOQL syntax and SOSL syntax differ greatly. For a truly in depth break, please refer to their respective documentation. However, a simple example of each is:
SOQL
SELECT Id, Name FROM Account WHERE Name = 'Acme'
Return all Accounts where the Name is exactly Acme.
SOSL
FIND {Joe Smith} IN Name Fields RETURNING lead(name, phone)
Look for the name Joe Smith in the name field of a lead and return the name and phone number.

What does Salesforce recommend?
Finally, let's take a look at what Salesforce says is the best option (page 11):
Use SOQL when
  • You know in which objects or fields the data resides.
  • You want to retrieve data from a single object or from multiple objects that are related to one another.
  • You want to count the number of records that meet specified criteria.
  • You want to sort results as part of the query.
  • You want to retrieve data from number, date, or checkbox fields.
Use SOSL when
  • You don't know in which object or field the data resides and you want to find it in the most efficient way possible.
  • You want to retrieve multiple objects and fields efficiently, and the objects may or may not be related to one another.
  • You want to retrieve data for a particular division in an organization using the divisions feature, and you want to find it in the most efficient way possible.
Some additional considerations when using SOQL or SOSL:
  • Both SOSL search queries and SOQL WHERE filters can specify text to look for. When a given search can use either language, SOSL is generally faster than SOQL if the search expression uses leading wildcards or a CONTAINS term.
  • In some cases, when multiple WHERE filters are being used in SOQL, indexes cannot be used even though the fields in the WHERE clause may be indexed. In this situation, decompose the single query into multiple queries each with one WHERE filter and then combine the results.
  • Executing a query with a null in a WHERE filter makes it impossible to use indexing. Such queries must scan the entire database to find appropriate records. Design the data model not to rely on nulls as valid field values.
  • If dynamic values are being used for the WHERE field and null values can be passed in, don’t let the query run to determine there are no records; instead check for the nulls and avoid the query if necessary.
When designing custom query/search user interfaces, it is important to follow these guidelines:
  • Keep the numbers of fields/searched to a minimum. In LDV environments, querying a large number of fields in the same query can be difficult to performance tune.
  • Determine whether SOQL or SOSL or a combination is appropriate for the search.

Why to use Database.Stateful()?

Database Stateful is interface. It is used in batch classes to maintain the state of the class across transactions i.e. if you want to use ...