Automated Document Generation

Krista:
All right. Hey Gordon, how's it going today?

Gordon:
Great. How's it going Krista?

Krista:
So far, so good. If you want to stop sharing your screen, we'll start this. So thanks for joining us. I washed my hair today and everything, and you're looking bright and chipper down in Fredericksburg, Texas, if I understand right.

Gordon:
That's right.

Krista:
So Gordon, why don't you tell us a little bit about what you're going to be talking about today, automated document generation, just before you start.

Gordon:
Yeah. So in a lot of our automation projects, we have a requirement to generate documents of some sort and it comes up enough that I wrote a support site article on our website, which you can check out. And so I just wanted to talk a little bit about the nuances around that because there could be a lot of different reasons why documents need to be generated. And there could be situations where actually we find out really, you don't need to generate documents. So I just wanted to talk about the different options that our consultants have out there and our customers have as well.

Krista:
Nice. So you get a lot of crazy requirements thrown at you all the time and requirements that don't necessarily actually need to exist. So I guess let's start there and I'll give you the reigns and let you share your screen.

Gordon:
Great. All right. So the first thing I wanted to talk about here is the requirement itself. We get different types of requests, like the solution must include document generation, or we need everything in PDF or content creation is required for adoption. These are just kind of some snippets of things we hear sometimes when we're scoping our projects. And this is all well and good and oftentimes there are good reasons for these requirements, but these are not business requirements.

Gordon:
So one of the important things is for our consultants and for our customers to understand why these requirements exist, so that we can best meet those needs.

Gordon:
So this next page is kind of the three categories that I came up with of why document generation might be at least perceived to be required. So the first one is, we need to generate a consumer document, like an invoice or a legal document. So there are certain, especially legal or compliance reasons why documents are necessary and that's a very good reason why document generation is necessary. In a minute, I'll talk about how we can generate documents like that.

Gordon:
Another reason that this might come up would be for either audit or tracking or compliance reasons. Now, this is a case again, where maybe for legal reasons, you do need to have an actual document, so a PDF or a physical piece of paper but oftentimes this is a situation where you actually don't need to generate documents and there are other ways for an organization to prove that they have done things the right way and followed all of those policies and guidelines.

Gordon:
And then the final one is, the use case is basically, I need to capture my process data and send it to someone who's either offline or they're not part of our application, essentially. And again, that's a situation where it does make sense for us to pull that information out but whether it needs to be a document or not is up for debate.

Gordon:
Okay. So now that we have the guidelines here, the baseline of what we're going to talk about, I want to talk about some options that you have for actually generating those documents.

Gordon:
Number one is, you can print to PDF. So all of our applications, we build pretty much, are web applications and that means you're in a web browser. So the easiest thing you can do is take whatever information you are seeing on the screen and press Control P and just print it. And then one of the options in modern web browsers is to save that page to PDF.

Gordon:
Now it may not look exactly the way it looks on the screen and we do have again, linked in my support side article, I linked to another article that Tom [Bouchart 00:04:35] wrote about how to optimize your page for printing. So if you know that someone's going to be printing a page, there are a couple of tricks you can do, to make sure that it prints nicely. And also if you are in the IBM BAW tool, the Brazos Dashboard's toolkit gives you a really easy way to include literally all of your process data with really no configuration necessary. So if you want to give someone the ability to print out all of the data related to a process, I would highly recommend giving that a try.

Gordon:
Now, of course, when we do this, it doesn't look like a typical document. You're not getting a structured Word document or anything like that, but it does give you the ability to share the information you're seeing on the screen with someone who is not logging into the system and might not have access to all the systems that you do. So if you just need kind of a quick and dirty solution, this is the easiest by far and it does work for some of our customers.

Gordon:
All right. So option two is probably the best option for most situations. This is where you generate a document based on a template. And so this goes for those legal documents or invoices or anything that has a structured document type that you have to follow closely. Basically, there are several third-party applications out there, including Aspose, PDFKit, and a couple of Apache Toolkits that will allow you to generate either word documents or PDFs, where you basically just go into Word, you create your document and then you put in placeholders, like you see in my screenshot here on the page. And then you can basically use that third-party library to identify those placeholders, and then put your process data into those places in a structured way.

Gordon:
The downside here is that many of those third-party applications do have a licensing cost, so you've got to consider that. Now they're not particularly expensive, compared to the process automation software that you're using, but it is a consideration. The Apache offerings are free but they're not quite as easy to use as the other ones, so it's just a consideration there.

Gordon:
One other thing to think about, is these third-party applications typically have, well, not all of them have both, but you're going to have the option between a Cloud API versus a built in Java integration. So for example, Aspose actually has both, so you can do the same thing either way. The nice thing about that Cloud API is that you don't have to write any code. All you have to do is set up a REST integration and let Aspose do all the work on their side. Now, of course, this has some security concerns, so you'll have to discuss that with your client before you go with a solution like that. If you use that built in Java solution, everything's running on your client's servers, so that's a bit more secure.

Gordon:
One thing I want to mention on this page, before I leave, is for a demo that I did last week, Bill Smith helped me by building out a solution just like this, using the Apache POI Toolkit and we are currently working on making that more genericized and generally consumable, so that if you do have a requirement to generate Word documents as part of your solution, you'll have a working example to start from there. So we're not quite done cleaning it up yet but Bill did an awesome job in making it a seamless integration with our demo last week.

Gordon:
All right. So option three is, you can generate a document dynamically. So if you do need to build out a document that varies in structure, you do have the ability to dynamically generate that document, using some of the same libraries that I just mentioned.

Gordon:
So in this case, instead of taking a structured template and then feeding in values into those placeholders, we can actually completely build up a document from scratch. So it gives you the ability to build out tables and all sorts of different repeating structures and really display any kind of data that you want in a document. So obviously that makes this the most flexible option but it's also the most coding by far.

Gordon:
So you're going to have to build up every little bit of your document, step-by-step. It also means formatting is a challenge, because like I said, if you don't know exactly how the document is going to look at the end, you've got to be pretty creative about how you're building it out and you've got to think a little bit more like a web developer, as you're building out the structure of your document. And again, with this option, there might be a licensing cost, so just consider that as you're going through.

Gordon:
And then of course, option four is that maybe you don't have to generate a document at all. So, as I mentioned in the beginning, if the reason for document generation is for auditing or historical records, I would recommend that you advise your client to change the way they think about their historical records because really storing everything as a document is not the ideal way of getting at your information. It's not very searchable. The data is no longer structured, when you do it like that. And the other thing is your process solution, more than likely already has all of this historical data saved, in either a performance data warehouse or some other sort of database that's part of the solution.

Gordon:
And so this is not news to you, but it's something I would recommend that you try to change the way your client is thinking because if they really want to generate a bunch of documents and then put them in a content management solution or worse, print them out and put them in file cabinets, this is a much, much better way to go about it and you can get creative about how you expose that information to the people that need to see it.

Gordon:
So just for example, you can build out a dashboard using either your process solution, or even just building your own webpage of some sort that can display that information. And then the nice thing about having all that information in the dashboard is then you can search through it. You can sort it, you can export it to Excel, you can filter it, you can do all sorts of things that you can't do in a file cabinet.

Gordon:
So anyway, I would just recommend you try to change the way your clients are thinking if their reasoning is for auditing and historical purposes. Of course you can't change everyone's mind, but it's worth the conversation because I think this is an easier solution and it will ultimately serve your customer better. And that's why I put the last bullet point there. I put it it might require some political maneuvering to get people to think your way but just something to consider there. So that's all I had for slides.

Krista:
So Gordon, if you'll stop sharing your screen and we got a couple of questions to ask you in the chat. So the first one is, do you generally generate PDFs Word documents and why? And does BP3 have any examples of this?

Gordon:
Well, first of all, it's all about your customer's requirements. So they might answer that question for you. Last week for the demo, the requirement was that we needed PDF and Word documents. I would say the general rule of thumb is if you want the person who is receiving the document to be able to change it in some way, then you're going to want to go with a Word document. Word documents are basically an invitation for the person to change it. And so by that token, there are many documents that we absolutely do not want the person to change and in that case I would go with a PDF.

Krista:
So then another question's come in. What's the best practice and I think this leads into what you're talking about, is what's the best practice for getting from the requirements to the real problem?

Gordon:
Yeah. So I would say the best way to get at that is to ask a lot of why questions. So why do you have this requirement in here? And it's a fair question. It's not a challenge necessarily but it makes sure that there is some reason behind it. You may not be talking to the person who knows the answer, why but if you know that why question, then you can really serve your customer better.

Krista:
And another question that we've gotten in chat was, are some automation stacks better suited to this problem than others?

Gordon:
Any automation stack that can make an API call can work with third-party APIs. I would say most automation stacks also have the ability to use a third-party Java library, like we were talking about. I think we're pretty agnostic as far as the automation platform and the third-party library. They all work pretty well together. So-