Web service Issue
This was one such small but nasty issue to debug.
I am working on a project with Websphere Commerce as the order capture tool. There is functionality on the site where customers can select a link named “Bonus Offers” and then view the list of bonus offers and also be able to claim the offer online. This is a customization as Websphere commerce does not provide such feature out-of-the-box (OOTB).
This getBonusOffers functionality was implemented as an external web service that is hosted on Oracle Service Bus (OSB). Websphere Commerce was customized by creating a client for invoking the outbound Webservice. I will cover the details of creating a web servi ce client in websphere commerce in my later posts.
The problem that I was facing was that when the webservice was called to get all the bonus offers, WCS would display the offers if the webservice response was within a specific size limit (I tested it and found to be around 15KB response size) over and above which WCS wouldn’t display the responses as the invocation framework of WCS was returning a null response object.
There was nothing in the System logs related to this. I had to enable the trace levels to all for the components:
com.ibm.commerce.wc.messaging.adapters.jcahttp.JCAHTTPManagedConnectionImpl
com.ibm.commerce.wc.messaging.adapters.jcahttp.ws.JCAHTTPWSManagedConnectionFactoryImpl
com.ibm.websphere.commerce.WC_SERVER
com.ibm.websphere.commerce.adapters.jcahttp
com.ibm.ws.webservices.*
com.ibm.websphere.commerce.WC_MESSAGING
com.ibm.websphere.commerce.WC_TRANSPORT_ADAPTER
com.ibm.websphere.commerce.WC_SENSITIVE_INFO
Once I enabled the log levels to all and restarted the WAS app server, and clicked on the link which activates the web service call and I got the trace log. I executed the two scenarios, one for a successful response object (for smaller response size <15 KB) and other for a null response object (response size > 15KB).
For a successful invocation, I received Buffering the response, response content length: 7580 in the trace log.
Snippet of the trace log for a successful invocation is as below:
flushBuffer:(<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Header/><soapenv:Body><offers:GetBonusOfferDetailsRequest xmlns:offers="http://www.thegoodguys.com.au/ns/GetBonusOffers">
<offers:StoreId>27</offers:StoreId>
</offers:GetBonusOfferDetailsRequest></soapenv:Body></soapenv:Envelope>)
[26/10/10 18:49:09:473 EST] 00000052 1 UOW= source=com.ibm.ws.webservices.engine.SOAPPart class=com.ibm.ws.webservices.engine.SOAPPart method=writeTo org= prod= component= thread=[WebContainer : 0]
Exit: SOAPPart writeTo FORM_SOAPENVELOPE
[26/10/10 18:49:09:473 EST] 00000052 1 UOW= source=com.ibm.ws.webservices.engine.SOAPPart class=com.ibm.ws.webservices.engine.SOAPPart method=_clearCache org= prod= component= thread=[WebContainer : 0]
Clear SOAPPart Cache
[26/10/10 18:49:09:473 EST] 00000052 < UOW= source=com.ibm.websphere.commerce.WC_MESSAGING class=c8e64ba:12be77ebf6b:-7fff method=com.ibm.commerce.messaging.outboundservice.SOAPWrapperRecordImpl.write(OutputStream) org=IBM prod=WebSphere Commerce component=WC_MESSAGING thread=[WebContainer : 0]
Exit
[26/10/10 18:49:10:255 EST] 00000052 1 UOW= source=com.ibm.websphere.commerce.adapters.jcahttp class=com.ibm.commerce.wc.messaging.adapters.jcahttp.JCAHTTPInteractionImpl method=execute(InteractionSpec interactionSpec, Record inputRecord, Record outputRecord) org= prod= component= thread=[WebContainer : 0]
Buffering the response, response content length: 7580
[26/10/10 18:49:10:255 EST] 00000052 > UOW= source=com.ibm.websphere.commerce.WC_MESSAGING class=c8e64ba:12be77ebf6b:-7fff method=com.ibm.commerce.messaging.outboundservice.SOAPWrapperRecordImpl.read(InputStream) org=IBM prod=WebSphere Commerce component=WC_MESSAGING thread=[WebContainer : 0]
Entry parm0=<< input stream >>
However, for an unsuccessful invocation the trace log had: Not buffering the response, returning the inputstream, data may or may not be immediately available.
I checked if there was a problem at the web service itself. However, there was no problem at the web service level because I used SoapUI to test the web service and I could get the response xml back.
When I was searching backed by a clue by IBM Labs, I found that this is a known problem and there is a websphere commerce fix provided by IBM.
The problem was that websphere commerce did not parse for response when Content-Length header was not available in the response. For smaller responses, the Content-Length http header was available and hence WCS was displaying the response whereas for large responses, there was no Content-Length header in the response which made WCS think that there was no response and hence return a null response object before the response body could processed.
Scenario 1 for short response
Date Tue, 26 Oct 2010 17:23:32 GMT
#status# HTTP/1.1 200 OK
Content-Length 7508
Content-Type text/xml; charset=utf-8
X-Powered-By Servlet/2.5 JSP/2.1
Scenario 2 for large response
Transfer-Encoding chunked
Date Tue, 26 Oct 2010 17:24:00 GMT
#status# HTTP/1.1 200 OK
Content-Type text/xml; charset=utf-8
X-Powered-By Servlet/2.5 JSP/2.1
We can see that there is no Content-Length http header in scenario 2 whereas there is a response body. Also, the Transfer-Encoding http header is set to “chunked”.
The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer containing entity-header fields. This allows dynamically produced content to be transferred along with the information necessary for the recipient to verify that it has received the full message.
Since the messages are passed as chunks, there is no Content-Length header present. Content-Length header is present only when the actual size of the message and the size of the transmission is the same. In case of “chunked” the sizes are different.
Since the messages are passed as chunks, there is no Content-Length header present. Content-Length header is present only when the actual size of the message and the size of the transmission is the same. In case of “chunked” the sizes are different.
Resolving the Problem
Download the fix pack 1.0.0.0-WS-WCFeaturePack1-IF1142.zip. Extract the .pak file to the WC_UpdateInstaller/maintenance folder. Run Update.bat from the update installer folder. This will install the fix.
Once the fix is installed, update the wc-server.xml with the following
Open wc-server.xml and find <InteractionSpec node in the XML for the class com.ibm.commerce.wc.messaging.adapters.jcahttp.ws.JCAHTTPWSInteractionSpecImpl as in
On a websphere commerce developer toolkit you can find the wc-server.xml file in <<WC_ToolkitEE_InstallDir\xml\config\>>.
For a commerce server installation, update the file at <<CommerceServer_InstallDir>>\instances\<<instance_name>>\xml\<<instance_name.xml>>.
Once the instance file is modified, you may require to update the the current EAR in the application server. The recommended way is to use the updateEAR ant build target to update the application server EAR configuration file with the instance XML configuration. This is done using the following command
Ideally, you should refrain from modifying the wc-server.xml file manually in <<AppServ_InstallDir>>\ \profiles\<<instance>>\installedApps\<<instance>_cell\WC_<<Instance>>.ear\xml\config. Instead use the above command updateEAR ant target.
For a commerce server installation, update the file at <<CommerceServer_InstallDir>>\instances\<<instance_name>>\xml\<<instance_name.xml>>.
Once the instance file is modified, you may require to update the the current EAR in the application server. The recommended way is to use the updateEAR ant build target to update the application server EAR configuration file with the instance XML configuration. This is done using the following command
WC_installdir/bin/config_ant.bat -DinstanceName= instance_name UpdateEAR
Ideally, you should refrain from modifying the wc-server.xml file manually in <<AppServ_InstallDir>>\ \profiles\<<instance>>\installedApps\<<instance>_cell\WC_<<Instance>>.ear\xml\config. Instead use the above command updateEAR ant target.
If you have manually modified the wc-server.xml in the appserver EAR, then ensure that you also have the instance xml updated with the modification if not then during the next deployment, the Application server EAR configuration might be overwritten by the instance XML and you loose all changes.
<OutboundConnector default="true" enabled="true" id="-101"
name="HTTP-WS" retries="3">
<JNDI JndiName="eis/JCAHTTP-WS" display="false"/>
<ConnectionSpec
ClassName="com.ibm.commerce.wc.messaging.adapters.jcahttp.JCAHTTPConnectionSpecImpl" default="true"/>
<InteractionSpec
ClassName="com.ibm.commerce.wc.messaging.adapters.jcahttp.ws.JCAHTTPWSInteractionSpecImpl" default="true">
and add the following attribute / property below the above highlighted line
<EditableProperty Admin="bufferResponse"
display="false"
editable="yes"
name="setIsBufferResponse"
value="false"/>
Once the files are updated, restart the websphere application server. This should resolve the problem and you should be able to get larger response sizes from a web service call.
More details at the below IBM support site link
http://www-01.ibm.com/support/docview.wss?uid=swg1JR36471
