Skip to main content
Published: March 31 2005, 1:00:00 AMUpdated: July 25 2022, 2:06:36 AM

One of the most important aspects in implementing applications is the logging of the raw XML and SOAP requests. Yet it is one of the most overlooked aspects. When done properly it can save many hours of headaches when dealing with real world issues, and allow you to provide a high level of service to your customers, not to mention get quick turnaround on issues from the eBay Developers Program support staff.

One of the features that a developer using the SDK should plan for is how to use the Logging mechanism effectively, becuase doing so can save precious development and debugging time.

An idea that can help greatly is to have a separate log file for each end user the application serves per day or even per hour. Variations on this can be implemented such as using 1 log file per hour across all users. This is a better approach then keeping one hugh running log file, although in our testing and support experience, keeping log files separated by time period and by user for each time period can be very valuable in tracking down and resolving issues quickly.

We suggest having a top level Logging folder with subfolders for each year, then month, then day, then hour and a folder in each hour for each user. This may sound difficult to manage or overkill, but seeing is believing, and once you commit to it, it's a lot easier to manage then you might think. Once you implement something like this you will wonder how you ever did without it.

Here is an VB.NET example of naming a log file:

Dim Now As DateTime = DateTime.Now.ToUniversalTime()   'note that we decide to log based on GMT
logfile = "C:\eBay\Logging\" & Now.Year & "\" & Now.Month & "\" & Now.Day & "\" & Now.Hour & "\" & mSession.AppUser.EBayUserId & "\log.txt"

What you essentially have is a log directory structure which you can then put on a WebServer for quick and easy access to the log files and put security restrictions on through the web share. For a quick example, lets say you have 100 userids that you service, me1 through me100. You would have the following directory structure for logging:

C:\eBay\Logging\2008\ under which you would have 12 directories (1 through 12)
so for Jan you would have C:\eBay\Logging\2008\1\ under which you would have 31 directories (1 through 31)
so for Jan1st you would have C:\eBay\Logging\2008\1\1\ under which you would have 24 directories (0 through 23)
so for Jan 1st the 4:00 GMT hour you would have C:\eBay\Logging\2008\1\1\4\ under which you would have 1 directory for each user served by your application ... in this case C:\eBay\Logging\2008\1\1\4\me1 through me100
If you put the eBay or Logging directory under a web share, you would be able to navigate quickly and directly to log files exactly for the user and time that you needed to refer to. You can have utility programs in Perl or JSP pages to slice and dice through the log files to fit your needs (for example look for all error codes 10007 received for all users on a certain day, you can imagine how easy that would be with this logging implementation in place).

Again, all of this may sound like overkill, but in the end you will be thankful if you serve multiple end users through server applications and run into issues that need investigation; log files of the actual XML in the API calls are of utmost importance. eBay uses roughly something like this in it's server logging mechanisms and it has proven extremely useful in quickly diagnosing and resolving issues.

This concept is easily extended for more elaborate logging based on return error codes, exceptions, warnings, etc., or implemented in a more simple directory structure, or even implemented when using just the call library on a much smaller scope.

This is well worth the small amount of time up front that it takes to think about and implement properly.

How well did this answer your question?
Answers others found helpful