Skip to main content

Hi!

I am having some difficulties trying to get the Base64 value from attachments uploaded to Assyst when working from within an ETM data mapper. I’m currently working in IPaaS 1.8 and Assyst 24R2.

The issue I’m trying to solve is for an ETM channel to automatically trigger when a new event is created in a specific service offering, and for ETM to then use the event and its uploaded CSV attachment as input for triggering a specialized import.

To facilitate this, I’ve created a serialized-CSV-to-JSON mapping function, that works of output from common.decodeBase64ToString so that I can feed this resulting JSON onwards to this specialized data mappers that performs the assyst import.

The destination, channel, common.decodeBase64ToString, CSV→JSON parsing function, and subsequent import all work as expected during development in debug mode. However, this has only been with “hand-fed” Base64 data, as I’ve not been able to figure out how to grab or expose the Base64 attachment data during data mapping in ETM.

Event Attachment returns information about the attachment, but not the base64

Getting the Base64 is no problem when using regular REST in a browser or using Postman, but using variable Assyst search for event attachments returns the attachment and the content, but no Base64 string.

Using variable search fields with field expansion does not seem to have any way of exposing this data. I’ve tried looking in the EJB (localhost:[port]/assyst/assystEJB/Attachment/fields), however the closest I got was the Base64Attachment, which did not work (and I couldn’t quite make out what the EJB was trying to indicate for that entry)

Given this wiki article, it seems to require explicit use of both the event and attachment ID, and the use of field expansion not providing this Base64 data could make sense. However, I’m not sure how using Assyst REST (such as assystREST/v2/events/6052667/attachments/519564) in Postman and using an Event Attachment mapper in ETM should differ. To my understanding these should both return the same properties when requesting an object, but here it seems to not be the case.

Is Base64 explicitly removed from the available fields when working in ETM, or is there some other way to get this attachment data so that I can put it through the common.decodeBase64ToString function?

 

Thank you very much for your time

Richard

Be the first to reply!