Understanding Views

Views allow you to aggregate messages from one or more SOW topics in AMPS and present the aggregation as a new SOW topic. AMPS stores the contents of the view as serialized messages in memory, similar to a materialized view in RDBMS software.

Views are often used to simplify subscriber implementation and can reduce the network traffic to subscribers. For example, if some clients will only process orders where the total cost of the order exceeds a certain value, you can both simplify subscriber code and reduce network traffic by creating a view that contains a calculated field for the total cost. Rather than receiving all messages and calculating the cost, subscribers can filter on the calculated field. You can also combine information from multiple topics. For example, you could create a view that contains orders from high-priority customers that exceed a certain dollar amount.

AMPS sends messages to view topics the same way that AMPS sends messages to SOW topics: when a publish arrives for a message that is used to calculate the view, AMPS recalculates the values in the view as necessary and sends a message on the view topic. Likewise, you can query a view the same way that you query a SOW topic.

Defining a view is straightforward. You set the name of the view, the SOW topic or topics from which messages originate and describe how you want to aggregate, or project, the messages. AMPS creates a topic and projects the messages as requested.

A view requires one or more underlying topics. Any topic, view, or queue defined in the SOW section can be the underlying topic for a view. However, the underlying topic for the view must be defined in the AMPS configuration file before the view itself is defined.

All message types that you specify in a view must support view creation.

Since AMPS uses the SOW topics of the underlying messages to determine when to update the view, the underlying topics used in a view must be in the SOW. Any topic, view, conflated topic, or queue defined in the SOW section can be the underlying topic for a view. However, the underlying topic or topics must be defined in the AMPS configuration file before the view is defined.

AMPS updates each view after a publish or delta publish to a message in an underlying topic. Updates are processed for each view in the order in which AMPS processed the updates to the underlying topic. AMPS processes these updates asynchronously, after each SOW update is persisted. For additional performance, AMPS provides the ability to conflate updates to views that process high velocity updates, as described in Inline Update Conflation.

As with a SOW topic, an incoming publish that does not change the value of the underlying message or the calculated value in the view is considered to be an update to the view topic. If an application needs to see only changed fields, that application should use a delta subscription (with the no_empties option).

When the underlying topic for a view is a queue, the view will show only the messages in the queue that are not currently leased to subscribers.