Service Virtualization

My requirement is to read byte array format in CA dev test and reply back the success message.In the below message i want to read only json format payload,is their any way to read only json format

My byte array file is in below format

Exchange NA-AAA.DCS.TOPIC
Routing Key CA.AAA.ACCOUNT-REGISTRATIONVERIFICATION
Redelivered
Properties
timestamp: 1526491312
message_id: 9f9b36f0-592d-11e8-94e7-12425a5fee69
priority: 0
delivery_mode: 2
headers:
MULE_SESSION: rO0ABXNyACNvcmcubXVsZS5zZXNzaW9uLkRlZmF1bHRNdWxlU2Vzc2lvbi7rdtEW7GGKAwAFWgAFdmFsaWRMAA1mbG93Q29uc3RydWN0dAAmTG9yZy9tdWxlL2FwaS9jb25zdHJ1Y3QvRmxvd0NvbnN0cnVjdDtMAAJpZHQAEkxqYXZhL2xhbmcvU3RyaW5nO0wA

mcd-transactiontype: CA.AAA.ACCOUNT-REGISTRATIONVERIFICATION
mcd-marketid: AA
MULE_ENDPOINT: amqps://NA-AAA.DCS.TOPIC
mcd-sourceapp: WEB
MULE_ROOT_MESSAGE_ID: 9f9b36f0-592d-11e8-94e7-12425a5fee69
mcd-apiuid: 644e1dd7-2a7f-18fb-b8ed-ed78c3f92c2b
MULE_ENCODING: UTF-8
content_encoding: UTF-8
content_type: application/json

Payload :

{
"dcsId": "111240AZZZZ001535",
"marketCode": "CA",
"languageCode": "en",
"profile": {
"base": {
"username": "***@mailinator.com",
"firstName": "test",
"lastName": "gma"

}

Can you be more specific on exactly what is going wrong?  Is there an exception stack trace you can share?

> content_encoding: UTF-8

> content_type: application/json

My guess is that whatever error you're getting is related to the content encoding.  By convention, the Content-Type and Content-Encoding fields of an AMQP message should follow the MIME Content-Type and MIME Content-Encoding standards.  Your message is not following this convention.  It's putting the character set in the Content-Encoding field rather than putting it as part of Content-Type (content_type: "application/json; charset=UTF-8"). 

Is this a common usage of the AMQP Content-Encoding field?  I honestly don't know.  The AMQP spec is maddeningly short on actual requirements for most of its message header fields, so I had to take my best guess on a lot of things.

If this is the error you're getting, then contact support and tell them your exact version of DevTest, and we can try to have a patch to make the RabbitMQ code more lenient with "unconventional" Content-Encoding values.

I flagged the suspect content-encoding with MuleSoft last year, when I was unable to complete a POC because DevTest wouldn't accept the incorrect "UTF-8" value in AMQP. During that POC, I even added a step in AnyPoint Platform to force a change in the encoding from "identity" to "zip", but it still came through as "UTF-8", so DevTest still choked on it.

I could find no property to change in AnyPoint Platform to force a change in content-encoding value either. While poring through the MuleSoft Jira, I found that they fixed incorrect values in content-encoding for HTTP 2 years ago, but they didn't ripple that fix to any other protocols.

Rick, I wish somebody had told me told me about that issue with you PoC.  I would have patched it a year ago.  Rather than failing hard, we can simply ignore the invalid content encoding and hope for the best.

Hi Kevin,

As message is not in proper format I am unable to virtualize it and Lisa is unable to read the incoming message so that I am unable to reply back to the message.

I am using CA DevTest 10.3

Bala, I have produced a patch that simply ignores unsupported or otherwise invalid values for Content-Encoding.  To receive it you will have to contact support and mention the internal tracking number: DE374312.

Thanks Kevin,I contacted support team.

Hi Kevin,

I received patch from support team and still issue is not resolved.I have verified in Inspection View and see "incomingArray is []"

I have run the example MAR you sent to support, along with your sample request (PublisherMsg_Sample.txt).  With the patch, 10.3 is able to read the text body out of the request message, and the JSON DPH extracts 241 arguments.  This does not match the 107 arguments in Service Image's one transaction, so it returns the response for the unknown request.  When I instead run with your RR pair request, MQ_DCS-req.txt, this produces the correct 107 arguments and results in a valid response from the VS.

Are you sure you have the patch applied correctly?  I do not see "incomingArray is []".  With debug logging enabled I see "incomingArray is [dcsId, languageCode, ...]"

Hi Kevin,

I have created RR pairs from the incoming msg extract which contains (204) arguments,If i use the incoming msg to create VSI,null request has been created. Thats the reason why I have extracted the content I want and prepare RR pairs.

Yeah you are correct if i use 241 argument incoming msg it is not able to match and returning no match found.We need to do either of the following

1) Create VSI using incoming msg with all the arguments

2) Write script to extract the msg we want from the incoming msg

3) Incoming msg should be read by VSI and send response.

I'm sorry, I'm not following you.  Have you tried recording with the patch in place?  Are you still having a problem with the RabbitMQ transport protocol, or is this now all about data protocols and VSI arguments?

Hi Kevin,

Now its working fine.Thanks for your patch

Are you talking about sending that property in the request from some test app, or in the response from the virtual service?

If you're talking about sending that property from the virtual service then this is the correct property, set in the response meta-data:

> msg.CustomProps.mcd-marketid

If you're talking about sending that property in the request, then that depends on your test/client app.

Hi Kevin,

I am talking about sending header property in response from VSI,thanks for the confirmation