When generating a web services connector in webMethods, I’m running into some issues when the wsdl contains simple types other than strings. ie. If a simple type is defined as a dateTime type in the wsdl, webMethods interprets this as a string in the input document it generates. It puts a dateTime constraint on the string (dateTime {[url=“XML Schema”]http://www.w3.org/2001/XMLSchema[/url]} but that does not work when invoking the webservice. The webMethods soap/rpc engines fails with a type does not conform to datatype. That’s if I map a string with the same constraints to the input field on the generated document.
If I changed the string to an object and try to map it to the string input field, I get a string type expected error. Which makes sense.
Am I missing something simple here? Has anyone run into this? Thanks.
Lack of visibility into how the default RPC soap processor does type conversion is one of my reasons for preferring document / literal.
One debugging technique is to disable everything in your service and add a pub.flow:tracePipeline statement on the first line. That lets you see (perhaps in nauseating detail) how the default RPC soap processor is converting the XML doc to your IData (input doc).
For finer control over this, you can use document / literal or write and register your own RPC soap processor. Probably not worth the effort for something this simple, however.
Mark,
Thanks for the tips. I prefer doc/literal myself (now that I know how to work it in webMethods ) Unfortunately this is an external vendor’s WSDL, that we are stuck with for the time being. It is a very complex implementation using RPC, which is not good and is causing us several problems.
Now that I figured out the outgoing date problem (user error), we now have an incoming date problem( on the response). The simple type is defined as a dateTime in the wsdl/schema and webMethods creates it correctly when it generates the web service connector and associated documents. String with a dateTime type. When the web service responds with the reply date, it is sending the dateTime back. webMethods chokes on that with an invalid type. It says it is expecting a string. If I manually edited the response doc in webMethods and change it to a Date object. The response then works.
I not sure why that is the case. I really should not have to edited the generated documents. At least I don’t think I should have to do that.
What component of IS is generating the “expecting a string” error message? Do you have “validate inputs” checked on the service being invoked or is it the rpc soap processor?
I assume that you don’t have option of changing this WSDL, right?
It is the rpc soap processor. We tried running as is and it generated that error. We do have the option of changing the WSDL. And that is the route we are taking for now. I saw a couple of service requests on advantage where the resolution was to do just that as well.
Thanks for your help, I used the trace pipeline just to verify some things as well. The data is being sent and received in the right format, the rpc processor is just having a bit of a fit with it.
Good that you can change the WSDL, many times that is not the case. If that had not been an option, your best workaround may have been to create a custom RPC soap processor that corrects this behavior. It’s a bit of a pain to do just for this issue, but I’ve become a fan of custom soap processors because it gives you a good place to put business logic common to all soap messages such as logging, SAML or WS-Security processing, etc.
I have a requirement to share one of my webMethods Service as Enterprise Web Service. When I generated the default WSDL file from Developer and sent it to the other party, I got the following 3 comments
The binding and parameter formatting are setup to use RPC/encoded
Schema specified in the types section
To avoid above 2 problems suggest we use document/literal formatting
Can some one explain how to change webMethods default WSDL to not usr RPC encoding and use document/literal formatting.
Chandra,
The webMethods SOAP Developer Guide and the WebService Developer Guide go into detail on how to do this. There are also some threads plus examples out here on how to construct your documents and flows so that doc/literal will work correctly.
Unfortunately, it takes a bit of work to expose a Flow or Java service as a document/literal web service.
The high-level steps are:
create a “wrapper service” that accepts a soapRequestData object and returns a soapReponseData object []In the wrapper service use the pub.soap.utils:getBody service to extract a node from the body of the soap message []Convert the node into a document that contains the inputs of the service you wish to expose using either the pub.xml:queryXMLNode or pub.xml:nodeToDocument service []Invoke the service []Create and empty soap envelope to hold the response using pub.soap.utils:createSoapData []Rename the document containing the results of your service to include a prefix name (e.g. “xs:”) []Use pub.xml:DocumentToNode to create a node. Populate its “nsdecls” property with the prefix from the preceeding step and some namespace definition (e.g. [url=“http://my.company.com/myServiceName”]http://my.company.com/myServiceName[/url]) []Use the pub.soap.utils:addBodyEntry to add the node to the body of the soap envelope []Populate the universal name properties of the wrapper service with a local name and namespace name. This will allow the default soap processor to determine which service to invoke with it receives a soap message with the namespace and localname you specify. For example, when the default soap processor receives a message whose top-level node is foo:myservice with an xmlns foo=“[url=“http://mycompany.com/myService”]http://mycompany.com/myService[/url]” it will invoke the wrapper service whose local name is myService and whose namespace name is “[url=“http://mycompany.com/myService”]http://mycompany.com/myService[/url]”. Note: XML namespaces do not have to (and often do not) refer to actual server locations.
If this sounds like a lot of work, you’re right, it is. The good news is that you can create helper Flow and java services to do most of this work for you and even move the wrapper service functionality into a custom soap processor.
The attached example should give you some ideas. Use the testAddInts flow service to step into and trace through the addIntsWrapper service to see what it’s doing.
Oh, and you’ll want to change the soapAddress on the test service to match your server. My server uses a different setting for the default soap directive.
Mark
WSDL for Doc/LIt version of addInts service addInts.wsdl (3.0 k)
Thanks Mark…It’s a great help. Can any one outline, why we want to go for doc/literal instead of RPC protocol, doc/literal in webMethods is a pain…any thougts??
I think there are fewer interoperability issues with the document/literal style than with soap/rpc and for that reason I see more doc/lit web services in enterprise-class projects than soap/rpc.
Another reason is that webMethods does not provide a way to process Soap headers with the soap/rpc style. If you are using any of the WS-* standards (e.g. WS-Security, WS-Addressing, etc.) or if you need to work with soap headers to communicate “out-of-band” information, you will need to use the document/literal style.
By creating a custom soap processor and using it instead of the default (doc/lit) soap processor, you can get almost all of the benefits of doc/lit (header processing, validation, better control over soap faults, etc.) with almost the same ease of use and developer productivity as soap/rpc.
) Unfortunately this is an external vendor’s WSDL, that we are stuck with for the time being. It is a very complex implementation using RPC, which is not good and is causing us several problems.
SoapDocLitExamples IS Package