a
Setting up Datapools
Datapools distribute updates from the Server to the Clients. Datapools are only required if your application will distribute updates of data (this includes both updates from the back-end application and from other clients) . If all clients will continue to use the initial data then you won't need Datapools.
Please note: Datapools are read-only; and do not update data on the back-end application.
From the Application Manager do one of the following:
The Data Source tab is used to define where datapool gets its update from.
There are five different methods to feed data to the Datapool:
POLLING: used for HTTP, JDBC and SOAP Datapools. The Presentation Server periodically polls the Application for updates. When using Polling, the first poll occurs immediately. The Presentation Server is inactive until the first user connects.
HTTPSTREAM: the Presentation Server opens an HTTP Request and the Application sends updates as they occur.
JMS: provides updates via Java Messaging Service. For more information see JMS Fed Datapool.
SOCKET: as per streaming but using the underlying socket mechanism.
CONNECTOR: user defined connector for adding updates to the Datapool. The connector has to implement DataUpdateConnector interface. The Datapool is then registered as listener to the connector. When a new update is available, it is sent to the Datapool via listener's call-back function, newUpdate(). For more information see Connector Fed Datapool.
When you select different Data Source method, different fields will be shown.
The Format tab is used to define how the raw update data should be dealt with, when it arrives to the Datapool.
Please note: The XSL file could potentially add or remove elements or attributes and change names of elements or attributes. Using this feature requires that a JAXP compliant XSLT library is available on the servlet engine's CLASSPATH, for example Xalan, Apache's open source XSLT library (xalan.jar).
Place your XSL files in the XSL sub-directory (under the Application root directory) as the Transformation XSL file drop-down menu displays only the XSL files that are in that directory.
Enter the location of an XSL file (relative to the application directory) used to transform incoming data before it is sent to the client.
Please note: This only applies to XML Service Functions.
Check this box if you want the Timestamp to be extracted from a customized location. If this option is selected you can set the Element and Attribute for locating timestamp information. By default Timestamp are extracted from a Timestamp Attribute on the root element of the XML returned by the Service.
Please
note: This option is useful when the return data doesn't contain Timestamp
information. However, if you use MASTER-MASTER cluster configuration,
data might be lost in fail over situation, because the timestamp value
for a data block can be different on two Presentation Servers.
Please also note that APS uses Java currentTimeMillis() to set the
timestamp. Although its precision is down to 1 ms, the problem is that
default timing systems on the native platforms are, in general, of low
resolution. The currentTimeMillis is updated every 10ms ~ 16 ms. Therefore
it is possible that 2 updates arrive in order but end up in the same millisecond.
Check this box if you want the Presentation Server to use system clock for the Timestamp value.
Set this field to an XPath statement pointing to the element containing Timestamp information. By default the Presentation Server continues to find Timestamp information from root element. If more than one element matches, only the first element is used.
Specify the attribute name containing the Timestamp info or TEXT() to indicate that the element's text contains the timestamp. By default the Presentation Server finds Timestamp information from Timestamp default attribute.
Specify whether the Timestamp field is to be read as a Date/Time or as an Integer. By default the Type is set to Integer.
Specify the Format used to parse the Timestamp from the specified Element and Attribute. For a Date/Time this should be a format recognized by java.text.SimpleDateFormat. For an Integer this should be a format recognized by java.text.DecimalFormat. By default if the Type is set to Integer then the Timestamp Attribute is read as an Integer.
If you only want to add certain part of update to the Datapool, enter an XPath query to locate the XML element. The query may return more than one element. If it does the timestamp applies to all found elements, unless the custom Timestamp information is defined.
The Advanced tab let you define how updates should be filtered and delivered to users with Data Routing and general Datapool caching as well as update replication between MASTER and SLAVE Presentation Servers.
Untick this option if you want to set up a non-transient Datapool: the updates received are kept in the Presentation Server while the application is active. The main reason to do this is to have the data used as a filter for other Datapools. By default the Transient option is selected and the updates received by the Datapool are sent to the client subscribing to the Datapool.
If you make a Datapool non-transient, you need to specify an Initial Data Service to initialize the non-transient Datapool.
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 techlet use the following:
Please note: The Chem techlet can be found under the Techlets node, in Altio Live Studio.
Datapool:
Name: WATCH_POOL
...
Filter: /WATCH/WATCH_ITEM[@USER=${connection.user}]
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 each update of the WATCH_POOL datapool, only elements
which match the filter are 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. In this case we are specifying a particular user to receive updates,
so only a user connected as 'Joe' would receive the update.
If no filter for a Datapool is specified, updates for that Datapool are
sent to all users.
These settings let you defined how many updates should be kept in the memory and on the disk. When the number of memory caches reaches the memory cache buffer size, the specified number of updates are flushed (or a quarter of memory caches if the number of updates to be flushed is 0 or not specified). Tick the Log Flush info option otherwise
In general it is a good idea to set flush size to a number between a quarter to a half (1/4 ~ 1/2) of the memory cache size. Alternatively you can just set it to 0 and let the Presentation Server to default the value to a quarter of the memory cache size.
Tick the Log Flush info option if you want the Datapool to log flush info to a log file. In the Archive File field enter the location where all flushed updates will be written to the log file. By default this log file is dpflush.log located under ${ApplicationRoot}/data sub-directory. Flush info can be useful to determine if the datapool cache size is configured in optimal way to handle datapool activities. If the Log Flush info is not selected the flushed memory caches are deleted.
Keeping more caches in the Datapool means that a user can stay longer disconnected (for example to visit other web pages) and can after his reconnection get all the updates received while he was off the page.
Used in MASTER-SLAVE cluster environment. It define how the SLAVE Presentation Server should get updates from the MASTER.
Datapool Activities, Datapool Flush Details, Datapool Flush History