Fixes are available
Rational Performance Test Server 8.6
Rational Test Virtualization Server 8.6
Rational Integration Tester 8.6
Rational Integration Tester Fix Pack 1 (8.6.0.1) for 8.6
Rational Test Virtualization Server Fix Pack 1 (8.6.0.1) for 8.6
Rational Performance Test Server Fix Pack 1 (8.6.0.1) for 8.6
Rational Integration Tester Fix Pack 2 (8.6.0.2) for 8.6
Rational Performance Test Server Fix Pack 2 (8.6.0.2) for 8.6
Rational Test Virtualization Server Fix Pack 2 (8.6.0.2) for 8.6
Rational Integration Tester Fix Pack 3 (8.6.0.3) for 8.6
Rational Performance Test Server Fix Pack 3 (8.6.0.3) for 8.6
Rational Test Virtualization Server Fix Pack 3 (8.6.0.3) for 8.6
Rational Integration Tester Fix Pack 4 (8.6.0.4) for 8.6
Rational Performance Test Server Fix Pack 4 (8.6.0.4) for 8.6
Rational Test Virtualization Server Fix Pack 4 (8.6.0.4) for 8.6
APAR status
Closed as program error.
Error description
Valid messages that were created from a WSDL show validation problems in IBM Rational Integration Tester (RIT) STEPS TO REPRODUCE: 1. Import the WSDL into Schema Library 2. Create a Send Request test action. 3. Configure the HTTP transport. 4. Paste existing message content into the text node of the message. 5. Associate the message with the WSDL EXPECTED RESULTS: The message is valid and no red crosses appear in the message tree. ACTUAL RESULTS: Red crosses appear to show that one or more elements are invalid.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: * * All users of Rational Integration Tester * **************************************************************** * PROBLEM DESCRIPTION: * * It is possible for an XML message to be validated * * incorrectly by Tester resulting in red crosses being shown * * even though the message is compliant to the WSDL. * **************************************************************** * RECOMMENDATION: * **************************************************************** This problem is occurs when there is a local element referencing a abstract type that is already being processed by the RIT xsd parser. e.g. Given the element and types below <xsd:element name="object" type="Object" /> <xsd:complexType name="Object" abstract="true"> <xsd:sequence> <xsd:element name="childObject" type="Object" /> </xsd:sequence> </xsd:complexType> <!-- A ConcreteObject type that extends the abstract Object type --> <xsd:complexType name="ConcreteObject" abstract="false"> <xsd:complexContent> <xsd:extension base="Object"> <xsd:sequence> <xsd:element name="concreteField" type="xsd:string" /> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> the local element 'childObject' is of type Object which is the parent type and therefore will already be on the transformation stack. The logic that handles this scenario did not cater for the case where the type is abstract which means additional processing is required to determine which other types are extension ( ConcreteObject ) so that they and contents ( concreteField ) can be made available .
Problem conclusion
This problem has been resolved in Rational Integration Tester 8.6.0.
Temporary fix
Comments
APAR Information
APAR number
PI12541
Reported component name
RATL TEST WORKB
Reported component ID
5725G7900
Reported release
850
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2014-02-26
Closed date
2014-07-04
Last modified date
2014-07-04
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
RATL TEST WORKB
Fixed component ID
5725G7900
Applicable component levels
R800 PSN
UP
R801 PSN
UP
R850 PSN
UP
R851 PSN
UP
R860 PSY
UP
Document Information
Modified date:
15 October 2021