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.
Published¶
When item is valid, it gets some metadata updates:
state
is set based on action_current_version
is incrementedversion_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 byguid
:uri
should be the resource identifier on the webbut since the item was not published yet it can’t be determined at this point
added
priority
fieldadded
service
fieldadded
slugline
fieldadded
keywords
fieldadded
evolvedfrom
field
Associations dictionary may contain entire items like in ninjs example or just the item
guid
andtype
. 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
- Verify if the rendition media file exists in the assets service (
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 assetsURL
has themultipart/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) –