Forum Discussion

cromzinc's avatar
cromzinc
Occasional Visitor
6 years ago

Unable to have different parameter types for the same param in the same service

I updated ReadyAPI to 2.6.0, and since when I edit a parameter type (template -> query) for a request in the project, it carries over to my tests perfectly. Soon as I go back to the project and edit a different request parameter type, the prior one reverts evertime.

 

I have tried saving in between edits, saving and exiting the app, saving all projects. Nothing seems to work, I just can't manage to retain the parameter type I set on a request. 

 

Any suggestions to remedy this issue, or what I may be doing incorrectly is very welcomed. 

  • richie's avatar
    richie
    6 years ago

    Hey cromzinc 

     

    I'm unsure if I'm misunderstanding but I think you're hitting an issue I noticed quite recently and it is a known issue with ReadyAPI!

     

    The hierarchy to the objects in your 'Projects' tab is as follows:

     

    Service >> Resource >> Method >> Request

     

    I noticed that if I created multiple Resource's in the same service with different multiple query parameters, then the most recent change overrode previous ones.

     

    So if I have 2 resources within the same service and they have say the following parms

     

    Resource1

     

    APIKey - header type
APIClient - header type
QueryParmX - query type
QueryParmY - query type

     

    Resource2

     

    APIKey - header type
APIClient - header type
QueryParmA - query type
QueryParmB - query type

     

    Then when I went into the SoapUI tab and tried to create a REST request based on Resource1, even though I select Resource1 via the 'New REST Request' modal window, when the REST request is created in my testcase, the parameters are those found in Resource2!

     

    It's a known issue according to what I've read in the help somewhere.  The way around this was to create separate Services for each of the requests - despite the fact that really - its the same service, same resource with different query parms.

     

    The way I got around this was to create separate Service level requests for each of the requests with different query parms - that way, when you select the request in the SoapUI tab - it does select possess the correct parameters.

     

    I've attached 2 images so you can see - I have one with a QueryParm entitled ID, the other is the same request with a different QueryParm entitled MUID.  When I tried to create these within the same Service - it didn't work - it behaved as I describe above - so this was way I found around the problem.

     

    Admittedly, its not very efficient - but it does get the job done....perhaps one of the other forum members might have a better idea?  but this is the way I handled it! :)

     

    I hope I've been clear,

     

    Cheers,

     

    richie

  • richie's avatar
    richie
    Community Hero
    6 years ago

    Hey cromzinc 

     

    I'm unsure if I'm misunderstanding but I think you're hitting an issue I noticed quite recently and it is a known issue with ReadyAPI!

     

    The hierarchy to the objects in your 'Projects' tab is as follows:

     

    Service >> Resource >> Method >> Request

     

    I noticed that if I created multiple Resource's in the same service with different multiple query parameters, then the most recent change overrode previous ones.

     

    So if I have 2 resources within the same service and they have say the following parms

     

    Resource1

     

    APIKey - header type
APIClient - header type
QueryParmX - query type
QueryParmY - query type

     

    Resource2

     

    APIKey - header type
APIClient - header type
QueryParmA - query type
QueryParmB - query type

     

    Then when I went into the SoapUI tab and tried to create a REST request based on Resource1, even though I select Resource1 via the 'New REST Request' modal window, when the REST request is created in my testcase, the parameters are those found in Resource2!

     

    It's a known issue according to what I've read in the help somewhere.  The way around this was to create separate Services for each of the requests - despite the fact that really - its the same service, same resource with different query parms.

     

    The way I got around this was to create separate Service level requests for each of the requests with different query parms - that way, when you select the request in the SoapUI tab - it does select possess the correct parameters.

     

    I've attached 2 images so you can see - I have one with a QueryParm entitled ID, the other is the same request with a different QueryParm entitled MUID.  When I tried to create these within the same Service - it didn't work - it behaved as I describe above - so this was way I found around the problem.

     

    Admittedly, its not very efficient - but it does get the job done....perhaps one of the other forum members might have a better idea?  but this is the way I handled it! :)

     

    I hope I've been clear,

     

    Cheers,

     

    richie