Activation Files for Publishing Engine
Introduction
Activation files are XML files that are required to start the publishing job in APP and provide APP a script to run. They must conform to the structure described below.
Activation File Structure
An example activation file might look like this:
The Publishing Engine APP activation file structure is very simple, consisting of only five elements:
Element
Description
<activation>
The root element is a wrapper for the <input>, <script> and <output> elements. <activation> contains:
◦ 0 or 1 <input> element
◦ 1 or more <script> elements
◦ 0 or 1 <output> element
<input>
<input> is an optional child of <activation>. The purpose of this element is to provide a list of files expected to be provided and used by the script(s) which can be checked before the script is processed. If any of the files listed by <file> children are not present, the job will fail, thus providing a means to check everything is ready before the job is processed. <input> contains 0 or more <file> elements.
<script>
The <script> element contains either script code within a CDATA section, or a link to an external file. By default it is expected that the activation file script code will be provided here as a copy of the activation file contents from Enterprise.
The <script> element has three attributes:
◦ A ‘type’ attribute indicates the language of the script and can be either ‘js’ or ‘app’. The type will determine which scripting engine will be used to process the script in APP.
◦ An ‘href’ attribute can provide a link to an external script file using an absolute path (JavaScript only so ‘type’ must be ‘js’). If ‘href’ is provided, the <script> element must be empty. If it is not empty, only the linked file will be run.
◦ An ‘id’ attribute to identify the script in the log and job response.
The <activation> element can contain one or more <script> elements, making it possible to run scripting before and after the activation script itself.
<output>
<output> is another optional child of <activation> whose role is similar to that of <input> in that any files listed will be checked to see if they exist after the scripts have been run. If any files listed do not exist then the job will be reported as having failed. <output> can contain 0 or more <file> elements to list the files expected.
<file>
<file> is a child of both <input> and <output> and is used to provide the location of a file which expected to be found either before (for <input>) or after (for <output>) the scripts have been run. The <file> element has a ‘href’ attribute which contains an absolute path to the expected files.