Elvis Server can be tightly integrated with Enterprise Server to make the assets that are stored in Elvis available in the workflow of Enterprise.
Connecting the two systems is done through the Elvis Content Source plug-in for Enterprise. This makes it possible to:
- Drag assets from Elvis onto an InDesign layout that is stored in Enterprise
- Use Elvis within Content Station 9
- Export assets from Elvis to Enterprise
- Import assets from Enterprise to Elvis
For a general overview, see Integrating Enterprise Server with Elvis 5 - introduction.
Figure: Using Elvis in Content Station.
Installation
Step 1. Download the Elvis Content Source plug-in from the Enterprise Server download page.
Step 2. Unzip the file and place the resulting 'Elvis' folder into the following location:
<Enterprise Server folder>/config/plugins
Basic configuration
As a minimum configuration step, connect Enterprise Server with Elvis Server by setting the Elvis URL.
Step 1. Open the configuration file of the Elvis plug-in in Enterprise in a text editor:
<Enterprise Server folder>/config/plugins/Elvis/config.php
Step 2. In the ELVIS_URL option, define the URL of the Elvis Server to connect to.
* Elvis server URL (without a trailing slash)
*
* Used for server communication between Enterprise and Elvis Server.
*
* This is typically 'localhost' (if Elvis and Enterprise are running
* on the same machine), or the internal ip address of the Elvis Server.
*/
define('ELVIS_URL', 'http://localhost:80');Additional configuration
Whenever an asset is updated in Elvis (such as updating its metadata, opening it in an external editor, or deleting it), Enterprise users need to be made aware of this. Similarly, when an Enterprise user makes a change to an asset, this needs to be communicated to the Elvis users.
This communication is provided through a script that runs on Enterprise Server using cURL. It is a long-polling PHP script which periodically checks the Elvis Server for asset updates.
Once an asset update is received it is applied directly to the Enterprise object.
cURL setup
The script is executed on Enterprise Server by using cURL.
Installation
- For Mac OS X and Linux: cURL is pre-installed on these systems, no installation steps are necessary.
- For Windows: download it from the cURL download site and install it.
Script setup
The script runs for a maximum amount of time and needs to be scheduled to always run.
Configuration
The following parameters are used:
- maxexectime. The maximum amount of time that the script runs in seconds. The value should be between 60 and 1800 seconds (1 and 30 minutes) and should match the schedule interval. Default value=600.
- maxtimeoutperrun. The maximum timeout in seconds for each update call to the Elvis Server. It should not be higher than the 'maxexectime' value. Default value=60.
Scheduling
The scheduling can be done by using Cron (Linux / Mac OS X) or the Task Scheduler (Windows).
Example configurationConsider an example configuration with the following settings:
Schedule configuration on Mac OS X & Linux
Step 1. Open the cron jobs via the Termina ( crontab -e ) or use an editor such as CronniX. Step 2. Add the job: */5 * * * * curl "http://localhost/enterprise/config/plugins/Elvis/sync.php?maxexectime=300&maxtimeoutperrun=60" Step 3. Save the settings. The job is now active.
Schedule configuration on Windows
Step 1. Open the Task Scheduler. Step 2. Create a new Task. Step 3. Type a descriptive name, such as "Elvis sync job". Step 4. In the 'Triggers' tab create a new Trigger with the following settings (found under 'Advanced settings'):
Step 5. Click OK to close the New Trigger window. Step 6. In the 'Actions' tab, create a new Action with the following settings:
Step 7. Click OK for all open windows. The Task is now active. |
Elvis plug-in setup
To give the plug-in sufficient access rights for making the changes to the assets, give it Super User rights for Elvis and Admin rights for Enterprise Server.
Step 1. Open the configuration file of the Elvis plug-in in Enterprise in a text editor:
<Enterprise Server folder>/config/plugins/Elvis/config.php
Step 2. Validate the following credentials:
- ELVIS_SUPER_USER
- ELVIS_SUPER_USER_PASS
- ELVIS_ENT_ADMIN_USER
- ELVIS_ENT_ADMIN_PASS
/**
* Elvis SUPER_USER username and password, needed for creating PDF previews
* with InDesign Server.*/
define('ELVIS_SUPER_USER', 'woodwing');
define('ELVIS_SUPER_USER_PASS', 'ww');
/**
* Enterprise Admin username and password, needed for metadata synchronization
* from Elvis to Enterprise. By default we use a user which is known in both
* systems with the same credentials.*/
define('ELVIS_ENT_ADMIN_USER', ELVIS_SUPER_USER);
define('ELVIS_ENT_ADMIN_PASS', ELVIS_SUPER_USER_PASS);Step 3. Save and close the file.
Enabling the plug-in
The installed plug-in needs to be enabled in Enterprise Server. Do this by accessing the Server Plug-ins page.
In Enterprise Server, click Server Plug-ins in the Maintenance menu or on the Home page.
By accessing the page, the plug-in should be automatically enabled and show a green icon.
Figure: The Elvis plug-in enabled on the Server Plug-ins page.
Testing the integration
Step 1. In Enterprise Server, access the Health Check page.
Step 1a. In Enterprise Server, click Advanced in the Maintenance menu or on the Home page. A page with all advanced Maintenance features appears.
Step 1b. Click Health Check. The Health Check page appears.
Step 2. At the bottom of the page, click Clear All.
Step 3. Only select the Elvis Content Source test.
Step 4. Click Test.
The test is executed and the result is displayed next to the test. It should display “OK”.
Note: If the test fails, an error is displayed together with instructions for solving it. Follow the instructions and then run the test once more.
Step 5. Test the integration by for example dragging some files from Elvis into InDesign onto a layout that is stored in Enterprise.
Test the integration by for example dragging some files from Elvis into InDesign onto a layout that is stored in Enterprise.
Comment
Do you have corrections or additional information about this article? Leave a comment! Do you have a question about what is described in this article? Please contact Support.
2 comments
On Script setup (sync.php): In a scenario with multiple WoodWing application servers, should this script run on each application server, some applications servers, or absolutely only a single application server? Currently the documentation doesn't mention configuration for scaled up scenarios.
From class ElvisSync, I think the answer is "You can run it on as many application servers as you like, because the job uses a semaphore, and only one can be active at any time", but it would be good to get a clear and documented answer on that.
Additionally, while you're at it -- I didn't bother to check where these are documented -- it would be really nice if you could answer the same question for jobs "jobindex.php?createrecurringjob=AutoPurgeTrashCan", "jobindex.php?createrecurringjob=AutoCleanServerJobs", "jobindex.php?createrecurringjob=TransferServerCleanUp", and "idsjobindex.php".
Hi Siebrand,
First of all, apology for the very late reply.
Please see below for the answers:
From Elvis point of view:
From Elvis point of view this should not give any issues.
The retrieveAssetUpdates the sync job calls from Enterprise is compatible with multiple enterprise system ids.
From Enterprise point of view:
As you have found it out yourself, that this script can be run on multiple Application Servers simultaneously. This is due to that the script is semaphore protected ( the same for the idsjobindex.php which is explained below ).
So at any one time, only one sync.php will be really executing and doing the sync ( even though many are installed and called ).
Calling jobindex.php to create recurring jobs from multiple Application Servers (AS) (each having an exact copy of the crontab) is NOT wanted. They are not designed to run in parallel and you do not want to have 5 same cleanup jobs in the queue because you have installed 5 AS machines. so these kind of jobs have to be created from one AS instance only.
This one is periodically run by crontabs in "dispatcher" mode. It has a semaphore protection for that, so there will be only one dispatching for e.g. 1 minute, then dies off and the crontab creates another instance and so on.
So even when there are many dispatcher processes created (one per AS), only one will become the real dispatcher due to the semaphore. When it finds a match between an IDS instance and a job, it calls itself async via cURL but now with a parameter that tells himself to run in processing mode, which is seen as another process that is separated from the dispatcher. This process ( the one running in the processing mode) can run in parallel with any other processes because they all get one IDS instance and one job to work with which will never be conflicting. In other words, idsjobindex.php is designed for a multi-AS setup
And indeed, we don't have this documented elsewhere so far. We will improve on this and add in the above information too. Thanks for bringing this up.
Please sign in to leave a comment.