Hi,

Yes, exactly.

I verified this by manually changing the attribute order in the WSDL-file and
pressing Reload. If I choose preserve mapping it will retain the old order,
and if I reset the mapping it will re-order the fields.

         Best Regards - Misi, RRR AB, http://rrr.se

> So if you have a Filter and say to Reload the WSDL and Preserve Mapping then
> DevStudio just adds the new attributes/elements to the end instead of in the
> sequence where they are defined?
>
> That is a BUG as it will render the web service call completely unusable.
>
> Fred
>
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
> Sent: Friday, July 31, 2015 5:25 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Outbound WebService call attribute sequence
>
> Hi,
>
> I think I found the problem. If I "Reload" the WSDL and choose "Yes" to the
> "Preserve Mapping" question, any new attributes will be added to the end.
>
> I really thought I hade tried starting from scratch with a new Action before I
> started this email discussion, but apparently I did a mistake...
>
> I do not think that preserving a mapping is not the same thing as preserving
> and old sequence order...
>
> I have tested this in DevStudio 7.6.04 SP5 and 8.1.2.
>
>         Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>
> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
> Find these products, and many free tools and utilities, at http://rrr.se.
>
>> Does it always come in same order?
>>
>>
>> I see that <ns0:RequestID/> is null in the xml, but the definition states,
>> <xs:element name="RequestID" type="xs:string"/>. Here does minOccurs="1".
>>
>> --
>> J
>>
>> 2015-07-30 16:15 GMT+02:00 Misi Mladoniczky <m...@rrr.se>:
>>
>>> Hi Fred and Jarl,
>>>
>>> This is an external web service we are consuming, and the order of the
>>> attributes does not seem to comply with the WSDL file we have loaded...
>>>
>>> From WSDL file:
>>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
>>> targetNamespace="http://www.abc.com/Schemas/abc.xsd";
>>> elementFormDefault="qualified" attributeFormDefault="unqualified">
>>>  <xs:complexType name="INC_CreateType">
>>>   <xs:sequence>
>>>    <xs:element name="RequestID" type="xs:string"/>
>>>    <xs:element name="MESSAGE_TYPE" type="xs:string"/>
>>> ...
>>>    <xs:element name="MI_INC_TICKET_TYPE" type="xs:string" minOccurs="0"/>
>>> ...
>>>    <xs:element name="MI_INC_countrySE" type="xs:string" minOccurs="0"/>
>>>    <xs:element name="MI_INC_sendtofaultix" type="xs:string" minOccurs="0"/>
>>>    <xs:element name="TIKSU_INC_ID" type="xs:string" minOccurs="0"/>
>>>   </xs:sequence>
>>>  </xs:complexType>
>>> </xs:schema>
>>>
>>>
>>> From SOAP-envelope in arjavaplugin.log when calling the external web
>>> service:
>>> <soapenv:Body><ns0:INC_Create xmlns:ns0="
>>> http://www.abc.com/Schemas/abc.xsd";>
>>>   <ns0:RequestID/>
>>>   <ns0:MESSAGE_TYPE>Update</ns0:MESSAGE_TYPE>
>>> ...
>>>   <ns0:TIKSU_INC_ID>IM766314</ns0:TIKSU_INC_ID>
>>>   <ns0:MI_INC_countrySE>SE</ns0:MI_INC_countrySE>
>>>   <ns0:MI_INC_sendtofaultix>Yes</ns0:MI_INC_sendtofaultix>
>>>   <ns0:MI_INC_TICKET_TYPE>NETWORK_INCIDENT</ns0:MI_INC_TICKET_TYPE>
>>> </ns0:INC_Create></soapenv:Body>
>>>
>>> As you see the MI_INC_TICKET_TYPE has a different order in the SOAP-message
>>> than in the WSDL-file.
>>>
>>> I will confess that I am not fully proficient in manually reading these
>>> files,
>>> but I have shown you the only occurrence of MI_INC_TICKET_TYPE in the WSDL
>>> file.
>>>
>>> The abc.xsd referenced does not really exist. Could that have anything to
>>> do
>>> with this? I would think not, but...
>>>
>>> In any event the order in which things are sent comply with the order in
>>> which
>>> the attributes show up in DevStudio.
>>>
>>>         Best Regards - Misi, RRR AB, http://rrr.se
>>>
>>> > You are consuming an external web service in a Filter?
>>> > The order of fields is what is specified in the WSDL from the external
>>> service
>>> >
>>> > If you are creating a service for an external app to consume you can
>>> define
>>> > the fields yourself by cutting and inserting fields before mapping (or
>>> making
>>> > your own schema XSD file and using that)
>>> >
>>> > Fred
>>> >
>>> > -----Original Message-----
>>> > From: Action Request System discussion list(ARSList)
>>> > [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
>>> > Sent: Thursday, July 30, 2015 7:12 AM
>>> > To: arslist@ARSLIST.ORG
>>> > Subject: Outbound WebService call attribute sequence
>>> >
>>> > Hi,
>>> >
>>> > We are doing an WebService to an external WebService that is dependent
>>> on the
>>> > sequence in which the fields are sent in the SOAP envelope.
>>> >
>>> > Can you control this? I am not seeing a clear pattern here
>>> unfortunately, but
>>> > it seems to send them in the same order as they appear in DevStudio.
>>> >
>>> > But this order is not the order of the WSDL file, nor is it alphabetical.
>>> >
>>> > It is not the order in which the mappings occur if you look in an
>>> exported
>>> > DEF-file.
>>> >
>>> > Any ideas?
>>> >
>>> >         Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
>>> 2011)
>>> >
>>> > Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
>>> > * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>>> > * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
>>> > Find these products, and many free tools and utilities, at http://rrr.se
>
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to