on 03-21-2014 3:00 PM
Hi Experts,
I am just having a heck of a time trying to get a $batch to properly process from my external application. I am getting an HTTP response code of 202, telling me that my request is getting to where it needs to go.
However, in the body of the response I'm getting the error "System expected the element '{http://www.w3.org/2005/Atom}entry'". After searching around through the discussions and seeing these three threads, then finding and reading this excellent help document, I am still at a loss.
I can successfully take the request body that I generate and use the Gateway client to do the entries, but when I try to use the Advanced Rest Client Application, or try to use the application I am developing I get the error noted above.
Here is how the request looks:
Header attribute Content-Type: multipart/mixed; boundary=batch, method: POST (there are some other authentication attributes, but those appear to be working)
Request body:
--batch
Content-Type: multipart/mixed; boundary=changeset
--changeset
Content-Type: application/http
Content-Transfer-Encoding: binary
PUT ContractDetailsCollection(1) HTTP/1.1
Content-Type: application/atom+xml
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<atom:entry xmlns:atom="http://www.w3.org/2005/Atom">
<atom:content type="application/xml">
<m:properties xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices">
<d:Id>1</d:Id>
<d:Description>batch test id 1</d:Description>
<d:Value>1111</d:Value>
</m:properties>
</atom:content>
</atom:entry>
--changeset--
--batch--
Does anyone have an idea as to what I'm doing wrong? I have tried the formats in the above discussion threads, and everything I try in tweaking the body format seems to lead to the same "expected the element..." error, but NetWeaver Gateway Client works and updates my backend data.
Any help is very much appreciated. Thank you!
I have finally gotten a workaround for this: instead of trying to have the HTTP request body in XML, I sent my request with JSON as the body. Now things are processing successfully.
This doesn't resolve the issue of the XML never posting successfully, but it does allow me to move along in my development.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Paul,
This means that Gateway Client is doing something more than the Advanced Rest Client. May be you can check the payload reaching Gateway in both the cases and compare them.
learn how to trace the payload, if you are on SP7, use this
SAP Library - SAP NetWeaver Gateway
Thanks
Krishna
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Krishna. I was unaware of this tool and now I have the link saved for future reference.
Unfortunately for me, my system is not at that SP level. Is there anything you or anyone else can think of that might help me?
I have my external application writing out its payload, and it compares character-for-character with the post I have above. So I definitely think you are right - I just need some way to figure out what Gateway is doing above and beyond my external application.
Another very informative posting, Krishna! If you have any knowledge, I have another question based on the results of using the tools suggested by Lindsay.
Looking at the data between the successful (from Gateway) and unsuccessful (from Chrome) request headers, I can see that the ~request_line and ~server_protocol fields are different. The request from Gateway specifies HTTP/1.0, and from the Chrome tool HTTP/1.1. Could this be causing my different results?
Hi Paul,
I do not think HTTP protocol versions should really matter. Does the request body exactly look same?
Does Gateway Client(GC) make any extra calls compared to ARC? I have earlier experiences where GC actually behaves different that other rest clients.
From the error message it seems like gateway i snot able to recognize the request body.
Thanks
Krishna
That's what is really confusing to me - I pulled the body from an ICF recording of the Gateway request and an ICF recording from the ARC tool, and they are character-for-character the same (proved out by a compare tool so I knew I wasn't going crazy).
This is going to be a really small, simple thing that I'm missing...I just know it.
Hi Paul,
It may be that you are prefixing tags with "Atom" - "Atom" isn't actually declared prior to this.
Content type "atom+xml" does not, as I see it, mean that the Atom namespace is recognised.
Try declaring the entry element with this template
<entry xml:base="http://yourserver.someorg.com:8000/sap/opu/odata/sap/yourservice/" xmlns="http://www.w3.org/2005/Atom" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices">
Remove all 'atom:' references, such as atom:entry, atom:content.
Just a guess, based on the request body not looking logical. I am not an expert on Atom
Regards
Ron.
Thanks for the suggestion, Ron. Unfortunately for me, that's one of the many different formats I've tried as I've worked through this. To double check, I made an ARC test case exactly like your suggestion and I still get the error.
A regular GET or PUT will work, it's just this blasted $batch! Is there any configuration on the Gateway side that needs to be done to explicitly enable $batch from an external call? As I mentioned, it works in the Gateway Client tool.
Paul
Oh well! It was just that I had exactly this problem last week (non-batched request) and it was related to namespace declaration position.
Looking back on my past work with $batch, my examples do look similar to yours.
I have just remembered one thing about batch bodies - they are very fussy about where line breaks are placed. I was getting all kinds of nonsensical errors until I found OSS note 1869434. It's quite useful as a guidleline anyway but it does mention the need to have a minimum amount of linefeeds at certain places. I had to experiment with line breaks until I got it 'right' - there didn't seem to be a clear pattern. Obviously the batch parser needs a bit more work done on it to improve reliability.
There is nothing extra required on server to enable batch processing.
Hope this helps
Ron.
User | Count |
---|---|
86 | |
10 | |
10 | |
9 | |
6 | |
6 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.