Hi, Has anyone ever built a plug-in that allow us to populate the doc

Hi Amirul,

Is the intent to create a document for each indexed value in the array or are you looking to put multiple PV values into a single document and then create multiple copies of that one document?

Hi Amirul, if you are looking to input list pv's into a template I've often used the function 'joinarray' to generate flat text that can be easily inserted into a document template. The speed to generate the text would correlate with the size of the array you're working with.

'joinarray' lets you delimit each array element with your own string. I like working with html templates because you have a wide assortment of choices with how to display your information. I prefer using unorder list tags, but div, p, and table are all possible as well.

Hope this gives you some ideas.

Hi,

I want to generate multiple version of documents based on different pv lists. Example: Generating letters to multiple unique customers in a single document node call (rather than looping through each customer).

Hi Amirula, In your document generating node there is a tab called other with options for running multiple instances simultaneously. You can provide one of your pv lists to represent howmany items should spawn, then use tp!instanceindex as an index for all your pv lists when you fill out your template set-up.

Check out forum.appian.com/.../Other_Tab

Hi Felix,

Thanks for the info beforehand and yes we have done this way before. One of the problems that we have with MNI or looping is breaking the activity chaining on the process. We need to show the generated letters before sending them and if there a lot of them, the activity chaining breaks before we are able to show the review screen. We could increase the max limit activity chaining from configuration level but I don't believe that solution would be scaleable in the long run. That's why we're looking ways of generating templates in one pass as we have optimised the other nodes leading to the review screen.

Regards,

Amirul

Mind you when I said MNI breaking the activity chaining is not always the case depending on the number of letters that we generate. Once it reaches big numbers, it breaks the activity chain.

I was also thinking another way to work around the issue with generating documents in big numbers without breaking the activity chain. One way is to put the document generation in an asynchronous subprocess and proceed to the review screen and then put a refresh button to refresh the list of generated documents as they are being generated in the background but I just felt it's a bit clunky from user perspective.

This sounds like a tricky design problem. It is probably possible to guage whether your chaining will break if you can estimate how many documents will be generated, and if you feel the wait would end up being too long then have an alternative path laid out for the user to understand that their request will take longer than chaining would allow.

What would be a really useful tool would be if you had your document generation jobs run asyn to your user process and present a 'Please Wait' form for the user. In the 'Please Wait' form you'll need to write a script that can ping the document generating process to know if it has finished or not so it can proceed to a kind of Review Results form. I haven't implemented such a design myself, but its one I'm keenly interested it.

The "please wait" process is certainly possible.

In your process, on submission of a form, chain in to a synchronous sub process that lands on another user input task.

In the meantime, the parent process runs in parallel and does what it needs to. When the processing is completed set a Boolean value to true, which is initialised in the child process by reference as false.

The user is now looking at the form, which you could automatically submit using some JavaScript (will be on the forum somewhere) after say 10 seconds. Every time it submits it loops back around until the Boolean value is set to true which after submission of the form is checked on an XOR. We also terminate the looping after a certain amount of time by setting a counter.

When the processing is ready we then display a link to take the user to the process dashboard as this is what we have used it for in our example.

This sounds like a very straight forward approach that would use Appian's process modelling as oppose to using lengthy customisation.

You would simply need to introduce a fixed interval function callback in your script which would automatically submit the Appian form which appears to use the class "form runtime".

In terms of UI you could also hide the form button and have an animated loading GIF image for your users.

Cool tip David.

Yes the animated gif is what we use, I have used this type of functionality in other BPM products as well. Helps avoid anything to complicated outside of the available functionality and keeps the user within the context of the work they are doing.

You can always make this reusable as well by passing the process ID in for the link and a message to display on the form as well while the user is "waiting".