One of the unique features of the InterFormNG2 workflows is the ability to setup very dynamic and generic workflows.
There are multiple advantages with a generic workflow:
1.It is much smaller compared to a setup, that e.g. contains a whole subtree for each document type.
2.It is much faster to edit as you only need to insert a change once and not for each subtree...
3.It is easier to adapt to a specific setup, so this is the way to go for business partners that wants to distribute a predifined package.
Some of the things to consider for the generic workflow are:
1.Should the input type be generic or are all files arriving in the same way?
2.The process for all files must follow the same pattern, where some actions may be optional.
3.Should some input files be split and/or transformed?
4.Should some input file be enriched with SQL?
5.Setup the workflow to generate output in a standardized way, while opening up for special deviations from the standard.
6.Is this overkill? If there are only a few different documents to handle, then you perhaps do not need a full generic workflow.
This section is to give inspiration for how to setup a generic workflow with these topics in mind:
Step 1: Generic input type.
Step 2: Setup optional splitting and related transforms.
Step 3: Setup logging.
Step 4: Setup optional enrich via SQL.
Step 5: Setup default values for workflow variables to be used for all potential outputs.
Step 6: Special rules to handle deviations from the default values for specific documents.
Step 7: Create output(s).
Step 8: Error handling.
Generic input type
The input data files for InterFormNG2 normally arrives in the same way, but you might want to allow input files to arrive in various ways e.g. via both a monitored folder(s) and via a webservice. In these cases you should consider to build a common workflow, which each of the input workflows call.
Here you first create a sub-workflow with the input type, From other workflow. Here we call the sub-workflow, main1 and this is where all processing is to be done. We expect XML files as input so the main1 workflow is setup with the input file type, XML:
Now the initial workflows (that are getting the input files) can call the main1 workflow:
Setup optional splitting and related transforms
In this section we consider how to handle input files no matter if they are to be split up or not and still be able to process both the splitted and unsplit files in the same workflow elements.
In short you have these options:
1.You can use a choice element (condition) with a condition to test if the actual input file is to be split up or not and then use separate subtrees in the workflow: One for the split and another branch for the un-splitted files. This may be a good choice, if only a very few documents are to be split up.
2.If more document types are to be split up, then you should let both branches of the solution above call a common sub-workflow, which should be able to handle the output of all files - no matter if they have been split up or not.
The last option is covered below as this is the solution, that is most generic.
The main workflow, which we call MAIN1 (which fits the workflow mentioned above) determines (with a condition in a choice) if the specific input file is to be split up or not:
The files, that are to be split calls a subworkflow, generic_split and the files, that are not split are to call the next part of the common workflow, MAIN2:
The files, that are to be split calls the sub-workflow, generic_split:
So with the setup above all input files are calling the MAIN2 either directly or after the split.
Splitting of the files is done with these components:
Here the splitting is combined with two xslt transformations in order to reformat the files and keep common headers. This is covered in the section, Split and transform example.
The example above can be used, if you are not splitting up too many input file types. If there are many, then you should consider to setup a generic way to select the two transformations via workflow variables before the generic_split workflow is called and then only have one branch for each variation of the path used for splitting up the XML file, as this path cannot be defined dynamically via an XPath expression.
Setup logging
Now we want to add logging to the workflow above. We want to add the Log info key component for all input files and the New log line component for each splitted XML file.
The Log info key is added as early as possible in the workflow. At best before the MAIN1 workflow is called:
For the log info key it is a good idea to concatenate the type of document with the document number e.g. 'Invoice_' and the invoice number. Here you might also need to select the data for the log info key in different ways depending on the document in question. If that is the case, then you should consider to implement yet another sub-workflow with a choice element in order to set the value in the right way for all the different document types.
For the splitted files you need to insert the New log line directly after the split like so:
The suggestion above for the value of the log info key should also be considered for the New log line.
You should also consider for how long the job logs should be kept. This is setup in the job log settings for the tenant.
You should also consider for how long you want to keep the system log files.
It is also a good idea to consider to enable the email log.
Optional enrich via SQL
For some of the XML files we want to add more data into the XML via SQL. This is done with the workflow component, Enrich XML from database, where the database should be setup in the tenant under Database connections.
We want to handle the SQL part in a sub-workflow, which returns either the original XML or the changed XML, depending on if an SQL enrich was run or not.
So we call the sub-workflow, generic_SQL from the main workflow, main2:
Below is shown how you can link the document type (which is found in a node in the input XML file) with an .xent file to execute one or multiple SQL lookups in order to add missing data into the XML file. Here we build on the prerequisite, that the xent file (if there is one) is named the same as the data found in the node /Root/DocumentType. With this in mind this is the generic workflow, Generic_SQL:
The components used looks like this:
First we set the name of the xent file into a workflow variable, xentfile by concatenating the extension to the documentType found in the input file:
In the upper branch of the choice component we can test if the enrich component is actually to be called:
Finally we can then run the xent file with the workflow component, Enrich XML from database.
Processing will return to the main2 workflow with a payload, that might have been enriched with data from an SQL lookup.
Setup output variables with default values
At best it is possible to uniquely identify what output(s) the input file is to generate and all related properties. In this case we setup these workflow variables to covers this:
outputType
This could signal one or more of the outputs: pdf, print and email. If more than one output is required, then each output type are included e.g. "pdf,print" could tell InterFormNG2 to both generate a PDF file and to also print the result of a merge. If this cannot be directly found in the input file, then you could consider to use a translation file to configure this - just remember, that if you edit the translation file directly from the file explorer, you might need to temporarily disable caching or only cache fonts.
template
This variable is to identify which template to use for the merge later on. The value can be set as the documentType from the input file concatenated with the extension, '.ift'.
For each of the output types you should setup a default value:
(Suggestion for variable names are listed below)
For PDF output
interform.plugin.archiver.folderName
This should contain the path/directory where the optional PDF is to be generated.
interform.plugin.archiver.fileName
The name of the PDF, if a PDF file is to be generated.
interformng.output.conflictResolution
What to do, if the PDF file already exists.
For print output
interform.destination.printer.printerName
Name of the printer, that is registered in InterFormNG2.
printerSocket.timeout
It is recommended to set this to 20, in order to set a time out of 20 seconds for printers, that are connected directly to InterFormNG2.
For emailing
interformng.emailServerName
Set the name of the email server configuration to use.
email.subject
The subject of the email.
email.from
The email address to set as the sender.
email.to
The email address to send to.
email.cc
The CC receiver of the email - if used
email.bcc
The BCC receiver of the email - if used.
email.replyTo
An email Reply to address - if used.
interformng.emailTemplate
The email template to use.
interformng.attachmentName
The name to use for the attached PDF file.
email.hold
If the email should be held or not (yes or no).
The assignment looks like this:
With this addition the main2 workflow now looks like this:
Change variable value for specific deviations
The standard value for the variables defined in the last section might be true for the most, but there might be special rules/requirements for specific documents. In order to be fit such requirements we can now call another sub-workflow and let that overwrite the normal values for specific documents and/or specific customers.
This is done with a new sub-workflow, which we can call output_override. In here we can use the choice component to test the values of the current input document and here override the values of some variables if needed:
We now include this sub-workflow in the main2 workflow:
Generate outputs
Now we are finally ready to generate one or more of the outputs: Print, PDF and email.
We do that with a condition for each of the output types and combine that with the multicast component. This makes it e.g. possible to later alter the payload in each of the output branches if necessary without changing the other output types.
This is inserted in the main2 workflow:
The conditions for each of the 3 branches looks very similar and tests, if the specific output is one of the requested with the contains XPath function:
The test for print looks like this:
For each of the branches all parameters are set as one of the variables listed previously:
Error handling
The final thing to consider is the error handling as an error might occur during processing e.g. if something is missing in an input file. The potential errors can be handled in multiple ways:
1.You can setup InterFormNG2 to send an email to an administrator, if an error should occur.
2.You can validate the input file and force the processing to stop with an error, if the validation fails.
3.You can also consider to setup an error workflow on the workflow header and even set another error handler at any point in the workflow(s).
The last option is shown below, where we choose to store the input file in a specific folder, if the processing should fail.
The payload might change at some point, so we want to save a copy of the input file, so that the error workflow is able to get hold of the original input file.
That can be done by storing a copy of the input file with the workflow component, Payload to named property as the first thing in the main1 workflow:
In the error workflow you can the retrieve the original payload with the component, Named property to payload and then e.g. save a copy of this file into an error folder e.g. like described in the section, Workflow: How to move files into an error folder.
