I´m facing a problem that it seems to be an unsolvable one.
I´ve imported on an IS (v 8.0) a WSDL descriptor, in order to build a consumer for an external Web Service, which is hosted in a WebLogic server.
It´s seems to work smoothly as long as we test the trigger that IS has created .Unfortunately, the call to this trigger from a flow hosted in the same IS, produces no output, even though the remote service has been executed properly.
The response document returned to the pipeline is well built but doesn’t emerge from the atomic consumer. Therefore, the consumer is useless.
Debugging the flow service, we’ve observed that the request XML (obtained using the utility documentToXMLString) doesn´t match with the DocumentType that IS has built.
The difference is that unless the format of the Input DocType appears to be correct, the XML output doesn´t qualify de request with the target namespace, as clients built with another tools do (SOAP UI, OSB)
Can you please elaborate when you say “It´s seems to work smoothly as long as we test the trigger that IS has created .” A WSDL has a pre set input and output and if a target is sending you a XML response which does not conform to the doucmentType which was generated by the IS during the process of the WSDL import then the issues is not in webMethods but in the service at the target.
Request them to send you an updated WSDL and do a test through a test stub to ensure that the response coming back from the target exactly confrms to the signature generated during the WSDL import process.
Use SOAP UI to import the WSDL and simulate the process. If there is a mismatch between the expected and actual response you will be able to find the issue.
Thanks for your answer. I think I haven´t explained myself. Sorry. Here I´m go again.
The WSDL that we have imported into IS is well built and actualized. In fact, performing the operation from a client generated by SOAPUI or OracleServiceBus it works right and we obtain the values expected. Te remote service is OK. Moreover, many of our applications use it, as far as is one of the most “popular” ones.
However, when we invoke the same service with the consumer generated by IS, it behaves strangely. Debugging this flow, flow1, you can see that the remote service has been executed and the values are returned to the pipeline. But even though the match between the pipeline values and the output variables is well done, no values emerge.
Obviously, building a flow2 that’s invokes flow1 doesn’t produces any result either, given that the values in the pipeline of flow1 doesn´t populate the output variables.
Summarizing. With some services, the ones with a WSDL structure similar to the one I´ve posted before, IS isn´t able to populate the output variables, while other products do.
What I´d need to know is what´s the difference? How it´s possible that a consumer that IS itself had built doesn´t return values to another flow built inside the same IS.? Is there any configuration settings we had to change ?
With your explanation we can rule out that the target is the culprit as if its returning a proper response using SOAP UI then you are sorted.
Now to diagnose the issue we need to check up a couple of things first
From your environment (Unix/Wintel) do a telnet to the target IP address/hostname with the relevant port. At time the system is not able to resolve the hostname so it identifies the IP address.
If the above test is successful you should be assured that from the box you service is reachable. Ensure the WSDL you are importing should be directly used as the WSDL when you are creating a webService descriptor. In this case the consumer. Is this works then your connectivity is fine.
Now if step 1 and 2 are successful you need to debug the webService itself. Now if you have the correct import done you would need to use the service method(s) that would be generated under the connectors folder under the folder where you have created the webService. Now you need to stub the connector into a webService and then you need to do the trace the flow within the service connector. Check which step is the service failing if it is indeed failing.
If the soap call is successful then when you do the F7 into the connector there would be no errors in the pub.client:soapClient call within the connector. Here is the catch. This is the service which will execute the actual SOAP call to the target. Check all parameters that are going into the input of this service like address,wsdl name and specially auth which has the type, user and pass string inputs. Check if all values are accurate. Here in these there parameters you need to set up the type of authentication you need to establish and you need to check with the target as to what kind of authentication they are using. Weather its certificates, or whether its a simple user name and password.
It can happen that because u are not using the right authentication configuration you are having the issue.