a
Data Routing
By default a Datapool forwards all data updates to every client subscriber. Data Routing allows each update to be sent to a selective set of users.
For each subscriber, a datapool may be set to forward all, none or some of each data update received. This is determined from the update itself and/or filter data that can be modified at run-time.
If a Presentation Server receives updates for 600 stock quotes, a filter may specify that subscriber A only be sent quotes for stocks X, Y and Z. If subscriber A decides they also want to view quotes for stock W, then they should be able to add this to the quotes they receive by submitting a request, to update the filter data.
Routing is established by allowing each datapool to have a filter defined. Filters operate using an Xpath statement that determines which data is to be sent to each subscriber.
In its simplest form a filter acts upon only the data provided in the update itself. For example to filter the personalized watch list in the CHEM demo use the following:
<DATAPOOL NM="WATCH_POOL"
FILTER='/WATCH/WATCH_ITEM[@USER=${connection.user}]'>
…
</DATAPOOL>
This filter would apply to a data update such as:
<WATCH AL_ID='WATCH' TIMESTAMP='3'>
<WATCH_ITEM POST_ID='1002' USER='Joe' TS='3' AL_ID='WATCH-1036'
WATCH_ID='1036'/>
</WATCH>
For every update for the WATCH_POOL datapool, only elements matching the filter will be sent to a given user. In this case the user's logon name, as specified by ${connection.user}, is compared against the USER attribute of WATCH_ITEM elements that pass through the Datapool. Only updates that match are sent to the user. Here only a user connected as Joe would receive this particular update.
If no filter for a datapool is specified, all updates for that datapool are sent to all users.
Curly brackets are used to indicate a substitutable parameter
in the filter Xpath. Parameters are substituted from a user's connection.
You can also reference to session attributes with ${session.xxx}
where xxx is the session attribute.
For more information see Property References.
Filter parameters are evaluated once for each subscriber when they first request data from the filtered datapool (for example, changing the value of a session parameter during the session will not alter the filter).
To perform anything other than fairly basic filtering, Xpath queries need access to a portion of the application data in order to be resolved.
Marking certain datapools as being non-transient allows a copy of this application data to be held within the Presentation Server. The Xpath filter can then operate on both the data update node being processed and the data from all the datapools designated as non-transient.
A non-transient datapool is defined as follows:
<DATAPOOL NM="USERS_POOL" TRANSIENT='N'
INITURL='http://altiojd:9040/servlet/com.altio.altiodb.AltioDB?
APPID=FIN&ACTION=GET&TARGET=/USERS'>
In this case the datapool maintains the following data:
<USERS>
<USER USER_ID='Joe' FULL_NAME='Joe 90'>
<USERSYMBOL SYM_ID='1' NM='YHOO'/>
<USERSYMBOL SYM_ID='2' NM='MSFT'/>
</USER>
<USER USER_ID='Jane' FULL_NAME='Jane 91'>
<USERSYMBOL SYM_ID='3' NM='YHOO'/>
<USERSYMBOL NM='AMZN' SYM_ID='1009'/>
<USERSYMBOL NM='LU' SYM_ID='1010'/>
</USER>
</USERS>
A non-transient datapool still has all the functionality of a normal datapool. It can be subscribed to, and will reflect changes dynamically through to clients. Through the use of Service Functions the non-transient data can be updated so as to modify the effect of filters dynamically.
For example, with the above data, users can be added and removed, and can have stock symbols added and removed from their data. These changes will be held by the Presentation Server and then can be used when the next data update to those users is filtered.
The INITURL attribute is specific to non-transient Datapools. It is an optional URL that can be used to fill a non-transient datapool with initial data. Note that this is not the same as the initial data that is sent to a new subscriber when they connect, as it is only used once to initialise the internal state of the Datapool data held by the Presentation Server.
An example of a Datapool that filters based on the contents of a non-transient datapool is shown below.
<DATAPOOL NM='SECURITIES_POOL'
FILTER='/SECURITIES/SECURITY[@SYMBOL=
/USERS/USER[@USER_ID=${connection.user}]/USERSYMBOL/@NM]'>
This would apply to a data update such as this:
<SECURITIES>
<SECURITY AL_ID='S-101' VOLUME='1250600' SYMBOL='MSFT' LOW='62.45'
TS='973668' SEC_ID='101' TODAYS_CHANGE='3.80' DESC='AFFIMATRIX'
PERCENT_CHANGE='25.0' CUR_PRICE='82.56' HIGH='77.55'>
<PHIST OBS_ID='AFFX5' TS='973666' AL_ID='P-AFFX5' PRC='82.56'/>
</SECURITY>
</SECURITIES>
The FILTER can be interpreted as meaning: "get me any SECURITY that has a SYMBOL listed under my USER". The datapool would only send a user a SECURITY update if there is an entry in the USERS data (as in the example above) which matches them to that filter. In this way a user may be sent none, some or all the security updates received by the Presentation Server, and likewise each update may go to none, some or all the current subscribers to the SECURITIES_POOL datapool.
With the update shown only users with a USERSYMBOL of MSFT would get this update. So user Joe would receive the new stock price, but user Jane wouldn't.
When the contents of the USERS data changes, so will the updates that get sent out from this datapool. So, in this example, a Service Function can be set up to add a symbol to the list of symbols for a user, and they would immediately begin receiving updates for that symbol.
An important thing to note is that the initial context of the Xpath in a datapool filter is the current update node being processed. The context within the filter Xpath's predicates, however, is resolved using non-transient data. In the above example /SECURITES/SECURITY relates to the update being processed and /USERS/USER[@USER_ID=${connection.user}]/USERSYMBOL/@NM to the non-transient data.