Publish to another instance using advanced remote-space publishing

Overview

Publishing to a different space in a another instance in this example requires the installation and configuration of the Comala Remote Publishing app to set the target instance and target space for the publishing action.

In this example we'll look at some advanced markup including customised approvals, queued actions, custom events and error handling.

Before you start

If you haven't already done so, please read remote-space publishing and complete the required configuration for both remote and local instances of Confluence.

Basic Markup

Here is the basic markup shown on the remote-space publishing page:

{workflow:name=Remote-space Publishing}
   {state:Editing|submit=Review}
   {state}
   {state:Review|approved=Published|rejected=Editing}
      {approval:Review|assignable=true}
   {state}
   {state:Published|final=true|updated=Editing}
   {state}
   {trigger:statechanged|state=Published}
      {remotepublish-page:remote}
   {trigger}
{workflow}

While the above example will enable the remote-space publishing, there are some potential issues which should be considered:

How long does the content take to publish, particularly in cases were several pages might be published at the same time?
What happens if an error occurs? The publishing app might be mid-upgrade, or the configuration could be invalid, etc.

To accommodate these potential issues, we'll make the following updates to the script:

Add a new "Synchronise" state which will trigger the publishing process
Add some custom events to handle success and failure scenarios
Add an "Error" state to decide what happens if synchronisation fails

Adding the states

Here is the script from above, with the added "Synchronise" and "Error" states added. We've also updated the trigger to be activated by the Synchronise state rather than the Published state. Also, the Review will now transition to Synchronise state instead of Published when approved.

{workflow:name=Different-space Publishing}
   {state:Editing|submit=Review}
   {state}
   {state:Review|approved=Synchronise|rejected=Editing}
      {approval:Review|assignable=true}
   {state}
   {state:Synchronise}
   {state}
   {state:Error}
   {error}
   {state:Published|final=true|updated=Editing}
   {state}
   {trigger:statechanged|state=Synchronise}
      {remotepublish-page:remote}
   {trigger}
{workflow}

Improving the states

Currently the Synchronise state will show the default state selection drop-down, which isn't what we want. Let's hide that using the hideselection parameter, and we'll also give the state a description to explain what's going on to anyone who opens the Workflow Popup during synchronisation:

   {state:Synchronise|hideselection=true|description=Content is being published to remote server, please wait...}
   {state}

We should probably show an on-screen message during synchronisation too, using a set-message action in the trigger:

Our Error state also needs some work.

We'll add buttons to Retry or Ignore – we can achieve that using a customised approval. We'll also hide it from the Progress tracker using the hidefrompath parameter.

We also set the colour for the state to be red (#ff0000).

Queued and custom triggers

Complex content might take a few moments to publish, espeically if an entire page hierarchy is being published at the same time. So we'll queue the actions in the trigger.

Here's the updated Synchronise trigger:

If the server is busy, it may take a moment before the queued actions are processed. We want the "Synchronising" message to be displayed as quickly as possible, so let's split that out in to a separate trigger that uses the pageapproved event instead:

The pageapproved event is sent before the state change, and thus before the statechanged event.

We're almost finished. The last thing we need to do is handle the outcome of the {remotepublish-page} action – to achieve that we can use the newevent parameter.

The newevent parameter creates a new custom event after the actions in the trigger have been completed. We'll called the event AfterSync . In addition to creating the event, the newevent does two other things:

It sends a success flag to triggers listening to the event – this indicates whether the actions in the original trigger were successful or not
If errors occurred whilst processing the actions, the @errormessage@ value reference will also be set in triggers listening to the new event

It's perfect for our needs, almost as if newevent was created precisely for this purpose.

Putting it all together

Here's the finished workflow: