We are using Siebel CRM for an inbound integration and using session management based soap requests and response. The problem is that when we generate WSDL from Siebel it does not include session management related header neither in request nor in response. We are using .net application to call Siebel inbound web service.
Now, our .net application is based on the classes generated after de-serialization of the Siebel generated WSDL and it is not including session response header. Session response header is being inserted by Siebel on run-time. Due to this our .net application could not get the session header.
What solution can be for the above problem from .net or Siebel side ?
I don't think Siebel generates this part in it's WSDL, the examples on Oracle and other blogs mention that the extra Headers need to be sent in the incoming SOAP to Siebel, but they are not present in the generated WSDL.
You will have to modify the WSDL after it is generated from Siebel, and then add the header section in it. Then your .NET side can parse out this section. Or you will have to handle the session side in the .NET app.config file
Related
I am testing a new webservice that is receiving messages from an application and responding with messages with specific information. The webservice then uses this information to create new messages for downstream systems. I need to know the best way I can test this using the Ready API tool, we just got a pro license. Is it SOAP or REST I need to use. Ideally I want to simply copy my application messages in to the tool, call the webservice and get the response, which I can then check is the correct response for the test
To find your web-service is SOAP or REST.
Please check whether your web service has WSDL to verify it has SOAP web-service, you can get your web-service's WSDL by post-fixing WSDL with your web service url.
Eg: http://{yourservice-url/path1}?WSDL
If your service don't provide WSDL from the above URL, then your web-service is REST.
In Azure I am able to create a Logic App Custom Connector to a SOAP API endpoint using Call Mode: SOAP to REST.
This SOAP Web Service needs an HTTP Header named Cookie with the value LoginCert=.
When modifying the Request of this connector I cannot find a way to add the Cookie HTTP header in the REST request and have that same Cookie be added to the SOAP request. Does anyone know how or if it is even possible to have HTTP headers from the REST request forwarded to the SOAP request made by the custom connector?
PS: This is possible in Azure via the API Management tool's REST to SOAP using the same WSDL, and then using the newly created REST endpoints inside of a Logic App Flow but this is not the solution.
TLDR: How can one add a HTTP header in an SOAP to REST Azure Logic App Custom Connector so the header is forwarded to the SOAP endpoint?
This is not currently supported by the SOAP to REST WSDL generated custom connectors for SOAP. You need indeed to either escape to APIM or you need to form the request payloads via LIQUID action then use the HTTP request action's advanced option to specify the cookie.
I am going to develope REST(without any framework like SPRING) services which can accept xml. I am going to create XSD for the input xml format.
Now, when client sends some invalid xml which is not as per schema, how should i validate it? Do i need to write a specific code to validate. Can't it get failed in the client side itself?
Previously we had soap service, so if i try to send soap request which is not as per schema, soapui will throw error. The request even will not come to server i guess.
I hope you understood my question, please clarify.
RESTful clients are free to transmit any content they wish to the server, and even try to negotiate different encoding formats like JSON instead of XML. That's part of the power of REST.
It's up to the server to validate that clients send correctly encoded data in the payload, and return a 400-range status code such as 400 - Bad Request if they do not.
You will need to write all your server validation code yourself unless the REST API framework on the server side provides it for you.
i have a web service written in php, i added it as web reference to my asp.net web site (asp,c#)
i knew how to call web service's method from c#.net client,
but the problem i still have: i want to send a soap header with web service call (from c#.net client to php server)
i did this but in php client, by using $client->setHeaders, and parsed the sending header in $server,
but how to do it in c#.net client,
note: i don't have a header class in server.php , ant it works fine with php
please help
Use WCF custom headers to fill in extra information to pass along to php.
http://cisforcoder.wordpress.com/2010/12/01/how-to-implement-basic-http-authentication-in-wcf-on-windows-phone-7/
This example in the link passes along the header for Authorization
If you make a web reference to the php service, then I can point to the person who already asked it before here on the forum.
Adding SOAP headers to ASMX service requests
If you are using nuSoap, you can go the library, you'll find the code where packet response is been generated. There you can add your own attributes and headers as per your requirement.
I'm trying to generate a quick website to allow a customer to access a SOAP service specified in WSDL. Any language/toolkit is ok.
Ideally I'd like to feed the WSDL file to a code generator and have it emit servlets/PHP/python, one URL per operation specified in the WSDL, with form fields equivalent to the attributes in the WSDL. The generated app would allow the user to fill in a form, submit the operation to the SOAP service, and return the result.
There's a website at http://www.soapclient.com/SoapTest.html that does almost exactly what I want to do, but they don't publish any source code.
The website at http://www.soapclient.com/SoapTest.html was generated using this tool: http://www.sqldata.com/SoapClient/soapclient30.htm
It's a Windows-only program, but the C++ code it generates might be fairly easy to port to another platform, or be translated to PHP, etc.