Publishing to a Remote Server

Transcription

1 DOCUMENTATION Publishing to a Remote Server Jahia s next-generation, open source CMS stems from a widely acknowledged vision of enterprise application convergence web, document, search, social and portal unified by the simplicity of web content management. Jahia Solutions Group SA 9 route des Jeunes, CH-1227 Les acacias Geneva, Switzerland

2 Summary Summary Publishing to a Remote Server Typical Remote Server Publication Architecture Detailed Operation Requirements Setting Up Remote Server Publication Publication Workflow with Remote Site Publication Checking the Status of Remote Server Publication Processes Page 2 / 14

3 1 Publishing to a Remote Server The Enterprise version of Jahia makes it possible to implement complex architectures in which the editing and viewing environments are totally separate, each environment having its own database and working autonomously, usually with a firewall between the two environments. This type of architecture meets specific requirements in particular regarding security but it results in a number of changes in the way the platform works and it requires certain rules to be observed. 1.1 Typical Remote Server Publication Architecture In an environment featuring a remote server, the architecture of a Jahia platform can be represented as follows: - A server or a cluster of servers is used as the editing environment (on the right-hand side in the diagram). This is where authorized editors and contributors can create and manage the sites contents (in Edit mode as well as in Contribute mode). - A server or a cluster of servers is used as the viewing environment (on the left-hand side in the diagram). This is where users (visitors, Internet surfers ) can view the published pages and also generate contents such as comments, evaluations, forum posts etc. in a totally secure way. - There is usually a firewall between the two environments. Page 3 / 14

4 1.2 Detailed Operation Editors work as usual (in Edit or Contribute mode) and create their contents in the default workspace of the editing environment. When they publish their contents, these are copied in the live workspace of the editing environment. All the operations performed on the live workspace when publishing (creating, editing or deleting nodes) are saved in a log file. Depending on the selected publication workflow, the content can be simply applied to the live workspace of the editing environment and then replicated on the viewing environment at the intervals defined by the administrators, or the remote server publication can be performed immediately after the publication in the editing environment. The log file is sent (via http) to the remote server and is replayed directly on the live workspace of the viewing environment. 1.3 Requirements 1 The source and target sites must exist prior to the execution of the first synchronization. 2 The source and target sites must use the same set of templates. 3 In order to guarantee the content s integrity and to avoid conflicts when the viewing environment server is updated, it is important not to perform operations that directly affect the live workspace of the editing environment, i.e. not to use User-Generated Content functionalities (forum, wiki, comments ) on the editing environment. The live workspace of the editing environment should only be updated via the publication processes and the UGC should only be used on the viewing environment. Conversely, it is crucial that no editing activity is carried out directly on the viewing environments, beside UGC activities. If the contents of the default and live workspaces evolve separately and simultaneously in the two environments, Jahia could be unable to reconcile the two workspaces and to perform the relevant Page 4 / 14

5 updates. At best this could result in the publication being totally blocked on the remote server, at worst in a complete corruption of the remote server, requiring it to be reset and to start again from the editing environment, losing all of the UGC that was created in the meantime. Please note: Jahia can be configured to prevent the editing of contents in the default workspace of the viewing environment. 4 User-Generated Content is located on the viewing environment server and cannot be retrieved automatically to the editing server. However, it is quite easy for integration teams to display it (since its location is known) in editing tools in the editing environment, via Ajax calls for instance. 1.4 Setting Up Remote Server Publication All setup operations except the target site creation of course are performed from the editing environment. The remote publication management screen can be found in the Managers menu in Edit mode. By default, the remote publication manager is empty if no publication has been declared yet. Page 5 / 14

6 Click on the File menu or right-click within the page to create a new remote publication. In the floating window that appears, enter the settings for the publication. Page 6 / 14

7 Name: this is a free text field. You can name your publication as you wish. Source node: a drop-down menu showing the list of existing sites on your editing platform. Select the site for which you want to publish content to a remote server. Target server URL: the URL of the server on which the content must be published (please note: for testing purposes, it is possible to make remote publications between two sites from the same environment). Remote path: the path to the site on which the content must be published on the remote server, starting from the root directory. This path uses the following pattern: /sites/name_of_the_site. User of target site: the user account that will publish the content. User password on target site: the associated password. Cron expression for scheduling: a drop-down menu that is used to schedule a recurring execution. Minute: the publication will be performed every minute. Hour: the publication will be performed every hour. You can define the exact minute of the hour. Page 7 / 14

8 Day: the publication will be performed every day. You can define the exact time of the day. Week: the publication will be performed every week. You can define the exact day of the week and time of the day. Month: the publication will be performed every month. You can define the exact day of the month and time of the day. Year: the publication will be performed every year. You can define the exact date and time of the year. Test settings: if this box is checked, Jahia will try to connect to the specified server when the remote server publication settings are saved. If the connection fails, a warning message will appear, the settings will not saved and the configuration screen will remain displayed in order to edit the settings. Page 8 / 14

9 Once the settings have been saved, the window will close and the settings will appear in the main window. When selecting this publication in the list, detailed information is displayed and can be edited in the lower part of the screen. It is also possible to rename or delete the publication using the contextual menu. The execution of the publication can also be forced, regardless of the scheduling options. Page 9 / 14

10 The Roles Tab The Roles tab allows you to define which users will be able to see the option to run the remote publication process at the end of a standard publication workflow. By default, all users with validation rights are able to see and to run the remote publication processes as soon as they are created. To remove the permission to launch a remote server publication at the end of a publication workflow from a user or a group, you must select the relevant remote publication process, then in the Roles tab you must break inheritances (since the rights are cumulative) and finally you must redefine which groups are allowed to see this process. 1.5 Publication Workflow with Remote Site Publication As we mentioned at the beginning of this document, the remote site publication can occur: Page 10 / 14

11 - immediately after a publication in the editing environment (depending on the available rights); - at a later time according to the defined scheduler, which runs as a background job and triggers at specified intervals. If a remote publication process is declared and the validating user has appropriate permissions, a new step is displayed at the end of the workflow. This step makes it possible to validate or reject the execution of the remote publication immediately. You can only force the execution of one remote server publication process among all the processes defined for your site. Page 11 / 14

12 1.6 Checking the Status of Remote Server Publication Processes To ensure that the remote server publication process has been activated, open the background jobs list from the tool bar in Edit mode. By default, remote publication tasks are not displayed. To show them in the list, check the corresponding box in the Type filter menu located in the top left corner. Page 12 / 14

13 Page 13 / 14

14 Jahia Solutions Group SA 9 route des Jeunes, CH-1227 Les acacias Geneva, Switzerland Page 14 / 14