Re: [Openoss-devel] tipEntityGetMultiple stereotype not generating correct response iterator element and other comments

[Xose R. S. V. <xr...@op...>]

Hi Craig I have fixed the velocity template that miss the behaivour that 
you describe in your email.

I will analyze the filtering model and your proposals now.
Regards
El 11/08/2012 11:42, Craig Gallen (opennms) escribió:
> Hi Xose, Marc
>
> Once again I'm afraid I've come up with a new bug in the xml generated 
> by the soap generator and some other questions. I have found this 
> while trying to get the PM model implementation to generate correctly.
>
> 1.Problem:  tipEntityGetMultiple stereotype not generating correct 
> iterator response element
>
> In pm_cbe_perf_mon_coll_adhoccollectionservice_msg.xsd we can see two 
> examples of generated iterators;
>
> a)    getTrackingRecords is an explicit method declared in the 
> AdhocCollectionService with stereotype settings 'isBulkPotential' and 
> 'bulk transfer pattern = ITERATOR'.
> In the this case the response object getTrackingRecordsResponse 
> correctly extends iterator:CommonResponse
>    <xsd:complexType name="getTrackingRecordsResponse">
>       <xsd:complexContent>
>          <xsd:extension base="iterator:CommonResponse">
>             <xsd:sequence>
>                <xsd:element name="trackingRecords" 
> type="problem:TrackingRecordResultWithIterator" minOccurs="0" 
> maxOccurs="1">
> ... etc
>
> b)     getAdhocCollections is generated using the tipEntityGetMultiple 
> stereotype on the AdhocCollection entity
> in this case the response object getAdhocCollectionsResponse 
> incorrectly does not extend iterator:CommonResponse
>    <xsd:complexType name="getAdhocCollectionsResponse">
>       <xsd:sequence>
>          <xsd:element name="AdhocCollections" 
> type="tns:AdhocCollectionResultWithIterator" minOccurs="0" maxOccurs="1">
>  ... etc
>
> This is a bug and needs fixed quickly for the PM interface to work. We 
> need to change the soap generator to ensure that all iterator 
> responses extend from iterator:CommonResponse whether explicitly 
> declared in a method stereotype or declared through the 
> tipEntityGetMultiple stereotype. i.e.;
>    <xsd:complexType name="getAdhocCollectionsResponse">
>       <xsd:complexContent>
>          <xsd:extension base="iterator:CommonResponse">
>               <xsd:sequence>
>                    <xsd:element name="AdhocCollections" 
> type="tns:AdhocCollectionResultWithIterator" minOccurs="0" maxOccurs="1">
>  ... etc
>
> ____________
>
> 2. Question / feature request - needs consideration by the team
> The filtering mechanism seems overly complex and very different 
> between the use of primitive.filter and tipEntityGetMultiple
> This is a plea to think through whether we could simplify the template 
> filtering mechanism to support any type of entity rather than having 
> it type specific. The comments below are observations and will need a 
> bit more thinking through but I think they align with what is needed 
> for the inventory interface.
>
> In the TIP Profile the primitive.filter has the following 
> documentation; 'Primitive filter datatype corresponding to a choice of 
> template or query filter'. This is not what we generate.
>
> The generated XML for attribute filter type primitive.filter in the 
> ResourceAlarmRetreivalService ( RAM Model)  is
> <xsd:element name="filter" type="filter:XPathQueryFilter" 
> minOccurs="0" maxOccurs="1">
>
> In other word there is no choice of template or query filter. 
> primitive.filter only uses xpath
>
> In the getAdhocCollections request generated from the 
> tipEntityGetMultiple stereotype we generate
> attribute filter of type   AdhocCollectionFilterChoice
>
> <xsd:complexType name="getAdhocCollectionsRequest">
>       <xsd:complexContent>
>          <xsd:extension base="iterator:CommonRequest">
>             <xsd:sequence>
>                <xsd:element name="filter" 
> type="tns:AdhocCollectionFilterChoice" minOccurs="0" maxOccurs="1">
> ... etc
>
>    <xsd:complexType name="AdhocCollectionFilterChoice">
>       <xsd:choice>
>          <xsd:element name="templateFilter" 
> type="tns:AdhocCollectionTemplateFilter" minOccurs="0" maxOccurs="1"/>
>          <xsd:element name="queryFilter" 
> type="filter:XPathQueryFilter" minOccurs="0" maxOccurs="1"/>
>       </xsd:choice>
>    </xsd:complexType>
>
>    <xsd:complexType name="AdhocCollectionTemplateFilter">
>       <xsd:complexContent>
>          <xsd:extension base="filter:TemplateFilter">
>             <xsd:sequence>
>                <xsd:element name="templates" 
> type="tns:ArrayOfAdhocCollectionTemplate" minOccurs="0" maxOccurs="1"/>
>             </xsd:sequence>
>          </xsd:extension>
>       </xsd:complexContent>
>
> In other word we have a choice of AdhocCollectionTemplateFilter or the 
> XPathQueryFilter which we could get from primitive.filter above 
> (although the signature is very different). This is overly complex and 
> inconsistent. We clearly need primitive.filter to generated the same 
> sort of selection mechanisms as tipEntityGetMultiple but the 
> primitive.filter template filter needs to be generic to any entity 
> type rather than specific to a particular entity as in 
> AdhocCollectionTemplateFilter
>
> Would it be possible for both primitive.filter and 
> tipEntityGetMultiple to generate something like;
>
>    <xsd:complexType name="FilterChoice">
>       <xsd:choice>
>          <xsd:element name="templateFilter" type="tns:TemplateFilter" 
> minOccurs="0" maxOccurs="1"/>
>          <xsd:element name="queryFilter" 
> type="filter:XPathQueryFilter" minOccurs="0" maxOccurs="1"/>
>       </xsd:choice>
>    </xsd:complexType>
>
>    <xsd:complexType name="TemplateFilter">
>       <xsd:complexContent>
>             <xsd:sequence>
>                <xsd:element name="templates" 
> type="tns:ArrayOfTemplate" minOccurs="0" maxOccurs="1"/>
>             </xsd:sequence>
>       </xsd:complexContent>
>
> where all Entity Template types then extend Template?
>
> What do you think?
>
> Craig
>
>
>
>
>
>


-- 

*Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D
T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029
www.optaresolutions.com
<http://www.optaresolutions.com>
Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com>