Showing posts with label export. Show all posts
Showing posts with label export. Show all posts

Thursday, December 22, 2011

Discrepancies in Reports and Report Actions

I learned an interesting thing about reports today: What's displayed in a report can be different from what gets exported or from what gets added to a campaign. Let me try giving an example to clarify my statement.

Here's what we expect to happen:
  1. Run a Leads report.
  2. Review the data on the report. Let's say that the report shows 3 Leads.
  3. Click Add to Campaign. The 3 Leads we saw are added to a campaign.

Here's what could actually happen:
  1. Run a Leads report.
  2. Review the data on the report. Let's say that the report shows 3 Leads.
  3. Click Add to Campaign. Four (4) Leads, not 3 Leads as we just saw, are added to a campaign.
  4. Return to the report. 4 Leads are now shown, instead of 3.
  5. Click Export and complete the export. Five (5) Leads, not 4 Leads, are exported

The cause of this behavior is that when an action is performed on a report, namely Add to Campaign or Export, the report is run again in the background to as part of performing the action. In other words, what we see on the report before we export or add to a campaign can be thought of as a "preview" of what would happen after we perform an action.

In most cases this is probably a non-issue, but I thought the phenomenon was worth noting in the off case that someone is perplexed by an odd discrepancy between a report and a campaign member list or an export file.

Thursday, September 8, 2011

Apex Data Loader for Mac, Linux and Unix

Salesforce had the foresight to code the Apex Data Loader (ADL) in Java, which is a cross-platform tool that should work on any computer that has a JRE installed. This implies that the ADL should work on all OS's, not just on Windows.

Force 201 made a great post about running ADL with a GUI, but I just wanted to know how to run the ADL in batch mode from a command line (so that I can script the process).

It turns out to be as easy as the following:
  1. Download and install the Apex Data Loader on a Windows computer.
  2. Copy the files in "%ProgramFiles%\salesforce.com\Apex Data Loader apiVersion" to the desired directory on the target computer or server. Use binary mode for data transfer when applicable.
  3. Setup the batch mode configuration files as you normally would. This generally includes config.properties and process-conf.xml.
  4. Look at "\bin\encrypt.bat" to figure out how to create an encrypted password if you need one.
  5. Look at the last few lines of "\bin\process.bat" in the folder to figure out what syntax to use to run ADL via the command line.

For example, with ADL 22.0 on Linux, I can change to the base directory containing all of the ADL files and run this command:
java -cp DataLoader.jar -Dsalesforce.config.dir=conf com.salesforce.dataloader.process.ProcessRunner process.name=classMeetingExtractProcess

classMeetingExtractProcess is the id of one of my beans defined in process-conf.xml.

Friday, May 27, 2011

JavaScript Hack to Add All Fields to Export Template

Faced with the daunting task of creating an export template in ApplyYourself that included all available fields, I decided to try my luck at using JavaScript to do the job for me (with greater accuracy).

The end result is the following hack, which adds all exposed nodes to the template.
javascript:

/* Grab the fields frame. */

var fieldsFrame =
    document.getElementsByName(
        "frameQuestionsTree")[0];
var fieldsWindow = fieldsFrame.contentWindow;
var fieldsDocument = fieldsWindow.document;

/* Grab the actions frame. */

var actionsFrame =
    document.getElementsByName(
        "frameActions")[0];
var actionsWindow = actionsFrame.contentWindow;
var actionsDocument = actionsWindow.document;

/* Find the exposed nodes to add. */

var fieldsATags = fieldsDocument.getElementsByTagName("a");
alert(fieldsATags.length + " A tags found in fields window.");

var nodeIdPattern = /Nod[0-9]+/;
var nodeATags = new Array();
for (var i = 0; i < fieldsATags.length; i++) {
  var fieldsAElem = fieldsATags[i];
  var fieldsAIdAttr = fieldsAElem.attributes["id"];
  if (fieldsAIdAttr) {
    if (fieldsAIdAttr.value.match(nodeIdPattern)) {
      var nodeNumText = fieldsAIdAttr.value.slice(3);
      fieldsWindow.setSelectedNode(parseInt(nodeNumText));
      actionsWindow.BtnAddField_onclick();
    }
  }
}
This hack was tested in...
  • Chrome 11 on Windows 7
  • Internet Explorer 9 on Windows 7

Thursday, May 12, 2011

Increasing Speed of Command Line Extract/Export with Apex Data Loader

I had a strange problem when I tried to automate a routine, daily export that I was performing with the Apex Data Loader (version 20.0 and 21.0): Exporting through the GUI only took 5 seconds, but exporting through the command line took anywhere from 30 minutes to 1 hour.

After 4 weeks, Salesforce Premier Support finally delivered a solution to the case I logged: Set the sfdc.debugMessages value to false. I'm very glad that Premier Support was able to find a simple solution to this problem.

Apparently, debug messages were so verbose for every record being exported that operation time increased by a ridiculous factor. Luckily for me, debug messages are not that important for an export.

Monday, August 9, 2010

Salesforce CSV Format for Report Exports Is Not IETF RFC 4180-compliant

At the time of writing this post, I believe the published standard for CSV file formatting is the IETF RFC 4180.

Also at the time of writing this post, I believe that the Summer 2010 version Salesforce does not produce IETF RFC 4180-compliant CSV files for exported reports.

Here are a few differences in the Salesforce CSV file:
  • Salesforce uses a single LF ('\n') to start a new row of data instead of a CRLF ('\r\n').

  • Salesforce exports line breaks in street addresses with just a LF instead of the CRLF specified by the RFC.


A few more noteworthy considerations for the Salesforce report CSV files:
  • All values are delimited with double-quotes.

  • Salesforce does double double-quotes for values that contain the double-quotes character, as stipulated in the RFC.

  • For Text Area fields, Salesforce does convert line breaks in the field value to CRLF sequences, with the exception of native Street fields.

  • There is a footer in the CSV file that does not contain any data at all, which may complicate straight data imports into other systems or programs like Microsoft Access.