I'm trying to upload a file to SharePoint programmatically via a Mac Application that I am currently writing. I can use the GetListItems webservice to retrieve a list of files, and all authentication etc works correctly. I form the SOAP message myself as follows:
At first I thought I just had the Objective C side written incorrectly, but I've been using the HTTP request extension for Firefox, 'Poster', and still can't get it to work.
The soap message in Poster that I construct 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>
<CopyIntoItems xmlns="http://schemas.microsoft.com/sharepoint/soap/">
<SourceUrl>http://null</SourceUrl>
<DestinationUrls>
<string>myurl.com/Shared Documents/Documents/TestingFile.txt</string>
</DestinationUrls>
<Stream>VGVzdGluZyB0ZXN0aW5n</Stream>
</CopyIntoItems>
</soap:Body>
</soap:Envelope>
The stream (at the moment) is just some data, to see if I can get it to work. I read that setting the SourceUrl as http://null, can help in some instances. I also read that the DestinationURL needs to be the full path. The problem here is:
1) If I put the URL without https:// then I get a response of:
<?xml version="1.0" encoding="utf-8"?><soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><CopyIntoItemsResponse
xmlns="http://schemas.microsoft.com/sharepoint/soap/">
<CopyIntoItemsResult>0</CopyIntoItemsResult><Results><CopyResult ErrorCode="Success"
DestinationUrl="myurl.com/Shared Documents/Documents/TestingFile.txt" /></Results>
</CopyIntoItemsResponse></soap:Body></soap:Envelope>
2) If I put the full path, e.g.
https://myurl.com/Shared Documents/Documents/TestingFile.txt
then the result tells me the same as before, except for this bit:
<CopyResult ErrorCode="Unknown" ErrorMessage="Object reference not set to an instance of an
object."
DestinationUrl="https://dbp.btfinancialgroup.com/Shared%20Documents/Papers/TestingFile.txt"
/>
3) If I put the full path, in quotes, e.g.
"https://myurl.com/Shared Documents/Documents/TestingFile.txt"
then the results tell me the same as the first, e.g. that it was successful, but with
a destinationURL of this:
DestinationUrl=""https://dbp.btfinancialgroup.com/Shared
Documents/Papers/TestingFile.txt""
In ALL of these scenarios, the file does not exist in the destination at the end of the request.
I'm really stuck, as most online suggestions are for remedying C# problems, which use the .net protocols for connecting to SharePoint.
Any suggestions?
Thanks
To assist in anyone else who may come across this problem.
It turned out not to be an issue with my code at all, which I established by making a C# project to try and use the better connectivity it provides to SharePoint, and also spoke to someone in Microsoft Support who confirmed my code should work.
In the end, it was incorrect mappings on the server, which meant the web service never linked correctly to the URLs. This caused the "Object reference not set to an instance of an object" error.
To anyone else receiving this error message, it may not lie just in a problem with the values you are passing to the web service - also check the mappings set up on the server. Apparently the ULS logs may help with this, the Microsoft support guy mentioned, in terms of narrowing down what's causing it.
Related
Even though I'm setting Compavility version in request header (967), when I'm making a call (GeteBayDetails in that case), the response comes with version higher than I need and want (979). These applies to both app I'm currently developing and even API Test Tool. Is there something that I'm missing? Or the Version tag in response isn't related to Compability Level?
Header:
X-EBAY-API-SITEID:212
X-EBAY-API-COMPATIBILITY-LEVEL:967
X-EBAY-API-CALL-NAME:GeteBayDetails
Body:
<?xml version="1.0" encoding="utf-8"?>
<GeteBayDetailsRequest xmlns="urn:ebay:apis:eBLBaseComponents">
<RequesterCredentials>
<eBayAuthToken>...</eBayAuthToken>
</RequesterCredentials>
</GeteBayDetailsRequest>
And the response:
<?xml version="1.0" encoding="UTF-8"?>
<GeteBayDetailsResponse
xmlns="urn:ebay:apis:eBLBaseComponents">
<Timestamp>2016-09-27T11:21:41.341Z</Timestamp>
<Ack>Failure</Ack>
<Errors>
<ShortMessage>Nieznany błąd.</ShortMessage>
<LongMessage>Nieznany błąd.</LongMessage>
<ErrorCode>17460</ErrorCode>
<SeverityCode>Error</SeverityCode>
<ErrorClassification>RequestError</ErrorClassification>
</Errors>
<Version>979</Version>
<Build>E979_INTL_API_18061441_R1</Build>
</GeteBayDetailsResponse>
PS. As far as I know, request fails because of the newer version of the API. And worked before like a charm. Thats why I want to stick to 967.
What you are seeing is normal behavior in that the response will always contain the most recent API schema that could service your request. I encounter many calls for which there are no applicable execution differences between the requested schema and the performing schema, for a given particular request. Also this returning "latest schema version that could service the API request" behavior is how you can determine if you can move up your compatibility level safely, as support drops off periodically.
Of course when the response has a lower schema than the latest in the release notes for the API, then you know you are in a situation where at some point you have to change your code to reflect what has been deprecated or changed before the support for the last schema that can service your particular request ends.
This eBay DTS article mentions this Information in the API Response
as well as going over the eBay API schema versioning process.
Also, be sure on XML POST requests to specify the API schema version in the request itself using the Version tag, not just the HTTP header as with the example call code for the GeteBayDetails API documentation:
<?xml version="1.0" encoding="utf-8"?>
<GeteBayDetailsRequest xmlns="urn:ebay:apis:eBLBaseComponents">
<!-- Call-specific Input Fields -->
<DetailName> DetailNameCodeType </DetailName>
<!-- ... more DetailName values allowed here ... -->
<!-- Standard Input Fields -->
<ErrorLanguage> string </ErrorLanguage>
<MessageID> string </MessageID>
<Version> string </Version>
<WarningLevel> WarningLevelCodeType </WarningLevel>
</GeteBayDetailsRequest>
Hope this helps
I have a web service project containing 3 web services (which require no input parameters) but which I need to schedule to be called once every night. To achieve this I have done some Googling and created a console application to call the web services, which I should now be able to schedule with Windows Task Scheduler.
I am a total novice at writing console apps and have only a tiny bit of experience with VB.NET, but I achieved what I needed in the console app by entering a web reference to the web service, then applying the following simple code:
Sub Main()
Dim wscall As New EmployeeEmailWS
wscall.UpdateAbsenceTables()
wscall.GetThreePeriodsInAYear()
wscall.GetSixDaysInAYear()
End Sub
This simply triggers the three web services to run successfully.
However, having got this far, I would really like also to somehow read in the Soap web service response so that I can write it into a database as a log of each result.
The response message is as simple as the following (from SoapUI), but I just don't know how to obtain it:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<UpdateAbsenceTablesResponse xmlns="http://www.ernspnamespace7.co.uk/EmployeeWS">
<UpdateAbsenceTablesResult>
<ResponseCode>00001</ResponseCode>
<ResponseDescription>Absence Tables Successfully Updated</ResponseDescription>
</UpdateAbsenceTablesResult>
</UpdateAbsenceTablesResponse>
</soap:Body>
</soap:Envelope>
Can anybody please point me in the right direction for how to obtain this response into my console app. Particularly if I could somehow get the values of ResponseCode & ResponseDescription and convert them into Strings then I would be back in familiar territory for my basic knowledge.
Thanks.
Never mind.
It suddenly occurred to me that I could just add some code to the end of the web services to write their output to a database table every time they are called. That avoided the need to bother with the XML altogether.
I am creating a REST web service that returns XML documents by serializing .NET objects using the DataContractSerializer. It works very nicely returning documents like:
<?xml version="1.0" encoding="utf8" ?>
<patient xmlns="http://stackoverflow.com/example">
.....
</patient>
by using code like this:
Message MyRestMethod()
{
Patient patientObject = new Patient() {Name="Mickey Mouse"};
Message message = WebOperationContext.Current.CreateXmlResponse<Patient>(patientObject);
return message;
}
However sometimes, the web service is used by a web browser, and so it would be much nicer if it would return documents like this:
<?xml version="1.0" encoding="utf8" ?>
<?xml-stylesheet type="text/xsl" href="/stylesheet/format.xsl" ?>
<patient xmlns="http://stackoverflow.com/example">
.....
</patient>
I have done some substantial digging around, and can almost do it by deriving my own message and overiding OnWriteBodyContents() to get access to the XmlDictionaryWriter. At this point, I then discovered that WriteProcessingInstruction(name, text) not able to write xml-stylesheet instructions.
More importantly, WCF client code receiving an xml-stylesheet processing instruction also bombs out, so even if you "hack" the stream at the character level to add it, it would need not to be sent to WCF clients...
If anyone has a better suggestion, please let me know...
Having dome some substantial reading on this, the answer is that it is not sensible to add an xml-stylesheet marker in the XML being returned to the WCF client.
The markers are processing instructions, which instruct the interpreter to process the XML document in a certain way. In this particular case by applying an XSLT to the document. the WCF serialisation and deserialiser both reject XML with stylesheet processing instructions, which makes sense - as in the WCF client case you do not want the processing instruction to be followed.
However, for my usecase, having the stylesheet processing instruction in when the xml is returned to a browser does make sense, so I have solved my problem by doing a conditional serialisation based on the UserAgent in the request, and in the case of it not being the WCF client application, I am adding the stylesheet to the stream thats used to create the response message.
In such case you are most probably going to to custom message encoder because xml declaration is added by message encoder and it doesn't provide any features to add any other directives.
We have a custom exception handling behaviour (implementing IErrorHandler) in our solution which essentially uses Automapper to convert exceptions to faults.
This has been working well since day 1. However we have just noticed while browsing ServiceTraceViewer (looking at server logs - not client) on our shared development server that any faults returned from our services omit the detail element.
Running exactly the same code and configuration on my development machine, the detail element is correctly populated. As I say configuration files (behaviours, bindings) are identical on both machines. Both configurations do specify includeExceptiondetailsInFaults = true.
I've also added a bunch of log statements that seem to indicate that the same code path is followed on both machines with the same values for various things like fault code, fault reason etc.
My dev machine is 2008R2 standard (64bit). The server in question is also 2008R2 Standard (64 bit).
I can post extracts of the code if required, but in the first instance is there anything environmental that could allow for what we're seeing?
Extract from problem file:
<s:Body u:Id="_1">
<s:Fault>
<s:Code>
<s:Value>s:Sender</s:Value>
</s:Code>
<s:Reason>
<s:Text xml:lang="en-NZ">An error occured during the request to the ...</s:Text>
</s:Reason>
</s:Fault>
</s:Body>
Not 100% sure about etiquette here. This is an answer I guess to my specific brand of stupidity. Maybe somebody else will be as stupid, then the answer applies to them...
I was sure I had compared everything (I stated exactly the same code / configuration). But the behaviour configuration file I just gave a quick visual. After another developer approached me I realised that the local files were NOT the same as the server files. Doh!
In fact the server files had one extra line added by a post build step - triggering another custom behaviour which implemented IErrorHandler in addition to the IErrorHandler behaviour we already use for logging etc.
I guess I'm going to open another question now which seeks an answer to the approach on having multiple behaviours implementing the same interface and not polluting eachothers functionality (like returning Faults).
I am developing eBay manager that is almost completed. Everything is running fine, like posting of data, getting order details from eBay.
Now I need to update the status of Shipping Tracking numbers, Carrier on eBay. Here I am getting error and I can't figured out what is the problem. Any help in this regards will be highly appreciated.
Help Reference: http://developer.ebay.com/DevZone/XML/docs/Reference/eBay/CompleteSale.html
Error response:
<?xml version="1.0" encoding="UTF-8"?>
<GetSellerTransactionsResponse
xmlns="urn:ebay:apis:eBLBaseComponents"><Timestamp>2010-01-13T12:50:29.644Z<Ack>Failure<Errors><ShortMessage>Invalid
job context type<LongMessage>The job context object
is not supported by Action Service
Framework.<ErrorCode>21843<SeverityCode>Error<ErrorParameters
ParamID="0"><Value>GetSellerTransactions<ErrorParameters
ParamID="1"><Value>CompleteSaleRequestTypeRequestError<Version>643<Build>E643_CORE_BUNDLED_10284414_R1</GetSellerTransactionsResponse>
I got this error when accidentally having the wrong X-EBAY-API-CALL-NAME value for the call I was making.
For example, in my header I put GetSellerEvents, but my request body was using GetSellerList.
Hope that helps!
Joe
Just had a similar issue. I had non-matching values in the headers and the XML; I had AddItem in the header, but VerifyAddItemRequest in the XML. (A copy and paste issue). The XML part needs to be AddItemRequest in this case.
After fixing this, I made my first-ever successful item listing in the sandbox.