Products | Versions |
---|---|
TIBCO ActiveMatrix BusinessWorks | - |
Not Applicable | - |
Resolution:
Though the SOAP Envelope gives the users ability to declare any attribute as part of the
Header element, the declaration of this in the Envelope schema is as shown:
<xs:complexType name="Header">
<xs:sequence>
<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" />
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>
processContents="lax" indicates that if there is schema available to validate the Header element
then BW *has* to use this schema. If this schema does not declare the correct attributes for
the request/response (like "actor"), you will see this error.
Q)What needs to be done to accommodate this?
The absract wsdl or concrete wsdl(if the error is on the client side) that defines the Header
element should be changed to add the "actor" attribute to the element definition.
For example, in the wsdl, if the Header element is declared as:
<message name="HeaderMessage">
<part name="Header1" element="ns2:ParHeader"/>
</message>
And ParHeader is defined as
<xsd:complexType name="ParHeaderType">
<xsd:sequence>
<xsd:element name="HostEnvironment" type="xsd:string"/>
<xsd:element name="UserId" type="pc:UserIdType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="ParHeader" type="pc:ParHeaderType"/>
Change this to(note the extra attribute "actor"):
<xsd:complexType name="ParHeaderType">
<xsd:sequence>
<xsd:element name="HostEnvironment" type="xsd:string"/>
<xsd:element name="UserId" type="pc:UserIdType"/>
</xsd:sequence>
<xsd:attribute ref="SOAP-ENV:actor"/>
</xsd:complexType>
<xsd:element name="ParHeader" type="pc:ParHeaderType"/>
Make sure, prefix SOAP-ENV refers to http://schemas.xmlsoap.org/soap/envelope/
Q)What about mustUnderstand attribute? Why is this automatically available in BW?
There might be users who use "mustUnderstand" attribute without defining it in
the wsdl, which results in user errors.BW tries to accommodate that by defining
an optional "mustUnderstand" attribute transparently. It is not practical to
extend this and guess what other attributes might be used. So currently mustUnderstand is available by default and not any other attribute.