Does anyone Have any experience in creating a webservice client on Integration Server without using a WS Descriptor generated through designer. The reason I ask is while I understand the reason SAG is eliminating some of the service that allow for more custom flexibility, we do have some issues with the descriptors and want to find some options.
Issues:
The auto-created WSD consumer creates too many nested document types that really slows down our automated CI deployments.
The auto-created WSD consumer creates documents named with the namespace pulled form the WSDL schema. The problem is that our applications auto generate WSDLs and that namespace can change. If that happens our WSD breaks.
So my thought is to create a custom WS client that limits these two problems but still follows the basic principals of SOAP standards. I wanted to use the service wm.pub.client:soapClient but I am struggling with the “wsdname” input, it is required but I cannot seem to find out what exactly needs to be used here (wsdl address does not work). Somehow the auto-generated descriptors pass that wsdname hidden from the pipeline.
Anyone with some examples of how to use pub.client:soapClient or some advice on building a custom WS client. Also any suggestions on how to fix our issues using the standard descriptors generated by designer would help too.
BTW. we are still on version 8.2 (so maybe it get’s better with 9x?)
I believe you have to still depend on the WSD in 8.x and above. But are you sure the wsdName is mandatory? As the soapClient should still work as the other Service In params will make it work.
for example:address,request,wsdBinderName,soapProtocol,soapAction,wsdOperationName,transportHeaders,method,auth
I am trying to avoid the WSD/Consumer…the document generation causes issues with us integrating with a Spring Framework generated WS. For some reason it expects the wsdname field if you call it from a wrapper. Meanwhile when a WSD consumer that value is nowhere in the pipeline and I assume it is somehow generated from the sourceURI defined for the service.
Just looking for some pointers on perhaps building a custom web service client on IS without the use of the descriptor generating a consumer.
If you are not using any WS-Security then you can compose the soapData(add header,body and other tags) and then post it to the target URL using the pub.client:http service but that is lot of work. If you have more than one place that will need this feature then probably write a Framework service to compose the soapData and send it over.
I believe in earlier version of webMethods they used to have something called soapHTTP service that can do exactly what you are asking for here. This is currently either deprecated or i just cant find it anymore.
The auto-created WSD consumer creates too many nested document types that really slows down our automated CI deployments.
Are you using Deployer GUI for deployments? Have you tried automating your deploments using Deployer.bat? It is light weight and works with out the overhead of the Deployer UI. If this is a package level release then better yet use either publish\subscribe option or write a script using Deployer.bat to move the whole package to target IS directories.
The auto-created WSD consumer creates documents named with the namespace pulled form the WSDL schema. The problem is that our applications auto generate WSDLs and that namespace can change. If that happens our WSD breaks.
Is this a custom built application? Does this application have the ability to define namespaces? If yes then i would suggest the NS names be defined manually instead of automatically and then import the WSDL in to webMethods. This will solve all your problems.
We have/had the same or similar problem with namespace prefixes changing from s1 to s2 and with that breaking the mapping from s1:docTypeX to s1:docTypeX which would become s2:docTypeX to s1:docTypeX which would not work.
We ended up creating a “wsdl-proxy service”. When creating a consumer (or provider) WSD, it would not get the wsdl (string/document) served directly from the endpoint URL, but through the proxy. The proxy service reads the original URL and changes the auto-generated prefixes s1, s2 to configured prefixes like claim, policy, more readable and above all, consistent prefixes.
Thanks for some of the feedback. We use the Automated Build (ABE) to deploy which uses the deployer scripts mentioned by akki_ 84. It is not an option to use pub/sub for deployment as we do not want to support a mixed bag of deployment options (we are sticking with ABE).
We have tested the soapClient service and it does seem to require the wsdName. I will try the addSoapData combination with HTTP client…that might be the trick!
Yes I agree with you ABE (repository) based is very useful for especially global team development scenario.(there is some extra work involved ofcourse)
Thanks for the update on the wsdName thing and it might be the working option.
And I doubt you have set that in your manually coded flow-service, since you don’t have/want it.
And in the code below that, it heavily relies on the generated Consumer WSD so I think your path using soapClient ends there.