Each subscriber has their own directory. Within that directory, you can setup one or more configuration files. Each configuration file can contain one or more groups of symbols to be published. Each group file lists one or more relation-columns that you are interested in tracking. The following shows an example config directory structure:
config/spock/ <-- the subscriber name config/spock/groups <-- the folder that holds group files config/spock/groups/O_NET_ALL <-- an individual group file that contains a list of relation-column pairs config/spock/groups/TEST config/spock/groups/TEST2 config/spock/spock_o_rack_net.cfg <-- a cfg file that subscribes to one or more group files
The config file contains one record per line where each record consists of three comma separated fields. The first field is a group file name located in the groups directory. The second field is a number that represents the number of days to use for the low band. The third field is a number that represents the number of days to use for the high band.
The data applied to typical MIM servers is vast. Often times downstream subscribers receive more data than they expect. For example, a vendor may refresh all their historical values, causing nearly every record for a relation-column to change. To help cope with these problems, the publisher has a throttle mechanism. There is a full-band spool directory which receives the full bulk of data. There is a high-band spool directory, which receives high bandwidth data. And finally, there is a low-band spool directory, which receives low bandwidth data. The throttle for high and low are controlled by specifying the number of past days to monitor. Setting the low band to 3 indicates that you are only interested in corrections and updates within the last 3 days of data. Likewise, setting the high band to 20 indicates that you are only interested in the last 20 days of data.
For example, the spock_o_rack_net.cfg file may contain 1 or more lines like the following:
O_NET_ALL, 7, 30
In this example, the symbols listed in the
O_NET_ALL group is configured with a low band of 7 and a
high band of 30.
The group file contains one record per line, where each record contains a relation, column pair. For example:
INTC, Close SUNW, Volume
The group files can be configured using regular expressions instead of explicit relation names, but we recommend using this syntax sparingly. There are two reasons for this. First, if regular expressions are not carefully constructed, you may end up publishing more data than you originally intended. This is often a source of confusion. Second, regular expressions are more expensive for the publisher to evaluate when publishing thousands of records.
The syntax for configuring a regular
expression is to precede the pattern with a /. This
indicates to the publisher that you are providing a regular expression
pattern instead of an explicit relation name. The pattern will be
matched against the relation name. For example, the following line
subscribes to all symbols that begin with NG_ and the Close
column.
/^NG_.*$, Close
 | You can also specify that you want your regular expression to apply to the full relation path instead of just the relation name. This is done with two slashes. For example: //TopRelation:Futures:Nymex:CL:CL_.*, Close |
When configuring your subscriber, you can use
[[all]] instead of the name of a column. This indicates
that you want to subscribe all of the columns of a particular relation
instead of individual columns.
This following example will subscribe to all the columns for NG_2008F:
NG_2008F, [[all]]
Currently, the publisher will publish all changes that have been
applied to the server with facts_read and with
XmimPutRecords(). Because futures continuous relations are
not loaded into the MIM server directly with facts_read or
XmimPutRecords(), they are not published. (Futures
continuous relations are synthetic contracts like NG and are computed
based on the values of the futures contracts.) At some point in the
future, we may modify the server to log futures continuations as they
are saved to disk.
You cannot run multiple publishers against the same database. Each database keeps a delta log that tracks all the changes that have been applied since the last time the publisher checked. When the publisher picks up the deltas, the server clears the log so that the deltas are not published a second time. If more than one publisher is configured to run against the same database, some values will appear to be missing to each of the publishers.