Unmarshalling Error

[vtsao]

I'm getting this error:

Fatal error: Uncaught SoapFault exception: [soap:Client] Unmarshalling Error: cvc-type.2: The type definition cannot be abstract for element ns1:searchParameters. in src/Google/Api/Ads/Common/Lib/AdsSoapClient.php:200

OS: Linux (Debian)
PHP: 5.2.6-1+lenny16
libxml: 2.6.32
API: v201302
Library: 4.2.1
Apr 2, 2013 Delete comment Project Member #1 api.pmatthews
Hi Davis,

It seems likely that you're getting this issue as $addXsiTypes is set to false, in the AdsSoapClient.php:

https://code.google.com/p/google-api-adwords-php/source/browse/src/Google/Api/Ads/Common/Lib/AdsSoapClient.php

Could you confirm that you no longer see errors if you set $addXsiType to true. To implement this, simply add the following line, at line 404:
$addXsiTypes = TRUE;

Cheers,

• Paul, AdWords API Team.
  Status: MoreInfoNeeded
  Apr 3, 2013 Delete comment Adding XSI type to SOAP request needs to support parsing PHP version labels for PHP installations bundled with Ubuntu. #2 couponchiefs
  I was seeing the same error (Unmarshalling Error: cvc-type.2).

OS: Linux
PHP 5.2.6
Library: 4.2.1
API: v201302

I can confirm that setting $addXsiType to true in AdsSoapClient fixes the issues. Previously the xsi types were not getting added to the XML. Once they were added, everything worked fine.
Apr 3, 2013 Delete comment #3 couponchiefs
Unfortunately, when I manually set "$addXsiTypes = TRUE;", while some of the previous failed API calls now work, it now brings back the previous error that was supposed to be fixed with this release:
"Unmarshalling Error: cvc-elt.4.2: Cannot resolve 'Selector' to a type definition for element 'ns1:serviceSelector'."
For example, this error now shows up when running the GetKeywords script.

OS: Linux
PHP 5.2.6
Library: 4.2.1
API: v201302

Apr 4, 2013 Delete comment #4 davis.fridenvalds
If I set $addXsiType to TRUE as Paul suggested, I get another error:

Fatal error: Uncaught SoapFault exception: [soap:Client] Unmarshalling Error: cvc-elt.4.2: Cannot resolve 'Paging' to a type definition for element 'ns1:paging'.

OS: Linux (Debian)
PHP: 5.2.6-1+lenny16
libxml: 2.6.32
API: v201302
Library: 4.2.1
Apr 4, 2013 Delete comment Project Member #5 api.pmatthews
Thanks for the additional info there Davis.

Can you tell me, what was the last working version of the API for you? And does it still work?

Cheers,

Paul.
Apr 4, 2013 Delete comment #6 davis.fridenvalds
The last working API version was v201206.
Apr 11, 2013 Delete comment #8 velimira
aving the same issue with
PHP Version 5.2.6-1+lenny10
libxml: 2.6.32
API: v201302
adx_api_php_lib_4.2.2

v201209 was working fine
Apr 11, 2013 Delete comment #9 davis.fridenvalds
We couldn't wait any longer and upgraded our PHP to 5.3.3-7+squeeze15 and now it is working fine.
Apr 11, 2013 Delete comment #10 kmhoggatt
The workaround I found for this issue is this:

1. Set "$addXsiTypes = TRUE;" on AdsSoapClient.php line 404.
2. Update all of the getXsiTypeName() functions in each of the classes defined in /Util/ReportUtils.php to return a blank string. For example, in the Paging class definition, modify the function getXsiTypeName() to 'return "";' instead of 'return "Paging";'. Do the same for Selector class, Predicate class, etc.

After doing this, lib version 4.2.2 works fine with PHP 5.2.6 and v201302.
Apr 12, 2013 Delete comment #11 velimira
Thanks, this worked
Jul 22, 2013 Delete comment #12 steve962
I ran into the same exact issue with lib version 4.4.0. The solution presented in comment #10, editing the ReportUtils.php module to change all the getXsiTypeName() calls to return empty strings worked for me, even though it meant changing the library, something I really hate to do. (But was necessary to get us updated so we were running again.)

PHP Version 5.2.4-2ubuntu5.17
libxml version: 2.6.31
API: v201306
adwords_api_php_4.4.0

We were upgrading from API v201209 using lib 3.2.1, which worked fine.

Sep 26, 2013 Delete comment Project Member #13 api.pmatthews
We'll look into making this value configurable from the settings.ini

Regards,

• Paul, AdWords API Team.

[sixtycent]

Have the problem with Adwords v201309 + v201306

The solution from #10 doesn`t work.

php: 5.3.1
libxml Version 2.7.6
googleads-php-lib v5.1.0.

Fatal error: Uncaught SoapFault exception: [soap:Client] Unmarshalling Error: For input string: "DAILY" ... googleads-php-lib-master\src\Google\Api\Ads\Common\Lib\AdsSoapClient.php on line 216

[tenitski]

That example is out of date
You need to use something like
$campaign->budget = new \Budget('123', 'default budget', 'DAILY', new \Money(10000), 'STANDARD');
rather then
$campaign->budget = new \Budget('DAILY', new \Money(10000), 'STANDARD');
as in example code.

See the docs here
https://developers.google.com/adwords/api/docs/reference/v201309/BudgetService.Budget

[steve962]

I can confirm this problem still exists. The solution for #10 worked to fix it, as it did for previous versions. Between this issue and the api.properties parsing problem, it's getting really difficult to upgrade library versions - I'm basically only doing it when absolutely forced to by an API sunset.

Adwords PHP library: 5.2.1
Adwords API: v201402
OS: Ubuntu 2.6.24
PHP Version 5.2.4-2ubuntu5.17.
Libxml: 2.6.31

-->Steve Bennett

[saturnism]

@steve962 it would be highly recommended to upgrade PHP 5.2. PHP 5.2 has been out of support for more than 3 years now.

Different PHP versions seems to require different addXsiType settings - it could be good to make this setting configurable.

[khoggatt]

I'm going to repeat the same comment that steve962 just made. I'm trying to upgrade to v201402, and I still see the same problem I faced exactly a year ago.
The same hack that I submitted last year, still works to resolve the issue:

1. Insert "$addXsiTypes = TRUE;" on /Ads/Common/Lib/AdsSoapClient.php, line 420.
2. Update all of the getXsiTypeName() functions in each of the classes defined in Ads/Adwords/Util/ReportUtils.php to return a blank string. For example, in the Paging class definition, modify the function getXsiTypeName() to 'return "";' instead of 'return "Paging";'. Do the same for Selector class, Predicate class, etc.

OS: Linux
PHP: 5.2.6
Adwords Client Library: 5.2.2
API: v201402

[steve962]

I'll add to @saturnism that, unfortunately, it's not always possible to control the PHP version we're using. For a variety of reasons, we're running this on a server we cannot easily upgrade PHP on right now. We have plans to eventually migrate everything off that server, but they're low priority compared to a lot of other things on our plate. (It's enough of a scheduling nightmare as it is, dealing with the way-too-often-every-8-months necessity of migrating to another PHP library and API version that Google has been forcing on us in recent years...)

[saturnism]

duplicate #2

[saturnism]

@steve962 I noticed that you are setting addXsiTypes to true, and then essentially removing all Xsi Type Names. Could I trouble you to confirm that, if you can force addXsiType = FALSE, do you still get the same errors?

Thanks,

[khoggatt]

@saturnism If you leave addXsiTypes set to FALSE (as the code does by default with this PHP version), then SOME of the API calls succeed, but other ones fail. Depending on which functions you're using, you'll eventually run into an error similar to the one that started this thread in the first place:
"Fatal error: Uncaught SoapFault exception: [soap:Client] Unmarshalling Error: cvc-type.2: The type definition cannot be abstract for element ns1:searchParameters. in src/Google/Api/Ads/Common/Lib/AdsSoapClient.php".

If you modify the code, and force addXsiTypes to True, then some of the previously failed operations are now successful, but other functions which originally were successful (for example GetKeywords operation), now provide a slightly different error: ""Unmarshalling Error: cvc-elt.4.2: Cannot resolve 'Selector' to a type definition for element 'ns1:serviceSelector'."

Note that the only solution I've found to work is to set addXsiTypes to true, and then remove SOME of the Xsi Type names (specifically those from ReportUtils.php). We're not removing all of them, as you suggested.

Based on this info, it seems that, at least for some of the earlier versions of PHP (i.e. 5.2), some of the XsiTypeNames are needed, and some have to be omitted in order for the library to work properly.

-Kyle