You can create an index data XML output file with the advanced workflow component, Index data. The index file can e.g. be used for archiving
You can use a transform component to convert the XML into another format before saving it to a file.
The index data component only accepts printable as input, so it cannot be inserted in any place in the workflow. You need to make sure, that the previous workflow component output a printable output e.g. PDF. You can e.g. not place the index data component after the create PDF file component, as the output from that is XML.
Here is as sample workflow, where the Index data component is used:
In the generated document, all the specified index values will be under an element called "IndexValues". Additional metadata will be in the element "MetaDataValues". The elements md5, sha-1 and sha-256 are hash values of the document that was previously created from the template. If the created document was saved to the file system, then the file name element will have the file name of the document.
The index data component has these parameters:
Add index element
Click this blue icon to add more lines below. This will more detail nodes to the output XML file. Click the trash can icon on the far right to delete a line.
Index label
The name of the label/node in the output XML file.
Index value
The value to insert for the index label. This should normally be a dynamic value. In the example above I have loaded a sample XML file in the workflow and referenced it via the magnifying glass.
With the demo invoice xml file and the definition above the output file will look like this:
Below you can see an example of how the index data component can be used in the workflow:
You might want to ensure, that the file name of the index data file is the same as the PDF file, that was generated. You can do that, if you setup the second To filesystem component up like this:
Notice the functions setup for the file name:
concat(substring($interform.plugin.archiver.fileName,1,string-length($interform.plugin.archiver.fileName)-4),'.xml') and that the file name conflict resolution is setup to overwrite.
The problem is, that the PDF file, that we created first might be given a different name, that we think, because a file already existed with the same name. One of the file name conflict resolutions is to give the PDF file a number at the end to generate a unique name. The clever thing is however, that the predefined output variable, $interform.plugin.archiver.fileName contains the final name of the PDF file after running the first To file system component.
The challenge is then to convert the extension from .pdf into .xml. One way to do that is to remove the last 4 characters of the original file name and then append '.xml' to the file name, and that is exactly what is done here:
concat(substring($interform.plugin.archiver.fileName,1,string-length($interform.plugin.archiver.fileName)-4),'.xml')
The concat concatenates two strings:
1) The initial part of the PDF file name.
2) .xml
The initial part (without .pdf) is found by taking a substring of the full file name, but reducing the length with 4, so if the PDF file is called e.g. 'Invoice_1234.pdf', then the length is 16. We then subtract 4 and do a substring to the the first 12 characters: ''Invoice_1234' and then concat it with '.xml' to get ''Invoice_1234.xml'.
The workflow above use these components:
Create PDF document to create an internal PDF in the payload.
To filesystem to copy the PDF file into a file.
Index data to build up an index file.
To filesystem to write the index data into a file.
