WoodWing Help Center

Integrating Elvis 5 in Enterprise Server 9

Integrating Elvis 5 in Enterprise Server 9

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:

For a general overview, see Integrating Enterprise Server with Elvis 5 - introduction.

Elvis in Content Station

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 configuration

Consider an example configuration with the following settings:

  • Enterprise runs under http://localhost/enterprise
  • The script should run every 5 minutes (=300 seconds) for an indefinite period of time

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.

By accessing the page, the plug-in should be automatically enabled and show a green icon.

The Server plug-in enabled

Figure: The Elvis plug-in enabled on the Server Plug-ins page.

Testing the integration

Was this article helpful?
0 out of 0 found this helpful / Created: / Updated:
Have more questions? Submit a request

2 Comments

  • 0
    Avatar
    Siebrand Mazeland

    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".

     

     

  • 0
    Avatar
    MengLu Au Yong

    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:

    1. sync.php in Elvis-content source plugin.

      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?

      1. sync.php
        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 ).
    2. Server jobs and InDesign Server jobs.

      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".

      1. jobindex.php ( Server Jobs )

        "jobindex.php?createrecurringjob=AutoPurgeTrashCan", "jobindex.php?createrecurringjob=AutoCleanServerJobs", "jobindex.php?createrecurringjob=TransferServerCleanUp"

        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.

      2. idsjobindex.php (InDesign Server Jobs)

        and "idsjobindex.php".

        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.

    Edited by MengLu Au Yong
Please sign in to leave a comment.