IBM Support

PI12541: MESSAGES CREATED FROM A WSDL SHOW RED CROSSES IN THE MESSAGE EDITOR

Subscribe

You can track all active APARs for this component.

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

More support for: Rational Test Workbench

Software version: 8.5

Reference #: PI12541

Modified date: 04 July 2014