Copying binary attribute values: is it possible?

0
Hi All, I am currently trying to create a case + attachment in Salesforce through a Mendix app. Since I want to do this from many domain models in one app, I’d like to have a Mendix module which holds (parts of) the Salesforce domain model and then copy whatever I need from my other domain models to the “Salesforce domain model in Mendix”. For the attachment, this means the domain model will look something like this: In my other domain models, I have (generalizations of) FileDocuments (the usual Mendix kind), and I want to send these to Salesforce as part of the attachment (most notably the binary attribute). However, using microflows you can’t copy a binary attribute from one object to another binary attribute of another object. I am not sure why. This is a problem, since a “Salesforce” Attachment is not a FileDocument and therefore I don’t see a way of giving a value to its binary attribute. I tried getting around this by writing a custom Java action: This should take a “mailboxDocument” (a generalization of FileDocument) and return an “Attachment” in the “Salesforce domain model in Mendix”. This “seems” to work (no errors), but I have no way of verifying if the binary content is actually transferred to the Attachment since the binary content is “not shown” in the debugger. All I know is that, eventually, somewhere in my flow it fails to end up the in actual call to Salesforce. All of the other attributes are correctly displayed, though: Is there any other way of copying the value of a binary attribute to an object that is not a generalization of a FileDocument?
asked
5 answers
1

If you’re using the community commons module at all I suggest having a look at the DuplicateFileDocument java. 

They’re using something like this to get the contents and re-store them again:

InputStream inputStream = Core.getFileDocumentContent(context, toClone); 

        try {
            Core.storeFileDocumentContent(context, target, (String) toClone.getValue(context, system.proxies.FileDocument.MemberNames.Name.toString()),  inputStream); 
            return true;
        } catch (Exception e) {
            e.printStackTrace();
        }
        finally{
            try {
                if(inputStream != null)
                inputStream.close();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }

You can use similar logic for the reading, you’ll need something a bit different for writing though.

answered
1

You could try to change the Body attribute of your Attachment entity to a unlimited String to see whether it is not empty then. Probably you can then use the Base64 decode to get the binary back into a Mendix file document.

answered
1

Update: we “solved” it by changing the “Body” attribute into a string-type.

If we ever do get a java-action to work which allows to set a binary attribute we’ll let you know :)

answered
0

Thanks! Yeah I don’t think I have to write anything to a FileDocument, though obviously I might be wrong :) I did use a community commons class to figure out the second argument of the “setBody”-method. 

Small update: I did try to set the third argument of the “setBody”-method (the length of the inputstream) to the fileSize + 1, which returns an end of file error. Also I tried some small random values > 0, which all worked. Meaning the inputstream does seem to read the correct data, which is not-null.

Any other ideas? Maybe simply setting the attribute (“setBody”) is not enough and we need a refresh or a commit?

If anyone knows a way of checking the value of a binary attribute in debug-mode that would be a great help as well. 

answered
0

Using the debugmode in Eclipse, I did find out the actual value appears to be null, thanks! :)

Will continue to work on this later this week, maybe I can make a Java-action more people can use (FileDoc to binary or something).

 

answered