When we create a new soapui project why 2 requests generated instead of 1. For eg in the attached snapshot one is "StockQuoteSoap" and other is "StockQuoteSoap12". while xml request is same under both of these.
So what is the purpose of two same requests.
Thanks
One is for SOAP version 1.1, the other is for SOAP version 1.2. This is generated via the WSDL from your server.
Related
I am extending a standard ODataService for SAP Sales Order create to custom service.
The Service request version is 2.0 for all request where the standard service is hit, but the point where the custom service is hit automatically the Service request version gets updated to DataServiceVersion 3.0 and MaxDataServiceVersion 2.0.
Whenever I Place order I get below mentioned error.
“The Data Services Request version '3.0' is not supported for the request payload.”
Attached screenshot will show you the exact error and the request contents in details-
EDITED [23/01/2017]
I know that SAP Gateway only supports OData version 2.0.
Similar issue- https://archive.sap.com/discussions/thread/3689384 (However it is not helping in my case.)
Is there a way to update DataServiceVersion in the request manually.
Any hint will be appreciated, thanks in advance !
If you wish to call a different version of your service, please add a segment parameter to the URL as in the following example v=2
https://ldai1g1y.wdf.sap.corp:44356/sap/opu/odata/IWFND/CATALOGSERVICE;v=2/....
In my current project we are using lighttpd server. Here I am trying to upload the file. I am getting two Response Headers, first is with 301 Status code (Moved Permanently) and second is with 200 (OK).
But when I am checking in the folder I am not able to find any file (I mean no file uploaded).
I have tried both way to upload file as given links below:
http://jsfiddle.net/danialfarid/0mz6ff9o/135/
ngFileUpload
https://jsfiddle.net/JeJenny/ZG9re/
In both way I am getting the same response.
So here I have some sort of questions:
1) Is file upload is possible using AngularJS only? (No Server Side Script)
2) If possible, Is there any config problem with lighttpd?
Thanks !
Need Help...
The server side (or any web server) must be configured to handle POST and PUT requests. CGI, FastCGI, SCGI scripts can be written, or you can proxy to another backend. For simple file uploads, lighttpd also provides mod_webdav which you can configure (and protect with mod_auth) to allow you to upload files without having to write any server-side code.
https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModWebdav
I am running a Tomcat 6 server configured to use port 7787.I have to post data from a Silverlight app to a servlet running on this server.Ofcourse this is crossdomain so it requires me to have clientaccesspolicy.xml in the root.
I have seen various questions about this here and on the web and all have the same answer.To put the xml in webapps/ROOT.This works if I try to access the xml via
http://somedomain/
However since the servlet is running on port 7787 I have to post to somedomain:7787 and thus Silverlight tries to find the xml under
http://somedomain:7787/
This is unsuccesfull.
I am sure that Silverlight does indeed check somedomain:7787 for the xml as I used Firebug to confirm it.Is there anything in Tomcats configuration I can change or somewhere else I can place the xml so Silverlight can find it under port 7787.Or is there perhaps something I can change on the Silverlight side where the POST is being done?
On Windows machine simply copy the two security files to Tomcat's webapps/ROOT folder
As long as you can get response from ...:7787/crossdomain.xml, anyway solution is OK.
Looks like Silverlight only cares about the response.
I created a Silverlight client and it is OK to get response both from WCF service and Tomcat.
I write a simple web service in java use NetBeans, a function accept an array of string.
Then I use delphi written a web service client and call the function, server always received an empty array.
When I use soapUI to test the web service, it runs normally.
I checked the xml content send by delphi client and compare with soapUI.
this is send by delphi client:
<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<helloList xmlns="http://hw.xzq.com/">
<helloList>line 1</helloList>
</helloList>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
This is send by soapUI:
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:hw="http://hw.xzq.com/">
<soapenv:Header/>
<soapenv:Body>
<hw:helloList>
<!--Zero or more repetitions:-->
<helloList>?</helloList>
</hw:helloList>
</soapenv:Body>
</soapenv:Envelope>
I copied the xml content of delphi client to soapUI, the server received empty array now.
I modified the xml content by change these three lines:
<hw:helloList xmlns:hw="http://hw.xzq.com/">
<helloList>line 1</helloList>
</hw:helloList>
after this, the server received my string array.
SO, I think the problem is delphi client send array content without a prefix namespace.
But how to correct this?
Thanks for your help!
By the way, comment the line
InvRegistry.RegisterInvokeOptions(TypeInfo(HelloWorld), ioDocument);
no help.
I can verify the problem with NetBeans 7.2 / JAX-WS and Delphi 2009:
simple data types work, arrays fail
I had to uncomment one line in the generated unit as described in Delphi 2007 not consuming JAX-WS web service properly
I tried both .NET 3.0 / Metro 1.0 and .NET 3.5 / Metro 1.3 compatibility
Maybe newer Delphi versions can handle this (Delphi XE3 maybe anybody)
My Java code:
#WebMethod(operationName = "example")
public void testArray(#WebParam(name = "arr") String[] arr) {
System.out.println("in web method");
System.out.println("Array has " + arr.length + " entries");
for (String s : arr) {
System.out.println(s);
}
}
See also: Delphi and Java Integration using Web Services
I write web service using NetBeans 7.2 with Metro 2.0 (.NET 3.5/Metro 1.3 compatible), the client written by delphi 7 with Delphi SOAP Runtime and Importer Update (24535) installed.
I think the problem was delphi client generated xml not compatible with the web service.
I guess this may be help, but I don't know how to do same thing in java.
In the Server, to go to the SOAP web module, select the HTTPSoapPascalInvoker
component, and open up the Options property in the Object Inspector. Make sure
the option "soRootRefNodesToBody" is checked.
In the other way, I guess useing "RFC" type for the web service may be help, but RFC type need JAXB and not support java.util.List.
SO, is another way can correct this?
For a project we need to add attachments to workitems through a Silverlight application.
Our Silverlight app has a WCF service with which it communicates to our TFS 2010 server with the TFS API.
I can bind attachments from within the WCF service just fine, however what are the best practices to do this through Silverlight, seeing that SL is clientside and the WCF service serverside?
The way I look at it is that I need to upload the attachment to the server first, add the workitemid and the serverpath of the newly uploaded file, in some sort of log. Run a process/application on the server which searches the log for new entries, and then call the webservice which will add the attachment to the workitem.
Is this the best way to go?
Any help or suggestions would be greatly appreciated.
I would generally approach this as you described, without creating the intermediate logfile:
Upload the attachment using your SL client to the server.
Calculate the serverpath of the attachment.
Call the WCF service to process the attachment and specify the serverpath and workitem id.
Thank you Kroonwijk, for your suggestions on how to make the approach somewhat simpeler.
In the end I processed the file(s) to a byte[] on the Silverlight client side.
This byte[] is sent to the webservice accompanied by a workitemID. On the Server side(webservice) the byte[] gets saved to a temporary file on the server, and gets attached and saved to the workitem.
All works well with one WCF call, without having to use a process or file transfers to the server.
Point of notice: you might have to increase the message quota limit in your WCF bindings.