[OllyC]

hi,

We've got a customer that wants us to implement a web service.
The web service will receive a message, send back a response to the customer and send the received message to the integration layer.
The response just needs to be something simple and can be hardcoded into Java.

I've played around with the examples and we've got the SDK but it looks like Gateway Interchange can't generate the response itself, the response must come from the back end system - is that correct?

Is there anyway round this in either the web services or plain HTTP transports?

cheers,
Olly.

[remery]

Hello Olly,

The Interchange Web Services Business Protocol does support generating the response within Interchange (without the integration layer involvement). The Advanced Tab of the Community's Web Services Pickup Exchange has a setting - "Synchronous response generated in backend". The setting defaults to on. Go to the advanced tab and modify the value to off. Then in the wsdd filoe used to define the web service being received - make sure to include a "responseFlow" element. Example:

<responseFlow>
<handler name="Response" type="java:com.example.ResponseHandler"/>
</responseFlow>

where com.example.ResponseHandler is a java class that extends the org.apache.axis.handlers.BasicHandler class, and builds up the SOAP response as desired. You could just use the existing ExampleSendHandler as a starting point.

I am not sure what version of Interchange you testing, but this functionality is included at least as far back as 5.5.2.

I hope this helps.

-Ric

hi,

We've got a customer that wants us to implement a web service.
The web service will receive a message, send back a response to the customer and send the received message to the integration layer.
The response just needs to be something simple and can be hardcoded into Java.

I've played around with the examples and we've got the SDK but it looks like Gateway Interchange can't generate the response itself, the response must come from the back end system - is that correct?

Is there anyway round this in either the web services or plain HTTP transports?

cheers,
Olly.

[OllyC]

thanks for the quick response - we're on 5.5.1.0.1 but I'll give it a go.

Cheers,
Olly.

[OllyC]

I've tried a few tests - but I always get the same result, after the request is posted no response comes back i.e. the connection just hangs, not even a HTTP 204 comes back.

I've set up the WSDD with the response elements and unchecked the "Synchronous response generated in backend" checkbox in the delivery exchange.

I've tested with a variety of Java files, including the ExampleSendHandler (after removing the integration id checking part) and the security handler.

I've anyone has any ideas, that would be great - example Java source for a response would be appreciated too

cheers,
Olly.

[remery]

You should probably turn on debug in log4j.properties for com.cyclonecommerce.webservices.protocols.ws
Once a message is received by Interchange, look in the _te.log file - you should see a couple of debug lines that pertain to the SOAP response. One line will have the text "isSynchronousResponseExpected: " - hopefully the value will be true. The other interesting line will include the text "isSyncRespGenInBackend:" - the value should be false. If this looks ok, and there are not any random stack traces in the log4j log. Then you will need to figure out if your response handler is getting called. This should be easy to do, by making sure you have some log4j debug code in your handler. Then making sure log4j.properties enables your debug.

Here is an example response handler. "No warranty granted or implied"

CODE

package example.wshandler;

import com.cyclonecommerce.util.VirtualData;
import com.cyclonecommerce.webservices.protocols.ws.security.WSSConstants;
import com.cyclonecommerce.webservices.soap.security.SecureSOAPMessageException;
import org.apache.axis.AxisFault;
import org.apache.axis.Message;
import org.apache.axis.MessageContext;
import org.apache.axis.handlers.BasicHandler;
import org.apache.axis.message.SOAPBodyElement;
import org.apache.log4j.Logger;

import javax.xml.soap.SOAPBody;
import javax.xml.soap.SOAPElement;
import javax.xml.soap.SOAPEnvelope;
import java.io.ByteArrayOutputStream;

public class ExampleResponseHandler
extends BasicHandler
{
private final static Logger logger = Logger.getLogger("example.wshandler");

public ExampleResponseHandler()
{
}

public void invoke(MessageContext msgContext)
throws AxisFault
{
com.cyclonecommerce.api.inlineprocessing.Message inlineMessage =
(com.cyclonecommerce.api.inlineprocessing.Message)msgContext.getProperty(WSSCons
tants.CI_INLINE_MESSAGE);
if (inlineMessage == null)
throw AxisFault.makeFault(new SecureSOAPMessageException("Cannot Handle SOAP message without Inline Message"));

Message soapMsg = msgContext.getCurrentMessage();
SOAPEnvelope envelope = soapMsg.getSOAPEnvelope();
try
{
VirtualData data = inlineMessage.getData();
ByteArrayOutputStream stream = new ByteArrayOutputStream();
data.writeTo(stream);

SOAPBodyElement postResponseElem = new SOAPBodyElement("http://example.com/", "Response");
SOAPElement postReturnElem = postResponseElem.addChildElement("postRequestResult");
SOAPBody body = envelope.getBody();
postReturnElem.addTextNode(new String(stream.toByteArray()));
body.addChildElement(postResponseElem);
}
catch (Exception e)
{
throw AxisFault.makeFault(e);
}
}
}

I've tried a few tests - but I always get the same result, after the request is posted no response comes back i.e. the connection just hangs, not even a HTTP 204 comes back.

I've set up the WSDD with the response elements and unchecked the "Synchronous response generated in backend" checkbox in the delivery exchange.

I've tested with a variety of Java files, including the ExampleSendHandler (after removing the integration id checking part) and the security handler.

I've anyone has any ideas, that would be great - example Java source for a response would be appreciated too

cheers,
Olly.

[OllyC]

Thanks for your help - I've made lots of progress.

I upgraded to 5.7 to give me a better chance of success, Gateway Interchange is now showing the response in the message search screen.

To get the recipient of the response specified I had to use WS-Addressing on the inbound message - is there a way round this? I wanted to specify the sender and receiver on the exchange point, but it didn't work (recipient empty in the response).

However, even with using WS-Addressing - the client posting the message gets no response as before and the connection is hanging.

in the _te.log there is the following:

CODE

2009-02-05 20:43:54,675 - [Worker13-3] DEBUG (WSProtocolSender.g:187) - isSynchronousResponse: true CoreId: ci1233866634267.504@cyclonetst_te
2009-02-05 20:43:54,676 - [Worker13-3] DEBUG (WSProtocolSender.d:10) - getWsMessageType: response CoreId: ci1233866634267.504@cyclonetst_te
2009-02-05 20:43:54,676 - [Worker13-3] DEBUG (WSProtocolSender.addPayload:144) - Adding Payload to WebServices Message
2009-02-05 20:43:54,677 - [Worker13-3] ERROR (WSProtocolSender.send:52) - Error packaging Message
com.cyclonecommerce.webservices.protocols.WSProtocolSenderException: packageMessage caught Exception: null
at com.cyclonecommerce.webservices.protocols.ws.WSProtocolSender.packageMessage(WSP
rotocolSender.java:58)
at com.cyclonecommerce.webservices.protocols.ws.WSProtocolSender.send(WSProtocolSen
der.java:207)
at com.cyclonecommerce.tradingengine.messaging.config.ProtocolSenderProxy.send(Prot
ocolSenderProxy.java:10)
at com.cyclonecommerce.tradingengine.messaging.handler.ProtocolSenderState.f(Protoc
olSenderState.java:41)
at com.cyclonecommerce.tradingengine.messaging.handler.ProtocolSenderState.handleMe
ssage(ProtocolSenderState.java:25)
at com.cyclonecommerce.tradingengine.messaging.handler.MessageHandlerJob.run(Messag
eHandlerJob.java:47)
at com.cyclonecommerce.tradingengine.cluster.failover.FailoverableJobTask.execute(F
ailoverableJobTask.java:0)
at com.cyclonecommerce.util.task.TaskScheduler$a_.primRun(TaskScheduler$a_.java:0)
at com.axway.util.EventedThread.run(EventedThread.java:81)
Caused by: java.lang.NullPointerException
at com.cyclonecommerce.webservices.protocols.ws.WSProtocolSender.addPayload(WSProto
colSender.java:160)
at com.cyclonecommerce.webservices.protocols.ws.WSProtocolSender.getPackagingMessag
e(WSProtocolSender.java:203)
at com.cyclonecommerce.webservices.protocols.ws.WSProtocolSender.packageMessage(WSP
rotocolSender.java:93)
... 8 more

Any ideas on what could cause the error? I've tried adding Addressing and Security handlers to the WSDD, but it made no difference.

I'll try some more tomorrow with more debugging on.

[remery]

A couple of ideas on the NullPointerException.

First - make sure to modify the Collaboration Settings for Web Services to set the Payload Location dropdown to "None". This is probably the cause of the exception you are seeing. "None" tells the packaging code to disable the automatic inclusion of a payload into the SOAP Message.

Second. You probably should modify the sample I sent you and remove the 'VirtualData data = inlineMessage.getData();' line. And any lines that reference the data variable. Since you are doing a synchrnous reponse, the getData() method will return either null or an empty VirtualData.

As far as the addressing issue. Off the top of my head, I am not sure why hard coding the sender and receiver is not working. I need to give that question some more thought.

Thanks for your help - I've made lots of progress.

I upgraded to 5.7 to give me a better chance of success, Gateway Interchange is now showing the response in the message search screen.

To get the recipient of the response specified I had to use WS-Addressing on the inbound message - is there a way round this? I wanted to specify the sender and receiver on the exchange point, but it didn't work (recipient empty in the response).

However, even with using WS-Addressing - the client posting the message gets no response as before and the connection is hanging.

in the _te.log there is the following:

CODE

2009-02-05 20:43:54,675 - [Worker13-3] DEBUG (WSProtocolSender.g:187) - isSynchronousResponse: true CoreId: ci1233866634267.504@cyclonetst_te
2009-02-05 20:43:54,676 - [Worker13-3] DEBUG (WSProtocolSender.d:10) - getWsMessageType: response CoreId: ci1233866634267.504@cyclonetst_te
2009-02-05 20:43:54,676 - [Worker13-3] DEBUG (WSProtocolSender.addPayload:144) - Adding Payload to WebServices Message
2009-02-05 20:43:54,677 - [Worker13-3] ERROR (WSProtocolSender.send:52) - Error packaging Message
com.cyclonecommerce.webservices.protocols.WSProtocolSenderException: packageMessage caught Exception: null
at com.cyclonecommerce.webservices.protocols.ws.WSProtocolSender.packageMessage(WSP
rotocolSender.java:58)
at com.cyclonecommerce.webservices.protocols.ws.WSProtocolSender.send(WSProtocolSen
der.java:207)
at com.cyclonecommerce.tradingengine.messaging.config.ProtocolSenderProxy.send(Prot
ocolSenderProxy.java:10)
at com.cyclonecommerce.tradingengine.messaging.handler.ProtocolSenderState.f(Protoc
olSenderState.java:41)
at com.cyclonecommerce.tradingengine.messaging.handler.ProtocolSenderState.handleMe
ssage(ProtocolSenderState.java:25)
at com.cyclonecommerce.tradingengine.messaging.handler.MessageHandlerJob.run(Messag
eHandlerJob.java:47)
at com.cyclonecommerce.tradingengine.cluster.failover.FailoverableJobTask.execute(F
ailoverableJobTask.java:0)
at com.cyclonecommerce.util.task.TaskScheduler$a_.primRun(TaskScheduler$a_.java:0)
at com.axway.util.EventedThread.run(EventedThread.java:81)
Caused by: java.lang.NullPointerException
at com.cyclonecommerce.webservices.protocols.ws.WSProtocolSender.addPayload(WSProto
colSender.java:160)
at com.cyclonecommerce.webservices.protocols.ws.WSProtocolSender.getPackagingMessag
e(WSProtocolSender.java:203)
at com.cyclonecommerce.webservices.protocols.ws.WSProtocolSender.packageMessage(WSP
rotocolSender.java:93)
... 8 more

Any ideas on what could cause the error? I've tried adding Addressing and Security handlers to the WSDD, but it made no difference.

I'll try some more tomorrow with more debugging on.

[remery]

It looks to me like there is a bug in Interchange 5.7 when building the Web Services Synchronous Response. The NullPointerException you are seeing, looks like it is being caused by a Null Content Type on the response. The issue can be worked around by adding a rule in the Message Handler to set the "ContentMimeType" message attributes for the responses. You can set the value to "text/xml". Not sure what Conditions you should use to trigger the action.

On the message addressing question.. The receiver of the SOAP Request can be dynamically determined by the Trading Engine. The more difficult problem is determining the Sender of the SOAP Request. Since you want to hard code the sender value, I suggest that you add a Message Attribute for "SenderRoutingId" on the receiving Community's Embedded HTTP Pickup Exchange. Hard coding the sender on the "From address" tab of the Pickup Exchange, will not work. The "From address" value gets evaluated in the Message Handler, which is after the response has been built. The sender has to be evaluated before the response is created. Using a Message Attribute should do the trick.

-Ric

[OllyC]

After setting the ContentMimeType I'm able to generate a response now, but it has no body:

CODE

HTTP/1.1 200 OK
MIME-Version: 1.0
Content-Type: text/xml
Content-Transfer-Encoding: binary
Content-Id: DDA23546C0FED4C3883C8299FFA5E0CD
Content-Length: 247
Connection: close

<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body/></soapenv:Envelope>

I had tried to hardcode the body as follows, and copied the coding for the header from the ExampleSendHandler:

CODE

SOAPBody body = envelope.getBody();
SOAPElement element1 = body.addChildElement("Response", "example", "http://example.com/");
element1.addTextNode("received");

SOAPHeader header = envelope.getHeader();
SOAPElement element = header.addChildElement("IntegrationId", "example", "http://example.com/");
element.addTextNode("olly_123");

Also the log looks like its going to the send handler and reports an empty URL (rather than just processing the message as a response):

CODE

2009-02-09 10:54:52,563 - [Worker4-1] DEBUG (WSProtocolSender.send:113) - WSProtocolSender processing Message ci1234176890599.386@cyclonetst_te
2009-02-09 10:54:52,652 - [Worker4-1] DEBUG (WSProtocolSender.g:187) - isSynchronousResponse: true CoreId: ci1234176890599.386@cyclonetst_te
2009-02-09 10:54:52,652 - [Worker4-1] DEBUG (WSProtocolSender.d:10) - getWsMessageType: response CoreId: ci1234176890599.386@cyclonetst_te
2009-02-09 10:54:52,654 - [Worker4-1] DEBUG (WSProtocolSender.addPayload:144) - Adding Payload to WebServices Message
2009-02-09 10:54:52,654 - [Worker4-1] DEBUG (WSProtocolSender.i:123) - shouldAddPayload: false CoreId: ci1234176890599.386@cyclonetst_te
2009-02-09 10:54:52,658 - [Worker4-1] DEBUG (WSProtocolSender.g:187) - isSynchronousResponse: true CoreId: ci1234176890599.386@cyclonetst_te
2009-02-09 10:54:52,659 - [Worker4-1] DEBUG (WSProtocolSender.g:187) - isSynchronousResponse: true CoreId: ci1234176890599.386@cyclonetst_te
2009-02-09 10:54:52,661 - [Worker4-1] DEBUG (WSDDCache.getWSDDDocument:12) - Placing ../conf/default_send_handler.wsdd into WSDDCache. Cache size: 2
2009-02-09 10:54:52,662 - [Worker4-1] DEBUG (WSDDCache.getWSDDDocument:8) - Cache Hits=1 Cache Misses=2
2009-02-09 10:54:52,662 - [Worker4-1] DEBUG (HandlerChainUtil.getResponseChain:17) - Retrieved WSDDResponseFlow null from WSDDGlobalConfiguration org.apache.axis.deployment.wsdd.WSDDGlobalConfiguration@68bd43
2009-02-09 10:54:52,662 - [Worker4-1] DEBUG (HandlerChainUtil.getResponseChain:12) - Cannot resolve Response SOAPHandler Chain: ../conf/default_send_handler.wsdd
2009-02-09 10:54:52,663 - [Worker4-1] DEBUG (WSProtocolSender.g:187) - isSynchronousResponse: true CoreId: ci1234176890599.386@cyclonetst_te
2009-02-09 10:54:52,716 - [Worker4-1] DEBUG (WSProtocolSender.send:159) - WSProtocolSender completed processing Message ci1234176890599.386@cyclonetst_te
2009-02-09 10:54:53,051 - [Worker7-2] WARN  (Url.<init>:37) - Invalid url entered.
java.net.MalformedURLException: Invalid url, cannot be null empty or blank.
        at com.cyclonecommerce.util.Url.<init>(Url.java:16)
        at com.cyclonecommerce.tradingengine.transport.TransportSettingsBuilder.a(TransportSettingsBuilder.java:67)
        at com.cyclonecommerce.tradingengine.transport.TransportSettingsBuilder.getSettings(TransportSettingsBuilder.java:87)
        at com.cyclonecommerce.tradingengine.transport.system.production.ProducerFactory$a_.visitHttpExchangePoint(ProducerFactory$a_.java:91)
        at com.cyclonecommerce.collaboration.transport.http.HttpExchangePoint.accept(HttpExchangePoint.java:17)
        at com.cyclonecommerce.tradingengine.transport.system.production.ProducerFactory.ge
tProducer(ProducerFactory.java:1)
        at com.cyclonecommerce.tradingengine.transport.system.production.ProducerTask.produ
ce(ProducerTask.java:31)
        at com.cyclonecommerce.tradingengine.transport.system.production.ProducerTask.execu
te(ProducerTask.java:120)
        at com.cyclonecommerce.util.task.TaskScheduler$a_.primRun(TaskScheduler$a_.java:0)
        at com.axway.util.EventedThread.run(EventedThread.java:81)

So any more ideas on this?

[remery]

Couple of things I noticed.

1) I do not think the correct wsdd is being used for the response. Notice the following debug lines:

Retrieved WSDDResponseFlow null from WSDDGlobalConfiguration org.apache.axis.deployment.wsdd.WSDDGlobalConfiguration@68bd43
2009-02-09 10:54:52,662 - [Worker4-1] DEBUG (HandlerChainUtil.getResponseChain:12) - Cannot resolve Response SOAPHandler Chain: ../conf/default_send_handler.wsdd

The "Cannot resolve Response SOAPHandler chain" - indicates that either the wsdd is incorrectly formed or the wrong file is being used.

2) The stack trace indicating a missing URL leads me to beleive that the code is attempting to create a new HTTP connection instead of sending a synchronous response. I am thinking that if you solve issue #1 then the URL problem will go away.

[OllyC]

I agree, it looks like SGI starts treating the response as a new message and tries to send the data using an output delivery exchange.

However, I've no idea how to stop this - it looks like another bug.
(i.e. I've configured the response in the receive WSDD as per the documentation - there are no links to the Send WSDD except in the outbound delivery exchange)

So - going back to my original question, it looks like generating the response in SGI is not possible. - or if it is possible, it's not standard or simple and there are no working examples.

cheers,
Olly.

[OllyC]

I tried adding a response section into the Send WSDD as well and finally got a response back!
(if the response section is not in the receive WSDD a 204 is sent back to the client, if not in the send handler, the response is an empty SOAP envelope - so it has to be present in both)

Also I got round the addressing issue (if WS-Addressing is not used the response fails with unknown recipient even if the sender is hardcoded onto the receiving delivery exchange) by setting the SenderRoutingID in the receiving Java code:

CODE

inlineMessage.setMetadata("SenderRoutingId", "OLLY");

I still see error messages in the server_te.log:

CODE

2009-02-09 14:16:58,942 - [Worker39-2] DEBUG (HandlerChainUtil.getResponseChain:17) - Retrieved WSDDResponseFlow org.apache.axis.deployment.wsdd.WSDDResponseFlow@12c0b3f from WSDDGlobalConfiguration org.apache.axis.deployment.wsdd.WSDDGlobalConfiguration@967893
2009-02-09 14:16:58,943 - [Worker39-2] DEBUG (SOAPHandlerChain.invoke:13) - Enter: SOAPHandlerChain::invoke
2009-02-09 14:16:58,943 - [Worker39-2] DEBUG (SOAPHandlerChain.invoke:12) - Exit: SOAPHandlerChain::invoke
2009-02-09 14:16:58,944 - [Worker39-2] DEBUG (WSProtocolSender.g:187) - isSynchronousResponse: true CoreId: ci1234189018453.513@cyclonetst_te
2009-02-09 14:16:58,950 - [Worker39-2] DEBUG (WSProtocolSender.send:159) - WSProtocolSender completed processing Message ci1234189018453.513@cyclonetst_te
2009-02-09 14:16:59,306 - [Worker43-2] WARN (Url.<init>:37) - Invalid url entered.
java.net.MalformedURLException: Invalid url, cannot be null empty or blank.
at com.cyclonecommerce.util.Url.<init>(Url.java:16)
at com.cyclonecommerce.tradingengine.transport.TransportSettingsBuilder.a(Transport
SettingsBuilder.java:67)
at com.cyclonecommerce.tradingengine.transport.TransportSettingsBuilder.getSettings
(TransportSettingsBuilder.java:87)
at com.cyclonecommerce.tradingengine.transport.system.production.ProducerFactory$a_.visitHttpExchangePoint(ProducerFactory$a_.java:91)
at com.cyclonecommerce.collaboration.transport.http.HttpExchangePoint.accept(HttpEx
changePoint.java:17)
at com.cyclonecommerce.tradingengine.transport.system.production.ProducerFactory.ge
tProducer(ProducerFactory.java:1)
at com.cyclonecommerce.tradingengine.transport.system.production.ProducerTask.produ
ce(ProducerTask.java:31)
at com.cyclonecommerce.tradingengine.transport.system.production.ProducerTask.execu
te(ProducerTask.java:120)
at com.cyclonecommerce.util.task.TaskScheduler$a_.primRun(TaskScheduler$a_.java:0)
at com.axway.util.EventedThread.run(EventedThread.java:81)

but i'll ignore them for now and raise with Axway support.

thanks for your help,

Olly.

[remery]

I think there is still a configuration issue within your environment. I am wondering if it is possible the wrong receive handler is being used by the inbound message.
What does log4j indicate for the receive handler? There should be a debug line that looks like - "DEBUG (WSProtocolReceiver:xx) - WSDD Config Filename:" ? Does the file name indicated include the Response flow?

I tested your scenario last week and had Synchronous Responses working. One oddity on the configuration I used was - I did not override the Receive handler config on the Advanced Tab of the Pickup Exchange. Instead I added a Message Attribute of AxisHandlerConfigWSDD to the Pickup Exchange Message Attributes page. The value of the attribute is the wsdd filename. Either method should work for specifying the receive wsdd. But, the behavior you see leads me to beleive that the wrong wsdd is being utilized.

Here is what my WSDD looks like:

CODE

<deployment
xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<globalConfiguration>
<requestFlow>
<handler name="ReceiveHandler" type="java:example.ReceiveHandler"/>
</requestFlow>
<responseFlow>
<handler name="BuildResponseHandler" type="java:example.BuildSyncResponseHandler"/>
</responseFlow>
</globalConfiguration>
</deployment>

On the community HTTP Pickup
- Advanced tab - Generate sync response in the backend is disabled
- Message Attributes tab - AxisHandlerConfigWSDD - set to filename of the wsdd shown above. Also I specified SenderRoutingId to equal the routing id of the trading partner sending the message, since we wanted to hardcode this.


On the default Web services Collaboration page
- payload location - none
- encrypt and sign disabled

The only other things I did where to make sure the handler class files are in Interchange's class path. And updated filereg.xml to include the name of the wssd file.

It seems like you are very close to getting your scenario to work.

Good luck,
ric

I tried adding a response section into the Send WSDD as well and finally got a response back!
(if the response section is not in the receive WSDD a 204 is sent back to the client, if not in the send handler, the response is an empty SOAP envelope - so it has to be present in both)

Also I got round the addressing issue (if WS-Addressing is not used the response fails with unknown recipient even if the sender is hardcoded onto the receiving delivery exchange) by setting the SenderRoutingID in the receiving Java code:

CODE

inlineMessage.setMetadata("SenderRoutingId", "OLLY");

I still see error messages in the server_te.log:

CODE

2009-02-09 14:16:58,942 - [Worker39-2] DEBUG (HandlerChainUtil.getResponseChain:17) - Retrieved WSDDResponseFlow org.apache.axis.deployment.wsdd.WSDDResponseFlow@12c0b3f from WSDDGlobalConfiguration org.apache.axis.deployment.wsdd.WSDDGlobalConfiguration@967893
2009-02-09 14:16:58,943 - [Worker39-2] DEBUG (SOAPHandlerChain.invoke:13) - Enter: SOAPHandlerChain::invoke
2009-02-09 14:16:58,943 - [Worker39-2] DEBUG (SOAPHandlerChain.invoke:12) - Exit: SOAPHandlerChain::invoke
2009-02-09 14:16:58,944 - [Worker39-2] DEBUG (WSProtocolSender.g:187) - isSynchronousResponse: true CoreId: ci1234189018453.513@cyclonetst_te
2009-02-09 14:16:58,950 - [Worker39-2] DEBUG (WSProtocolSender.send:159) - WSProtocolSender completed processing Message ci1234189018453.513@cyclonetst_te
2009-02-09 14:16:59,306 - [Worker43-2] WARN (Url.<init>:37) - Invalid url entered.
java.net.MalformedURLException: Invalid url, cannot be null empty or blank.
at com.cyclonecommerce.util.Url.<init>(Url.java:16)
at com.cyclonecommerce.tradingengine.transport.TransportSettingsBuilder.a(Transport
SettingsBuilder.java:67)
at com.cyclonecommerce.tradingengine.transport.TransportSettingsBuilder.getSettings
(TransportSettingsBuilder.java:87)
at com.cyclonecommerce.tradingengine.transport.system.production.ProducerFactory$a_.visitHttpExchangePoint(ProducerFactory$a_.java:91)
at com.cyclonecommerce.collaboration.transport.http.HttpExchangePoint.accept(HttpEx
changePoint.java:17)
at com.cyclonecommerce.tradingengine.transport.system.production.ProducerFactory.ge
tProducer(ProducerFactory.java:1)
at com.cyclonecommerce.tradingengine.transport.system.production.ProducerTask.produ
ce(ProducerTask.java:31)
at com.cyclonecommerce.tradingengine.transport.system.production.ProducerTask.execu
te(ProducerTask.java:120)
at com.cyclonecommerce.util.task.TaskScheduler$a_.primRun(TaskScheduler$a_.java:0)
at com.axway.util.EventedThread.run(EventedThread.java:81)

but i'll ignore them for now and raise with Axway support.

thanks for your help,

Olly.

[OllyC]

My config sounds just like yours, I've tested in both 5.7 and 5.5.1 and had to create the response section in both send and receive WSDD files.

Do you have any delivery exchange set up for your partner? this may be what is confusing my SGI.
When I had an old AS2 delivery exchange, the response errored complaining that the AS2-From was missing, I still have an outbound webservice Exchange configured, so it looks like SGI is using it for the response.

I'm happy that what we've got works, I'll implement the customer with the 2 modified WSDD files.

here is a large piece of the log file, the receive WSDD is found on line 3 (I've modified the default WSDD for testing), but then switches to the send WSDD 8 lines from the end when building the response.

CODE

2009-02-09 18:09:48,616 - [Worker20-3] DEBUG (WSProtocolReceiver.f:137) - isResponseMessage: false CoreId: ci1234202988184.1314@cyclonetst_te
2009-02-09 18:09:48,616 - [Worker20-3] DEBUG (WSProtocolReceiver.f:137) - isResponseMessage: false CoreId: ci1234202988184.1314@cyclonetst_te
2009-02-09 18:09:48,636 - [Worker20-3] DEBUG (WSProtocolReceiver.j:172) - WSDD Config Filename: default_receive_handler.wsdd CoreId: ci1234202988184.1314@cyclonetst_te
2009-02-09 18:09:48,636 - [Worker20-3] DEBUG (WSDDCache.a:7) - WSDDCacheEntry stale:../conf/default_receive_handler.wsdd
2009-02-09 18:09:48,637 - [Worker20-3] DEBUG (WSDDCache.getWSDDDocument:25) - ../conf/default_receive_handler.wsdd read from the WSDDCache.
2009-02-09 18:09:48,637 - [Worker20-3] DEBUG (WSDDCache.getWSDDDocument:9) - Cache Hits=12 Cache Misses=2
2009-02-09 18:09:48,638 - [Worker20-3] DEBUG (HandlerChainUtil.getResponseChain:36) - Retrieved WSDDResponseFlow org.apache.axis.deployment.wsdd.WSDDResponseFlow@1f3471d from WSDDGlobalConfiguration org.apache.axis.deployment.wsdd.WSDDGlobalConfiguration@c1c2f1
2009-02-09 18:09:48,638 - [Worker20-3] DEBUG (WSProtocolReceiver.isSynchronousResponseExpected:455) - isSynchronousResponseExpected: true CoreId: ci1234202988184.1314@cyclonetst_te
2009-02-09 18:09:48,655 - [Worker20-3] DEBUG (WSProtocolReceiver.i:194) - isSyncRespGenInBackend: false CoreId: ci1234202988184.1314@cyclonetst_te
2009-02-09 18:09:48,657 - [Worker20-3] DEBUG (WSProtocolReceiver.a:409) - hasSoapBody: true CoreId: ci1234202988184.1314@cyclonetst_te
2009-02-09 18:09:48,677 - [Worker20-3] DEBUG (WSProtocolReceiver.c:48) - shouldIntegrateSoapBody: true CoreId: ci1234202988184.1314@cyclonetst_te
2009-02-09 18:09:48,678 - [Worker20-3] DEBUG (WSProtocolReceiver.a:179) - ShouldHandleSoapBody: true CoreId: ci1234202988184.1314@cyclonetst_te
2009-02-09 18:09:48,679 - [Worker20-3] DEBUG (WSProtocolReceiver.d:463) - SOAPAction Header for message ci1234202988184.1314@cyclonetst_te ""
2009-02-09 18:09:48,682 - [Worker20-3] DEBUG (WSProtocolReceiver.b:472) - hasAttachments: false CoreId: ci1234202988184.1314@cyclonetst_te
2009-02-09 18:09:48,682 - [Worker20-3] DEBUG (WSProtocolReceiver.b:237) - shouldHandleAttachments: false CoreId: ci1234202988184.1314@cyclonetst_te
2009-02-09 18:09:48,683 - [Worker20-3] DEBUG (WSProtocolReceiver.a:484) - isRejectedWithNoResponse: false CoreId: ci1234202988184.1314@cyclonetst_te
2009-02-09 18:09:48,683 - [Worker20-3] DEBUG (WSProtocolReceiver.receive:480) - WSProtocolReceiver finished Message receive
2009-02-09 18:09:48,691 - [Worker20-3] DEBUG (EbxmlMshSignalEater.doAction:16) - shouldEatMshSignal returned false
2009-02-09 18:09:49,302 - [Worker21-3] DEBUG (EbxmlMshSignalEater.doAction:16) - shouldEatMshSignal returned false
2009-02-09 18:09:49,305 - [Worker21-3] DEBUG (WSProtocolSender.send:42) - WSProtocolSender processing Message ci1234202988656.1320@cyclonetst_te
2009-02-09 18:09:49,385 - [Worker21-3] DEBUG (WSProtocolSender.g:150) - isSynchronousResponse: true CoreId: ci1234202988656.1320@cyclonetst_te
2009-02-09 18:09:49,385 - [Worker21-3] DEBUG (WSProtocolSender.d:158) - getWsMessageType: response CoreId: ci1234202988656.1320@cyclonetst_te
2009-02-09 18:09:49,386 - [Worker21-3] DEBUG (WSProtocolSender.addPayload:37) - Adding Payload to WebServices Message
2009-02-09 18:09:49,386 - [Worker21-3] DEBUG (WSProtocolSender.i:3) - shouldAddPayload: false CoreId: ci1234202988656.1320@cyclonetst_te
2009-02-09 18:09:49,386 - [Worker21-3] DEBUG (WSProtocolSender.g:150) - isSynchronousResponse: true CoreId: ci1234202988656.1320@cyclonetst_te
2009-02-09 18:09:49,387 - [Worker21-3] DEBUG (WSProtocolSender.g:150) - isSynchronousResponse: true CoreId: ci1234202988656.1320@cyclonetst_te
2009-02-09 18:09:49,387 - [Worker21-3] DEBUG (WSDDCache.a:7) - WSDDCacheEntry stale:../conf/default_send_handler.wsdd
2009-02-09 18:09:49,388 - [Worker21-3] DEBUG (WSDDCache.getWSDDDocument:25) - ../conf/default_send_handler.wsdd read from the WSDDCache.
2009-02-09 18:09:49,388 - [Worker21-3] DEBUG (WSDDCache.getWSDDDocument:9) - Cache Hits=13 Cache Misses=2
2009-02-09 18:09:49,389 - [Worker21-3] DEBUG (HandlerChainUtil.getResponseChain:36) - Retrieved WSDDResponseFlow org.apache.axis.deployment.wsdd.WSDDResponseFlow@13f67a9 from WSDDGlobalConfiguration org.apache.axis.deployment.wsdd.WSDDGlobalConfiguration@1aec462
2009-02-09 18:09:49,389 - [Worker21-3] DEBUG (SOAPHandlerChain.invoke:13) - Enter: SOAPHandlerChain::invoke
2009-02-09 18:09:49,390 - [Worker21-3] DEBUG (SOAPHandlerChain.invoke:2) - Exit: SOAPHandlerChain::invoke
2009-02-09 18:09:49,390 - [Worker21-3] DEBUG (WSProtocolSender.g:150) - isSynchronousResponse: true CoreId: ci1234202988656.1320@cyclonetst_te
2009-02-09 18:09:49,394 - [Worker21-3] DEBUG (WSProtocolSender.send:15) - WSProtocolSender completed processing Message ci1234202988656.1320@cyclonetst_te

[remery]

Yes. The trading partner needs to have a Web Services Business Protocol Delivery Exchange Configured. Even if the trading engine will not be sending messages to the configured URL on the trading partner. You can make up a bogus URL if you will never be sending directly to the trading partner (only synchronous responses).

-Ric

[remery]

Additionally the Web Service Business Protocol needs to be the default business protocol on the partner.
-ric

[OllyC]

Additionally the Web Service Business Protocol needs to be the default business protocol on the partner.
-ric

I agree - but this is what seems to confuse SGI and make it look in the Send WSDD as well as the Receive WSDD.

one last question - is there a way of accessing the original inbound message in the Java code for the response? Are any of the message attributes shared? (it look like just the http connection id).

Otherwise I think the receive Java code will need to store the message (e.g. in a file) and the response Java code pick up and read the file,
Alternatively we could split the message and bounce it back into SGI (both a bit messy) - any recommendations?

thanks again,
Olly.

[remery]

one last question - is there a way of accessing the original inbound message in the Java code for the response? Are any of the message attributes shared? (it look like just the http connection id).

Unfortunately the original message is not available in the response handler. I agree that the availability of the original message would be very useful.

Regards,
Ric