Enhancing a lengthy process with a progress bar
Posted By: nicocrm on January 29th, 2011 in Javascript, Programming, Saleslogix
No Gravatar

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">
    <httpRuntime executionTimeout="3600" />

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');

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

<script type="text/javascript">

Or to report an error:

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

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() {
    // this will ensure the progress bar gets hidden once the iframe finishes loading
    document.getElementById("bulkRequestSubmitFrame").onload = reportSubmissionComplete;

    It looks like this:

    Progress Bar

    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));
        context.Response.Write(@"<script type='text/javascript'>

    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).

Tracking changes in related SalesLogix entities
Posted By: nicocrm on January 19th, 2011 in Saleslogix
No Gravatar

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)

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!

Confirmation prompt in SalesLogix Web
Posted By: nicocrm on January 6th, 2011 in Uncategorized
No Gravatar

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){
    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!