Letter Migration to Version 13

[codylerum]

Currently in 12 we have the option of passing in a java.io.File which is then handled by the library to read the content and include it with the post.

With 13 it appears we just have a String value. How do we do this with parity in version 13? I would be fine sending in a byte[] or an inputstream as well.

[BennyKitchell]

Hey @codylerum

I will investigate more into this, I am seeing in the docs we currently support different types of strings. But I also see that the old Java SDK did accept File types. I am going to follow up with another team if that is still supported and update the docs if that's the case.
If not, I am happy to make a method for taking in a file and parse it to a string on our end. Hope this helps, thanks!

[codylerum]

My preference would be to pass though the content as a byte array or I can convert to base64 or something. But the docs seem to imply that you take

1. HTML String that I assume you will render into a PDF
2. template id
3. a remote url that we would have to host on another server
4. "String" but I can't tell what string would imply.

Basically I have a PDF bytes and would like to have that transferred like it does currently. File is actually an inconvenience for me as I have to write it to a temp folder on my server to pass it you and then delete it after.

[BennyKitchell]

Perfect, changing a byte array to a string should be no problem on our end.
I will try to create a proof of concept tomorrow, and if nothing else get a method out of the door for you to use so you have minimal workarounds. Appreciate all the feedback, these things are incredibly helpful!

[codylerum]

No problem and I can easily create it to base64 or something for transfer just need to know that the API will take it.

[codylerum]

Beyond this issue and the legacy DateTime stuff I've been able to convert our impl using Letters, Checks and verifications without issues.

[BennyKitchell]

That's great news, I am glad it's mostly been working for you! I will get back to you asap on how we can handle the File situation.

[BennyKitchell]

@codylerum I have a ticket created for this, for next sprint. From what I am finding on the api team's side, we should be able to have both a method to accept a file, and a method to accept a byte array. Unless otherwise updated on here, I would expect the change to be out in the next two weeks. I will fully update this ticket with that version once it has been released.

[codylerum]

@BennyKitchell Sounds good. We have a working implementation on the 12.x API so there is no rush.

[BennyKitchell]

@codylerum I know it's been a bit, I wanted to let you know the team is still working on getting this out the door. We appreciate your patience. Thanks!

[codylerum]

@BennyKitchell Just checking in on this one to see if there is an ETA

Thanks!

[codylerum]

Assuming we can stay on 12.x for a while I'm probably just going to shelve this for now and look again in 2023

[BennyKitchell]

@codylerum Apologies for the delay on this, we ran into some issues on headcount and workload. This will be our focus for this sprint and we will get this out by end of this month. Apologies again!

[BennyKitchell]

@codylerum I was able to implement the functionality of adding a file with the letter on upload, had to provide an overloaded method to pass it in. I was not able to add in the byte array functionality yet. But I am hoping this will help your team be able to utilize version 13 until then. I don't have a definite date on the byte array functionality, but I will be working on it where I can find spare time.

[BennyKitchell]

The version is 13.4.0 and is released.

[codylerum]

@BennyKitchell thanks. We will probably hold off until byte array is added.

Most of our content is generated dynamically so we don't really want to have to write it out to temp file on disk just to add to the api and then delete after. This is what we do today....