Hi,

Product : WM 7.l1

I am trying to create some sample web services in WM 7.1 by exposing some of the IS services.
While doing this I had an observation.The schema elements in WSDL file created from WM 7.1 is prefixed with some chars like “ns_x003A”. While the XSD’s which were used to creating the inputs for the IS services did not have these prefixed chars.
Also the WSD consumer generation also defaultly prefixes the same characters in all the elements in the referred documents.

I am facing some issues while mapping the webservice input (with characters) to the document type in the IS service. I need to do some explicit mapping to solve the issue.

Could someone help in understanding the behaviour?

Regards

Probably the best thing to do is read up on namespaces and XML. Prefixes seem to cause a lot of grief to folks. There are a couple of post here that go into a lot of detail on prefixes and how they are used. Just because the XSD doesn’t contain prefixes doesn’t mean the local elements are not part of a namespace, depends on whether a default namespace construct was used. My guess is that it probably was.

Dileep,

I think we’re going to need an example of the XSD and the generated WSDL to explore this further.

In general, prefixes do not matter so long as they are associated with identical namespace definitions.

Mark

Thanks for your responses.But I guess I have not articulated the question well. It is not about the namespace prefixes which I am taking about, I should be perfectly fine if the namespace prefixes are different but the namespace value remains the same.

The problem is with the element name itself.

Suppose I create a XSD schema with an element name “CustomerId”, the same element is coming as "ns_x003A_customerId" in the WSDL and in the document generated by the consumer WSD.

I will get a sample ASAP.

Regards
Dileep

Hi

I am attaching a sample XSD and WSDL. I guess you will observe that the element names has been changed to a different with "ns_x003A_

Regards
CustomerReq.xsd (608 Bytes)
Test.wsdl (3.06 KB)

The XSD you attached only has a single complex type. The WSDL shows additional types, so I assume this XSD is not the one you used but a contrived example.

What steps did you take to create your flow that used documents from the XSD as its input and then how did you create your Web Service Descriptor in provider mode.

What Flow service are you exposing as a web service and what are its inputs and outputs?

Agree that there is no match between your XSD and the WSDL, but need more info on the steps you followed to create your flow and expose it as a web service.

Mark

Dileep,
I think you are running an issue that is the driving force behind why you should do WSDL first development. You are taking an existing service and then generating a WSDL from it. You are leaving it up to webMethods IS to interpret your service and it’s documents.

The IS WSD service is abstracting your service and generating schema elements and types based upon it’s interpretation. It would appear to have some issues when the input documents are already namespace qualified. Take a look at Mark C.'s example on you will see how to do it without explicit namespace qualification on the input documents. The WSDL generated from that appears as you would expect based upon the signatures and without modification.

If you modify Mark’s documents to be explicitly namespace qualified you will see the same types of interpretation issues that you are currently seeing.

If you do WSDL first it you will not have this issue. For me personally I don’t like enabling an existing service as a web service. I prefer the web service to be abstract and hand off the processing/implementation to another service. It’s kind of a router pattern with the web service really not doing much.

Thanks Mark and MarkG. I followed a bottom up approach of exposing an already existing IS flow service as web service, which may not be a good idea to do.

To reiterate the steps which I followed :-

1. Created an XML Schema for both input and output( with namespace et al)
2. Used these schemas to generate the input and output documents.
3. Create a flow service with the input and output (doctype references) with the docs created in previous step.
4. Created a WSD Provider ( selected the IS Service ) and used rest all default values.
5. Copied the WSDL URL and checked for the element names. All the element names were coming with a prefix “ns_x300A”.
6. Created a consumer with WSDL URL. The documents created also had the same problems.

If I created a document directly without the use of schemas, everything seems to be okay.

Regards
Dileep

So, you’re saying that your Flow service input and output documents contained correct variable names, but a WSDL generated from that Flow had the mangled ones?

Yet another reason to use WSDL-first approach whenever possible. IMHO, letting tools generate your WSDL (or any other interface) for you is what Rob would call a Bad Idea.

Start with your XSD, create a WSDL from it using XML Spy Enterprise or equivalent, then create your WSD Provider node from the WSDL.

Mark

Thanks for your inputs Mark. As you said we should not depend on the tools to generate the WSDL for us. I guess this could be a best practice.

Regards
Dileep