Google Data

We’ll be performing routine system maintenance on Thursday, May 13th from approximately 6:00pm to 6:30pm PDT. You won’t be able to access AdWords or the API during this time frame, but your ads will continue to run as normal. While, AdWords system ma…

We’ll be performing routine system maintenance on Saturday, May 8th from approximately 10:00am to 2:00pm PDT. You won’t be able to access AdWords or the API during this time frame, but your ads will continue to run as normal. Best,- Eric Koleda, AdW…

In our previous blog post, we discussed how v2009 error handling works in synchronous APIs. In this blog post, we cover asynchronous error handling in BulkMutateJobService. If you are new to BulkMutateJobService, check out our introductory blog post and code.google.com article.

Due to its asynchronous nature, error handling in BulkMutateJobService is slightly different than in other services. Instead of throwing an ApiError object, BulkMutateJobService returns FailureResult or BatchFailureResult objects as its operation results. These objects in turn contain the relevant ApiErrors. BulkMutateJobService processes the operations within an operation stream in multiple atomic batches. If there is even one faulty operation in a batch, it causes the other non-faulty operations in the batch to fail as well. When a batch of n operations fails, you will get one FailureResult and n – 1 BatchFailureResults as results for the failed batch of operations. The FailureResult object will always be first in the batch, and will contain one ApiException object. The ApiException contains all the errors for the entire batch of operations, just like for other services. This will be followed by n – 1 BatchFailureResults, which can be viewed as placeholders, one for each operation in the batch.

For instance, assume that you are trying to create the following 9 text ads in a single OperationStream. For the purposes of this example, assume that the system processes operations in batches of 3. The errors are highlighted in red.

When BulkMutateJobService processes these operations, it will return the following results:

Result[0]: FailureResult. ApiException.errors has one ApiError   PolicyViolationError @ operations[2].operand.ad.description2Result[1]: BatchFailureResult, operationIndexInBatch = 1Result[2]: BatchFailureResult, operationIndexInBatch = 2

Result[3]: FailureResult. ApiException.errors have 1 ApiError   AdError.URL_NO_SCHEME @ operations[0].operand.ad.urlResult[4]: BatchFailureResult, operationIndexInBatch = 1Result[5]: BatchFailureResult, operationIndexInBatch = 2

Result[6]: ReturnValueResult, successfully created Ad.Result[7]: ReturnValueResult, successfully created Ad.Result[8]: ReturnValueResult, successfully created Ad.

As shown in the results above, there is a 1:1 correspondence between the number of operations and number of results. You can get the successful operations by scanning the return value for results which are not FailureResult or BatchFailureResult (operations 6, 7 and 8 in this case). Then, scan through the results to locate FailureResult objects (which always appear at the beginning of the failed batch) to get the operation that actually failed (operations 2 and 3 in this case). You can now pick the failed operations that do not correspond to the ones obtained from FailureResult, and make a new job for them (0, 1, 4, 5). Note that the OGNL path in FailureResult is relative to the batch and not the operationstream, so you have to offset it by the index of FailureResult to get the failed operation (e.g. Results[3] is a FailureResult and its OGNL path is operations[0].operand.ad.url, so the failing operator in the original list is 3 + 0 = operations[3]).

A BulkMutateJob may also return the following error results, even though they’re not common:

LostResult: This happens when BMJS has lost results for some of a job’s operations. You can recover from this error by checking numFailedOperations and numUnprocessedOperations for the job. If both are zero, or if the number of errors in ApiError matches numFailedOperations, then the operations were successful, but the results are missing. In any other case, you have to retrieve the entities that were targeted by the operations and see if the operation actually succeeded or not.

UnprocessedResult: This indicates that the mutate operation was not processed. This could happen because the workflow implementation prevented the operation from being processed (e.g. the operations exceed API quota). You can recover from this issue by checking the job status, making sure that you have sufficient API quota left, and simply retrying the operations in a new job.

In an upcoming blog post, we will cover the most common errors you may get in v2009, and how to address them. We’ve included support for error handling in all of our client libraries to help get you started, so please try it out and share your feedback with us on the forum or the projects’ issue trackers.

– Anash P. Oommen, AdWords API Team

Today, we’re announcing preferred AdWords API pricing for agencies and developers of search engine marketing (SEM) tools. With preferred pricing, this important group of developers will get free API units based on managed client spend.As an agency or a…

You might remember that six months ago we announced that on April 22, 2010 we would be sunsetting many v13 services. Since then, we’ve posted reminders over the last 100 days right here on the blog. It’s finally April 22, so today we’re sunsetti…

As with any programming system, error handling is a critical part of the AdWords API as well. In v13, we used to describe every error by its own error code. While this was simple and handy, the API provided less additional information about the error i…

If you haven’t migrated to the new v2009 AdWords API yet you have only 14 days left to do so. Developers that don’t migrate by April 22 will experience failed calls to most v13 services. The only v13 services that will remain accessible are Account…

We’ll be performing routine system maintenance on Saturday, April 10th from approximately 10:00am to 2:00pm PDT. You won’t be able to access AdWords or the API during this time frame, but your ads will continue to run as normal. Best,- Eric Koleda…

In previous versions of the API, services had separate methods for adding, updating, and removing items in an AdWords account. The v2009 version changed this paradigm and combined the functionality into a single method called mutate. The mutate metho…

Attention AdWords API developers: you now have just 30 days to migrate your application to the new AdWords API. On April 22, most v13 services will be sunset. We announced version v200909 on October 22, 2009 and told you that in six months we would sun…

We'll be performing routine system maintenance on Saturday, March 20th from approximately 10:00am to 2:00pm PDT. You won't be able to access AdWords or the API during this time frame, but your ads will continue to run as normal. Best,- Eri…

We recently finished the last of our AdWords API Hack Days in Europe, and it was great to see so many AdWords API developers come out for these events. We realize that not everyone could attend one of the Hack Days in person, so we’ve been working on n…

Last month we reminded you that on April 22 most v13 services will be turned off. In 60 days, the following v13 services will no longer be accessible:CampaignServiceAdGroupServiceCriterionServiceAdServiceInfoServiceKeywordToolServiceSiteSuggestionServ…

We’ll be performing routine system maintenance on Saturday, February 20 from approximately 10:00am to 2:00pm PDT. You won’t be able to access AdWords or the API during this time frame, but your ads will continue to run as normal. Best,- Eric Koleda,…

Our recent AdWords API Hack Days in San Francisco and New York were a huge success, filled with presentations, question and answer sessions, and one-on-one coding help. We were glad to see that many developers have already started the migration to the…