Publishing

Publish types

There are multiple types of publishing, which corresponds with item life cycle:

  • publish
  • correct
  • kill

For each there is specific resource and service:

class apps.publish.content.publish.ArchivePublishService
class apps.publish.content.correct.CorrectPublishService
class apps.publish.content.kill.KillPublishService

all inheriting from base publish service:

class apps.publish.content.common.BasePublishService

These in general handle validation and update item metadata.

Validation

When publishing starts, it first validates the item based on its content profile definition or in case content profile is missing it will get validators from db. There are different validators for different content types (text, package, picture, etc) and publish type.

Items in packages are also validated if were not published before. Package is considered not valid if any of its item is not valid.

Schema definition

When using content profiles or validators, you specify a schema for each field like:

"headline": {
    "type": "string",
    "required": true,
    "maxlength": 140,
    "minlength": 10
}

More info about validation rules in Eve docs.

Published

When item is valid, it gets some metadata updates:

  • state is set based on action
  • _current_version is incremented
  • version_creator is set to current user

These changes are saved to archive collection and published collection. On client those items are not visible anymore in monitoring, only in desk output.

Publish queue

New items from published collection are further processed via async task:

apps.publish.enqueue.enqueue_published()

Pick new items from published collection and enqueue it.

Enqueueing is done via:

class apps.publish.enqueue.enqueue_service.EnqueueService

Creates the corresponding entries in the publish queue for items marked for publishing

enqueue_item(item)

Creates the corresponding entries in the publish queue for the given item

Return bool:True if item is queued else false.

There it finds all subscribers that should receive the item and if any it will format the item and queue transmission.

Output Formats

class superdesk.publish.formatters.NINJSFormatter

The schema we use for the ninjs format is an extension of the standard ninjs schema.

Changes from ninjs schema:

  • uri was replaced by guid: uri should be the resource identifier on the web

    but since the item was not published yet it can’t be determined at this point

  • added priority field

  • added service field

  • added slugline field

  • added keywords field

  • added evolvedfrom field

  • added source field

Associations dictionary may contain entire items like in ninjs example or just the item guid and type. In the latest case the items are sent separately before the package item.

Superdesk NINJS Schema in JSON.

class superdesk.publish.formatters.NITFFormatter

NITF Formatter for Superdesk

Format items to NITF version 3.6.

class superdesk.publish.formatters.NewsML12Formatter

NewsML 1.2 Formatter

class superdesk.publish.formatters.NewsMLG2Formatter

NewsML G2 Formatter

class superdesk.publish.formatters.EmailFormatter

Superdesk Email formatter.

  • Does not support any media output, it’s for text items only.

It uses templates to render items, those can be overriden to customize the output:

  • email_article_subject.txt

    email subject

  • email_article_body.txt

    email text content

  • email_article_body.html

    email html content

It gets article with item data, can be used in templates like:

<strong>{{ article.headline }}</strong>

Transmission

Last task is to send items to subscribers, that’s handled via another async task:

superdesk.publish.transmit()

Transmit items from publish_queue collection.

This task runs every 10s.

Content Transmitters

class superdesk.publish.transmitters.HTTPPushService

HTTP Publish Service.

The HTTP push service publishes items to the resource service via POST request. For media items it first publishes the media files to the assets service.

For text items the publish sequence is like this:

  • POST to resource service the text item

For media items the publish sequence is like this:

  • Publish media files: for each file from renditions perform the following steps:

    • Verify if the rendition media file exists in the assets service (GET assets/{media_id})
    • If not, upload the rendition media file to the assets service via POST request
  • Publish the item

For package items with embedded items config on there is only one publish request to the resource service.

For package items without embedded items the publish sequence is like this:

  • Publish package items
  • Publish the package item

Publishing assets

The POST request to the assets URL has the multipart/data-form content type and should contain the following fields:

media_id
URI string identifying the rendition.
media
base64 encoded file content. See Eve documentation.
mime_type
mime type, eg. image/jpeg.
filemeta
metadata extracted from binary. Differs based on binary type, eg. could be exif for pictures.

The response status code is checked - on success it should be 201 Created.

class superdesk.publish.transmitters.FTPPublishService

FTP Publish Service.

It creates files on configured FTP server.

Parameters:
  • username (string) – auth username
  • password (string) – auth password
  • path – server path
  • passive – use passive mode (on by default)
class superdesk.publish.transmitters.FilePublishService

Superdesk file transmitter.

It creates files on superdesk server in configured folder.

class superdesk.publish.transmitters.EmailPublishService

Email Transmitter

Works only with email formatter.

Parameters:recipients – email addresses separated by ;
class superdesk.publish.transmitters.ODBCPublishService

Superdesk ODBC transmitter.

Calls a stored procedure with item data.

Parameters:
  • connection_string (string) –
  • stored_procedure (string) –