Loading ...
Sorry, an error occurred while loading the content.

PHP issues with Basic Report Service

Expand Messages
  • bradtharris@sbcglobal.net
    PHP does not support a data type of long . Is supports only integer or float (double is an alias of float). The WSDL for basic report service defines the
    Message 1 of 3 , Apr 1, 2009
    • 0 Attachment
      PHP does not support a data type of "long". Is supports only integer or float (double is an alias of float). The WSDL for basic report service defines the Reportid field as a long. Since PHP cannot support "longs", the PHP soap tool converts all "longs" to integers. This works fine until the value of a report ID exceeds the largest value that can fit in an integer. When that happens, the soap tool breaks because it refuses to allow a value larger than the largest value that can fit in an integer even though the field is defined as a long. The field is passed to the web service as a null value. Then a soap fault is returned indicating an invalid report ID.

      Has anyone else run into this? I first saw this when I converted to V5 lst week but I now find that it happens in V4 as well.

      The only thought that I had to solve it is to copy the WSDL to a local url and then change the type from long to string so that a larger value could be passed. I don't know if that will work or not. Does anyone have another idea other than rewriting everything in another language or building all the soap envelopes by hand?

      In any case this is a real hole in the Yahoo interface in terms of claiming to support PHP since many many fields in the WSDL are defined as longs and should any one of them ever contain a value greater than can fit in an integer, there would be a problem.
    • mcnealysm
      ... Hello, What SOAP client you are using? Please see: http://developer.searchmarketing.yahoo.com/docs/V5/sample_code/php.php#issues ... function
      Message 2 of 3 , Apr 6, 2009
      • 0 Attachment
        --- In yws-searchmarketing@yahoogroups.com, "bradtharris@..." <bradtharris@...> wrote:
        >
        > PHP does not support a data type of "long". Is supports only integer or float (double is an alias of float). The WSDL for basic report service defines the Reportid field as a long. Since PHP cannot support "longs", the PHP soap tool converts all "longs" to integers. This works fine until the value of a report ID exceeds the largest value that can fit in an integer. When that happens, the soap tool breaks because it refuses to allow a value larger than the largest value that can fit in an integer even though the field is defined as a long. The field is passed to the web service as a null value. Then a soap fault is returned indicating an invalid report ID.
        >
        > Has anyone else run into this? I first saw this when I converted to V5 lst week but I now find that it happens in V4 as well.
        >
        > The only thought that I had to solve it is to copy the WSDL to a local url and then change the type from long to string so that a larger value could be passed. I don't know if that will work or not. Does anyone have another idea other than rewriting everything in another language or building all the soap envelopes by hand?
        >
        > In any case this is a real hole in the Yahoo interface in terms of claiming to support PHP since many many fields in the WSDL are defined as longs and should any one of them ever contain a value greater than can fit in an integer, there would be a problem.
        >

        Hello,

        What SOAP client you are using? Please see: http://developer.searchmarketing.yahoo.com/docs/V5/sample_code/php.php#issues

        The following sample code works for long ids with mbstring and soap packages :

        --------------------------------------------------------

        function addReportRequestForAccountID($basicReportService, $accountID)
        {
        global $SAMPLE_DATA;

        $now = time();

        $reportRequest = createReportRequest(
        "Last30Days", /* dateRange */
        NULL,
        "MyReport",
        "AccountSummary", /* Report Type */
        NULL
        );

        debug("Calling addReportRequestForAccountID");

        $retObj = execute($basicReportService,
        'addReportRequestForAccountID',
        array( 'accountID' => $accountID, 'reportRequest' => $reportRequest )
        );

        checkResponse($retObj);
        debug("------> Report ID: [".$retObj->out ."]");

        debug("Calling addReportRequestForAccountID");
        return $retObj->out;
        }

        function getReportDownloadURL($basicReportService, $reportID)
        {
        $retObj = execute($basicReportService,
        'getReportOutputUrl',
        array( 'reportID' => $reportID, 'fileFormat' => array( 'fileOutputType' => 'CSV', 'zipped' => true))
        );

        checkResponse($retObj);
        debug("------> Report Status/URL: [" . $retObj->out ."]");
        return $retObj->out;
        }

        --------------------------------------------------------
      • Tim Hawkins
        I ran into the same issue, the samples seem to work on the sandbox, and in some cases, but as soon you put it into a real world system it fails, its not just
        Message 3 of 3 , Jun 12, 2009
        • 0 Attachment
          I ran into the same issue, the samples seem to work on the sandbox, and in some cases, but as soon you put it into a real world system it fails, its not just reoprtID's, in fact any ID if it exceeds 11 digits gets truncated to PHP_MAX_INT. I suspect that the sandbox is consistently returning shorter ID's due to the significantly lower volume of ID churn.

          The problem lies in the php_soap extension, when using the wsdl file. We found that switching the the nusoap library, fixed the issue as it binds any integer type that is greater than 32bits to a string. But the sample PHP client exhibits the same problem


          --- In yws-searchmarketing@yahoogroups.com, "mcnealysm" <mcnealysm@...> wrote:
          >
          > --- In yws-searchmarketing@yahoogroups.com, "bradtharris@" <bradtharris@> wrote:
          > >
          > > PHP does not support a data type of "long". Is supports only integer or float (double is an alias of float). The WSDL for basic report service defines the Reportid field as a long. Since PHP cannot support "longs", the PHP soap tool converts all "longs" to integers. This works fine until the value of a report ID exceeds the largest value that can fit in an integer. When that happens, the soap tool breaks because it refuses to allow a value larger than the largest value that can fit in an integer even though the field is defined as a long. The field is passed to the web service as a null value. Then a soap fault is returned indicating an invalid report ID.
          > >
          > > Has anyone else run into this? I first saw this when I converted to V5 lst week but I now find that it happens in V4 as well.
          > >
          > > The only thought that I had to solve it is to copy the WSDL to a local url and then change the type from long to string so that a larger value could be passed. I don't know if that will work or not. Does anyone have another idea other than rewriting everything in another language or building all the soap envelopes by hand?
          > >
          > > In any case this is a real hole in the Yahoo interface in terms of claiming to support PHP since many many fields in the WSDL are defined as longs and should any one of them ever contain a value greater than can fit in an integer, there would be a problem.
          > >
          >
          > Hello,
          >
          > What SOAP client you are using? Please see: http://developer.searchmarketing.yahoo.com/docs/V5/sample_code/php.php#issues
          >
          > The following sample code works for long ids with mbstring and soap packages :
          >
          > --------------------------------------------------------
          >
          > function addReportRequestForAccountID($basicReportService, $accountID)
          > {
          > global $SAMPLE_DATA;
          >
          > $now = time();
          >
          > $reportRequest = createReportRequest(
          > "Last30Days", /* dateRange */
          > NULL,
          > "MyReport",
          > "AccountSummary", /* Report Type */
          > NULL
          > );
          >
          > debug("Calling addReportRequestForAccountID");
          >
          > $retObj = execute($basicReportService,
          > 'addReportRequestForAccountID',
          > array( 'accountID' => $accountID, 'reportRequest' => $reportRequest )
          > );
          >
          > checkResponse($retObj);
          > debug("------> Report ID: [".$retObj->out ."]");
          >
          > debug("Calling addReportRequestForAccountID");
          > return $retObj->out;
          > }
          >
          > function getReportDownloadURL($basicReportService, $reportID)
          > {
          > $retObj = execute($basicReportService,
          > 'getReportOutputUrl',
          > array( 'reportID' => $reportID, 'fileFormat' => array( 'fileOutputType' => 'CSV', 'zipped' => true))
          > );
          >
          > checkResponse($retObj);
          > debug("------> Report Status/URL: [" . $retObj->out ."]");
          > return $retObj->out;
          > }
          >
          > --------------------------------------------------------
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.