Forum Discussion

carina's avatar
14 years ago

[Res] Dynamic namespace path in XPath Match Configuration

Hello
I am hoping for some help.
When I try to do assert on my test case, I fail. Because the namespace path will vary from each run. Does anyone know how to come around this problem?
The problem is in the XPath Match Configuration and the XPath Expression.

My namespace path:
declare namespace ns1='http://localhost/1379bcd8-c86a-4d35-873f-ababe9a34868';

Suggestions on how to solve this (are they possible?):
declare namespace ns1='http://localhost/*';
or
declare namespace ns1='http://localhost/<variable>';

It is a rest service

6 Replies

  • slg12345's avatar
    slg12345
    Occasional Contributor
    Declare a project property "xmlns" and set the value('http://localhost/1379bcd8-c86a-4d35-873f-ababe9a34868' or whatever) on every run.

    In the xpath expression, give : declare namespace ns1='${#Project#xmlns}';

    Hope I understood the Q correct.
  • Hi,

    The above shared solution should work.
    Or you can use the wildcard character instead of the namespace in your xPath expression.
    //ns1:Node1/ns2:Node2/ns3:Node3

    should be written like
    //*:Node1/*:Node2/*:Node3

    Best Regards,
    {Pradeep Bishnoi}
    http://learnsoapui.wordpress.com
  • cbaquero's avatar
    cbaquero
    New Contributor
    Hi,
    did you get to declare the namespace with property expansion?
    I'm using the regular version of SoapUI and I couldn't do it with the expression

    declare namespace ns1='${#Project#xmlns}';


    Any help on this will be really appreciated.
    Regards,
    Carolina.-
  • I have the same issue and, unless I missed something, this doesn't address the problem.

    I get a namespace back in the format [...]/accounts/441164964032/devices/[xxx]

    The [...] part is always consistent and so not a problem but the [xxx] part is always different and consists of one or more numbers.

    The suggestion proposed by slg12345 doesn't address this as it seems they are suggesting that the namespace is effectively hardcoded to a project property. If I were to follow this I would be hardcoding the following (as an example) https://www.myurl.com/accounts/441164964032/devices/123 as property xmlns (or whatever I might choose to call it).

    When I then substitute this into my assertion as:

    declare namespace ns1='${#Project#xmlns}';

    This will simply resolve as https://www.myurl.com/accounts/441164964032/devices/123 and will fail as I will get something other than 123 at the end. I tried wildcarding this to https://www.myurl.com/accounts/441164964032/devices/* but it didn't work and I then tried using pradeepbishnoi's suggestion of:

    //*:Node1

    Except I used //*:Response[1]. This worked but I can't help feeling this is a bit of a hack since, if I understand correctly, this is simply saying anything that comes back passes. Could someone please explain what exactly this nomenclature is doing for me to make it clearer. I'd be very grateful for the assistance. It's nice that it seems to work now but I want to be able to understand why it is working.

    Thank you.
  • > if I understand correctly, this is simply saying anything that comes back passes.

    Not really. It means that any element with an element name of Response will be matched, regardless of the namespace. This may or may not be a problem in your particular case.

    Kind regards,
    Manne
    SmartBear Support