Was busy yesterday, finally got some replies in. I'll be pulling CVS, building and testing the Session stuff this AM.
Thanks for the code change. Curt Johnson - [EMAIL PROTECTED] The Technical Resource Connection, Inc. http://www.trcinc.com -----Original Message----- From: peter lin [mailto:[EMAIL PROTECTED] Sent: Thursday, January 29, 2004 12:38 PM To: JMeter Users List Subject: RE: HTTP Headers and Cookies in SOAP Requests thanks for the detailed response. That definitely gives me a better idea of what people are looking for. Most of the webservice stuff I've been doing is for internal consumption, so I haven't come across these types of issues yet. Curt Johnson <[EMAIL PROTECTED]> wrote: What we've got right now is Axis 1.0 with a custom patch to use a single session cookie on multiple endpoints. Our client is a .NET 1.0 thick app, which may or may not migrate to .NET 1.1 real soon now. I'm looking into upgrading our Axis to 1.1, but this may not happen for a while (till 1.2). I'm trying to use JMeter to imitate the .NET client. Without supporting the JSESSION cookie, I can't successfully maintain a session after I login. The headers are to handle the "Expect: 100-continue" and User Agent headers. User Agent probably isn't that important right now, but will be in the future. I believe setting there's an easy fix for this. I can set the session to true and pass the sessionID back to the cookie manager. I should be able to implement and test this pretty easily with my Echo servlet :) > We are looking at ditching the cookie session solution soon and moving > to SOAP headers. This is needed cause our SOAP needs to be transport > neutral and handle thin clients that don't support cookies. > As far as the overall improvements that I personally think would make > doing WebService tests easier: > 1. HTTP Proxy Server that has a TCPMON like listener, our .NET client > doesn't handle proxies (we didn't write it so we can't add it). have you tried the current proxy server in JMeter? I haven't used it myself. Perhaps Sebastian or Jordi can provide information about the feasible/ease of doing this. The problem is that the .NET client we have doesn't support proxies, so we can't get a request and response to work properly. > 2. Ability to suck data into User Parameter Preprocessor from a .csv > file or to point it at a .csv file. That would work as one line == one > set params so if you have 50 threads, thread 1 would get line 1 and line > 51 from the .csv file as params. Theoritically, this isn't all that hard, but it would require a bit of refactoring. The current process is the sampler reads the message from either (text area, file, or random file), creates a messageEnvelope, some other stuff and executes the request. to add pre-processor support, would mean the sampler has to first create the dom Document, parse and replace values, create messageEnvelope, other stuff and execute. We can discuss this offline. it might bore others. I noticed the ability to pull in the SOAP message from a file, but I was talking more about the user variables which are used for the HTTP Samplers as well. I'm already doing this with the regex extractor. I extract a SessionID from a SOAP response and insert it into the request in the next WebServices Sampler. Since that already works I would think that this would just require some changes to the User Defined Variables Config Element so that you could pull in the data from a .csv file. > 3. Components of the same "type", ie WebServices Sampler, seems to > "share" data on fields between instances in the GUI. I can give them > unique values by hand editing the test plan xml. per sampler, it does share all the same values, like SOAPAction, URL, and so on. I don't think this should be the case. Our test needs to hit different endpoints for most requests. We need a different SOAPAction and URL for most of our Samplers. Being able to use the HTTP Request Defaults to set the host and port would be useful here so we could change that rapidly for all requests in the test. > 4. On the WebServices Sampler, it doesn't seem to like our WSDL when > trying to extract methods, not a big deal and we're using an old version > of Axis. the current method of reading the WSDL is very simple and not complaint or even remotely close. I basically send a normal http request to the URL, get the inputstream, create DOM document and get the nodes. If it deviates from WSDL spec slightly, the helper class probably won't find it. The actual process is it gets element by name with "soap:operation" as the node name. This isn't really high on my priority list. I thought it was a cool feature, but we already know the operations for each of the endpoints, so it wasn't something I really needed. > 5. Need to be able to use the HTTP Request Defaults with the WebServices > Sampler. when you say defaults, are you referring to "SOAPAction", cookies, or headers? The HTTP Request Defaults element handles host, port, path and parameters. But the HTTP Headers and Cookie Manager should be important as well. > 6. We may only need the Session Cookie support you mentioned in your > previous email, but I'm wondering if the Axis client uses that for > multiple endpoints, which would follow HTTP rules, but we had to patch > 1.0 to provide a single Session Cookie across endpoints. Would > setMaintainSession(true) share this cookie to subsequent WebServices > Samplers in a controller? > I've done quite a bit of testing using JMeter and the HTTP Samplers > previously, that worked superbly, other than some GUI and data import > issues. > If the WebServices stuff can match the quality of the HTTP testing I've > done, I think that would be great. BTW, the Regex Extractor is awesome. > I'm using it to pull session id stuff out of the SOAP message and pass > it into the subsequent requests. the credit goes to sebastian and jordi. glad to hear the Regex work with the webserviceSampler. I haven't tried that, so it's good to know it works. > If you want, I'll give the setMaintainSession fix a shot and let you > know how well that works, but I'm sure myself or someone else will need > the extra functionality we've talked about. I should be able to implement the cookie support and test it on my way home :) hopefully by the time I get home it will be done and I can check it in. I also have a Echo asmx app I can test the cookies with, so maybe that would be sufficient for now. that way I can think about the additional enhancements carefully and figure out a good/clean way to support that functionality. peter lin --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
