Feed Publishing Framework

The Feed Publishing Framework provides:

  • Feed Publishing Wizard, a simplified guide for content owners and administrative users to create, configure, and maintain feed definitions and feed templates of various types.

  • Publish as Feed hidden pages to allow for feed publication directly from the data component.

  • Interfaces for end users to search for feeds and to discover related feeds.

  • Management of feed definitions, feed categories, feed templates and feed data types as PeopleTools managed objects.

  • A set of APIs and code samples to assist application developers in creating new types of feeds and integrating them with existing features.

    Multiple language support.

The following diagram shows the Feed Publishing Framework architecture. For this diagram, use this legend:

  • Orange boxes - Integration Broker components

  • Light blue boxes - Portal components or GUI

  • Yellow boxes - Data storage

  • White boxes - Feed Publishing Framework core

  • Red lines - Incoming request

  • Black lines - Response

  • Gold arrows - Data to and from database

Image: Feed Publishing Framework architecture

Feed Publishing Framework architecture

Feed Publishing Framework architectureFeed Publishing Frameworkdiagram of architecture

This section discusses:

  • Feed publishing runtime engine.

  • Feed document generation and delivery.

  • Feed document properties.

  • Feed data type application classes.

  • Creation of new feed data types.

The centerpiece of the feed document generation is the runtime engine. The runtime engine:

  • Handles the feed identification and authorization.

  • Sets the data source settings and data source parameter value.

  • Executes the data source object to collect data.

  • Transforms feed data to an Atom 1.0 feed document.

Runtime Engine Process Flow

When the runtime engine receives a request, it first locates the feed definition based on the feed ID, and then it determines whether the current user has access to the feed. If the user has permission, the process continues. If the user does not have permission, the process stops and the system displays an error.

Next, the runtime engine creates an instance of the feed data type application class associated with the specific feed definition, restores the Data Source Setting values and the Data Source Parameter values saved with the feed definition, and sets the runtime information, such as the requested language. At this time, the runtime engine also evaluates the runtime values of data source parameters with usage types of Admin Specified, System Variable, and User Specified.

Then, the runtime engine instructs the feed object to collect the data and return the feed data in an Atom 1.0 feed document. The runtime engine does not have direct knowledge about the feed data. All business logic relevant to data collection are encapsulated in the feed data type application class PeopleCode.

By default, the currently authenticated user of the request is used for gathering the feed data. Different users requesting the same feed may receive different feed data based on their permission. This behavior can be overridden by specifying the Feed Authorization options when you create a feed definition; that is, a user ID can be specified alone with a selection that specifies whether to use this user to generate feed documents for all requests of that feed or only for anonymous requests. This option is a per feed definition, and it will be stored with the feed definition.

By default, all feeds managed by the framework will be served as real-time feeds through Integration Broker framework by using the GetFeed service operation.

GetFeed Service Operation

A GetFeed service operation (PTFP_GETFEED) uses the runtime engine to locate the feed definition and generate feed document in Atom 1.0 format. Transformation can be done in the service operation level to get feed documents in other formats. Integration Broker manages user authentication, caching, and feed data type service operation-level security.

The primary task of the GetFeed service operation handler is to collect the request information and then forward it to the runtime engine. The handler also catches the exceptions raised by the runtime engine and reports them in the specific way applicable to Integration Broker.

By default, the GetFeed service operation only has one required parameter, the feed ID, and three optional parameters, the language code, the portal name, and the node name. The feed URL given out by the framework contains only these parameters, when applicable.

When a feed request comes in, the Integration Broker copies the values of the query parameters to the corresponding fields defined in the default feed request message definition. Then, the service operation passes this information to the runtime engine for further processing. If other query parameters exist in the request URL, then the service operation collects and passes them to the runtime engine. These additional query parameter values override the values of Data Source Parameters for which the usage types are User Specified.

Any feed data type can override this default behavior by providing its own feed request message definition extended from the default one, as well as by using a different method for generating the feed URL to include more default query parameters. Regardless, the feed ID query parameter should always be a required parameter. We do not recommend the use of query parameters for data source settings or non-user-specified data source parameters.

The runtime engine returns an Atom 1.0 feed document. The properties of the feed definition become the feed header properties of the feed document. Each item in the feed-format-neutral object collection becomes one entry of the feed document. A list of the data mapping relationships follows.

Feed Element Mapping

The feed data source uses a feed-format-neutral object collection to collect data. This table describes the mapping between the Atom 1.0 feed-level elements and the feed definition properties:

Atom 1.0 Feed-Level Element

Feed Definition Property




Feed data type and feed category.




Latest entry in PSRELEASE table.




System-generated URL to open the feed.


Alternate link: The content web page URL associated with the feed, which is provided by the data source.

Self link: System-generated URL to open the feed.






Feed description.


Feed title.


Current date and time of request.

This table describes the mapping between the Atom 1.0 entry-level elements and properties of items in the feed-format-neutral object collection. The real values of these properties are determined by the data source at runtime:

Atom 1.0 Entry-Level Element

Item Property





Note: This item allows multiple entries.


FullContent, if available.



Note: This item allows multiple entries.


GUID, if available, or content URL.


Alternate link: contentURL.

Other links: enclosure, if available.

Note: This item allows multiple entries.


Date and time published.










Date and time updated.

Note: If any property contains empty values, the corresponding element is not added.

The feed data type application class (PTFP_FEED:DataSource:DataSource) bridges the data and the feed definition. It has two roles:

  • At design time, it provides information to the framework about how to define the feed definition for this type of data.

  • At runtime, the framework uses the application class to collect feed data.

Design Time Role of Application Classes

At design time, the feed data type application class provides information about a specific type of data to the framework, including a list of data source settings, list of data source parameters and their default values, data security, and name of the default feed service definition. The feed data type application class handles events such as processes that occur when you delete a feed definition. The framework uses all of this information in the feed definition creation and maintenance.

Every feed data type may have zero to three data source settings. The data source settings uniquely define the feed data source of the given type of data. You must define and store the values of the data source settings with the feed definition. The feed data type application class can also provide the prompt information for each data source setting.

Every feed data type may have zero or more data source parameters. The data source parameters are used to fine tune the feed or personalize the feed; for example, a news publication feed should include all child sections or a workspace feed should not include discussion data. Values of data source parameters are determined at runtime based on the usage type, fixed value, system variable value, user-specified value, and so on. The default values of data source parameters are stored with the feed definition. The Feed Data Type application class could provide the description, prompt information, default values, and default usage type for each data source parameter.

Runtime Role of Application Classes

At runtime, the runtime engine finds the feed definition and the associated feed data type application class based on the requested feed ID. It creates an instance of the feed data type application class associated with the specific feed definition, restores the data source setting values and the data source parameter values saved with the feed definition, evaluates the runtime values of those data source parameters based on their usage type, and sets other runtime information. It then executes the object to retrieve the content data of the feed.

The feed data type application class uses a feed-format-neutral object collection to temporarily store the data. It does not transform data to a feed document directly. This design enables application developers to expand the object model or use their own data objects. The advantages of using a feed-format-neutral object collection instead of the feed-format-specific XML document are:

  • It shields you from having to deal with the complex details of a specific feed format.

  • It minimizes the possibility of using a wrong XML element or structure.

  • It standardizes the use of specific elements within the feed.

  • It enables easier migration to newer feed format standards or a completely different feed format.

The following list provides an overview of the steps to create a new feed data type:

  1. Analyze the requirements for the new feed data type.

  2. Create the feed data source application class by extending the abstract base DataSource class.

  3. Create the feed data type definition.

  4. (Optional) Update the property maintenance component.

    Note: Because any feed definition can be published through the Feed Publishing Wizard, it is optional to update the property maintenance component to add the Publish as Feed pages and Publish as Feed link to a component.

  5. Update the view content component or pagelet—that is, deploy the related feeds hover menu.

These steps are described in detail elsewhere in this book.