Return-Path: Delivered-To: apmail-jakarta-jmeter-user-archive@www.apache.org Received: (qmail 21991 invoked from network); 18 Mar 2009 03:32:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Mar 2009 03:32:14 -0000 Received: (qmail 30694 invoked by uid 500); 18 Mar 2009 03:32:11 -0000 Delivered-To: apmail-jakarta-jmeter-user-archive@jakarta.apache.org Received: (qmail 30675 invoked by uid 500); 18 Mar 2009 03:32:11 -0000 Mailing-List: contact jmeter-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "JMeter Users List" Reply-To: "JMeter Users List" Delivered-To: mailing list jmeter-user@jakarta.apache.org Received: (qmail 30664 invoked by uid 99); 18 Mar 2009 03:32:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Mar 2009 20:32:11 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates 64.233.182.189 as permitted sender) Received: from [64.233.182.189] (HELO nf-out-0910.google.com) (64.233.182.189) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Mar 2009 03:32:02 +0000 Received: by nf-out-0910.google.com with SMTP id 30so74019nfu.43 for ; Tue, 17 Mar 2009 20:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Kk1BMAaPN4/6cwqs4+PXf5YjuwBOAuEbqeO0hLA8eSM=; b=xyl3WAe4t5gg7X4UDIGGCjykIEPAquHsbSvwVVaw7ui7szUEz1JtG2lq1MxWvomgSA lTLzEGxLsy0gVr/onvWYMIN4Bm5ITY/JvJrejUUmtj5SSy8ssN+82CLEyzQ+6Tq+y4Kp DjrkHFTq3njve44wz+6weB+OGWopV3Nxkc48E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=G8YPNoDecszAUyo0Hy4y9pbQajYk71J/QV5kBLYzGljgMc4sk9mh7GTLUZy3LG80xB F1/u0Exq236CzVxUrpkJ+durldWJodGtkaTSkkk136nIR0NuYjuK3uloM4R5doDhSOBL dj/W09w/HQe2R88nA6s7eXcC/8O87rTThakdA= MIME-Version: 1.0 Received: by 10.210.120.17 with SMTP id s17mr567493ebc.54.1237347101355; Tue, 17 Mar 2009 20:31:41 -0700 (PDT) In-Reply-To: <1bee35590903171735p305b1de6l863ec434973214d4@mail.gmail.com> References: <1bee35590903170728k1b1c5c1fpef00ee85f92d9967@mail.gmail.com> <1bee35590903170758j2831471cja1605301d27bebbf@mail.gmail.com> <25aac9fc0903170804w1a2802f3td20e22f54666c198@mail.gmail.com> <1bee35590903171735p305b1de6l863ec434973214d4@mail.gmail.com> Date: Wed, 18 Mar 2009 03:31:41 +0000 Message-ID: <25aac9fc0903172031k3e51d59ax6bd7df2dc21b7644@mail.gmail.com> Subject: Re: Using UDV in SOAP Request From: sebb To: JMeter Users List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 18/03/2009, Mark Musone wrote: > Ok, so here's my dilema..hopefully someone can give me some suggestions on a > high level what would make the most sense for JMeter to do: > I've got literally about 1000 different SOAP/XML requests, each one being > different enough to warrent being in their own file. For example, I've got a > general SOAP request to "Store a Document", Well the document can be very > many different types (PDF, word, plain text..etc..), each type has their own > properties So i've got 100 or so different "Store a Document" SOAP/XML > files, each one storing a different type. I find it a bit surprising that there are so many different SOAP requests. Is there no way to parameterize these and use fewer requests? In the limit, I suppose one could have a variable for the entire SOAP body, and just read that from a CSV file, but that would be very awkard to maintain. Can you not find more similarities that would allow one to use small chunks of text as variables? > However, for each document "type", there are properties i need to be > variable (I want a random word document name, or if it's a JPEG image the > height and width should be random..etc..) > > My original idea was going to hopefully be simple in such that in each of > these 1,000 XML files, i'd just reference a ${variable} whenever I wanted > dynamic info..all of these XML files themselves would simply be pointed to > by the "Message Folder" attribute, and JMeter'll magically pick any of the > 1,000 XML files and magically do the variable substitution. > > Now that I understand it's not as cut and dry, with JMeter not processing > external files, is there an JMeter-best-practices way to accomplish it? It's best to reduce the amount of processing that JMeter has to do at run-time, so if you can create the personalised files outside JMeter, that would be best. For example, when I first started using JMeter, I needed to generate many thousands of randomly orderd unique account ids. That would have required a lot of memory to keep track of which ones had been used, so I created many smaller batches of accound ids, and used those in turn (with the StringFromFile function, which predates CSV Dataset). > I believe I can most likely have 1,000 SOAP request samplers (probably > inside a random controller) and copy and paste each of these XML files in > each sampler and have the variable substitution work...I guess that's the > brute force way..I'm just not sure if there's a better option. I probably > just need a pointer from the pro's of "Try this function/config".. If you are prepared to write some Java, then you could create your own copy of the SOAP/XML-RPC sampler to process the files on the fly. Or you could perhaps use a BeanShell or BSF Pre-Processor to generate the contents for the sampler. Or create a BeanShell function that returns the SOAP body. Again, coding is needed. > Thanks, > > Mark > > > > > On Tue, Mar 17, 2009 at 11:04 AM, sebb wrote: > > > On 17/03/2009, Mark Musone wrote: > > > Yep, I think you hit the nail on the head..they should rename it to "User > > > Define Constant" or "User Defined Global"! > > > > This has been made clearer in the documentation. > > > > Once the Test Plan and all UDVs have been processed, the resulting set > > of variables is copied to each thread to provide the initial set of > > variables. > > > > I.e. UDVs create regular JMeter variables, but only at test startup. > > > > > ok, so if i understand it correctly,I basically need to put whatever > > > function call I plan on using directly in the XML Data.. > > > > Yes, or pre-create the files and use a variable file name. > > > > > Will any of the methods you mention below work on external files, or am > > i > > > still screwed with being able to dynamically change anything in an > > external > > > file? > > > Thanks, > > > > > > > > > Mark > > > > > > > > > > > > On Tue, Mar 17, 2009 at 10:50 AM, Ian Blavins > > wrote: > > > > > > > G'day > > > > > > > > Despite the name User Defined Variables are in fact (global) user > > defined > > > > constants. UDVs are evaluated once prior to the run. Each UDV will > > take the > > > > final value seen in the test plan and will not change at run time. > > > > > > > > You can use UDVs to initialize local variables but it is the local > > > > variables whose values you have to modify during the run to achieve > > what you > > > > have in mind. (To add to the confusion a local variable can take the > > same > > > > name as a UDV (which will cause it to be initialized to the (static) > > value > > > > of the UDV.) This can make it look like the UDV is varying during the > > run > > > > but it is actually the local variable of the same name whose value is > > > > changing.) > > > > > > > > Modifying the value of a local variable can be done in various ways > > > > including with user defined parameters, by using the regular > > expression > > > > extractor on the results of a sampler, and others. > > > > > > > > The manual describes all this pretty accurately but the understanding > > of > > > > the term 'variable' is so ingrained in IT professionals that many > > JMeter > > > > users infer, incorrectly, the operation of UDVs from the name. > > > > > > > > > > > > > > > > Ian Blavins > > > > Software performance specialist > > > > . > > > > TEMENOS > > > > The Banking Software Company > > > > . > > > > PeopleBuilding 2, Maylands Av > > > > Hemel Hempstead UK HP2 4NW > > > > . > > > > T: +44 (0) 1442 431 106 > > > > E: iblavins@temenos.com > > > > . > > > > www.temenos.com > > > > . > > > > > > > > > > > > -----Original Message----- > > > > From: Mark Musone [mailto:mmusone@gmail.com] > > > > Sent: Tuesday, 17 March 2009 2:28 PM > > > > To: jmeter-user@jakarta.apache.org > > > > Subject: Using UDV in SOAP Request > > > > > > > > Hi All, > > > > > > > > I'm trying to use a User Defined Variable (I have it set to a static > > value > > > > for now) using the WebService (SOAP) Request. > > > > when I paste the XML in the SOAP/XML-RPC Data box, it works perfectly > > > > fine..the variable gets substituted and sent. > > > > > > > > I however would like to load the XML file using the "File with SOAP > > XML > > > > Data" field..essentially just give it the filename. > > > > When I put the same exact XML in a plain text file and specify the > > file, > > > > the > > > > variable does NOT get substituted, and instead, the SOAP request gets > > sent > > > > along as-is > > > > (i.e. the ${variable} is sent literally) > > > > > > > > The same goes for using the "Message Folder" option, which, long term, > > is > > > > really what i'd like to use. > > > > > > > > So is there something i'm missing on how to get UDV's working when > > > > referencing an XML SOAP file? > > > > > > > > Thanks for any help, > > > > > > > > Mark > > > > Disclaimer: > > > > If you have received this e-mail in error please notify the sender. > > > > Please note that any views or opinions presented in this e-mail are > > solely > > > > those of the author and do not necessarily represent those of TEMENOS. > > > > We recommend that you check this e-mail and any attachments against > > > > viruses. > > > > TEMENOS accepts no liability for any damage caused by any malicious > > code > > > > or virus transmitted by this e-mail. > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org > > > > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org > > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: jmeter-user-help@jakarta.apache.org