(Translated by https://www.hiragana.jp/)
Google Ads Developer Blog: adwords_v201109

In an effort to make more features available faster to AdWords API users, we’re launching AdWords API v201109_1, a dot release which includes services to help API users incorporate some recent AdWords web interface launches into their applications. New features include:
  • Keyword match properties NEAR_EXACT and NEAR_PHRASE, which allow API users to opt in/out of these match types.
  • LocationSyncExtension and the reports download service now have OAuth 1.0 support, bringing these services in line with others in the API.
As part of this dot release, we are also launching a few other features that will be available through an invitation-only beta. Similar to beta programs for the AdWords interface, the goal of this beta is to give developers earlier access to specific features, allowing us to incorporate feedback more quickly and innovate more effectively.

Moving forward, we will use dot releases to launch AdWords features more quickly. AdWords API v201109_1 does not start the sunset on prior versions, so you do not need to upgrade immediately. 

Complete release notes are available here. If you have any questions about these changes please reach out to us in the forum or during one of our office hours via Google+ Hangouts.

The AdWords API is designed to handle a high volume of changes, and many services allow developers to submit a large number of operations in one request. Most of the AdWords API services are synchronous though, so the client sends the request to the server, waits for processing and receives the result back.

Unlike other services, the MutateJobService (MJS) is designed for an asynchronous workflow. This has the following benefits:
  • No need to manage connections for each job - the job is executed autonomously and the results can be retrieved when ready.
  • Multiple jobs can be submitted and executed in parallel. In fact, the service has no limit on the maximum jobs count.
  • Transient errors like 'CONCURRENT_MODIFICATION' are automatically retried with no extra requests necessary.
  • Workload is automatically balanced so you will never receive a 'RateExceededError' error.
Also, MutateJobService operations cost only 50% of usual operations units cost.

Using MutateJobService in existing applications

Replacing existing calls to synchronous services with calls to MJS is easy. In most cases you can just use the same operations array to submit a job. Once submitted, the application needs to check the job status periodically to see when it is complete. Once ready, the results can be retrieved with the getResult method.

Please see examples in Java, PHP, Perl, DotNet, Ruby and Python for more details.

Recommendations:
  • Don't poll for job status too often as this can result in RATE_EXCEEDED_ERROR error. We recommend pausing for 30 seconds between get requests with an exponential backoff.
  • For better throughput, fewer large jobs are preferred over many smaller jobs. Once a job is scheduled and is executing, its progress will be very rapid.
  • When submitting many jobs for the same customerID, overall operation throughput will be optimal if no two outstanding jobs will be modifying the same AdGroup. Making all your jobs touch all AdGroups can cause severe slow-down or even job failures.
Note: while the old BulkMutateJobService is still available we recommend to use the MutateJobService for all future developments.

MutateJobService is covered in more details in our video presentation: Efficient API Usage with the MutateJobService. As always, please feel free to ask any questions regarding the AdWords API on our forum or during scheduled office hours.

Last week we sunset all versions of the AdWords API prior to v201109. If you have not yet migrated to v201109, you will now receive errors when making calls using previous versions.

For users still working on the transition from v13 to AdHoc reports, we want to remind you of resources available to help you out:
  • The report migration guide provides a side-by-side mapping between the fields available in the v13 ReportService and those available in v201109.
  • The mapping report to the UI guide maps the concepts and naming conventions used in the User Interface (UI) and the AdWords API reports.
  • Report basics covers how to structure and download reports.
  • This blogpost covers best practices for when to schedule reports, and this post covers how to download reports for multiple clients.
For additional resources visit the AdWords API documentation.

We also encourage you to submit questions to the forum or ask them during office hours.

We would like to once again remind you that after February 29, 2012, calls made using the following AdWords API versions will return errors:
  • AdWords API versions v13, v200909, v201003, v201008, v201101
We strongly encourage you to make the move to v201109 before the February 29th deadline. This will give you the opportunity to identify any issues before it is too late to roll back to previous versions.

In addition, check that you have no automated or scheduled scripts running that are using old code.

To ensure that your code uses only v201109, be sure you are using the latest version of our client libraries.

If you have specific migration questions, you can asking them in upcoming office hours or on the forum. Additional migration resources are available here.

This is a reminder that after February 29, 2012, calls made using the following AdWords API versions will return errors:
  • AdWords API versions v13, v200909, v201003, v201008, v201101
If you would like your applications to run without interruption, you must migrate to AdWords API v201109 by February 29th. Migration resources are available ...
This is a reminder that after February 29, 2012, calls made using the following AdWords API versions will return errors:
  • AdWords API versions v13, v200909, v201003, v201008, v201101
If you would like your applications to run without interruption, you must migrate to AdWords API v201109 by February 29th. Migration resources are available here. In addition, if you have specific questions, we encourage you to attend office hours or post questions to the forum.

On February 29, 2012, we will be sunsetting the following versions and services:
  • AdWords API versions v13, v200909, v201003, v201008, v201101
  • AdWords API version v13 AccountService will only be available on a whitelist basis.
Calls made using these versions will return errors after February 29th. It is therefore critical that you migrate to AdWords API v201109 if you would like your applications to run without interruption.

We encourage you to use the following resources for a successful migration:
Posted by Katie Miller, AdWords API Team

As announced in October, we will sunsetting all versions of the AdWords API prior to v201109 on February 29, 2012. To help you prepare to migrate to v201109, we've created a checklist that covers all of the required changes:

Required Changes:
  • Migrate all API calls to use v201109 services
  • Migrate all API calls to use clientCustomerId (instead of clientEmail) to identify an account as the target of an operation (Blog post)
  • Migrate campaign geo target creation and identification to use the new location criterion object (available through the CampaignCriterionService and the LocationCriterionService)
  • Migrate all other campaign targets (except ad scheduling) from the CampaignTargetService to CampaignCriterionService using the appropriate criterion objects defined within that service*
  • Migrate cross client reporting to v201109 AdHoc (single account) reports (Blog post)
  • Provide developerToken as HTTP header in AdHoc report requests
  • The last few API releases have seen various services migrate to generic selectors, as you update to v201109 you’ll need to migrate from service specific selectors to generic selectors as required. See the Selector Migration Reference for details
  • Update to the very latest version of the AdWords API client library specific to the programming language(s) that you use for API tool/platform development**
  • If you generate your own client side stubs from the API Service WSDLs, make sure that your requests strictly adhere to the WSDL definition as we have implemented stricter validation for the SOAP header and envelope (Blog post)

Optional Changes:

Note: If you do not make the required changes, calls made using versions of the AdWords API prior to v201109 will return errors after February 29th 2012

Additional Notes:
*In v201109, most targets become criteria, with each having it’s own ‘type’ of criterion object (see this Blog post for more details)
**This is an important requirement, so do make sure to check the version of the library or libraries that you are using against those available here



As announced in October 2011, with the release of AdWords API v201109, we will be deprecating the following versions and services:
  • AdWords API versions v13, v200909, v201003, v201008, v201101
  • AdWords API version v13 AccountService will only be available on a whitelist basis.
We will be sunsetting these versions and services in 55 days on February 29, 2012. If you have not started migrating to AdWords API v201109, we strongly encourage you to do so, as calls made using previous versions will return errors after February 29th. In particular, we anticipate that migrating from v13 to AdHoc reporting may take some time. Resources to help with this migration are available here. AdHoc documentation is available here and best practices have been outlined on the blog.

We’ve been running the “Discover v201109” blog series to introduce new services, as well as make the migration process easier for you. Posts include:
To keep up to date with future “Discover v201109” posts, click on the adwords_v201109 label on the Google Ads Developer Blog.

As with every new version of the AdWords API, we encourage you to review the resources in the AdWords API client libraries. If you have any questions please post them on the AdWords API forum. We will also continue to host Google+ Hangouts with members of the AdWords API Developer Relations Team.

Finally, we may send out periodic service announcements via email on the deprecation timeline and resources to migrate to v201109. Please be sure that your contact information is up to date in your My Client Center account. Review this blog post for more details.
 

You might not realize it if you use our client libraries, but at its core the AdWords API is based on SOAP and XML. Crafting a request by hand can be tricky, and even some SOAP toolkits have problems serializing to the correct format. In version v201109 of the API we enabled additional XML validation so that you will now be alerted to structural issues with your requests.

You might not realize it if you use our client libraries, but at its core the AdWords API is based on SOAP and XML. Crafting a request by hand can be tricky, and even some SOAP toolkits have problems serializing to the correct format. In version v201109 of the API we enabled additional XML validation so that you will now be alerted to structural issues with your requests.

The format of the request’s XML payload is specified by an XML Schema definition (XSD) embedded in the WSDL document for the service. The schema describes very precisely the types and elements that can appear in the request. In past versions of the API the server was somewhat lenient in how it processed the incoming XML. For example, it would silently ignore unknown elements. This had the potential to hide problems with your code or cause mysterious behavior.

With enhanced XML validation enabled, the aforementioned errors can be caught earlier, as the request payload must fully match the format in the schema. Below is a sample request and response showing a validation error for an unknown element.

Request

<?xml version="1.0"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <RequestHeader 
      xmlns="https://adwords.google.com/api/adwords/cm/v201109">
      <applicationToken>...</applicationToken>
      <authToken>...</authToken>
      <clientCustomerId>...</clientCustomerId>
      <developerToken>...</developerToken>
      <userAgent>...</userAgent>
    </RequestHeader>
  </soapenv:Header>
  <soapenv:Body>
    <get xmlns="https://adwords.google.com/api/adwords/cm/v201109">
      <serviceSelector>
        <fields>Id</fields>
        <fields>Name</fields>
        <ordering>
          <field>Name</field>
        </ordering>
        <foo>bar</foo>
      </serviceSelector>
    </get>
  </soapenv:Body>
</soapenv:Envelope>

Response

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <soap:Fault>
      <faultcode>soap:Client</faultcode>
      <faultstring>
        Unmarshalling Error: cvc-complex-type.2.4.a: Invalid content 
        was found starting with element 'foo'. One of '{
         "https://adwords.google.com/api/adwords/cm/v201109":ordering, 
         "https://adwords.google.com/api/adwords/cm/v201109":paging
        }' is expected.
      </faultstring>
    </soap:Fault>
  </soap:Body>
</soap:Envelope>

In this case the response is indicating that only the elements "ordering" or "paging" are permitted in this part of the request. Please note that this error is thrown as a raw SOAP fault, and is not wrapped in an ApiError object. There is no need to add special exception handling for these errors, as they are designed to be detected and resolved during the development phase of your application. If they do occur in your production environment you should log them for later analysis.

There are some side effects of using stricter XML validation that you should be aware of:

  • The order of the elements in the request now matters. The XSD lists elements in a sequence, and the order of the elements in the request must match. That same order is reflected in the API’s reference documentation, and our client libraries ensure that it is always respected.
  • Correct element ordering is also required for ad-hoc report download requests.
  • The xsi:type attributes in a request will always be checked and the values must use the correct namespace.

This additional XML validation has been enabled in the sandbox environment for a year and half, so if your application already works there then this change should be transparent. If you have any questions about this or other aspects of the API, you can reach us on the developer forum or during office hours.

This week we released an addition to the v201109 version of the API, enabling one of the most commonly requested uses of the API: account creation. The CreateAccountService creates AdWords accounts without login emails (corresponding to the new optional-login feature available in the AdWords UI).

This week we released an addition to the v201109 version of the API, enabling one of the most commonly requested uses of the API: account creation. The CreateAccountService creates AdWords accounts without login emails (corresponding to the new optional-login feature available in the AdWords UI).

Sample request

Let's dive right into some sample code using the Java client library. Notice that the only required parameters are currency, time zone, and descriptive name:

// Get the CreateAccountService.
CreateAccountServiceInterface createAccountService =
    user.getService(AdWordsService.V201109.CREATE_ACCOUNT_SERVICE);

Account account = new Account();
account.setCurrencyCode("EUR");
account.setDateTimeZone("Europe/London");

CreateAccountOperation operation = new CreateAccountOperation();
operation.setDescriptiveName("Account Created with CAS");
operation.setOperand(account);
operation.setOperator(Operator.ADD);

CreateAccountOperation[] operations = 
    new CreateAccountOperation[] {operation};

Account[] accounts = createAccountService.mutate(operations);

Notes

  • The new accounts will be automatically linked to the MCC account used to make the request.
  • Google accounts (and therefore login emails) are not created by this service; as a consequence, these newly created client accounts are only accessible via your MCC account.
  • Unlike v13 Account objects, these Account objects do not contain any address information.
  • The descriptiveName value is not included in the SOAP response, so make sure to record it elsewhere or retrieve it later using the ServicedAccountService.
  • It's not possible to specify billing information using this service.
  • You can pass more than one operation to the service and create multiple accounts with a single call.

Client libraries

We have a new Java client library available that includes CreateAccountService functionality and example code, and over the next few weeks we’ll be publishing updated libraries in other languages as well.

I hope this blog post will help you use this new feature effectively. As usual, If you have any questions about the AdWords API, check out our developer forum or ask us during our Google+ Hangout Office Hours.