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

[IDEA] Add attachment functionality to destination response #5351

Open
RunnenLate opened this issue Aug 16, 2022 · 4 comments
Open

[IDEA] Add attachment functionality to destination response #5351

RunnenLate opened this issue Aug 16, 2022 · 4 comments
Labels
enhancement New feature or request Internal-Issue-Created An issue has been created in NextGen's internal issue tracker RS-9149 triaged

Comments

@RunnenLate
Copy link

Is your feature request related to a problem? Please describe.
We are hitting a lot of REST endpoints that return a PDF and it would be helpful to have the ability to process that response as an attachment the same way an attachment is processed before the source.

Describe your use case
Store a PDF within a response as an attachment to reduce on logging and processing within Mirth connect.

Describe the solution you'd like
An optional attachment button within an HTTP Sender to capture an attachment the same way one is captured via the source

Describe alternatives you've considered
Currently, as a workaround, we are initiating the requests via a JavaScript Writer using the HttpGet and then adding it as an attachment.

@RunnenLate RunnenLate added the enhancement New feature or request label Aug 16, 2022
@pacmano1
Copy link
Collaborator

pacmano1 commented Aug 16, 2022

You can just call addAttachment in the response transformer in a normal http sender.

for a json response that looks like:
image

it would be the below to grab the CDA and base64 encode it (not necessary of course for a CDA).

addAttachment(msg[0]['getccdainfo'][0]['ccdaxml'].toString()), 'application/xml',true)

@RunnenLate
Copy link
Author

True but that doesn't accomplish what I was hoping to avoid and that's logging the entire PDF in the response.

image

@pacmano1
Copy link
Collaborator

pacmano1 commented Aug 16, 2022

The response needs to be collected of course with or without a button. It's an interesting idea of course just suggesting another workaround not mentioned your initial feature request. On a side note, we always set response transformer data types to raw so the response transformer always fires such that we can fully inspect the result (e.g. the response code, the data, handle sendAttempts, possibly set a message to sent even if errored, add some part of the response JSON as an attachment and so on).

@lmillergithub lmillergithub added triaged Internal-Issue-Created An issue has been created in NextGen's internal issue tracker RS-9149 labels Aug 17, 2022
@RunnenLate
Copy link
Author

I should have added this before but you can workaround this by using the org.apache.http libraries and calling the endpoint in javascript to get the response back without logging it.

var httpclient = new DefaultHttpClient();
var httpPost = new HttpGet($('URL'))
httpPost.addHeader('Authorization', 'Bearer ' +$('token'))
var resp = httpclient.execute(httpPost);
var status = resp.getStatusLine()
if (status.toString().match(/200+/g)) {
	var entity = resp.getEntity();
	var responseArray = EntityUtils.toByteArray(entity);
	var base64pdf = org.apache.commons.codec.binary.Base64.encodeBase64String(responseArray)
	addAttachment(base64pdf, 'application/pdf', false)
	var error = null
 	updateResult(error, base64pdf)
}

Need to code something for Web Service Sender payload now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Internal-Issue-Created An issue has been created in NextGen's internal issue tracker RS-9149 triaged
Projects
None yet
Development

No branches or pull requests

3 participants