Hello all, I am having issues with a webMethods document literal service (wsdl) no being able to be invoked from netbeans/sunone service.
Typically the error from the non-webm client is “Service… not found” or “unexpected null value for literal data”. I have read the posts here about the required setup of the xsd prefix/namespace (“top-level field” from web services doc etc) trying diffrent document type (and document reference) structure variations for the service input and output parameters without much success.
The “Service xxx not found” error message means that the element contained in the body of the soap request could not be found in the service registry. The service registry is populated when you set the “Universal Name” properties of a service.
[/highlight]
Then you would need a Flow service whose universal name properties were set with a namespace of “http://myco.com/services” and a localname of “createOrder”.
I’m not sure what your other error might be but until you get this one solved, you really aren’t invoking your service.
Thanks for the reply, i have soap messaging working now, based on setting the correct service interface(SoapRequestData,SoapResponseData In, SoapResponseData Out) and with an input Document Type definition containing a top level document element with the same name as the target service local name, and with a prefix refencing the same namespace …
I do see that lots of WM developers are having problems with creating WSDL whose binding style is document literal. Could some one post a sample package zip with services that successfully generate a document literal WSDL?
The service you wish to expose should accept and return document type references.
Define those document types with names like “createOrderRequest” and “createOrderResponse”.
Create a “container” document type for the request and response document types. The “container” document types will contain a single document type reference to the request and response document type respectively.
Name the “container” document types something like “createOrderRequestType” and “createOrderResponseType”.
Set the XML Namespace property on those document types to a namespace that is valid for your organization like “urn:myco.com/services/orders/test”. This namespace does not have to be a valid URL pointing to a real location. It’s actually helpful to NOT use a URL so that you don’t get confused over what a namespace really is.
Test your service in Developer to ensure that it can be invoked successfully using data in the “request” document type and that it will return data in the “response” document type. Be sure your service uses a try-catch sequence structure to handle any exceptions.
Create a document / literal “wrapper” service that extracts the content of the soap body and uses those contents to invoke your “wrapped” service. The wrapper service should have a single object input called “soapRequestData” and a single object output called “soapResponseData”
Set the Universal Name properties of the wrapper service specifying the namespace used above in Step 5 for the namespace value and “createOrderRequest” for the localName property. This causes your wrapper service to be invoked when a soap request is received that contains “ns:createOrderRequest” element in the soap body where ns is a prefix associated with the namespace specified above.
Write a test harness Flow service that creates a valid soap request by populating the request document type, converting it to a string, then a node and adding that node to the body of the soap request.
Use the Developer debugging tools to trace through your test harness and step into your wrapper service to ensure that the payload of the soap message is being extracted and converted into your input document properly. Do not proceed until you know this is working.
Open the document / literal wrapper service in Developer and choose “WSDL” from the Generate Code menu option.
Select “soap-msg” from the protocol menu
Specify the “container” document types as the input and output documents. In our example, that would be “createOrderRequestType” and “createOrderResponseType”
Specify a valid namespace for the targetnamespace of the service. Again, I recommend not using a URL. This can be the same value as the namespace name that you used for the container document types.
Save the WSDL to a location of your choosing.
To test your WSDL, generate a Flow service from it using a web service connector wizard or using your favorite WSDL2JAVA or .Net WSDL.EXE utility.
Note: The IS WSDL generator will not generate WSDL files that contain definitions for more than a single operation per WSDL file. To create WSDL files that do this, you’ll have to use a tool like XML Spy Enterprise Edition or the Eclipse Web Development Toolkit. DocLItWebServiceExample.zip (20.6 KB) createOrderRequest.wsdl (4.49 KB)
I am following your example of how to create a doc/lit service. I am unable to get step 9 to work. In step 9 am I supposed to be using the createOrderRequest doc or the createOrderRequestType doc? Also, when I attempt to call pub.soap.utils:addBodyEntry I get the following error:
com.wm.app.b2b.server.ServiceException: [ISS.0088.9142] Invalid Body Entry. SOAP Body Entries must have a namespace name.
In the test service I do the following:
map - to create document
pub.xml:documentToXMLString
pub.xml:xmStringToXMLNode
pub.soap.utils.createSoapData
pub.soap.utils:addBodyEntry
Before converting the document to a string, rename it using the prefix of your choice, say “ns1”, and then populate the nsDecls parameter with a prefix of “ns1” and a namespace that matches exactly the namespace that you assigned to your wrapped service in the Universal name properties. (See attached screenshot).
Mark: Your example greatly helped. We all appreciate the help, knowledge and guidance you give to members of wmusers.
To all Friends At wmusers.com:
On another note, why doesn’t webMethods fix this? While they made things so easy for SOAP-RPC, why aren’t they fixing SOAP-MSG? More over Document/literal is widely accepted and interoperable in industry. WSDL 1.2 spec doesn’t even mention about SOAP-RPC style and I would assume it has been deprecated.
I do understand that we could always write a custom processor, but why should I? I need to be concentrating on business logic/functions that I have to develop to support my company’s business, not spend time on writing custom stuff and worry about nitty gritty details of implementing hi-tech stuff.
Does any one know why webMethods wants us to go through the pain of writing wrapper services for using services through default soap processor?
Well, they are working on it. The design that I was briefed on looks solid and will be a great improvement over the current approach.
My issue is not with how WM is planning to correct the issue but with the pace at which they are doing so.
The document/literal web services functionality in IS has not changed significantly since IS 4.6 SP1. The current schedule is for the new stuff to release in Q12007 or Q22007. That will be over 4 years with no changes except for bug fixes. Ya’ think web services have changed any in that timeframe?
I don’t think WM likes the current solution, but they have had a couple of false starts and are now spreading resources across several fronts.
My recommendation: IS is the crown jewel of WM and web services are the piece of IS that has the market’s attention. Pull out all the stops on getting this design into the hands of customers ASAP. If someone has to wait a few extra months for the latest BAM bells and whistles it won’t kill 'em.
Those of you whose companies are participating in next month’s by invitation only WM Global Customer Council might want to find out who from your organization is attending and make sure they are fully briefed on the state of the WM products you care about.
