View Examples
Last updated
Last updated
Copyright 2013-2024 60East Technologies, Inc.
The following sections provide examples of practical scenarios that demonstrate AMPS views and how they can be used to aggregate and analyze data.
For a potential usage scenario, imagine the topic ORDERS which includes the following NVFIX message schema:
This topic includes information on the current state of executed orders, but may not include all the information we want updated in real-time. For example, we may want to monitor the total value of all orders executed by a client at any moment. If ORDERS was a SQL Table within an RDBMS, the “view” we would want to create would be similar to:
As defined above, the TOTAL_VALUE view would only have two fields:
ClientId: the client identifier
TotalCost: the summation of current order values by client
Views in AMPS are specified in the AMPS configuration file in View sections, which are defined in the SOW section. The example above would be defined as:
Views require an underlying topic in the SOW (which includes queues, conflated topics, or other views).
The Topic element is the name of the new topic that is being defined. This Topic value will be the topic that can be used by clients to subscribe for future updates or perform SOW queries against.
The UnderlyingTopic is the SOW topic or topics that the view operates on. That is, the UnderlyingTopic is where the view gets its data from. All XPath references within the Projection fields are references to values within this underlying SOW topic (unless they appear on the right-hand side of the AS keyword.)
The Projection section is a list of 1 or more Field tags that define what the view will contain. The field specifications can contain either a raw XPath value, as in /ClientId above, which is a straight copy of the value found in the underlying topic into the view topic using the same target XPath or an expression as described in the section on Constructing View Fields. In the case of ClientId, if we had wanted to translate the tag into a different tag, such as CID, then we could have used the AS keyword to do the translation as in /ClientId AS /CID.
Unlike ANSI SQL, AMPS allows you to include fields in the Projection that are not included in the Grouping or used within the aggregate functions. In this case, AMPS uses the last value processed for the value of these fields. AMPS enforces a consistent order of updates to ensure that the value of the field is consistent across recovery and restart.
An unexpected 0 (zero) or null value in an aggregate field within a view usually means that the value is either zero or NaN. Most AMPS message types default to using 0 instead of NaN. However, any numeric aggregate function will result in a NaN if the aggregation includes a field that is not a number.
Finally, the Grouping section is a list of one or more Field tags that define how the records in the UnderlyingTopic will be grouped to form the records in the view. In this example, we grouped by the tag holding the client identifier. However, we could have easily made this the “Symbol” tag /Tick.
In the below example, we group by the /ClientId because we want to count the number of orders for each client that have a value greater than 1,000,000:
Notice that the /AggregateValue and /AggregateValue2 will contain the same value; however /AggregateValue was defined using an XML CDATA block and /AggregateValue2 was defined using the XML > entity reference.
Since the AMPS configuration is XML, special characters in projection expressions must either be escaped with XML entity references or wrapped in a CDATA section.
Updates to underlying topics can potentially cause many more updates to downstream views, which can create stress on downstream clients subscribed to the view. If any underlying topic has frequent updates to the same records and/or a real-time view is not required, as in a GUI, then a replica of the topic may be a good solution to reduce the frequency of the updates and conserve bandwidth. For more on conflated topics, please see Conflated Topics.
This example demonstrates how to create an aggregate view that uses more than one topic as a data source. For a potential usage scenario, imagine that another publisher provides a COMPANIES topic which includes the following NVFIX message schema:
This topic includes the name of the company, and an identifier used for internal record keeping in the trading system. Using this information, we want to provide a running total of orders for that company, including the company name.
If ORDERS and COMPANIES were a SQL Table within an RDBMS, the “view” we would want to create would be similar to:
As defined above, the TOTAL_COMPANY_VOLUME table would have four columns:
CompanyId: the identifier for the company
Tick: the ticker symbol for the company
Name: the name of the company
TotalVolume: the total number of shares involved in orders
To create this view, use the following definition in the AMPS configuration file:
As with the single topic example, first define the underlying topics as SOW topics. Next, the view defines the underlying topic that is the source of the data. In this case, the underlying topic is a join between two topics in the instance. The definition next declares the message type of the projected messages. The message types that you join can be different types, and the projected messages can be a different type than the underlying message types. The projection uses three fields from the COMPANIES topic and one field that is aggregated from messages in the ORDERS topic. The projection groups results by the Tick symbols that appear in messages in the ORDERS topic.
This example shows how to project an underlying topic of one message type into a topic of a different message type.
There is very little difference between this example and the single topic view example above. The main difference is that, because the destination view has a different message type than the underlying topic, every reference to a field from the underlying topic must be fully-qualified with the message type.
As before, imagine the topic ORDERS which includes the following NVFIX message schema:
As before, we want to project the summation of current order values by client. The TOTAL_VALUE view will have two fields:
ClientId: the client identifier
TotalCost: the summation of current order values by client
However, in this case, we want to project the summary into a JSON document. To do this we simply specify that the final view will be in JSON format, and fully qualify all references to the underlying topic in the view definition.
The example above would be defined as:
This example uses an underlying topic in NVFIX format, computes an aggregation by ClientId, and then produces output in JSON format.
NVFIX Tag
Description
OrderID
Unique order identifier
Tick
Symbol
ClientId
Unique client identifier
Shares
Currently executed shares for the chain of orders
Price
Average price for the chain of orders
NVFIX Tag
Description
CompanyId
Unique identifier for the company
Tick
Symbol
Name
Company name
NVFIX Tag
Description
OrderID
Unique order identifier
Tick
Symbol
ClientId
Unique client identifier
Shares
Currently executed shares for the chain of orders
Price
Average price for the chain of orders