Copy link to clipboard
Copied
Been using the Embed API for over a year very successfully. On or around last Thursday, radio button fields do not seem to be behaving properly. I am receiving a PDF from the callback with BOTH buttons checked when they are supposed to be unique? Has there been a change or recent deployment?
Thanks,
Fred
Copy link to clipboard
Copied
Hi @freda63866688 Thanks for reaching out to us. We are looking into this. I shall keep you posted.
Copy link to clipboard
Copied
This is what comes back in the callback...the checkboxes( Radio buttons are mutually exclusive ) meaning they all have the same fieldname...... when I call getField( fname ) .... I always get back the first value .... so once set.... you can never set anything "to the right of it" since it seems that both values are in the data
Copy link to clipboard
Copied
Is there a production version of the embed API service. My current production system is now unusable and I was wondering if Adobe has a product that will do the same thing and provide some kind of SLA????
Copy link to clipboard
Copied
Can you share the input PDF file?
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Can you elaborate on exactly what yoiu mean by the above? Please be as detailed as possible... "filled out and sent to adobe" doesn't tell me what product was used and how.
Copy link to clipboard
Copied
I have been using the Embed API for over a year with great success. On the pdf manipulation side I was using iText 5 but needed to switch to iText 7 6 months ago to handle an issue with checkbox groups that span pages. Again, we have been working fine on 100s of PDF documents created by various Financial Institutions, different vendors, etc. but again successfully. Last week Thursday, it was reported that CheckBox groups ( radio buttons ) are not saving or being changed. I have spent 3 days and verified that I have not changed any code that would impact the saving of PDF data. So my question is .. did something change on your side?
This is pseudo code of the script in my HTML page using the Embed API: Pretty much right out of your documentation..
<div id="adobe-dc-view" style="width: 100%; height: 100%;" ></div>
<script src="https://documentcloud.adobe.com/view-sdk/main.js"></script>
<script type="text/javascript">
document.addEventListener("adobe_dc_view_sdk.ready", function() {
const saveOptions = { showSaveButton: true }
const previewConfig = { showDownloadPDF: false }
let adobeDCView = new AdobeDC.View({
clientId: "<my client id>",
divId: "adobe-dc-view"
});
adobeDCView.previewFile(
{
content: {
location: {
url: "@routes.FormWorkflowController.editWorkflowFormAsPdf( doc_id )"
}
},
metaData: {
fileName: 'doc.pdf'
}
},
{
embedMode: "FULL_WINDOW",
showPageControls: true,
dockPageControls: true,
showAnnotationTools: false,
showLeftHandPanel: true,
defaultViewMode: "FIT_PAGE",
showDownloadPDF: @hostserver.isLocalServer,
showPrintPDF: false,
enableFormFilling: true
}
);
adobeDCView.registerCallback(
AdobeDC.View.Enum.CallbackType.SAVE_API,
async function(metadata, content, options) {
let formData = new FormData();
formData.set(
"CaptureData",
new Blob([new Uint8Array(content.buffer, content.byteOffset, content.length)]),
"FormsLogic_PDF_Editor.pdf"
);
const response = await fetch("@routes.FormWorkflowController.uploadPDFForDataHarvest(doc_id)",
{ method: 'POST', body: formData });
if(response.ok) {
//move reload to end of js call stack (after promise is returned)
setTimeout(function() { window.location.reload(true); });
return new Promise((resolve, reject) => {
resolve({ code: AdobeDC.View.Enum.ApiResponseCode.SUCCESS, data: { metaData: metadata });
});
} else {
//adobe UI to display failed save without page refresh
return new Promise((resolve, reject) => {
reject({
code: AdobeDC.View.Enum.ApiResponseCode.FAIL });
});
}
},
saveOptions
);
});
</script>
The first PDF is a sample pdf that has been working for over a year that started not saving checkboxes last thursday.
Below is the pseudocode on my controller ...called by the registered callback above.
def uploadPdfForDataHarvest(...... ) = SecuredAction.async(streamingBodyParser(maxUploadSize)(newByteArrayOutputStream)) { implicit request =>
val keyword = "CaptureData"
request.body.file(keyword) match {
case Some(file) =>
file.ref match {
case Right(streamResult) =>
val bytes = streamResult.outputStream.asInstanceOf[ByteArrayOutputStream].toByteArray()
PdfGenerator.saveToFile( "public/output/adobe_returned_file.pdf", bytes ) <-- The second file above
val reader = new PdfReader( bytes ) <--- iText 5 or iText 7
val form = reader.getAcroFields()
val keys = form.getFields().keySet()
var data = Map[String, Seq[String]]()
data = data.++( keys.map { k =>
k -> Seq( form.getField( k ) )
} )
Note that I take the bytes coming in from the form data and write them out to a file which is the second file attached. Notice that the old radio button and the new radio button are both checked which seems like a bug to me since the field names for these should be the same and the values are what is different.
The form.getField( k ) call when it goes for the radio group always returns the first one ( 'Individual' ) even though that is old data and the new value '529 Plan' cannot be retrieved so that I can make the change.
Again, this was working last wednesday and now it seems to fail on all radio groups. I have not changed any code to impact this. The result is it seems...all getField(k) calls return the first value of the radio group ( selected or not ) when I get the result after a save.
Copy link to clipboard
Copied
Can yo save the file on your server and send me what you save prior to iText touching it. The returned PDF that was modified by iText doesn't even have a forms dictionary in it.
Copy link to clipboard
Copied
Copy link to clipboard
Copied
The raw output looks fine to me. The forms dictionary is present and the field appearances are still checks. I think the issue is introduced later in your code.
Copy link to clipboard
Copied
That may be true, however, can you tell me if something changed last week in the Embed API or PDF Format ? Was there a production code roll? Because my code that has been working for months stopped working and I need to understand how I can track this down in the future and where/how this defect got introducted into my system. Does Adobe Embed API have a release notes page where we can go to discover a new version, etc.?
Copy link to clipboard
Copied
There hasn't been a change. The link to the release notes is below.
https://developer.adobe.com/document-services/docs/overview/pdf-embed-api/releasenotes/
I can see you are using iText. They have the RUPS tool you can use to examine the PDF contents. Save a copy of your file after each processing step and take a look at it using RUPS. You can see the file modifications and see where the file gets broken.