I think I see paramsToSend get added in sendBody in frameworks/projects/rpc/src/mx/rpc/http/AbstractOperation.as
I think I see it "serialize" the object into a string. If OrderedObject doesn't work, you can write your own Proxy subclass and control the order. But interestingly, the code also looks like you can give HTTPService.send() the request string instead of an object of name/value pairs and it will use the string. HTH, -Alex On 7/11/17, 9:16 AM, "Jeffry Houser" <[email protected]> wrote: >Hi Alex, > > Interesting, that has potential. > > The potential problem is that the mx.rpc.httpAbstractOperation would >need an extension or rework, because it seems to copy my given >parameters into a paramsToSend object. I never could find the code >where paremsToSend is added to the outgoing request, though. > > >On 7/11/2017 12:04 PM, Alex Harui wrote: >> Hi Jeffry, >> >> Good you got something to work. I just had a thought that maybe you >>could >> pass in an mx.utils.OrderedObject as the parameters and still use >> HTTPService. >> >> -Alex >> >> On 7/11/17, 6:44 AM, "Jeffry Houser" <[email protected]> wrote: >> >>> Thanks Kyle and Javier for their thoughts. >>> >>> I was eventually able to do this using the lower level APIs of >>> URLRequest and URLLoader. I also had to manually create the parameter >>> string. Generically, the code is like this: >>> >>> >>> var parameters : String = ''; >>> parameters += "firstParameter=firstOne&"; >>> parameters += "amount=100&"; >>> parameters += "otherParameters=Other Random Misc Data&"; >>> parameters+= "lastParameter=LastOne"; >>> >>> >>> var r:URLRequest = new URLRequest(yourURLHere); >>> r.data = parameters; >>> r.method = URLRequestMethod.POST; >>> r.contentType = "application/x-www-form-urlencoded"; >>> >>> var l:URLLoader = new URLLoader(); >>> l.addEventListener(Event.COMPLETE, myResultMethod); >>> l.addEventListener(IOErrorEvent.IO_ERROR, myFailureMethod ); >>> l.addEventListener(SecurityErrorEvent.SECURITY_ERROR, myFailureMethod >>>); >>> l.load(r); >>> >>> Not as easy as using HTTPService, but functional and resolves this as >>> possible error cause when dealing with the vendor who built this API. >>> >>> Updated Stack Overflow Post: >>> >>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackov >>>er >>> >>>flow.com%2Fquestions%2F44924870%2Fcan-i-control-the-parameter-order-in-a >>>n- >>> >>>httpservice-post&data=02%7C01%7C%7Ced1ef0f084764fecd49108d4c862f8ac%7Cfa >>>7b >>> >>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636353774788091375&sdata=LvnEYTMT >>>wF >>> lYPCZ7p%2Bu50adnHbdATVmP8ZPIQVxK3xU%3D&reserved=0 >>> >>> My blog post on the issue: >>> >>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jef >>>fr >>> >>>yhouser.com%2Findex.cfm%2F2017%2F7%2F11%2FHow-can-I-control-the-paramete >>>r- >>> >>>order-when-doing-a-HTTP-POST-call-from-Flex&data=02%7C01%7C%7Ced1ef0f084 >>>76 >>> >>>4fecd49108d4c862f8ac%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636353 >>>77 >>> >>>4788091375&sdata=3jiLTEt%2FeZ2dwF2GgRyq0i1KPrCUAp1IhgAfPispLPY%3D&reserv >>>ed >>> =0 >>> >>> Thanks again! >>> >>> >>> On 7/5/2017 1:21 PM, Javier Guerrero García wrote: >>>> Hi Jeffrey! >>>> >>>> My 4 cents :) >>>> >>>> 1. Maybe defining the <mx:request> inside the <mx:HTTPservice> >>>> declaration (and just binding the contents) helps somewhat. Maybe not, >>>> but at least it's prettier :) >>>> >>>> >>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhelp.ad >>>>ob >>>> >>>>e.com%2Fen_US%2FFlex%2F4.0%2FAccessingData%2FWS2db454920e96a9e51e63e3d1 >>>>1c >>>> >>>>0bf69084-7fdc.html&data=02%7C01%7C%7Ced1ef0f084764fecd49108d4c862f8ac%7 >>>>Cf >>>> >>>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636353774788091375&sdata=h0BE >>>>Kg >>>> IfRGJ%2FZ0bSng4jra5JYMSv5blS0JBgQ8GRZZE%3D&reserved=0 >>>> >>>> 2. Stupid one: try method="POST" (uppercase), just in case :) >>>> >>>> 3. According to the mx.rpc.httpAbstractOperation code, if >>>> typeof(parameters) == "object" it iterates and messes up with the >>>> order, but if it's not, it should just copy it to "paramsToSend" >>>> ("else paramsToSend=parameters;"). BUT, on some HTTP request >>>> implementations (for instance jQuery, not sure about flex), if you >>>> pass a string instead of a proper object as data, it "assumes" you >>>> want to make a GET instead of a POST. Are you 100% sure that, when you >>>> pass "parameters" as a string, you are issuing an empty *_POST_* >>>> request? >>>> >>>> 4. Instead of Flash network monitor, just get a quick PHP somewhere >>>> and monitor exactly what is arriving (and how) in your HTTP call (a >>>> simple <?php var_dump($_REQUEST); ?> would do). I'm not really sure if >>>> the sorting is done by the monitor itself, and I'm really perplexed >>>> about ObjectUtil.getClassInfo(parameters) does sort the object >>>> properties alphabetically (what a waste of CPU cycles!). >>>> >>>> >>>> P.S. And please, fire/kill the intern who programmed the server side >>>> trusting the order of the parameters.... I'm sure there is an RFC >>>> somewhere that you can throw at his face explicitly stating that >>>> params order should NOT be relevant when parsing an HTTP query string. >>>> >>>> >>>> On Tue, Jul 4, 2017 at 4:55 PM, Jeffry Houser <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi Everyone, >>>> >>>> I'm updating a Point of Sale system that was built with Flex >>>>and >>>> AIR using the Cairngorm framework. >>>> >>>> The code integrates with a custom server provided by my client's >>>> payment processor vendor. Part of their requirement is that >>>> parameters be form posted to their server in a specific order. >>>>The >>>> Apache Flex framework does not appear to retain the parameter >>>> order of the object's parameters. Has anyone run into this >>>>before? >>>> >>>> More specifics, with code: >>>> >>>> 1) Service object set up in the Cairngorm Services.mxml: >>>> >>>> <mx:HTTPService id="service" >>>> showBusyCursor="false" >>>> requestTimeout="240" >>>> method="post" >>>> contentType="application/x-www-form-urlencoded" >>>> url="http://localhost.:16448/"; >>>> resultFormat="e4x" >>>> /> >>>> >>>> 2) Create Parameter object and call service method; this is done >>>> in a Cairngorm Delegate: >>>> >>>> var parameters : Object = new Object(); >>>> parameters.firstParameter = "firstOne"; >>>> parameters .amount = 100; >>>> parameters .otherParameters = "Other Random Misc Data"; >>>> parameters.lastParameter = "LastOne"; >>>> >>>> Then make the call: >>>> >>>> var call : Object = this.service.send(parameters); >>>> call.addResponder( this.responder ); >>>> >>>> 3) Flex Framework class mx.rpc.httpAbstractOperation, starting >>>> around line 862. This appears to loop over properties using >>>> classinfo.properties . This seems to get an alphabetical list of >>>> properties from my object and add them to the paramsToSend >>>>object: >>>> >>>> >>>> else if (ctype == CONTENT_TYPE_FORM) >>>> { >>>> paramsToSend = {}; >>>> var val:Object; >>>> >>>> if (typeof(parameters) == "object") >>>> { >>>> //get all dynamic and all concrete properties >>>>from >>>> the parameters object >>>> var classinfo:Object = >>>> ObjectUtil.getClassInfo(parameters); >>>> >>>> for each (var p:* in classinfo.properties) >>>> { >>>> val = parameters[p]; >>>> if (val != null) >>>> { >>>> if (val is Array) >>>> paramsToSend[p] = val; >>>> else >>>> paramsToSend[p] = val.toString(); >>>> } >>>> } >>>> } >>>> else >>>> { >>>> paramsToSend = parameters; >>>> } >>>> } >>>> >>>> 4) Looking at the raw data in the Flash Builder Network Monitor; >>>> the final request doesn't have the parameters in alphabetical >>>>order. >>>> >>>> >>>> >>>>otherParameters=Other%20Random%20Misc%20Data&lastParameter=LastOne&firs >>>>tP >>>> arameter=firstOne&amount=100 >>>> >>>> With this small sample it appears that the parameters are in >>>> reverse alphabetical order, but with the actual request data they >>>> are in a seemingly random--but always consistent--order. >>>> >>>> >>>> ------- >>>> >>>> Thanks for reading this far. My first attempt at a solution was >>>> to create the POST parameter string manually and use that as the >>>> parameter object. However in that case the body of the POST >>>> request was blank when reviewing it in the service monitor. >>>> >>>> So, has anyone run into this before? What was your solution? >>>> >>>> >>>> >>>> -- >>>> >>>> Jeffry Houser >>>> Technical Entrepreneur >>>> >>>> >>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dot >>>>-c >>>> >>>>om-it.com&data=02%7C01%7C%7Ced1ef0f084764fecd49108d4c862f8ac%7Cfa7b1b5a >>>>7b >>>> >>>>34438794aed2c178decee1%7C0%7C0%7C636353774788091375&sdata=abgmccKGMtx5g >>>>V0 >>>> as9JIlFopMaW5ojvyFuPwBEdMCtI%3D&reserved=0 >>>> >>>> >>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jef >>>>fr >>>> >>>>yhouser.com&data=02%7C01%7C%7Ced1ef0f084764fecd49108d4c862f8ac%7Cfa7b1b >>>>5a >>>> >>>>7b34438794aed2c178decee1%7C0%7C0%7C636353774788091375&sdata=ALMfL5RGTLc >>>>5R >>>> da5JbBYkbfYgByJNh%2FfVfdfuTa3AaY%3D&reserved=0 >>>> 203-379-0773 <tel:203-379-0773> >>>> >>>> >>> -- >>> Jeffry Houser >>> Technical Entrepreneur >>> >>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dot- >>>co >>> >>>m-it.com&data=02%7C01%7C%7Ced1ef0f084764fecd49108d4c862f8ac%7Cfa7b1b5a7b >>>34 >>> >>>438794aed2c178decee1%7C0%7C0%7C636353774788091375&sdata=abgmccKGMtx5gV0a >>>s9 >>> JIlFopMaW5ojvyFuPwBEdMCtI%3D&reserved=0 >>> >>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jeff >>>ry >>> >>>houser.com&data=02%7C01%7C%7Ced1ef0f084764fecd49108d4c862f8ac%7Cfa7b1b5a >>>7b >>> >>>34438794aed2c178decee1%7C0%7C0%7C636353774788091375&sdata=ALMfL5RGTLc5Rd >>>a5 >>> JbBYkbfYgByJNh%2FfVfdfuTa3AaY%3D&reserved=0 >>> 203-379-0773 >>> > >-- >Jeffry Houser >Technical Entrepreneur >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dot-co >m-it.com&data=02%7C01%7C%7Cb0438448d6174807fc3108d4c8783016%7Cfa7b1b5a7b34 >438794aed2c178decee1%7C0%7C0%7C636353865937125017&sdata=GaI1NHqx0jtaDQQP20 >XUZBcxyuVYUgXoMzXAXw9NAQk%3D&reserved=0 >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jeffry >houser.com&data=02%7C01%7C%7Cb0438448d6174807fc3108d4c8783016%7Cfa7b1b5a7b >34438794aed2c178decee1%7C0%7C0%7C636353865937125017&sdata=Zfu7951H7w26%2Bl >xHq81O%2Ft1j2FOs%2Fnifb94iHoazV6Q%3D&reserved=0 >203-379-0773 >
