I could not find a CSV parser for Salesforce so implemented this one and decided to share it. It’s simple but it handles quotes, newlines and arbitrary delimiters (I’ve implemented a few CSV parsers over the years so hopefully I am getting the hang of it). One thing a bit special with this one is instead of “tokenizing” the string as one might usually do in an optimized parser I went with a regex approach, basically this means the string may have to get read twice in a worst case scenario, but the way Apex calculates the complexity of your code is essentially the number of statements that get run. So the higher level approach, even if they are a bit less efficient overall, score better with Apex (less likely to hit the governor limit).

Here is the associated test class. One thing I really dig about the SF development model is the integration with unit tests. This almost makes up for the suckiness of the IDE.

I might as well make a few comments about the development process. First of all, the unit test integration is rather nice. They will automatically “sandbox” your database for the unit test and give you a coverage report. A few things to watch out for:

• Keep your eye on the “Problems” tab. If there is an error, maybe in some other file, the IDE will still happily run the previous version of your tests and you’ll be left wondering why your changes are not taking effect. Happened to me more than once.
• Use a sandbox for development – very little can be done in a production environment because you need test coverage to deploy the code, and you can’t test the code until it’s deployed.
• The Force.com IDE sucks really, really bad. I don’t have anything against Eclipse – I love Eclipse for Java code! But writing Apex code is very, very primitive. The build operations are quite slow (not “SalesLogix App Architect” slow, mind you, but still slow) and the errors reported are not clear. Intellisense very rarely works. Stuff occasionally gets out of sync and has to be blown away and resynced from server. Also, only a few items can actually be done from the IDE, the rest has to be configured using the web interface which is very cluttered and confusing. The only redeeming factors are the documentation which is top notch (both the reference guide and the community) and the unit test integration.

An alternative to be aware of is that the processing can be done remotely and use the bulk update API to do the communication with the database. In retrospect it might have been the way to go in this scenario, since I already had to do some processing in a remote app, but this was a good project to tour the Apex facilities with so I am glad I got the chance to do that.

I also used Heroku for the remote processing part, this was my first non-toy app on that platform, and a very positive experience so far.

I think I just found the most awesome warning message ever. I am going to write all my dialogs like this too now. “Deleting an account is usually safe. Are you sure you wish to delete this account?”

Sending an email from a web page (via the user’s client) is surprisingly tricky. A mailto: url can do the trick but it has some severe length limitations. Sending it via a background script does not have any such limitation but the user does not get a chance to edit the email, record it to their Sent Items, etc. Using Outlook automation allows for the most flexibility but it has some bad implications: only works on IE, requires some pretty specific security setting (trusted site + “enable activex controls not marked as safe”).

For an intranet scenario, where we can be certain that most users will be using Outlook and IE, I came up with the following solution. It will attempt to send the mail using Outlook automation and fall back to a “mailto” method if not available (i.e. either they are using another browser / OS, or they don’t have the correct security settings). It is a CommonJS module, I have started using RequireJS for custom modules to prevent namespace clashes.

The tricky part was making sure the URL stayed short enough – if it gets over a certain length, Firefox will just ignore it altogether (other browser will truncate it). This is the job of the addUrlComponents function. I call it with the recipient, subject and body parameters until the length is exhausted, but each is limited – this way if there is a ton of recipients, rather than trying to keep them all and getting a blank email, it limits the total address length to 900 characters and saves the rest for the email itself. It’s not ideal either way but I figured this was preferable.

I went ahead and created a test page for it since the addUrlComponents function was not trivial… this also gave me a good occasion to use qunit – very, very easy to get running with that test framework.

PS – this gist thing is a great way to get syntax highlighting on the cheap hah!

At any time we need to perform a lengthy process such as an import or a batch update, one of the elements necessary to provide a good user experience will be to give them a feedback on the progress. I have experimented with a few of them and wanted to show the one that I have found the most versatile and easy to implement.

First of all note that if you have a lengthy process you will need to configure the request timeout in the web.config. It would be something like (assuming your page is called Import.aspx):

<location path="Import.aspx">
  <system.web>
    <httpRuntime executionTimeout="3600" />
  </system.web>
</location>

Also, do take a look at the note on potential performance problems, at the end of this post.

Now, a quick review of the options:

• There is a progress bar control called RadProgressManager which is actually included as part of SalesLogix (they use it in the lead import screen). It works relatively well once you have it configured properly but I have found a few challenges when trying to use it. First of all, it works by polling, which means it makes repeated requests to the page to find out the progress – this is relatively inefficient, though usually not a big concern. Secondly, the control takes some work to properly configure – it is rather sensitive to the order in which components are loaded, where it is placed respectively to the update panels, whether the postback is asynchronous or not, etc. If everything is not “just right” it will fail, often with an obscure error message (or no message at all). Thirdly, the default look is absolutely hideous, so you usually have to replace the whole thing with a custom template – quite a bit of work. Finally it gives little options other than just reporting a progress percentage and a step description, so if you want to for example report errors as they happen you may be out of luck. For these reasons I have not used it very often.
• One other way is doing repeated refresh of the page (or just the update panel that contains the progress bar) to refresh the status. This works pretty well if the processing happens on a separate service (other than being inefficient as it requires a reload every time) but not if it is done on the same page of course as it would not be able to reload itself until the process was finished! Note that you can’t do the process on a handler and refresh the page either, as a page in SalesLogix always requires an exclusive access to the session.
• Finally there is an option recently called “pushlet” but which was already used years ago before Javascript even came of age. The idea is to post the data to the page which does the process, but instead of reporting the process “out of band” it just writes it out as it happens. Now, the idea is that instead of just writing the process to a blank screen, this page outputs a snippet of Javascript which gets executed and (via the method of your choosing) reports a progress or an error. The advantages are that it uses only one connection unlike the previous 2, reports the progress in real-time (unlike the other ones which will have a lag imposed by the polling rate), offers complete control of the UI, and is rather easy to implement, even more so if the UI is driven mostly from Javascript.

So, the basic concept of the “pushlet” is to post the form’s data into a hidden iframe. This can be done either by setting the SRC of the iframe (if no post data is required), by stuffing the form’s data into a form on the iframe itself and posting it, or by setting the TARGET of the current page’s form and posting it. The last one is most powerful as it will let you post files, but unfortunately also a bit more complex as you have to fight with ASP.NET to obtain a reference to the form and make sure you don’t interfere with the rest of the page. Here is a post that describes it though, and by a happy coincidence was posted right after I finished this one: Changing an HTML Form’s Target with jQuery – it’s for a vanilla ASP.NET scenario but should mostly apply to SalesLogix as well. An example of the second method, which works well enough as long as there is no need to upload a file:

var root = document.getElementById("bulkRequestSubmitFrame");
var rootDoc = root.contentDocument || root.contentWindow.document;
var baseUrl = location.href.replace(new RegExp("/[^/]*$"), "");
var url =  baseUrl + "/SmartParts/LitRequest/LitRequestBulkSubmit.ashx";
var scriptParts = [];
var doc = rootDoc.createDocumentFragment();
function createElement(tagName, attrs) {
	var elem = document.createElement(tagName);
	for (var a in attrs) {
		elem[a] = attrs[a];
	}
	return elem;
}

// this is the actual form data
doc.appendChild(createElement("input", { name: 'submission', value: Ext.util.JSON.encode(submission) }));
doc.appendChild(createElement("input", { name: 'itemSelection', value: Ext.util.JSON.encode(itemSelection) }));

rootDoc.body.innerHTML = "<form id='theform' action='" + url + "' method='POST'></form>";
var form = rootDoc.getElementById('theform');
form.appendChild(doc);
form.submit();

As the handler for the form processes the data, it will output snippets of javascript, such as:

<script type="text/javascript">
parent.reportSubmissionProgress(50);
</script>

Or to report an error:

<script type="text/javascript>
parent.reportSubmissionError("Unable to process contact id XYZ");
</script>

And the final piece on the client side is how to report the progress – this is made easy by the fact that ExtJS includes a decent-looking progress bar:

• To initialize it:

_percent = 0;
_errorText = "";
_progressText = "Contacting server...";
_progress = Ext.MessageBox.show({
  title: "Sync Progress",
  width: $(window).width() * .6,
  progress: true,
  progressText: _progressText
});

• To report progress:

function reportSubmissionProgress(percent, description){
  _percent = percent / 100;  // Ext % goes from 0 to 1
  _progressText = description;
  Ext.MessageBox.updateProgress(percent, description);
}

• To report an error:

function reportSubmissionError(error){
  _errorText += (error + "");
  Ext.MessageBox.updateProgress(_percent, _progressText, _errorText);
}

• And finally to hide it:

function reportSubmissionComplete() {
  Ext.MessageBox.hide();
}
// this will ensure the progress bar gets hidden once the iframe finishes loading
document.getElementById("bulkRequestSubmitFrame").onload = reportSubmissionComplete;

It looks like this:



The last piece of the puzzle is the handler on the server side, but this is also the easiest one. You can use a generic ASP.NET handler (ASHX) and just make sure you turn off buffering (context.Response.Buffer = false) and set an HTML content type (context.Response.ContentType = “text/html”) then use context.Response.Write to report the progress… to test it out, try something like:

public class TestHandler : IHttpHandler, IReadOnlySessionState
{
  public bool IsReusable { get { return false; } }
  public void ProcessRequest(HttpContext context) {
    context.Response.ContentType = "text/html";
    context.Response.Buffer = false;
    for(int i=0; i < 100; i++){
      context.Response.Write(String.Format(@"<script type='text/javascript'>
          parent.reportSubmissionProgress({0}, 'Reporting progress {0}...');
      </script>", i));
      Thread.Sleep(300);
    }
    context.Response.Write(@"<script type='text/javascript'>
         parent.reportSubmissionComplete();
      </script>");
  }
}

That's about it. It ends up being a good fit if you already have some javascript to drive some of the UI on your page. It's quite flexible and the way it works makes it easy to understand and troubleshoot using a tool like Fiddler or Firebug.

Remember that if the process is really lengthy, or if it is likely that many people will be doing it at the same time, you'll want to do that outside of the web client, because it will consume an ASP.NET thread and a connection handle as long as that connection is open. Then you have to use a separate service and use a polling mechanism to check on the progress, otherwise your server will grind to a halt as all its processes are stuck serving users - FYI, yes, this is based on first-hand experience. I recommend reading Improving ASP.NET Performance on the Microsoft P&P site, especially the section on threading (the whole thing is worth a read though).

I have been doing a bit of exploration via trial and error and wanted to post my findings here. Note all of those were found on SLX 7.5.2.

Say you want to audit changes in an entity related to the main entity of your form… for example in my case ticket.Contact (the customer can edit the contact’s first name from the ticket screen), or this would probably work the same with the address control on the account main view. You may run in the following issues:

• If you don’t make any change to the main entity itself, its Update event will not get called.
• The Update event of the related entity will not get called
• When you try to retrieve the changes for the related entity, you can’t simply do “((IChangedState)ticket.Contact).GetChangedState()” – this will return an empty change set. Instead you have to go through the member changes of the main entity.

Not much can be done about the first 2 items unfortunately – the event is just not getting triggered. This means you have to call the method to track the changes from the application code unfortunately for the time being (hopefully it will get fixed soon since it creates a pretty big hole in sdata applications – I have not tested to see if it was on 7.5.3). In the meantime let me elaborate on the last point. The main entity (e.g. ticket) keeps tracks of changes to related entities in its own ChangeSet. To retrieve changes on one of those linked entity you can use the Find() method of the ChangeSet to retrieve an EntityChange object. For some reason it does not allow one to retrieve this EntityChange using the property name (such as what you might use for FindPropertyChange or FindMemberChange ), but since you already know the id and it will be unique you can just use something like

EntityChange customerChange = changes.Find(x =>
          (String)x.ChangedEntity.EntityId == (String)ticket.Contact.Id);
if (customerChange == null)
    return;

From there, retrieve a ChangeSet using customerChange.ChangedEntity.EntityChanges, and you can manipulate that one like a regular ChangeSet:

ChangeSet changes = customerChange.ChangedEntity.EntityChanges;
PropertyChange nameChange = changes.FindPropertyChange("FirstName");

For a more deeply linked entity like ticket.Contact.Address it is also retrieved from the ticket entity’s ChangeSet:

EntityChange addressChange = changes.Find(x =>
    (String)x.ChangedEntity.EntityId == (String)ticket.Contact.Address.Id);

Hope this helps!

A lot of time in the LAN client I have some logic similar to this snippet (which updates the account manager to match the region selected by user in a picklist):

sUser = GetField("userid", "userinfo", "region = '" & Sender.Text & "'")
If sUser <> lueAccMgr.LookupID Then
  If MsgBox("Would you like to change the account manager to match selected region?", vbOkCancel) = vbOk Then
   lueAccMgr.LookupID = sUser
  End If
End If

In the web client you would want to do something like this:

IUser user = GetUserByRegion(CurrentEntity.Region);
if(user != CurrentEntity.AccountManager){
  if(PromptUserForConfirmation()){
    CurrentEntity.AccountManager = user;
  }
}

But how to implement the “PromptUserForConfirmation” method? You can’t do a modal dialog box from server-side code.

One method would be to implement all of the logic from client side. You can use an ajax call (maybe using sdata) to implement the “GetUserByRegion” in Javascript, and probably in this particular case it would be simple enough to be very feasible.

Sometimes there is a bit too much logic on the server side to be ported over to javascript, or you just don’t want to have to load too much logic on the client (which is often harder to maintain). In that case you can use what I call the “hidden button” trick. This keeps most of the logic on the server and separate the process in 2 steps, using a non-displayed button on the client to allow the script to “resume”. The button on the page would be something like (make sure you do “display: none”, not “Visible=false”, as the latter would prevent the button from being output on the page at all):

<asp:Button style="display:none" runat="server" id="btnConfirmRegionManagerChange" OnClick="btnConfirmRegionManagerChange_Click"/>

The code on the picklist change event would become:

// first postback, executes when the user has just made the picklist change
// (assuming the picklist is set up to autopostback)
// here we run the first part of the logic
IUser user = GetUserByRegion(CurrentEntity.Region);
if(user != CurrentEntity.AccountManager){
  // register a client script to show confirmation prompt and simulate a button click
  ScriptManager.RegisterStartupScript(this, GetType(), Guid.NewGuid().ToString(),
   "if(confirm('Would you like to change the account manager to match selected region?')) " +
     "$('#" + btnConfirmRegionManagerChange.ClientID + "').click();", true);
}

And finally the handler for the btnConfirmRegionManagerChange click would take care of the second part of the process:

// Here we just call the GetUserByRegion method again...
// If there was a lot of processing involved you could cache the result from the previous postback
// into a hidden field or a ViewState variable
IUser user = GetUserByRegion(CurrentEntity.Region);
CurrentEntity.AccountManager = user;

This way you have a bit of extra work, but the basic structure of the code remains the same so it is still easy to follow. I should mention I have not actually tried the code snippets above so if you copy / paste and find any typo please let me know.

Hope this helps!