Bad practice | Good practice | Alternatives |
Very large (>10MB) input payloads, for instance for batch creation of multiple outputs. | Small input payloads for one output at a time. | For batch spooled files, use the input component "From IBM i output queue (Stream)". Otherwise increase InterFormNG2's maximum heap size to allow for the necessary allocations. |
Workflows that generate a single huge job log because splits or repeats are used. | Use the "new log line" component to divide the job log after each split/repeat. | |
Sending multiple requests in rapid succession to a workflow with web-service input. (potentially up to around 250 jobs can run in parallel, which will cause high memory usage and slow execution of each job) | Throttle input requests before they reach InterFormNG2. Consider if a message queue workflow input component can be used instead, for instance ActiveMQ or Azure Service Bus. | 1. Enable tenant throttling in the system settings (but be aware that the input requests will still be queued in memory). 2. Consider having multiple InterFormNG2 installations with load-balancing in front. |
Multiple or large images in uncompressed PCL output. | 1. Use PCL6 if it is supported by the printer. 2. Enable "compress images" in advanced PCL settings. | |
Storing thousands of resources in a single library folder. | Divide the resources in multiple folders (for instance create a new folder for each date). Here you can create a folder based on the current date with the function, ng:timestamp. This expression could be included in the path for the output file to create a folder per month: '/' || substring(ng:timestamp(),1,6) || '/' or this to create a folder per day: '/' || substring(ng:timestamp(),1,8) || '/' | |
Having a workflow save thousands of files with the same filename into a single file system folder with the "append version" conflict resolution. | 1. Use unique file names. 2. Use the "time-limited store" feature where possible (requires unique IDs). 3. Use an archive system for long-term storage. | Divide the files into multiple folders (for instance create a new folder each day) or use the "rename existing" or "move existing" conflict resolution options. |
Using large sample inputs in the designer, resulting in a lot of pages being generated. (Each update to the template design will trigger a heavy re-rendering of the result view.) | Small sample inputs with just one variant of each page type. | |
Performing heavy SQL lookups in a template design. (In the designer, every update to the template design will trigger all the SQL lookups.) | The dataset should be complete before it goes to the template. Perform SQL lookups and similar data-fetching operations in the workflow. | |
In a template design, using only page-overflow for page breaks in documents with a lot of pages. | Whenever possible, use multiple page elements or the "page break" element to force page breaks. | |
In a template design, using an if-element to filter items from a repeat. For instance: - Repeat: /invoice_line - If: ./line_type = 5 | Add the filter condition on the repeat expression itself: Repeat: /invoice_line[line_type = 5] | |
Using the e-mail log as a long-term archive. (Search time will increase as the number of items in the log grows). | Use the automatic deletion to delete old logs within reasonable time. If necessary, move older emails to a separate archive. | |
Specify the full path to a node instead of asking XPath to search for it. | Do not refer to a node like '//page' unless really needed. If you e.g. want to refer to the page node of an input file, which represents a spooled file, then you should not use //page when you want to repeat through all page nodes. Instead you should specify the full path and include the root node (which actually is named 'spool'), if that is known and fixed, which it is for a spooled file. So for spooled files a page repeat should be setup with /spool/page instead of //page. |