Submit and vote on feature ideas.

Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

Stub Settings

LegacyForum
LegacyForum Posts: 1,664 ✭✭
edited December 2016 in SOAtest
is it possible to setup a response using the 'if request matches' setting, so that it responds if it does NOT match?
Tagged:

Comments

  • LegacyForum
    LegacyForum Posts: 1,664 ✭✭
    Using our public calculator Web service as an example, I could enter the following xpath,

    /*[local-name(.)="Envelope"]/*[local-name(.)="Body"]/*[local-name(.)="add"]/*[local-name(.)="y"]/text()!="8.0"

    Basically use the != operator as a "NOT" match.

    is it possible to setup a response using the 'if request matches' setting, so that it responds if it does NOT match?

  • LegacyForum
    LegacyForum Posts: 1,664 ✭✭
    Follow up question, (also thank you)

    Is there a way to setup the response from the stub so that it includes data form the request?

    for simplicity's sake

    currently

    I have implemented a stub that returns data from a request on ID.

    different responses depending on the ID

    so ID = 1 -> response 1
    ID = 2 -> response 2

    is there a way to say if NOT 1 and NOT 2 then response would be like

    " there is no record for ID (some ID)"

    where the some ID would be whatever the request was, that was sent to the stub?


    thanks so much sir!
  • LegacyForum
    LegacyForum Posts: 1,664 ✭✭
    At the moment, there's no intuitive way of doing it. There is one approach that will require some simple scripting. I'm attaching a .tst file should you need it as a reference.

    Let me illustrate it and explain what is happening in the .tst file, the test case structure looks like the following:

    CODE
    Test 1: read
      Incoming Request > XML Transformer
        Transformed XML > Method
      Outgoing Response > Method

    The XML Transformer extracts the value of the element and passes it to the Method tool. In the Method tool I store this value in the Method context (via context.put(key, value), it's basically implemented like a Map). In the Method tool for the Outgoing Response I can alter the response. If I see that the input value is "dummy_msg" I know I should return a specific error message. And in the specific error message I'm including the value I've stored in the Method context, which I can access via context.get(key).

    The "dummy_msg" string is set in the "Multiple Responses" in the Client Tester for Response 3. The logic is that it checks Response 1 and Response 2 for the ID, and if it doesn't match it moves on to Response 3. In Response 3 I've set it to be "Always Match". In other words, it'll return this Response regardless if it matches or not. And as I've been eluding to, the message it responds with is "dummy_msg" (you can name it anything, just be sure it's the same in the script of the Method tool attached to the "Outgoing Response").

    Again, it's not intuitive but it should address your use case.
  • LegacyForum
    LegacyForum Posts: 1,664 ✭✭
    just what I needed!

    thanks so much sir!

Tagged