gilugopi
Contributor
Joined 10 years ago
User Profile
User Widgets
Contributions
Re: Organize REST services?
I you had provided a screenshot of how your current structure looks like, it would have been easier to suggest a solution. 1. If you right click a project add rest resource from URI. Each would become separate end points and eventually you'll end up having a lot of end points Service 1 : http://example.com/customer Service 2 : http://example.com/customer/orders 2. Better is, let's assume you have already created service 'http://example.com/customer' To add /customer/orders service, right click on "http://example.com" end point and add new resource Give resource path as relative path '/customer/orders' You'll end up with a structure like http:/example.com - > /customer (Service 1) - > /customer/orders (Service 2) 3. Another way is, let's assume again you have already created service 'http://example.com/customer' Right click on 'http://example.com/customer' service and select new child resource. Give resource path as relative path '/orders' You'll end with a structure like below http://example.com - > ->customer (Service 1) ->orders (Service 2) Play around with options 2 and 3 to organize service which suits your need. Cheers! Gilu Gopi1.3KViews1like0CommentsRe: How to define a resource path with same parameter name
To my understanding you can't use like that. When SOAP UI see a web service URL which as 4 different parameters it has to assume that all these as separate parameters which should be able to take different values. Unless why would someone make the web service request complex by asking client to populate same values in many different parameters. And each parameter name is only a place holder ( or a variable name ) Now for the sake of testing let's assume that there is certain logic why service is designed like this. So to make this work you might have to define parameters with different names. {rackId}, {shelfId}, {slotId}, {portId} So but to make testing easier you can just pass same value to all these fields from a single property ( probably stored at test case level for example rackId : {#TestCase#id} shelfId : {#TestCase#id} Well, I know this is not what you asked for. Just putting across what came to my mind. Cheers! Gilu Gopi2KViews1like1CommentRe: Running SOAPUI NG in a Google Container
Don't know about Google Container, but I recently did something similar from Amazon Cloud. I think your requirements should be possible as far as you've access to do the following 1. Install Ready API 2. Install License ( In virtual machine's normally i would prefer to use floating license ) 3. Access from cloud to your source code management system to get checkout your test scripts. 3 Access from cloud to web service ( open any firewall ports required ) In my organization, the infrastructure / devops team help me with these permissions to get Ready API setup on Amazon cloud. Thanks & Regards, Gilu Gopi1.3KViews1like0CommentsRe: Handling collection of items in Ready API!
DataSource is not the answer for your need. You need to write sort of goovy script to add more items to your Json. Given below is an example. Refer to online documentation of groovy libraries JsonSlurper, JsonBuilder or JsonOutput so that you can write script specific for your need. Given below is an example script for demonstration. def jsonString = """ { "items":[ { "itemcode":1, "quantity":5}, { "itemcode":2, "quantity":6} ] } """ def json = new groovy.json.JsonSlurper().parseText(jsonString) class item{ def itemcode; def quantity; item(def itemcode, def quantity){ this.itemcode = itemcode this.quantity = quantity } } def item3 = new item(3,7) def item4 = new item(4,8) def jsonBuilder = new groovy.json.JsonBuilder(json); List items = jsonBuilder.content.items items.add(item3) items.add(item4) jsonBuilder.content.items = items; println jsonBuilder.toPrettyString() Output { "items": [ { "itemcode": 1, "quantity": 5 }, { "itemcode": 2, "quantity": 6 }, { "itemcode": 3, "quantity": 7 }, { "itemcode": 4, "quantity": 8 } ] } Cheers ! Gilu Gopi1.4KViews1like0CommentsRe: Custom property value is not called in parameterised request file.
This shouldn't be too hard using groovy script. Instead of adding property expansion inside your file, you should add a Setup Script to the test case to edit the xml file to update what ever value you need in your nodes. Set up script will run before execution of test steps and ensure correct data in your XML file itself. Here is an example script which edits and saves the sample xml in your first post in your thread. If you want to know more I would suggest to read any online documentation available for groovy.util.XmlParser def filePath = '/path/to/your/file.xml' // Replace with the correct path. def xml = new XmlParser().parse(new FileInputStream(new File(filePath))) xml.get('payload').getAt('modify-UG').getAt('charging-id')[0].value = context.expand('${#TestCase#MSISDN}') new XmlNodePrinter(new PrintWriter(new FileWriter(filePath))).print(xml) Cheers! Gilu Gopi3.2KViews1like2CommentsRe: SOAP ui license activation issue
Based on the error, I'm assuming you're using floating license for Ready API. If that's the case more users might be connected to the license server at this time that the number of licenses your organization has. That doesn't mean that you've to jump the gun to request purchase of additional licenses. Talk to who over manages your floating license server. Mostly they can pull out the list of users who are using floating license, and request who ever is not actively using it to check the license back in. If they can't find who all are using licenses, the account manager on SmartBear side can help you do this. Every company who has purchased a license will have an account manager on smarbear side. Talk to who ever owns license in your organization. They would be able to help you. Cheers! Gilu Gopi1KViews1like0CommentsRe: Repeat a Test Step until you get desired response and then move to next step.
You have to check with your product owner to identify what is the accepted SLA for updating this information in DB. If it's not updated in that much time, your test should ideally report as failed. Even the deadlock or anything of that sort is again applicable only if your DBAs set it up in that manner. I would check once immediately, then check again at the SLA if this SLA fails, still continue the test execution and check once more after one more time after 2 times the SLA is passed. If it still fails, it's some one else's job to fix the problem( unless you're the developer :smileyhappy: ). On a separate note: If you want to repeat this step multiple times, it might be a better idea to loop this test step execution in a Groovy Script test step. Below is a psuedo code which you might want to adjust based on your need. while ( counter < maxCounter && ['pass','fail'].contains(status) == false ){ testRunner.runTestStepByName('YOUR_TEST_STEP_NAME') // Write some xmlHolder or JsonSlurper code to get value for 'status' variable from service response here maxCounter ++ } Cheers- Gilu Gopi9.1KViews1like5CommentsRe: Is it possible to parameterize 'Endpoint' in Environment setting?
Basically anything which is to be shared across projects is better to be stored as a Global Property. Then you don't have to keep all project level property files and have overlapping information in all of these Let's say we have a customer service which is used under multiple projects, and need to be executed in multiple environments. I would store these end points in Global Properties . Ex customer_dev : dev.customer.myservice.com customer_qa : qa.customer.myservice.com Then in each of the project I use customer service, I'll have project level property for customer end point to be used under environments. Each environment end point would be like DEV Env > customer : ${customer_dev} QA_Env > customer : ${customer_qa} Later down the line if your project changes server hosted or you have to hit a loadbalancer URL you only have to modify only one global property and all projects would be up to date For example customer_dev : devloadbal.customer.myservice.com:8440 But all of these are optional if 1. you are not using same end points in multiple projects 2. your project end points are not likely to change. Cheers- Gilu Gopi3.2KViews0likes0CommentsRe: Is it possible to parameterize 'Endpoint' in Environment setting?
To my understanding loading end points from a config file is good way if you're working with SOAP UI Community edition ( Which do not have environment feature) The very purpose of environment module is so that you can hard code environment specific values like end point. For example - let's say your a service where end point changes in 3 different environment DEV, QA, UAT you should just hard code those end point values for each ENV dev : http://dev.mysevice.com qa : http://qa.myservice.com uat : http://uat.myservice.com Even if some of the url changes, you have only one place to update. Just like your good old properties file. But once you have set up everything in enviornment module you have option to just flip the environment selected using a drop down menu ( or a command line argument if you're using testrunner.bat/ testrunner.sh ) without the trouble of updating the property list everytime. Another way is to add each environment specific end point to Global Properties and pass those values to each environment. That way you can handle changes better, especially if same end points are used in multiple projects. There are many ways you could do this. But the approach mentioned above has served me well for years. Cheers! Gilu Gopi3.2KViews1like2CommentsRe: Loading or referencing environment properties
Actually Global Properties work well with environments And Environment settings are not under settings.xml, its under each projects xml file Lets say you create two different global properties envAPassword : envAPasswordValue envBPassword : envBPasswordValue Now you need a password property at the project level to show up in environments, let's call it projectPassword You need to environment settings 1. select envA and need to specify projectPassword value as ${envAPassword} 2. select envB and need to specify projectPassword value as ${envBPassword} Thus global properties flows seamlessly into your environment.2.1KViews0likes1Comment