[JayWilliamson@su...]

Has anyone used an outbound trading partner web services delivery exchange? I would expect the default web services configuration for outbound xml messages via the trading partner web services delivery exchange would work something like this:

Step 1. Poll outbound xml message (file) from internal file system via a pickup exchange
Step 2. Based on the binary directory name, it would use the directory/routing Id to identify the trading partner to send the message to
Step 3. The xml file would be parsed by the trading engine and included in the the SOAP body of the web service request to the external trading partner as it is sent to the https url I setup in the trading partner web services delivery exchange
Step 4. The trading partner's external web service would receive the web service request and return a response back to the trading engine
Step 5. The trading engine would/should place the response to the web service request to a configured file system or to a parameter accessible by a post process but this is the step that I am questioning - any ideas how a response to an outbound external web services request is handled by the trading engine? (we are on Gateway Interchange v.5.5.2 sp.8 but will soon be upgrading to v.5.8.0 sp.1).

Thanks in advance!
Jay Williamson
Jay.D.Williamson@supervalu.com

[remery]

Hello Jay,

Interchange's Web Service Business Protocol Support has a default Web Service Implementation. The default Web Service that Interchange support, does not send (or expect) a response. So in regards to your question on Step 5 - there would not be a response to handle. A way of saying this would be that the default Web Service is a "One-Way" Web Service.

The Interchange SDK includes samples and documentation on how to author custom Web Service implementations (both client and server). A custom Web Service can be written to expect a response to an outbound Web Service call (this would be a "Two-Way" Web Service). The response can absolutely be sent to your back end system through any of Interchange's supported integration transports. If you have a SDK license, I would suggest reading the section on the Web Services Business Protocol and looking at the samples.

I hope this helps.

-Ric

Has anyone used an outbound trading partner web services delivery exchange? I would expect the default web services configuration for outbound xml messages via the trading partner web services delivery exchange would work something like this:

Step 1. Poll outbound xml message (file) from internal file system via a pickup exchange
Step 2. Based on the binary directory name, it would use the directory/routing Id to identify the trading partner to send the message to
Step 3. The xml file would be parsed by the trading engine and included in the the SOAP body of the web service request to the external trading partner as it is sent to the https url I setup in the trading partner web services delivery exchange
Step 4. The trading partner's external web service would receive the web service request and return a response back to the trading engine
Step 5. The trading engine would/should place the response to the web service request to a configured file system or to a parameter accessible by a post process but this is the step that I am questioning - any ideas how a response to an outbound external web services request is handled by the trading engine? (we are on Gateway Interchange v.5.5.2 sp.8 but will soon be upgrading to v.5.8.0 sp.1).

Thanks in advance!
Jay Williamson
Jay.D.Williamson@supervalu.com

[JayWilliamson@su...]

Hello Jay,

Interchange's Web Service Business Protocol Support has a default Web Service Implementation. The default Web Service that Interchange support, does not send (or expect) a response. So in regards to your question on Step 5 - there would not be a response to handle. A way of saying this would be that the default Web Service is a "One-Way" Web Service.

The Interchange SDK includes samples and documentation on how to author custom Web Service implementations (both client and server). A custom Web Service can be written to expect a response to an outbound Web Service call (this would be a "Two-Way" Web Service). The response can absolutely be sent to your back end system through any of Interchange's supported integration transports. If you have a SDK license, I would suggest reading the section on the Web Services Business Protocol and looking at the samples.

I hope this helps.

-Ric

Thanks Ric - I appreciate the information. We don't have the sdk currently but keep running into more reasons to get it.
-jay