jump to navigation

Trials and tribulations of the ET WebServices API June 5, 2008

Posted by mmoriar1 in Uncategorized.
Tags: ,

Since last time I have implemented a (seemingly working) login system, set up the divs for the first draft of the page layout, validated the email address field, made some magic happen with repeaters, created a cool AJAX collapsible panel, and set up the site map. Extremely long sentence aside, I’ve been pretty productive.

The login system was a tricky fellow to design, but implementation was fairly simple. While not elegant, it IS functional. The tricky parts were figuring out how to authenticate the username/password with the ExactTarget system, how to go about storing the username/password for use in subsequent API calls, and how to prevent unauthenticated users from accessing other parts of the site. These difficulties were overcome by:

  • Performing a dummy API call to the ET servers and seeing if any exceptions are thrown. If an exception was thrown by the authentication, that message is displayed neatly to the user under the two username/password text boxes. If no exception was thrown, then the user is redirected to a start page.
  • Storing the username/password in the Session object. Session is naturally encrypted and is persisted as the user travels from page to page, so it works quite well.
  • Storing a boolean variable in the Session pertaining to whether or not the user has authenticated with the ET servers or not. At the top of each “restricted” page (in the page load), the page checks to see whether the user is authenticated, and if not it redirects to the login page. Despite a few display quirks, it works well.

Setting up the divs for the page layout was nothing more than fiddling with CSS. Here is what the page looks like as of now (draft 1). Ignore the debugging background colors 🙂

Validating the email field was quite easy as well after watching a tutorial video on the subject. (http://asp.net/learn/videos/video-193.aspx) It just makes sure that something is in the box using the RequiredFieldValidator and makes sure that it follows the name@site.domain format using the RegularExpressionValidator.

The magic with repeaters was fun. The idea was to fetch a Subscriber’s attributes (First Name, Last Name, Email, etc.) on page load and then display the attributes in editable text boxes so that a user could change their value(s), and then the Subscriber could be updated with an API call to the ET server. After debugging a few frustrating errors in the API/C# (discussed below), I loaded the Subscriber’s attributes into an ArrayList which was then bound to a repeater (guide consulted: http://stanleycn.blogspot.com/2006/10/how-to-bind-arraylist-to-repeater.html). The repeater simply displayed each attribute’s name on a label followed by a text box pre-populated with the attribute’s value. The result can be seen in the above image. One other thing that had to be done was to cast the Container.DataItem object in the repeater template to an attribute object like so: ((com.exacttarget.webservice.Attribute)Container.DataItem).

The AJAX in the page so far is little more than an UpdateProgress control used to visually indicate when the client is requesting stuff from the server (resources used: http://asp.net/learn/ajax-videos/video-123.aspx for the guide and http://ajaxload.info/ for the awesome animated gif) and a CollapsiblePanelExtender in order to hide/show the source code for the API call (guide: http://asp.net/learn/ajax-videos/video-89.aspx)

One time consuming debug that I had to do stemmed from the fact that in the API Guide example code on page 40 there is the line:

PartnerAPI.Send send = results[cntr] as Send;

which I reformed to say:

PartnerAPI.Subscriber sub = results[cntr] as Subscriber;

Seems OK, right? All of the rest of my code was correct, but I kept getting the compilation error that “it could not convert com.exacttarget.webservice.APIObject to Subscriber via an internal conversion”. But it had worked the previous day in its current state…hmmm… Well, after trying stuff, it turns out that it needed to be declared as such:

com.exacttarget.webservice.Subscriber sub = results[cntr] as com.exacttarget.webservice.Subscriber

Yep, fully qualified and all. Still haven’t figured out totally why that is, but it works and is pretty low on my priority list to clean it up.

The other time consuming bug which hit me was that when trying to grab a subscriber’s attributes, I would include “Attributes” in the properties list as such:

sub_request.Properties = new string[] { “ID”, “EmailAddress”, “Attributes” };

This makes sense, as Attributes are a member of the Subscriber object and are returned as an array of the Attribute object. But upon performing the retrieve call, I would get an error indicating that “the format doesn’t match the form’s field view” (or something similar). This is because you aren’t supposed to include “Attributes” in the properties list, as they are grabbed by default. I stumbled upon this fix in the developers.exacttarget.com forum. Problem solved.

Well that’s all for now, until next time,