Hi,

We are upgrading from 6.5 to 8.2 and we are trying to replace the deprecated services. My main problem is with replacing pub.client:soapHTTP. We are working with about a hundred packages that are using webservices and the WSDL files for some webservices could not be found. Please let me know if you can think of a way the WSDL file can be located from the webservice in 6.5 and how pub.client:soapHTTP service can be replaced if the WSDL could not be located.

We are thinking of building new WSDs in 8.2 if we can find the WSDLs and it is going to be a lot of work since we are dealing with more than hundred packages that need to be changed. So please also suggest if there’s a more efficient way to work on replacing deprecated services especially webservices.

Thanks

You mean that don’t have/can’t find WSDL’s handy that were past loaded in 6.5?

Not sure any efficient way to replace the deprecated service unless SAG released any 8.2.2 core fix for this?

Will this service works for you wm.server.ws:wsHTTP or client:soapClient used as replacement?

HTH,
RMG

In 8.2, you can set pre compatibility mode to true, and use 7.1/8.0 web service stack for backward compatibility of web service. For sure, at some point of time this will be removed in the future releases but as of now this is supported.

You should be able to locate the WSDL url from the web service provider/consumer in 6.5 right? URL will be active if the web services are still being used.

Senthil

Yes, the WSDLs loaded into 6.5 were probably in the local drives of the contractors who are no longer in the company, and we are having difficulties trying to contact the provider/partner. So we need to figure out a way to replace client:soapHTTP with client:soapClient without the WSDL files, but we don’ know how to do that yet, if there’s a way at all.

I’m trying to locate the WSDL url from the consumer, atleast for some packages. I tried looking at the connector properties, but no luck. I know we can find the url in 8.2 in connector properties, but it doesnt seem to be the same in 6.5. Please let me know how I can find the url.

Did you look on the created WSD in the Developer properties section?

“pre compatibility mode to true” → Where do you set this in extended??

The developer properties for the WSD in 6.5 does not have the WSDL url. If I create a WSD in 8.2, it shows the url in the properties, but not in 6.5 though.

Sorry I meant on the 82 itself the URL info.

If the WSD is migrated from 6.5 to 8.2, both versions are showing the same properties - so both versions for this WSD are not showing the url.
But if I create a new WSD in 8.2, it is showing the source url. Our problem is that, we do not have WSDL files to create new WSDs in 8.2.

I don’t think there is any easy way with out WSDL’s to replace the deprecated services rather than doing manually in the connectors/services.

How did you originally loaded the 6.5 WSD’s and now you lost those?

Like I said, they were loaded by people who are not working in the company anymore. We don’t know where they stored the WSDL files, there’s a good chance they had them in their local computer when they first loaded them.
Is there anyway we can manually change the connectors with the new services(client:soapclient), if the WSDL is not available?

When we are migrating from 7.1.2 to 8.2,what are the things we need to check i.e checklist to validate 7.1 environment and make sure that everything is working fine.

Kindly reply to this soon

Please refer to the documentation for upgrading webMethods products:
[URL]http://techcommunity.softwareag.com/ecosystem/documentation/[/URL]

Most of your questions will be answered in the documentation.

I am fear to say there is no easier way other than manually change across the board:

How do we manually change them? Is it not necessary to load the WSDLs into the new environment?

I assume you already moved/migrated those connector packages?

Yes, the connector packages are migrated to 8.2. They use the soapHTTP service which is deprecated in 8.2.

So manually changing each connector/service is the only option for now…I know you had to deal with tons of packages from your initial comments:

Meanwhile did you touch base with SAG support folks any migration utility for this kind?

We talked to SAG and they said they can’t help us with this.
I’m sorry, we are going in circles here. I want to know how to manually change the connector, to replace client:soapHTTP with client:soapclient?
I tried but failed to do it correctly. Please let me know.

In the connector service don’t you see the client:soapHTTP in the service logic?..also upload the screen shot that you currently have it from the Developer/Designer.

[ATTACH=CONFIG]875[/ATTACH]
Attached the connector service we migrated from 6.5 to 8.2.
It has client:soapHTTP, but I do not know how to modify the code to replace it with client:soapClient.

In the develop client on the step client:soapHTTP and in the properties window replace the service with pub.client:soapClient (and then save the connector service) and make sure the service inputs/outputs maps correctly (remap the links from pipelineIn/pipelineout)

HTH,
RMG

watt.server.xml.ncname.encode.backward.compatibility

After upgrade, if this parameter is set to ‘true’ in config/server.cnf, change it to false as this will have effect in all the new web services. It should be set to false.

This property might get dropped in future releases as the 6.5 and 7.x web services stack might not be supported in later versions.

In individual web service providers/consumers, there will be a pre-compatibility mode setting which we can set to ‘true’.

-Senthil

[ATTACH=CONFIG]877[/ATTACH]

Thanks for the useful info:

But I don’t see this key in the show/hide keys in the Extended in 8.2.2 server install

watt.server.xml.ncname.encode.backward.compatibility

If not there do we need to explicitly set it?

My bad… Misunderstood this property… I see from documentation the below details with respect to this property… This has nothing to do with pre-compatibility mode for all web services to be specific after upgrade… Even I don’t see it in my instance… Will check and get back…

Update WSDLs
1 Start Integration Server 8.2 SP2.
2 Review the migrationLog.txt file in the 8.2_installation_directory\install\logs
directory. If you see this error:
A property watt.server.xml.ncname.encode.backward.compatibility exists in
config/server.cnf with value as true. Make sure you make the required changes
as specified in the upgrade documentation. Not doing so could have adverse
effects as support for this property may be dropped in a future release.
Update your WSDLs as follows:
a In Integration Server Administrator, go to the Settings > Extended page. If you have
the extended setting watt.server.xml.ncname.encode.backward.compatibility and
it is set to true, reset it to false.
b Regenerate the clients for all Provider Web services that have an operation with
field names starting with “xml” in the input signature, output signature, header,
or faults.
****"

-Senthil

OK great: