I'm trying to figure out why my GetOrders function for the eBay API isn't working. Below are the headers I'm passing (this is in Perl):
$objHeader->push_header('X-EBAY-API-COMPATIBILITY-LEVEL' => $compatabilityLevel);
$objHeader->push_header('X-EBAY-API-DEV-NAME' => $devID);
$objHeader->push_header('X-EBAY-API-APP-NAME' => $appID);
$objHeader->push_header('X-EBAY-API-CERT-NAME' => $certID);
$objHeader->push_header('X-EBAY-API-CALL-NAME' => 'GetOrders');
$objHeader->push_header('X-EBAY-API-SITEID' => '3');
$objHeader->push_header('Content-Type' => 'text/xml');
...and the XML I'm passing is as follows:
<?xml version="1.0" encoding="utf-8" ?>
<GetOrdersRequest xmlns="urn:ebay:apis:eBLBaseComponents">
<DetailLevel>ReturnAll</DetailLevel>
<NumberOfDays>3</NumberOfDays>
<OrderRole>Seller</OrderRole><OrderStatus>Active</OrderStatus>
<RequesterCredentials><eBayAuthToken>$userToken</eBayAuthToken></RequesterCredentials>
</GetOrdersRequest>
(obviously $userToken is replaced with my actual user token)
I get a return from it:
$VAR1 = {
'xmlns' => 'urn:ebay:apis:eBLBaseComponents',
'Build' => 'E929_CORE_APIXO_17568878_R1',
'PageNumber' => '1',
'PaginationResult' => {
'TotalNumberOfPages' => '0',
'TotalNumberOfEntries' => '0'
},
'OrderArray' => {},
'Ack' => 'Success',
'HasMoreOrders' => 'false',
'Timestamp' => '2015-06-29T09:49:25.963Z',
'Version' => '929',
'ReturnedOrderCountActual' => '0',
'OrdersPerPage' => '100'
};
..but as you can see, no results. I know for a fact there are results (I've had it working with the PHP API already using the same kind of values as far as I can tell). Worst case scenario, I could create a basic PHP script to grab the results, and then pipe into the Perl script. Obviously this isn't ideal though (I would much prefer to have it all in one programming language)
Anyone got any ideas? I'm drawing a blank on it :/
Ok, I knew this would happen. 2 days of battling with this, and then as soon as I post something - I find the solution :)
The issue was that I was passing the following in the XML:
<OrderStatus>Active</OrderStatus>
It in fact needed to be:
<OrderStatus>Completed</OrderStatus>
That is now grabbing them perfectly :)
Related
I know this is a very old Perl module (5 or so years ago since the last update). I've found it useful for a project I'm doing though, that needs to be in Perl. Rather than starting from the bottom up, I've found this helpful to do the basics. I've already fixed up a few bugs with it - but this one I can't figure out
The module in question is: https://github.com/simoncozens/Net-KashFlow
An example usage with the problem is:
my $kf = Net::KashFlow->new(username => q|foo#bar.com|, password => "xxxx" );
my $i = $kf->create_invoice({
CustomerReference => "0123-1111111", CustomerID => 50108952,
CurrencyCode => "EUR"
}) || die $!;
$i->add_line({
Quantity => 1,
Description => "íéó foo bar test",
Rate => 10,
VatAmount => 4,
VatRate => 0,
CurrencyCode => "GBP"
});
This item gets added, but the "Description" value gets converted to:
7enzIGZvbyBiYXIgdGVzdA==
If you use normal a-z 0-9 it works fine (and shows correctly). The issue seems to be that its encoding into base64, and then not being decoded correctly at the other end. My guess is that KashFlow are not going to "fix" this, so it really needs to be done this end. I'm not really familiar with the SOAP::Lite module (again, a pretty old module it seems!), but that's what it uses.
This is the part I think that deals with adding a new "line" to the invoice:
InsertInvoiceLine => {
endpoint => 'https://securedwebapp.com/api/service.asmx',
soapaction => 'KashFlow/InsertInvoiceLine',
namespace => 'KashFlow',
parameters => [
SOAP::Data->new(name => 'UserName', type => 'xsd:string', attr => {}),
SOAP::Data->new(name => 'Password', type => 'xsd:string', attr => {}),
SOAP::Data->new(name => 'InvoiceID', type => 'xsd:int', attr => {}),
SOAP::Data->new(name => 'InvLine', type => 'tns:InvoiceLine', attr => {}),=> {})
], # end parameters
}, # end InsertInvoiceLine
You can see the structure here:
https://securedwebapp.com/api/service.asmx?op=InsertInvoiceLine
After researching this, it was suggested that you tell SOAP::Lite to not convert utf8 into base64, using (I assume), something like:
The structure is:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<InsertInvoiceLine xmlns="KashFlow">
<UserName>string</UserName>
<Password>string</Password>
<InvoiceID>int</InvoiceID>
<InvLine>
<Quantity>decimal</Quantity>
<Description>string</Description>
<Rate>decimal</Rate>
<ChargeType>int</ChargeType>
<VatRate>decimal</VatRate>
<VatAmount>decimal</VatAmount>
<ProductID>int</ProductID>
<Sort>int</Sort>
<ProjID>int</ProjID>
<LineID>int</LineID>
<ValuesInCurrency>integer</ValuesInCurrency>
</InvLine>
</InsertInvoiceLine>
</soap:Body>
</soap:Envelope>
So looks like its Body > InsertInvoiceLine > InvLine > Description .. but I'm unsure how I can tell it not to encode that particular string.
Any advise would be much appreciated. While its not a major show stopper (as all the data is in the system), it would be much nicer/easier to see the item names as expected :)
Thanks!
I think this is probably SOAP::Lite deciding to convert things to base64 when it thinks they aren't a particular subset of ASCII. You'll find this heuristic in SOAP/Lite.pm in SOAP::Serializer:
$self->typelookup({
'base64Binary' =>
[10, sub {$_[0] =~ /[^\x09\x0a\x0d\x20-\x7f]/ }, 'as_base64Binary'],
'zerostring' =>
[12, sub { $_[0] =~ /^0\d+$/ }, 'as_string'],
... many other types ...
'string' =>
[100, sub {1}, 'as_string'],
});
This comes into play when SOAP::Lite doesn't know an object's type because no one has told it. I'm guessing that in the bowels of your program it's serializing Description and typelookup sticks its dirty mitts in.
And from here you are on your own because SOAP::Lite is no fun. I would start by hacking on SOAP::Lite a bit to see what you can trace. Copy the SOAP/Lite.pm file somewhere and put that location in your #INC. That way you don't mess around with the original file.
If you never want the base64, it might be as simple as deleting that line in typelookup, although declaring the Description type would be more proper (but also a rabbit's hole of work, potentially). The fast fix can stand in while you work on the right fix.
There's also the Perlmonk's meditation How to convince SOAP::Lite to return UTF-8 data in responses as UTF-8?.
Can someone provide a sample code chunk of php using the sugarcrm API/nusoap for adding creating an acct. and then linking a lead to the acct?
I've got a sample function that adds a lead, and I can see how to create an acct, but I can't see how to tie a lead to the acct, to simulate the subpanel process in the sugarcrm acct/subpanel process.
thanks
// Create a new Lead, return the SOAP result
function createLead($data)
{
// Parse the data and store it into a name/value list
// which will then pe passed on to Sugar via SOAP
$name_value_list = array();
foreach($data as $key => $value)
array_push($name_value_list, array('name' => $key, 'value' => $value));
// Fire the set_entry call to the Leads module
$result = $this->soap->call('set_entry', array(
'session' => $this->session,
'module_name' => 'Leads',
'name_value_list' => $name_value_list
));
return $result;
}
$result = $sugar->createLead(array(
'lead_source' => 'Web Site',
'lead_source_description' => 'Inquiry form on the website',
'lead_status' => 'New',
'first_name' => $_POST['first_name'],
'last_name' => $_POST['last_name'],
'email1' => $_POST['email'],
'description' => $_POST['message']
));
You need to find the ID for the account and assign that ID to whatever the account_id field name is in the Lead Module. I have run into a couple things like this before and I have found it easier to go straight to the Sugar database. So, write a statement that will return the account is, for example: SELECT id WHERE something_in_the_account_table = something else;
Then you can assign that id in your $result array. I hope it helps. I didn't have any code or documentation in front of me or I would have helped more.
I have a weird problem where I want to store products from my shop in a session. This works well, except for some products. The shop is part of a cms where all products are rendered the same way. When someone adds a product to the shop this will be serialized and send with ajax to a script.
Almost all items are stored, but for some reason some items don't get stored. I can't find a connection or anything and I don't get any errors returned.
So this is the code that stores the product in a session:
$storeItemNumber = (string)$post['itemcode'];
$storeItem = array($storeItemNumber => array(
'title' => $post['title'],
'price' => $post['price'],
'quantity' => $post['quantity']
)
);
$shopSession->$storeItemNumber = $storeItem;
This is an example of a product that gets stored:
array('010101000' => array(
'title' => 'Product title - 15',
'price' => '28.95',
'quantity' => '1',
));
This is an example of a product that doesn't get stored:
array('400002001' => array(
'title' => 'Product title - Pink',
'price' => '5.50',
'quantity' => '1',
));
I already checked if the data gets through alright and it does right until the saving of it in a session.
What could possibly be a reason?
Had a look with a friend of mine and we both concluded it had something to do with the numbers. So I changed the function to the following and Now I'm able to add all the products without a problem.
I'll leave this question open for the time being, because I'm really curious why some numbers are stored and others not and what is a better/cleaner solution then mine.
I'm making a Drupal/PHP Module to upload information to Taleo (Talent Management) database using SOAP. This works well with regular data like text and dates, but not with a file.
The manual shows an example of a file attachment:
createAttachment Test Case:
<soapenv:Header/>
<soapenv:Body>
<urn:createAttachment>
<in0>webapi-5616904436472928038</in0>
<in1>15</in1>
<in2>test1.docx</in2>
<in3>test1.docx</in3>
<in4>application/vnd.openxmlformatsofficedocument.
wordprocessingml.document</in4>
<in5>
<!--type: base64Binary-->
<array>JVBERi0xLjQNJeLjz9MNCjYgMCBvYmogPDwvTGluZWFyaX==</array>
</in5>
</urn:createAttachment>
</soapenv:Body>
</soapenv:Envelope>
So I made a PHP file like this:
// Send attachment
$fileName = drupal_get_path('module', 'taleo') . '/test.txt';
$rawFile = fread(fopen($fileName, "r"), filesize($fileName));
$B64File = base64_encode($rawFile);
$params = array(
'in0' => $session,
'in1' => $candidate_id,
'in2' => 'test.txt',
'in3' => 'test.txt',
'in4' => 'text/plain',
'in5' => $B64File
);
$client_taleo->__call('createAttachment', $params);
When I do "echo $B64File" I get this: RmlsZSB1cGxvYWQgd2l0aCBEcnVwYWwgIQ==, so the file is being read correct.
But I always get this error:
ERROR: soapenv:Server.generalException-attBinDataArr is null.
Any ideas?
You forgot to encapsulate the base64-data in array-tags.
<array>JVBERi0xLjQNJeLjz9MNCjYgMCBvYmogPDwvTGluZWFyaX==</array>
Something like this should work:
$params = array(
'in0' => $session,
'in1' => $candidate_id,
'in2' => 'test.txt',
'in3' => 'test.txt',
'in4' => 'text/plain',
'in5' => array('array' => $B64File)
);
It was clear I had to do something with the array-tag, that's for sure.
The answer above deserves an "upvote", so I gave it one. But I found the correct answer myself... After a few seconds of "logic" thinking. :)
'in5' => array('array' => $B64File)
I updated my Savon version to 0.9.6 and my server requests seem to be malforming. Before the update, I was using Savon 0.9.2.
I have a similar problem as someone mentioned in the post below, however, it differs in that the repeated items include full objects. I've tried using arrays, with no luck.
Savon: How can I specify a custom XML in a hash body for a SOAP request?
The requests are built this way:
#Address object
address = {
'AddressCode' => 'Dest',
'Line1' => '1234 Anywhere Street',
'City' => 'Anywhere',
'Region' => 'Somewhere',
'PostalCode' => '12345',
'Country' => 'USA'
}
#Building the request
request = {"Request" => {
'CompanyCode' => 'DEFAULT',
'DocType' => 'Word',
'Addresses' => {'BaseAddress' => [address]}
}}
0.9.6 (Broken) Request portion
<ser:Request>
<ser:CompanyCode>DEFAULT</ser:CompanyCode>
<ser:DocType>Word</ser:DocType>
<ser:Addresses>
<ins0:Addresses>
<ins0:BaseAddress>AddressCodeDestLine11234 Anywhere StreetCityAnywhere RegionSomewherePostalCode12345CountryUS</ins0:BaseAddress>
</ser:Addresses>
</ser:Request>
0.9.2 (Working) Request portion
<ser:Request>
<ser:CompanyCode>DEFAULT</ser:CompanyCode>
<ser:DocType>Word</ser:DocType>
<ser:Addresses>
<ser:BaseAddress>
<ser:AddressCode>Dest</ser:AddressCode>
<ser:Line1>1234 Anywhere Street</ser:Line1>
<ser:City>Anywhere</ser:City>
<ser:Region>Somewhere</ser:Region>
<ser:PostalCode>12345</ser:PostalCode>
<ser:Country>US</ser:Country>
</ser:BaseAddress>
</ser:Addresses>
</ser:Request>
Does anyone have any ideas?
I would really appreciate any advice you are willing to offer.
Thank you!