|
|
| |
 |
Last
Updated:
 
    |
Understanding The Use Of Omniture’s Token System 
By Gary Angel
Expert Author Article Date: 2009-03-16 In my next post, I'm going to dive down and talk in more detail how the API actually works and show pieces of a real application. But before I go there, I wanted to touch one more time on tokens and give any programmers out there a heads-up on the "Great Token Gotcha." In my last post, I described Omniture's token system - the basic metering systems that controls how many API requests you can make and how they cost. In essence, each API request you make costs you a token. And to use the reporting API, you have to submit a request and then you have to get the report. So you typically use two tokens per request. Simple? It is, but there is a big gotcha out there. Here's how it works. To make a request to the API, you build up a report object that tells Omniture what data you want to retrieve and what time period you are looking for. When you've defined everything, you submit your report. So far so good. Now here comes the tricky part. Most Omniture Sample code works the same way. After the request is submitted, you go into a wait loop. You pause your program for a second or two, request the report object to see if it's finished. If it's done, you are good to go. If it's not done, you wait for another second or two and check again. Here's some heavily commented code (this whole post is really for programmers so feel free to skip if your interest in the API is more on the business site): //request the report reportQueueResponse response = glob.ws.ReportQueueRanked(rd); // Wait for 1000 milliseconds or 1 second System.Threading.Thread.Sleep(1000); // Grab report reportResponse reportR = glob.ws.ReportGetReport(response.reportID); // If the report is not ready then wait and check to see if it is ready while (reportR.status != "done") { // Wait another second System.Threading.Thread.Sleep(1000); // Check the report again reportR = glob.ws.ReportGetReport(response.reportID) // Keep checking (go back to the while until the reportR.status is done } This is a simple, obvious way to manage your code. There are others, but this is the way most of the Omniture examples on their dev site are built and it makes perfect sense. It's also terribly wrong and the reason isn't programmatic. What is hidden in the system is that Omniture will dock you a token for each and every time you make the: reportR = glob.ws.ReportGetReport(response.reportID); request to see if the report is ready. Yes, you will be charged a token! And since reports often take ten, fifteen, even forty seconds to run, you can burn up your entire token allowance of 2000 a month with just a few short requests. And, of course, the irony of this is that the worse Omniture's system is performing, the more expensive the system is. It's brutal, and until we realized that this call docked us a token, we were in constant danger on every request of running out of tokens and having to cease development for a month. Is there another way? Indeed there is, but I'm not sure everyone always realizes the difference - I know I didn't. Instead of the GetReport call, you need to make the GetStatus call - this will return the status of the report without dinging you a token. This call didn't even exist in earlier versions of the API - so it's easy to overlook or to miss its significance! So if you've been using (or are about to use) the API, and you didn't realize this little problem, I believe I've saved you a world of grief and confusion - at least if my own experiences are any guide. And I'm pretty sure that this little gotcha is responsible for a good deal of the confusion surrounding token policies and the reason many programmers believe that each request to the API uses multiple tokens depending on how complex it is. That's sure what it looks like until you realize that it's requesting the report (not running it) that you are being dinged for! In my next post on the API, I'm going to describe the basics of building an API application and show some samples of our work to give you a feel for what can be done. Comments About the Author: Gary Angel is the author of the "SEMAngel blog - Web Analytics and Search Engine Marketing practices and perspectives from a 10-year experienced guru. |
|
| DevWebProIN is an iEntry, Inc.® publication - All Rights Reserved Privacy Policy and Legal |
