jump to navigation

Running through the first finish line June 19, 2008

Posted by mmoriar1 in Uncategorized.
trackback

Since last time, I’ve tentatively completed all of the Subscriber pages (yaaay) and can now start working on tracking events.  Here is a rough overview of this post’s content:

  • I changed the repeater on the single subscriber pages to be more dynamic based on the type of data being entered, so I will share my experiences with that
  • I got upsert working, and will give a few pointers on the syntax of that
  • I will explain what I have found out about deleting subscribers
  • I handled the results and statuses of the multiple subscriber actions by using a GridView in conjunction with a DataTable, I will go into more detail about that
  • A few more odds, ends, and annoyances

So.  The repeater on the single-subscriber pages is different than it was last time.  Firstly, there’s only one, not two.  I changed things around in that instead of having one repeater just for the text fields and the other repeater just for the attributes which have picklists, there’s now just one repeater which contains a text box, drop down list, and check box in each table row.  Doing this allows the repeater to select which control will be visible based on the datatype of the attribute or the presence of a picklist.  It also looks more professional and will be more flexible to different clients’ attribute pools.  Take a look:

OLD

Old

NEW:

New

As you can see, the new page looks more aligned and organized.  You might also notice the “upsert” checkbox.  Upsert does indeed work when that box is checked, but it’s hard to figure out how to implement it from the API guide alone (at least for me).  For those of you who don’t know what an “upsert” call does, it is basically creating the subscriber, but if the subscriber already exists then instead of throwing an error it will update the existing subscriber with the information from the create call.  To enable upserting on a create call, use the following code:

CreateOptions co = new CreateOptions();
co.SaveOptions = new SaveOption[1];
SaveOption so = new SaveOption();
so.PropertyName = “*”;
so.SaveAction = SaveAction.UpdateAdd;
co.SaveOptions[0] = so;

…and then pass the CreateOptions object to the call like so:

CreateResult[] results = integrationFramework.Create(co, new APIObject[] { new_sub }, out
requestID, out status);

Booya, there you go.  You’re now upserting.

Additionally, with regards to the single-subscriber pages, a workaround for the problem in the previous post of not being able to specify an EmailTypePreference upon creation is to simply perform an update call on the created subscriber making sure to specify the desired EmailTypePreference.  The update call correctly sets the preference.

Next, I experimented with the deletion of subscribers.  Deleting subscribers is a tricky subject.  This is probably because most clients would never want to delete a subscriber since then all data related to that subscriber is lost.  The more elegant and useful way would be to unsubscribe them from everything and then just let their email address slip away into oblivion.  What I’ve found is that deleting a subscriber doesn’t delete them right away.  If you try and re-create the deleted subscriber after the deletion, you’ll find that you cannot, and an error will indicate that the subscriber is still present on the all-subscriber list.  Hmm…interesting.  Even more interesting is that while you cannot retrieve or re-delete the “deleted” subscriber.  You can upsert/update using the deleted subscriber’s email address.  Upserting the deleted subscriber brings them back to life in the subscribers list.  I don’t know as of yet the full internals of a deletion through ExactTarget, but that is all that I have discovered so far.

Next I constructed the multiple-subscriber pages.  The construction of the pages was simple: the idea was to have a user upload a file of comma-separated subscribers to be retrieved/created/deleted (in the ExactTarget format with attribute headers) and then to operate on that file.  File upload was easy (consult http://www.asp.net/learn/videos/video-255.aspx) and one thing I did was persist the file location in the Session object so that users only had to upload the file once and could then do create/retrieve/delete using the same stored file without having to upload every time.

Multiple-Creates/Retrieves/Deletes are all performed using the same API call syntax as in the single-subscriber pages, just instead of passing the API call one Subscriber to operate on, an array of Subscribers or email addresses is passed.  The tricky part was controlling the timeouts of the requests.  As of now, no more than 200 subscribers can be operated on without the request timing out.  Technically the limit is 2500, but if you have that many subscribers to create, ftp the file over to ET and do it that way. πŸ™‚

After the call is performed, the results are displayed to the user using a GridView bound to a DataTable.  A DataTable is a neato object which is basically a database accessed like a variable.  I consulted Google quite a bit when learning about them, so I suggest that you do too.  Once the API call pops back the array of output, I populate the DataTable with that data and then bind it to the GridView.  I then consulted these resources for enabling paging and sorting for the GridView (http://www.csharpfriends.com/Forums/ShowPost.aspx?PostID=36859 , http://forums.asp.net/t/956540.aspx?PageIndex=1), and these resources for hooking up the GridView with a DetailsView for a Master/Details layout (http://www.asp.net/learn/videos/video-08.aspx , http://www.asp.net/learn/videos/video-07.aspx).  See the result:

STATUS OF THE CALL IN A GRIDVIEW:

RETRIEVED SUBSCRIBERS IN A MASTER/DETAILS VIEW:

Some odds and ends I learned are as follows:

  • It took me a long time to debug the fact that my email addresses had whitespace and newlines (\n) on the end of them, so to fix this problem I used the handy .TrimEnd() function to get rid of all the whitespace following the string.
  • It’s very annoying of the API to not give good error messages.  Error code 2, for example, says “There was an unexpected error”.  Thanks!  What was the error?!  After debugging, it turns out the first attribute in my created subscriber’s attribute array was null, and ET didn’t like that very much.  Would it really be that hard to say “Attribute cannot be null”.  I’m done complaining, the product really is awesome. πŸ™‚

That should be it for now unless I forgot to mention something.

Until next time,

Mike

Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: