Schema Errors due to Repeatable Apply Rules in XML response rule
As a requirement to make it more reusable, for some XML response mapping rules we have implemented several node elements with the "Apply Rule" option enabled, so that we can refer to other MapFrom rules with elements in it. Please see the examples below:
Though in the example above a requirement for the "deposit" element calling this rule is that it has to be repeatable, but not optional. So we need to get minOccurs=1 and maxOccurs=unbounded for this element in the generated WSDL. We have enabled the “Repeating” checkbox which we can find in the Node tab of the deposit element in parent response rule (the left picture).
In the child response rule (right picture), we have the deposit elements, and here the base element does not have the "Repeating" and "Optional" flag enabled. The elements here should be inserted in the parent response rule.
As a requirement to make it more reusable, for some XML response mapping rules we have implemented several node elements with the "Apply Rule" option enabled, so that we can refer to other MapFrom rules with elements in it. Please see the examples below:
Though in the example above a requirement for the "deposit" element calling this rule is that it has to be repeatable, but not optional. So we need to get minOccurs=1 and maxOccurs=unbounded for this element in the generated WSDL. We have enabled the “Repeating” checkbox which we can find in the Node tab of the deposit element in parent response rule (the left picture).
In the child response rule (right picture), we have the deposit elements, and here the base element does not have the "Repeating" and "Optional" flag enabled. The elements here should be inserted in the parent response rule.
When we validate the response through SoapUI, it then returns schema compliancy errors, namely: "Element not allowed: deposit in element deposits".
Notice that the maxOccurs does not appear in the generated WSDL (eventhough we have set the repeating flag):
<complexType name="getDepositsResponseType">
<sequence>
<element minOccurs="1" name="deposits">
<complexType>
<sequence>
<element minOccurs="1" name="deposit" type="nslt1:depositType" />
</sequence>
</complexType>
</element>
</sequence>
</complexType>
<element name="getDepositsResponse" type="nslt1:getDepositsResponseType" />
A workaround we implemented for now is to place all of the deposit elements in a single response rule. Sadly, this way it is not reusable in other response rules calling the “child” response rule.
Any idea on how to fix the schema compliancy with the reusablity in place? Currently we're on PRPC 6.3 SP1.