Provider WSD generated from external wsdl has a "hard coded" reference to the schema

, ,
1

I created a provider WSD by importing an externally defined WSDL (Contract first). The WSDL has imports from a separate xsd file. The externally defined wsdl imports the schema through relative path.

The WSD that gets created has a hard coded reference to the external schema. Eg., schemaLocation=“http://machineName:portNumber/directory/SchemaName.xsd”. In our case, the machine name happens to be the development box.

Service consumers access the WSDL through https://prodMachineName:portNumber/ws/directory/ServiceName.WSD?WSDL . However, this WSDL points back to the schema located on the development box at http://machineName:portNumber/directory/SchemaName.xsd.

When the WSD gets migrated up the environments (test, stage, prod), the reference gets promoted as well, thus making the WSDL in production dependent on the schema location on development box. If the development box is brought offline for patching, this affects the web service consumers in production

Why would the product hard code the reference to the schema in wsdl? Can the WSD creation not suck the xml schema into the node.ndf file and get rid of this dependency? Are there any work arounds to this issue or fix packs that address it?

Any help is highly appreciated.

2

Hi gopal

If you can develop the WSD again then there can be a solution.

Before creating the WSD from the WSDL file, try replacing the schema location path which is hardcoded in the WSDL file with the schema name.
Then make sure that both WSDL file and schema are in the same folder.
Once the above activity is done try making the WSD Provider from the WSDL.

Above WSD should be made in the Dev box.Once WSD is generated deploy it to test/qa/prod.
Hope this works.

Regards
Mayank

3

Mayank,

Thanks for the reply.

The wsdl itself does not have the schema path hard coded, the schema is in the same path as the wsdl.

The webMethods IS hard codes it when it generates the WSD. I tried searching for any extended setting that could prevent this behavior, but there is none. This is possibly a bug in the product.

  • Hara
4
  1. Copy the schemas in to the consuming package resources directory along with the WSDL.
  2. Edit the external WSDL to point to a local path of the schemas.

ex:
<xsd:import namespace=“nsname” schemaLocation=“file:///D:/SoftwareAG/IntegrationServer/packages/packageName/resources/schemaName.xsd”/>

  1. Create a Consumer WSDL with the edited WSDL and use it.

Cheers,
Akshith

5

Akshith,

Thanks for the suggestion.

  1. The application that is consuming the web service is not webMethods. So, we have a provider WSD
  2. Specifying the file path in the wsdl adds hard dependency on the box where the schema is present. Besides, the wsdl does not refer to the schema (.xsd) through a path. The WSD generation process is adding that dependency, when it points to an externally authored wsdl
  • Hara
6

I think i misunderstood the questions.

Let me try this again, the WM IS is generating a WSDL with a hard coded references to schemas on the remote box (hosting IS). This is happening because the webMethods topLevel service is using input and output documents generated by consuming schema docs and when you generate the Provider WSD from this flow service you are seeing the reference. Does that sound right? If so, can you paste your schemas used for creating the input and output docs?

7

Change the targetname space on the WM Provider WSD to something generic. By default IS will generate something like this http://[B]remotehostname[/b]/pacakgeName/topfolder/subfolder/wsdName now change this to [url]http://test.com/wsdName[/url].

Now you can use this in different env with out having to bother about the hostnames. All you are doing is changing the targetNamespace of the WSDL.

8

Akshith,

Some of what I wanted to say might have been unclear. Let me try re-stating it :slight_smile:

  1. We adopted a contract first development approach. I authored the wsdl and the xsd externally. The wsdl references the xsd thus:
    <xsd:import namespace=“http://ns.companyName.com/businessEntity/businessProcess/v1” schemaLocation=“webServiceName.xsd”/>

  2. To import the (externally authored) wsdl into Developer as provider WSD, I copied the wsdl and xsd (into the same path) on a web server (let’s say, this server’s name is http://devServerName:port/)

  3. Imported the wsdl into the provider WSD. The provider WSD is represented as a node.ndf file on the file system. This file has a hard coded reference to the schema on the web server where I had copied the wsdl and xsd.
    <xsd:import namespace=“http://ns.companyName.com/businessEntity/businessProcess/v1” schemaLocation=“http://devServerName:port/webServiceName.xsd”/>

  4. We have a client that consumes our webservice using what is called “dynamic client”. It consumes the wsdl for every run time call. The wsdl is accessed by using http://serverName:portName/ws/folderName/webServiceName.WSD?wsdl

  5. When the WSD?wsdl is done, as in above, the node.ndf’s contents are loaded, which has the path to the schema on the web server that I had used, for creating the WSD in Developer. This places a dependency on the web server that I had originally copied the wsdl and xsd on. If the web server were to be down, the WSD?wsdl would fail since the client cannot access the xsd referenced with in.

There in lies the problem.

  • Hara
9

What happens if you include the schema in the WSDL (web server) and then consume the WSDL in webMethods? Does it still generate a hard reference to the xsd with the web server name?

Remove the below line and copy paste the schema inside the WSDL within the xsd:schema tags.

[COLOR=#333333]<xsd:import namespace="http://ns.companyName.com/businessEntity/businessProcess/v1" schemaLocation="webServiceName.xsd"/>[/color]