Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Putting JSON object into Response no longer stringifies the object in 3.3.1 #3745

Open
rbeckman-nextgen opened this issue May 11, 2020 · 3 comments

Comments

@rbeckman-nextgen
Copy link
Collaborator

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

Not sure if this is at all related to MIRTH-3824...

In version 3.3.0, you could put a JSON object into a Response object, and choose that response in your source connector, and everything would work just fine. When you viewed the response message (whether in the receiving channel's source or the sending channel's destination), you would correctly see the JSON object that was put into the response.

So, for example, you could do something like this in the Postprocessor, and respond from the Postprocessor:

var jsonObj =
{
"result": "This is the result.",
"data": "This is some other data."
}
return ResponseFactory.getSentResponse(jsonObj);

However, it's no longer working this way in 3.3.1. Now, when you look at the response message in the message view, you see:

[object Object]

And if you try to use the response in a response transformer, you get an error like this:

Response Transformer error
ERROR MESSAGE: Error evaluating response transformer
com.mirth.connect.server.MirthJavascriptTransformerException:
CHANNEL: HTTP Client with JSON
CONNECTOR: Destination 1
SCRIPT SOURCE: response
SOURCE CODE:
39: }
40: eval('importPackage(' + Packages.java.lang.Class.forName(className).getPackage().getName() + ')');
41: }
42: }
43: function doScript() {
44: msg = JSON.parse(connectorMessage.getResponseTransformedData());
45: function doTransform() {
46:
47:
48: var mapping;
LINE NUMBER: 44
DETAILS: SyntaxError: Unexpected token: o
at d89555a6-f1d2-4738-a164-48b213af267f:44 (doScript)
at d89555a6-f1d2-4738-a164-48b213af267f:91
at com.mirth.connect.server.transformers.JavaScriptResponseTransformer$ResponseTransformerTask.call(JavaScriptResponseTransformer.java:160)
at com.mirth.connect.server.transformers.JavaScriptResponseTransformer$ResponseTransformerTask.call(JavaScriptResponseTransformer.java:118)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

I've attached a couple of channels (an HTTP Sender that sends to an HTTP Listener with JSON as the data type) that demonstrate this. The channels work perfectly fine under 3.3.0, but cause an error under 3.3.1.

Imported Issue. Original Details:
Jira Issue Key: MIRTH-3862
Reporter: ericb
Created: 2016-01-06T10:22:41.000-0800

@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

Channels that demonstrate the problem. These work under 3.3.0, but not under 3.3.1.

Imported Comment. Original Details:
Author: ericb
Created: 2016-01-06T10:23:56.000-0800

@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

This is intended due to the changes made (reverted) for MIRTH-3794. It's important to realize that what you have is not "a JSON object". After this code:

var jsonObj = { "result": "This is the result.", "data": "This is some other data." }

The jsonObj variable is a JavaScript object, and as such according to the ECMA specifications should be coerced into a String in a specific way (the \[object Object\] thing). To put a JSON string into the response map, you just need to wrap that in a JSON.stringify(). The main reason for reverting that in MIRTH-3794 was because it broke many other things for people.

Imported Comment. Original Details:
Author: narupley
Created: 2016-01-06T11:11:58.000-0800

@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

OK, thanks Nick. Knew about the JSON.stringify() fix, but didn't realize that this was intended, as it worked in one version, but then stopped working in the next.

Imported Comment. Original Details:
Author: ericb
Created: 2016-01-06T11:20:46.000-0800

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.