raw http: how to retrieve the message body

[Ken Smith]

I am using the example processes from CAA, site_ws_sample. When using the RestProvider raw endpoint, or using the RawHandler endpoint, I can send a message from SoapUI and see a response being returned from bounceRest/bounceRaw, so I know the message has hit Cloverleaf. I can also see an entry being created in the SMAT for the message. However, I can’t see any sign of the message body/payload. It doesn’t show in the SMAT and it doesn’t appear in the log file. I’ve tried it with an xml message and a JSON message.

I’ve tried the RestProvider RESTTest endpoint with an xml message and it works properly. However, the vendor is proving messages in a JSON format and rest in the rest provider only supports xml.

What am I missing/overlooking?

Topic

[Tipu Razaq]

You may have to turn up the logs to ‘enable all’ (EO config) to see the payload. It’s in the metadata section of the message.

[Ken Smith]

Thanks for the advice. I have set logging to enable_all on Engine Log Configuration in the Properties tab for the thread. This hasn’t changed anything however. The message body does not appear in the logging or in the SMAT.

[Tipu Razaq]

I’ve always done it through the Network Monitor. Right click on the thread -> Control -> Full -> engine log configuration.

 

This takes effect immediately and is temporary until the process/thread is bounced.

 

Did you bounce the process after making the change the way you did it?

• This reply was modified 4 years, 9 months ago by Tipu Razaq.

[Tipu Razaq]

I reread your post. For the first paragraph you said you’re using the bounceRest/bounceRAW. If you’re using it out of the box those scripts have a KILL in their you may  have to change to CONTINUE for the message to be saved in SMAT. Not too sure, though.

 

For your second paragraph, you’re correct. Cloverleaf RestProvider only support XML. You’ll have to change it and add a RawHandler instead and add RestProvider underneath. We have JSON coming in so I know this setup works.

 

Can you upload a screenshot of your setup?

 

Here’s ours:

 

Attachments:

You must be logged in to view attached files.

[Ken Smith]

This is my basic config.

Attachments:

You must be logged in to view attached files.

[Ken Smith]

this is the raw handler

Attachments:

You must be logged in to view attached files.

[Ken Smith]

This is dumpMsg.tcl, does continue on the $mh:

proc dumpMsg { args } {
keylget args MODE mode ;# Fetch mode

set dispList {} ;# Nothing to return

switch -exact — $mode {
start {
# Perform special init functions
# N.B.: there may or may not be a MSGID key in args
}

run {
# ‘run’ mode always has a MSGID; fetch and process it
keylget args MSGID mh
keylget args CONTEXT context

puts “message id: $mh”
set INmsg [msgget $mh]
#set INmsg1 [httpget $mh]
puts “message body: $INmsg”
#puts “message body: $INmsg1”
echo \n\n$context Dump:
msgdump $mh
echo \n\n

lappend dispList “CONTINUE $mh”
}

time {
# Timer-based processing
# N.B.: there may or may not be a MSGID key in args
}

shutdown {
# Doing some clean-up work
}
}

return $dispList
}

[Ken Smith]

bounceRaw, relevant lines:

#lappend dispList “KILL $mh” : in original code
lappend dispList “CONTINUE $mh”

I changed to continue from kill. The interesting thing is that I routed the outbound message to a file thread and every time I send a message through, the file thread gets a message. However, there is nothing in the message as nothing is written to the file, except a new blank line, which indicates to me that a “message” is passing through the system. Still not seeing anything in SMAT.

[Ken Smith]

Thanks very much for your help, I’ve managed to get this working. There were I think 3 changes required.

First, was changing KILL to CONTINUE, as above, in the bounceRaw tcl.

Second, in my raw handler, I changed the context path, from “/rawJSON” to simply “/”

Third, and I think this is a peculiarity of SoupUI 5.1.2, which I was using as a test harness, I needed to change the media. I was using application/json, then tried text/html and the multipart options. I stumbled across another media type by accident, not available in the drop down, “x-www-form-urlencoded”.

I now get the message logged in SMAT, either xml or JSON, and the message writes out to my test file thread.

[Tipu Razaq]

Awesome! Glad you figured it out

[Ken Smith]

Addendum: I’ve created a new thread from scratch based upon my trials and tribulations above and again used SoapUI to test it. The media defaulted to application/json without my noticing and the message passed through successfully. So I think now that the media type/setting was a red herring.

[Author]

Replies