Fixes are available
6.1.0.37: Java SDK 1.5 SR12 FP3 Cumulative Fix for WebSphere
7.0.0.17: Java SDK 1.6 SR9 FP1 Cumulative Fix for WebSphere Application Server
6.1.0.47: WebSphere Application Server V6.1 Fix Pack 47
7.0.0.27: Java SDK 1.6 SR13 FP2 Cumulative Fix for WebSphere Application Server
6.1.0.39: Java SDK 1.5 SR12 FP4 Cumulative Fix for WebSphere Application Server
6.1.0.41: Java SDK 1.5 SR12 FP5 Cumulative Fix for WebSphere Application Server
6.1.0.43: Java SDK 1.5 SR13 Cumulative Fix for WebSphere Application Server
6.1.0.45: Java SDK 1.5 SR14 Cumulative Fix for WebSphere Application Server
6.1.0.47: Java SDK 1.5 SR16 Cumulative Fix for WebSphere Application Server
7.0.0.19: Java SDK 1.6 SR9 FP2 Cumulative Fix for WebSphere Application Server
7.0.0.21: Java SDK 1.6 SR9 FP2 Cumulative Fix for WebSphere
7.0.0.23: Java SDK 1.6 SR10 FP1 Cumulative Fix for WebSphere
7.0.0.25: Java SDK 1.6 SR11 Cumulative Fix for WebSphere Application Server
7.0.0.27: Java SDK 1.6 SR12 Cumulative Fix for WebSphere Application Server
7.0.0.29: Java SDK 1.6 SR13 FP2 Cumulative Fix for WebSphere Application Server
7.0.0.45: Java SDK 1.6 SR16 FP60 Cumulative Fix for WebSphere Application Server
7.0.0.31: Java SDK 1.6 SR15 Cumulative Fix for WebSphere Application Server
7.0.0.35: Java SDK 1.6 SR16 FP1 Cumulative Fix for WebSphere Application Server
7.0.0.37: Java SDK 1.6 SR16 FP3 Cumulative Fix for WebSphere Application Server
7.0.0.39: Java SDK 1.6 SR16 FP7 Cumulative Fix for WebSphere Application Server
7.0.0.41: Java SDK 1.6 SR16 FP20 Cumulative Fix for WebSphere Application Server
7.0.0.43: Java SDK 1.6 SR16 FP41 Cumulative Fix for WebSphere Application Server
APAR status
Closed as program error.
Error description
Unexpected WS-Addressing header is in SOAP message due incomplete distribution of all the properties associated with the CScope activity so that Activity incorrectly propagated on web service request WSWS3173E: Error: Did not understand "MustUnderstand" header(s):{http://schemas.xmlsoap.org/ws/2004/10/wscoor}Coordina tionContext at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCSOAPHandler. checkSOAPSemantics(JAXRPCSOAPHandler.java:355) at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCSOAPHandler. invokeServerRequestHandler(JAXRPCSOAPHandler.java:18
Local fix
'com.ibm.ws.wsaddressingAndDependentsDisabled=true' system property which is able suppresses any WS-Addressing SOAP headers
Problem summary
**************************************************************** * USERS AFFECTED: All IBM WebSphere Application Server users * * of the Compensation Service. * **************************************************************** * PROBLEM DESCRIPTION: An Activity Context was incorrectly * * propagated on Web Service Request. * **************************************************************** * RECOMMENDATION: * **************************************************************** A module contained a web service import to a backend Customer Information Control System (CICS). This module was invoked from several other modules, some deployed on the same application cluster, and some on other application clusters within the same cell. When the Web Service module was invoked from an application deployed on the same cluster, the <soapenv:Header> element was empty, and the service worked correctly. However, when we invoked the web service module from an application deployed on another application cluster (for example, Cluster1.TestApp --> Cluster2.QueryApp), the following <soapenv:Header> was inserted into the SOAP request(truncated here for brevity): <wscoor:CoordinationContext soapenv:mustUnderstand="1" .... </wscoor:CoordinationContext> which caused the backend CICS system to reply with a fault: "Header block local name 'CoordinationContext' is not defined to CICS. Mustunderstand check failed for the header block." We have tried several changes/workarounds, none of which have been successful. The root cause here is that when the request was sent from Cluster1 to Cluster2 a Compensation Service (CScope) context was present on the thread and was sent to Cluster2. When it was imported on Cluster2, the CScope context was created in such a way that the CScope context would be sent on Web Service requests (as a CoordinationContext) - when the CScope context was originally created on Cluster1 it was created in such a way that the CScope context would not be propagated. Currently there is no way to influence this behaviour.
Problem conclusion
A custom property will be introduced to allow you to specify individual beans for which you do not want Activity Context headers to be added to Web Service requests. The custom property specifies a file that contains a list of beans, 1 entry per line. The format of each entry is as follows: application#module#bean where:- application is the name by which the application is known to the server module is the name of the archive file that contains the bean bean is the name of the bean For example: PM23497Remote#PM23497Client.jar#Remote For each server that you want to have the new behaviour enabled: 1. Login to the Administrative Console 2. Select Servers -> Application Servers -> server -> Container Services -> Compensation service 3. Select Custom Properties 4. Click New 5. Enter SUPPRESS_CSCOPE_ON_WS_CALLS as the name 6. Enter the fully-qualified path to the file that identifies the beans as the value 7. Click Ok 8. Save changes 9. Restart the server In addition to the custom property, the following conditions need to be satisfied for this functionality to be activated: 1. The Compensation Service must be enabled on the server. 2. The bean must not have any Compensation Service meta-data associated with it. Compensation Service meta-data appears in the file ibm-ejb-jar-ext-pme51.xmi under the META-INF directory in the jar containing the EJB beans. If the file does not exist, then you know you have no Compensation Service meta data. Compensation Service meta-data will be present if you have chosen to use compensators when building your application, or if you have checked the property "Run EJB methods under a BusinessActivity scope" for the bean. 3. The server must be restarted to enable any changes made to the file to become effective. The fix for this APAR is currently targeted for inclusion in fix packs 6.1.0.37 and 7.0.0.17. Please refer to the Recommended Updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
Temporary fix
Comments
APAR Information
APAR number
PM23497
Reported component name
WEBS APP SERV N
Reported component ID
5724H8800
Reported release
61A
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2010-09-29
Closed date
2010-11-17
Last modified date
2013-09-24
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
WEBS APP SERV N
Fixed component ID
5724H8800
Applicable component levels
R61A PSY
UP
R61H PSY
UP
R61I PSY
UP
R61P PSY
UP
R61S PSY
UP
R61W PSY
UP
R61Z PSY
UP
R700 PSY
UP
Document Information
Modified date:
25 October 2021