Service Virtualization

  • 1.  How to set a response JMS message property with the value from a request JMS message property.

    Posted Jun 27, 2017 11:17 AM
      |   view attached

    Hi guys,

     

    I'm working on a JMS communication based service where messages have headers, properties and xml body.

     

    The service receives a message from a queue, creates a response xml and sends the message (with other headers and properties) on another queue.

     

    I've verified that I can set a response JMS property using a value from request xml using msg.props.myProp = {{=request_pathToXmlTag;/*defaultValue*/}},

     

    but I wondering how can I set a response JMS property using a value from a given request JMS property, something like msg.props.myProp = {{=request_msg.props.sourceProp;/*defaultValue*/}} where msg.props.sourceProp is present in the request.

     

    Is it doable?

     

    I'll attach a screenshot to help you understanding my needs.

     

    Thank you and
    Best Regards,
    Alessandro.



  • 2.  Re: How to set a response JMS message property with the value from a request JMS message property.
    Best Answer

    Posted Jun 27, 2017 03:08 PM

    The request message headers and properties are put into the VSE request's meta-data, which is not accessible when building the response.  You have two options:

     

     1. Add a Request Data Manager data protocol handler, and use it to copy the properties you need from the request meta-data to the request arguments.  This will probably require re-generating your service image.

     

     2. Edit your VSM's 'Listen' step, and uncheck the 'Quiet' checkbox.  This will cause it to write all message headers and properties to the test exec state.  You can then access custom message property values in your response meta-data with '{[lisa.jms.Recv.PropertyMap.<property name>}}' .  <property name> here is the actual name of your message property, without the 'msg.props....' prefix.  The prefix is different when using this method.



  • 3.  Re: How to set a response JMS message property with the value from a request JMS message property.

    Posted Jun 28, 2017 05:57 AM

    Hi Kevin,

     

    thank you for your answer, I managed to use request JMS properties using your first option.

     

    I've had to re-record my service image in order to choose xml data protocol (I was already using it) and the RDM protocol to manage request meta-data. Is there any way to add a new protocol to an already recorded image without re-recording it?

     

    Thank you very much and

    Best Regards,

    Alessandro.



  • 4.  Re: How to set a response JMS message property with the value from a request JMS message property.

    Posted Jun 28, 2017 11:43 AM

    Adding a data protocol will usually change the signature of your requests.  This means some or all of your VSI requests will no longer match.  You *can* manually fix this, by editing all of your VSI request signatures.  But if your VSI has more than a handful of transactions then it's probably far easier to just re-record/re-generate.  If you're doing a live recording then it's usually a good idea to save a raw traffic file so you re-generate the VSI without having to actually re-record.

     

    Alternatively, you could have used the second option, which does not affect the request arguments at all.



  • 5.  Re: How to set a response JMS message property with the value from a request JMS message property.

    Posted Jun 29, 2017 04:02 AM

    Hi Kevin, I'm in the case of just one or two transactions, so, as you told me, I can manually fix request signatures,

    but I'm actually wondering how add a data protocol via the workstation GUI.

     

    Thanks you.



  • 6.  Re: How to set a response JMS message property with the value from a request JMS message property.

    Posted Jun 29, 2017 11:48 AM

    You can manually edit the VSM and add another Data Protocol filter to the Listen step.  However, the UI there for selecting and configuring a DPH is not nearly as nice as it is in the Recorder.  I highly recommend going through the Recorder process again, both for the easier VSM configuration and making sure the VSI is re-built correctly.