This is the configuration for ACI BASE24 Transaction Manager environments which are monitored by the Payments product suite.
The Transaction Source statement is used to configure a new Transaction Log Reader (TLR). Multiple Transaction Source items are allowed within a configuration, representing each TLR, and each one is identified by a unique <source-name>. If no Transaction Source entries are specified in the configuration then no data will be provided by the collector.
Unique user-defined name for this TLR.
Location of the transaction log.
Type of transaction source. Valid values for B24ATM and B24POS are BASE24 or Other.
When set to Other, the Transaction Log Reader can actually deliver any type of transaction data. When set to BASE24 the <custom-params> parameter will be checked for validity before starting the TLR.
Executable name of the TLR. Must be specified if <source-type> is Other, but is optional for BASE24.
(Optional) Name of the record definition used for the custom keys for this TLR.
(Optional) This field is used to define a number of custom parameters that are specific to the type of TLR being used. They are entered in the form <token>=<value> and are comma separated.
For further details see BASE24 Custom Parameters
On HPE NonStop platforms this parameter is optional, if no TCPIP PORT is configured on the HPE NonStop platform, the collector will not listen on any TCP/IP port and will only accept IPC connections.
On MS Windows, UNIX and Linux this parameter is required.
This is the port number on which the Transaction Manager collector should listen for incoming connections from log readers. The collector requires exclusive use of this port. This is a required parameter.
If the specified <port-number> is in use, the collector will attempt to use the next available port number, starting from the one specified. It will keep trying for up to 20 port numbers until it finds one available. A warning will be logged to wvlog if the collector eventually uses a port number other than the one specified.
This only valid on HPE NonStop and is optional.
When provided, the collector will listen on the specified TCP/IP process for connections. Otherwise, the collector will listen on the first TCPIP-PROC specified in the NETWORK configuration. If none is specified in the NETWORK Configuration it shall listen on $ZTC0.
The Map Record statement specifies a particular Transaction Source that will populate a given record. Multiple Transaction Sources can populate a single record and/or a single Transaction Source can populate multiple records.
Multiple Map Record statements are allowed within a configuration and there must be at least one Map Record statement for every Transaction Source statement.
Name of the Transaction Source to be mapped.
Identifies the record to which the Transaction Log Reader (TLR) transactions should be mapped. It is possible to define multiple record mappings for the same TLR.
One of ATM, POS, Other or *.
When specified as ATM, POS or Other, only those transaction types will be mapped to the destination record.
When specified as *, all transactions from <source-name> will be mapped to the <record-name> record.
The Enable Key statement specifies that a new Key is enabled for a given record. Multiple Enable Key statements are allowed (and expected) for a given record. Multiple Enable Key statements are even allowed for the same <key>, provided that a unique <logical-key-name> is provided. At least one Enable Key statement must be specified for each record mentioned in a MAP RECORD.
Name of the Record for which the key is to be enabled, e.g. Base24AtmTransactionSummary.
Key or Keys to enable. This is a combination of Key fields for which a separate set of statistics is to be maintained.
The Keys are entered in the form, <key-field>[+<key-field> [+<key-field> …]].
For a list of applicable Key fields, see the Standard Transaction Key Fields.
Optional Where Clause which is used to filter the collected data. Only transactions matching this Where Clause will be accumulated for this Key, e.g. ATM=DEPOSITS. See Where Clauses for details about Where Clause functionality.
The Where Clause statement must be enclosed in single quotes if it contains any quoted strings, e.g. 'RESPCODE = "400"'
Optional unique name for the Enabled Key. When added, this is used as the associate name in the Data View Definition dialog box when creating a Display, Database etc. By adding a logical key name, it allows easier input into the Data View Definition, i.e. it is only necessary to enter the logical key name instead of the full set of key and/or where clause parameters. Normally this is only used in combination with a <where-clause> parameter, however it can be used with any Enable Key statement. Where <key> is specified for the same record more than once, a logical key name has to be used to make the entry unique.
Refer to Adding Transaction Key Fields for additional tips when adding Key fields.
This statement defines a set of amount ranges that can be used to categorize transaction data. Amount Range is optional. If not specified, the associated Amount Range fields will not be populated.
Record for which the range is to be set.
Amount field that this range will apply to, one of: Total, Cash or NonCash.
This defines a specific amount range for which separate statistics will be kept. Successive <range-delimiter> fields must increase in number. For example, Amount Range (Base24AtmTransactionSummary, Total, 100, 200, 300, 400) will create 5 distinct amount ranges (0-100, 100-200, 200-300, 300-400, 400+) for which separate statistics will be maintained when the associated key is enabled.
Specifies the BIN (Bank Institution Number) length to be used for the specified record. Defaults to 6 if not specified.
Record for which the BIN length is to be set.
Number of leading characters from the Primary Account Number (PAN) to treat as the BIN.
When standard or custom Key fields are unsuitable to gather the required data, User-defined Key fields can be used to specify a location within the transaction log from which data can be obtained and populated into one of the User fields (FLD<n>) in the Standard Transaction Key Fields. The User field can then be mapped to a Key field in the record. If not specified for a particular Transaction Source the corresponding User fields will be filled with spaces.
|<source-name>||Name of the Transaction Source for which the User field is to be defined. This configuration is passed down to the Transaction Log Reader so that it can extract the given field from the custom transaction record.|
<n> is the user field number to be populated: Maximum 60 (FLD1 thru FLD60).
Memory utilization in the transaction collectors is likely to increase in 11.8 due to the additional user fields. It may be necessary to increase the MEM-SIZE allocated to these collectors (in PROGNOSIS Configuration) and/or review the current collector configuration to ensure the optimal use of memory. For optimizing memory usage in the Transaction Surveillance collector, refer to TRANSACTION-DETAILS Section Syntax. For optimizing memory usage in the Transaction summary collector, refer to Minimizing Memory Usage in the Collector.
Contains the definition of how to extract the User field data from the custom transaction record. The syntax of this section is dependent on the Transaction Log Reader type being used.
For the BASE24 Transaction Log Reader, the syntax for this section is as follows:
<offset> - This is the offset of the data within the specified structure. For fixed fields, it is the offset from the start of the log record. For token fields, it is the offset from the start of the specified token.
<length> - Specifies the length of data to extract from the selected structure.
<token-id> - This is a two-character BASE24 token Id, e.g. 08 = Customer name token, B1 = Switch token - issuer. The full set of BASE24 token codes can be found in the ACI BASE24 Tokens manual.
Due to the potential length of the output, these field types may require the use of longer user fields. DATETIME use Field51-60, and INT64 use Field1-10 or Field41-50.
Specifies the mapping of a field from a standard or custom Key field passed up by the Transaction Log Reader to a Key field in the record. Map Field statements can only be specified for <source-name>, <record-name> combinations already referenced in the Map Record statements. By default, fields in the standard or custom Key will be automatically mapped to fields of the same name in the record. BASE24 Transaction Sources do not require any field mapping when mapped to the BASE24 Transaction Summary records.
Name of the Transaction Source from which the field is to be mapped.
Name of the Transaction Summary record that the field is to be mapped to.
Name of the field in the Transaction Log Reader (TLR) message that is to be mapped. <key-field> can be either a field in the standard transaction Key or a custom Key field for the TLR. For a list of Key fields, refer to Key Fields.
This is a field within the specified <record-name> to be filled with the contents of <key-field>.
Provide 1 or more message mapping functions to the Transaction Log Reader.
Name of the Transaction Source from which the field is to be mapped.
If there are many TRANSACTION SOURCEs in the Configuration and they all use the same source field and method, then it is possible to use a wildcard symbol, (asterisk), to denote every TRANSACTION SOURCE simultaneously. This is equivalent to writing the same MAP MESSAGE line for every TRANSACTION SOURCE.
A limitation of this syntax is that the <source field> must be contained in the Standard Transaction Key record only.
Selects the mechanism for populating the destination field. The available values for the method are:
MAP - Looks up the destination name from a dictionary file, using the source field as the index
RANGE - Looks up the destination name from a file where each destination name is keyed off a range of values instead of just a single index
This the name of the field being used in each of the method descriptions above. It must be explicitly one of the named fields in the 'Standard Transaction Key' record or one of the fields in the Custom Key record named in the Transaction Source definition.
It may be the case that the value of the source field doesn't correspond to any key, or any range, defined for the MAP and RANGE methods respectively. If this is the case, and there is no other Message Mapping rule, then the destination field will be empty, or have it's prior value. To address this, multiple Message Mapping rules are allowed per TRANSACTION SOURCE. The rules are applied successively, meaning that the last rule to apply to a record is the one that is used.
|<destination-field>||This the name of the field being populated by MAP MESSAGE function. The destination field may be any field contained in the Standard Transaction Key Fields record.|
This is the name of the CSV file containing either the MAP or RANGE values for the lookup processing. This file is located in the <Prognosis_Home>\Server\Configuration folder.
The format for this file is detailed in Populate the Mapping CSV Files
This statement is used to specify the name of the field that collects the transaction response codes, normally this will be 'RespCode'. However, this can vary for different ATM/POS transaction log solutions.
The purpose of this statement is related to the following Response Codes statement and a Response Field statement must be specified for each record referenced in a Response Codes statement.
Name of the Transaction Source containing the response code.
Name of the field to be used for response codes. For BASE24 this is 'RespCode'.
Example: See Response Codes statement below
Overrides the default treatment of the 'Approved', 'Denied' and 'TimedOut' response codes from a Transaction Source. This allows for an otherwise failed response code to be treated as a success. If not specified for a Transaction Source the <response-type> will be as provided by the Transaction Log reader.
Name of the Transaction Source for which this Response Code is to be defined.
One of: Approved, Denied, TimedOut.
Response code that will now be treated as the specified <response-type>. This overrides the default definition for this <response-code>.
The use of both the Response Field and Response Codes statements in the above example will cause response codes 150 and 151 to be treated as 'Approved', whereas normally they would be treated as 'Denied'.