During the last few weeks I was brought in to a new Mendix project to help troubleshoot and fix production bugs. One issue that was especially difficult to figure out involved the creation of a document based on a template with a whole lot of tokens. For those uninitiated, tokens are attributes that you can use in your application for emails or document generation to allow the dynamic values to populate instead of fixed text. Once I figured out what was causing the issue, I found what I believe is a limitation of the “generateDocument” action in a Microflow. I’m creating a ticket about this but if you’re interested in the problem and short-term solution, read on and I’ll explain.
The client had already tested and approved a feature that allowed their Reviewer-level roles to create new templates within the application to generate the documents needed for their particular customer inputs. They needed the flexibility to modify and create these on the fly, so the previous Mendix engineers created some standard templates that they are able to copy and modify to fit their needs. After months of being in production, one of the application users attempted to generate their document and it failed. This had never happened before.
My hunch was it had to be due to one of two things: An attribute used by a token in the document used some sort of special-character from a foreign alphabet, or something was afoul with the template used for this particular customer. Either way, I was pretty sure it wasn’t system related and instead data related because it would have been showing up as an issue consistently across all clients. That isn’t always true, but it was a hunch and a good start.
First I copied down the production database to my computer. Then I logged on as an administrator and changed that user’s password so I could logon as them and press the button that initiated the process. I setup the breakpoint in the microflow and pressed the button. It failed on the ‘generateDocument’ with a cryptic error:
Jun8 13:06:57.247 127.0.0.1 tr10000: ERROR - Connector: (1/180) com.mendix.modules.microflowengine.MicroflowException: javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: Invalid property encountered on "fo:inline": mso-ansi-language (See position 18:443) Jun8 13:06:57.248 127.0.0.1 tr10000: ERROR - Connector: (2/180)at Reporting.SM_ChangeVariablesInLetterTemplate (DocumentExport : 'Generate PDF (.pdf) document using template 'LetterTemplate'')
A colleague of mine started the process of removing one section of the document template at a time until we found the section with the error. It was as suspected in the letter body. I captured the string value (the body of the text was stored in an unlimited string in a non-persistent entity) as it was created, found an HTML renderer online, and pasted it in. No problems. The text appeared fine. More work to be done.
Next I took a closer look at the HTML itself. I noticed a couple of oddities. First, there were some random style attributes applied haphazardly throughout. For example, I would see something like (pseudo code):
‘<span style=”…>word </style>’
That indicated to me that most likely the text had been edited in a word processing program like MS Word, copied and then pasted into the Rich Text Editor on the application page. It’s very common for styling that is done in MS Word that might even be naked to the visible eye to accidently make its way into the Rich Text Editor. Normally that isn’t an issue but it can be and it’s something for your users to be aware of. I stripped that styling out where it appeared but the issue persisted. Onto the next issue.
I noticed that one line of text was set to “Font Size: 2.5” in the Rich Text Editor. When translated into HTML it came through as text-size: x-small (that might not be verbatim but it was called ‘x-small’. I removed this styling and it worked perfectly.
Apparently, from what I can conclude, the ‘generateDocument’ action doesn’t know how to deal with that particular styling. That is what I am creating the ticket about.
The good news is we were able to find it and fix it. The bigger picture is to figure out a way to allow the flexibility to create their own templates as they can today while enabling a way to check for and address any custom styling that might make its way into the process and cause errors. I’ll probably write about that once I have time to engineer a solution. ;)