Don,
Sounds like you are almost there. For your provider descriptor you create that off the external WSDL you have from the API, the endpoint will obviously change once it’s in webMethods IS , but within webMethods IS the provider WSD will have a link to the WSDL which your external calling app will hook up to. Your consumer decriptor will be created off the same external API WSDL. You will now have two WSD services within webMethods IS, one provider, one consumer both created off the same external API WSDL.
You’ll now need to add the plumbing to connect the two services within webMethods IS, ie the provider wsd service is just a shell, you’ll need to add an implementation in order to connect it to the consumer wsd service. I’ll skip the real world architecture styles for doing this since you are just trying to work through a proof of concept, in your implementation flow service(shell was created when you created the provider service) you will need map the inbound document to the input document of the consumer service which in turn invokes the external API. You’ll then map the output message of the consumer message to the output message of your provider service which will return that to the external calling app. More dirty water I know. :lol:
Just a caveat in a real world implementation I would not recommend doing it like I suggested above.
Mark
#webMethods#Integration-Server-and-ESB