Webservice: How to merge imported or included Schemas into WSDL?

[Former Member]

Hello experts,

we wrote some webservices with the ME SDK.

1. Common type definitions in XSDs.

2. WebService definitions in WSDLs which include the XSDs.

<xs:include schemaLocation="COMMON_TYPES.xsd"/>

Its the same than the standard ME webservices.

The only difference is that if we load the standard ME WDSL via URL, all the imported or included schemas are merged into the WSDL. But if we load our WSDLS, the imported or included schemas are not merged. Instead NetWeaver replaced the relative schemaLocation with an absolute URL.

<xs:include schemaLocation="http://hostdomain:50000/our-webservice/SomeServiceService?location=WEB-INF/wsdl/COMMON_TYPES.xsd&wsdl"/>

What do we have to do to force NetWeaver to merge all schemas into the WSDL like it does for the standard ME webservices?

Best Regards,

Martin

[tim_drury]

This is going to have to be answered by NW experts. I know that NW completely re-writes the WSDLs dynamically when it deploys web services. I know this because we have extensive <xs:documentation> and <wsdl:documentation> elements throughout our WSDL/schemas to assist users of our web services, yet they are all stripped out of the final WSDL that NW shows...

Have you tried looking in the NW forums for an answer to this question?

Do the URLs to your schemas that NW created not work?

-tim

[Former Member]

The URLs work. It's a matter of performance. Loading one single and optimized WSDL file including all required types is much faster than loading the WSDL file and afterward various XSD files.

I was searching the NW forum without success, but have not posted there yet. NW experts usually talk about NWDS, which is not helpful in case of ME and its SDK.

ME developers, any idea? Do we have to change something in the Ant file?

Martin

[tim_drury]

In the ME web services, schema imports remain schema imports and schema includes are replaced with the actual schemas. We, the ME application developers, have no control over this. Incidently we're using standard JAXWS and JAXB tools - we don't use NWDI/NWDS.

Here, for example, is a little of the BOM WSDL source - this is a hand-coded WSDL (i.e. of the WSDL-first genre):

<wsdl:definitions targetNamespace="http://sap.com/xi/ME"
    xmlns:me="http://sap.com/xi/ME"
    xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
    xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/"
    xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    
    <wsdl:documentation>BOM service</wsdl:documentation>

    <wsdl:types>
        <xs:schema targetNamespace="http://sap.com/xi/ME" 
            xmlns="http://sap.com/xi/ME" 
            xmlns:xs="http://www.w3.org/2001/XMLSchema"
            xmlns:gdt="http://sap.com/xi/SAPGlobal/GDT"
            elementFormDefault="qualified" attributeFormDefault="unqualified">
            
            <xs:import schemaLocation="SAP_GDT.xsd" namespace="http://sap.com/xi/SAPGlobal/GDT"/>
            <xs:include schemaLocation="COMMON_REFS.xsd"/>
			<xs:include schemaLocation="StandardMessageFault.xsd"/>
            <xs:include schemaLocation="BOM.xsd"/>
            
            <xs:complexType name="BomServiceResponse">
                <xs:annotation>
                    <xs:documentation>
                        Service response for response messages.
                    </xs:documentation>
                </xs:annotation>
                <xs:sequence>
                    <xs:element name="Action" type="gdt:Text"/>           
                    <xs:element name="ResponseObject" type="BOMRef"/>
                </xs:sequence>
            </xs:complexType>
            ...

and here is the WSDL created by NW after deployment:

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://sap.com/xi/ME" targetNamespace="http://sap.com/xi/ME">
  <wsdl:types>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ns1="http://sap.com/xi/SAPGlobal/GDT" elementFormDefault="qualified" targetNamespace="http://sap.com/xi/ME" version="1.0">
      <xs:import namespace="http://sap.com/xi/SAPGlobal/GDT"/>
      
      <xs:element name="StandardMessageFault" type="tns:StandardMessageFaultType"/>
      <xs:complexType name="BOMCreateRequestMessage_sync">
        <xs:sequence>
          <xs:element minOccurs="0" name="MessageHeader" type="ns1:BasicBusinessDocumentMessageHeader"/>
          <xs:element name="BOM" type="tns:BOMIn"/>
        </xs:sequence>
      </xs:complexType>
      ...
      <xs:complexType name="BomServiceResponse">
        <xs:sequence>
          <xs:element name="Action" type="ns1:Text"/>
          <xs:element name="ResponseObject" type="tns:BOMRef"/>
        </xs:sequence>
      </xs:complexType>
      ...

The import of the SAP Global Data Types (GDT) is preserved, but the includes of COMMON_REFS and the BOM data types are included directly into the deployed WSDL. Note that all <*:documentation> elements are stripped.

I, personally, know of no way to control NW to generate the WSDL differently.

-tim

[Former Member]

After some time we finally found the solution to our problem. Thank you for pointing us to JAX-WS.

The reason was the attribute wsdlLocation in the @WebService annotation. If it exists and points to a WSDL file, NetWeaver/JAX-WS decides to use the existing WSDL instead of generating a new flat WSDL.

@WebService(endpointInterface = "com.customer.ws.BrowserProcessingIn",

            wsdlLocation = "WEB-INF/wsdl/Browser.wsdl", 

            name = "BrowserProcessingIn", 
            serviceName = "BrowserServiceService", 
            portName = "BrowserServicePort", 
            targetNamespace = "http://ws.customer.com"
            )
public class BrowserProcessingInImpl 
     extends BrowserEndPoint 
  implements BrowserProcessingIn
{
   ...  
}

We removed the wsdlLocation and now we get one flat WSDL including all the required types and without references to XSD files.