Remote-space publishing

Overview

Remote-space publishing allows you to edit content on a local Confluence instance, and then publish it to a remote Confluence Cloud, Server or Data Center instance.

The Comala Remote Publishing app is used to publish content in a source space to a completely separate instance.

Whenever content is updated and approved in the source instance using Comala Document Management the Comala Remote Publishing app can automatically update the published content in the remote instance.

The remote instance can be configured to allow anonymous access to share the content with outside users.

The Comala Remote Publishing app for Comala Document Management must be installed on the source instance to enable remote-space publishing.

The Comala Remote Publishing app only functions when used with Comala Document Management.

Activating remote-space publishing

Once the Comala Remote Publishing app is installed there are three steps to setting up different-space publishing:

  • set up the remote Confluence instance

  • set up the local Confluence instance

  • update your applied Comala Document Management workflow to trigger the publishing process

The publishing action in the workflow is actioned using one of the following remote publishing macros.

These publishing action macros are added to workflow triggers in your custom workflow.

Remote instance setup

These steps should be performed on the remote Confluence instance in which you plan to publish content to

  • create the space where content will be published to

  • set up a user account with user permissions to view, add, and delete content in the space for the published content

When content is published into this remote space it will appear to be authored and edited by the user you have set up.

The remote instance can be a server, data center, or cloud instance.

Local setup

For remote publishing to work, the server/data center hosting the local Confluence instance must be able to access the remote instance.

These configuration steps are undertaken in each space in the local instance (source instance) where the content is initially created.

Source space Remote Publishing dashboard

The remote space details are configured in the Document Management dashboard In the source space that holds the source content.

  • navigate to Space Tools > Document Management > Remote Publishing

Confluence Allowlist configuration

From Comala Remote Publishing v2.6.10+, the space Remote Publishing dashboard includes a warning message.

For a source instance installation of Confluence v8.7.1 or higher, in order for outgoing connections to the remote space to be accepted you must include the remote instance in the Confluence Allowlist Configuration with the “Domain Name” type.

Add remote space details

  • add the remote space details to configure the remote space publishing

Configuration options

Description

Configuration options

Description

Name

The name of this publishing profile

Base URL

The base URL for the remote instance, for example

  • https://www.company.com/confluence/

User

The username of the user you created on remote instance

  • content updates on the remote instance will be carried out by this user account

Password

The password of the user created on the the remote instance - added as User in this configuration

Space Key

The SPACEKEY of the space to publish in to on the remote Instance

Publishing content

In our example, pages and blogposts with an applied Comala Document Management workflow, are published to the remote instance when the page transitions to the Published state.

This is done using the following workflow trigger listening for the state change to the Published state.

{trigger:statechanged|state=Published|queue=true} {remotepublish-page:remote} {trigger}

 

 

The remotepublish-page macro is configured to publish to the named space, remote.

Publishing requires connection and transmitting data to the other instance, and this could take some time.

A pending message is shown when the page is submitted for publishing.

If a published page is updated in the source space, the workflow status is changed in our applied workflow to a different workflow state. This does not affect the remote instance space page.

To publish any updates to the remote instance space the page needs to be re-approved and transition to the workflow state configured in the workflow trigger (the Published state in our example)

Publishing all pages in the Space

If you want all the existing pages in the space to be published remotely, then you need to set the state of all pages to the Published state.

You can do this through the Initialize states feature available for each workflow in the space tools Document Management dashboard.

Further publishing of source space instance pages retains the page hierarchy if the parent exists in the target remote instance space.

Workflow markup

The publishing is triggered by an action macro remotepublish-page. This action macro is added to a Comala Document Management workflow trigger.

{trigger:statechanged|state=Published|queue=true} {remotepublish-page:remote} {trigger}

The value used in the example for the remotepublish-page macro is the Name for the remote publishing profile added in the Remote Space Publishing Configuration dashboard in the source space - here we have used remote.

In our workflow applied to the source space content we can use a state change event to action the remote publishing

  • the change of state to the Published state

When the state changes to Published, a trigger is added to the workflow listens for this event.

When the trigger is activated the remotepublish-page macro instructs the Remote Publishing for Comala Document Management app to send the published content to the remote space.

{trigger:statechanged|state=Published|queue=true|newevent=pagepublished} {remotepublish-page:remote} {trigger}

We have also used this trigger to create a custom event newevent=pagepublished that can be used in other triggers.

Here we have used this custom event to check if the remote publishing is successful using the success=true parameter in the trigger.

For a successful publishing action - the custom event pagepublished

  • a workflow trigger generates a message confirming success

If the publishing action event pagepublished is unsuccessful - success=false

  • a workflow trigger listening for the unsuccessful event actions

    • the transition of the content to the Review state

    • generates a warning message notification

The example markup above is based on the example from same-space publishing, but we've added the following workflow trigger at the bottom. This additional trigger removes page content from the remote instance using the remoteremove-page macro.

With no configured transition to the Remove state from another state in the workflow, the ability to transition to the Remove state is limited to users with administrator permission who can use the administrator state override option to transition the page to the Remove state from any other state in the workflow.

The overall example workflow looks like

 

Here’s the complete workflow markup for this example. This includes a remote publishing process for blog posts using the newsstatechanged event, a Newsarchived state and publishing archived blog posts to a different remote instance remote2.

Several workflow triggers publish content to a remote instance. There are separate triggers for publishing

  • pages using the statechanged event

  • blog posts using the newsstatechanged event

These triggers also generate a custom event pagepublished that is used to generate message notifications.

Pages and blog posts in the Remove and Newsarchived states can only be transitioned to other workflow states (and hence back into the documentation and publishing process) by a user with administrator permission.

Macros

Examples

Administration

Workflows Exchange

See also

Filter by label

There are no items with the selected labels at this time.