CONNEX Configuration Syntax

This is the configuration for Connex environments which are monitored by the Payments product suite.

SUBSYS CONNEX

TRANSACTION SOURCE (<source-name>, <location>, <source-type>, <exe-name>, [<custom-key-definition>],[ <custom-params>])
TCPIP PORT (<port-number>[, <server-proc-name>])
MAP RECORD (<source-name>, <record-name>[, <filter>])
ENABLE KEY (<record-name>, <key>, [<where-clause>], [<logical-key-name>])
AMOUNT RANGE (<record-name>, <range-type>, <range-delimiter>, [<range delimiter>], [<range-delimiter>...] )
BIN LENGTH (<record-name>, <bin-length>)
USER FIELD (<source-name>, FLD<n>, "{SEGMENT|TOKEN} (<user-field-definition>)")
MAP FIELD (<source-name>, <dest-record-name>, <key-field>, <record-field>)
MAP MESSAGE (<source-name>, <method>, <source-field>, <destination-field>, <mapping-file>)
RESPONSE FIELD (<source-name>, <response-code-field>)
RESPONSE CODES (<source-name>, <response-type>, <response-code>[, <response-code> ...])

Syntax Elements

TRANSACTION SOURCE

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.

The commas in this statement must be retained as placeholders if any intermediate optional parameters are excluded, e.g. Transaction Source (name, location, type, exe-name , , params). However, if optional parameters starting from the end of the string are excluded then the preceding comma may be omitted, e.g. Transaction Source (name, location, type, exe-name).

<source-name>

Unique user-defined name for this TLR.

<location>

Location of the transaction log. For Connex this is specified in the format <lgwarm-subvol>:<logger-name>, where <lgwarm-subvol> is the subvolume where the LGWARM file is located and <logger-name> is the process name of the logger to be monitored by this TLR.

<source-type>

Type of transaction source, i.e. 'Connex'. When set to  Connex the <custom-params> parameter will be checked for validity before starting the TLR.

<exe-name>

Executable name of the TLR. For Connex this is 'IRCNXTLR', however, for Connex this is optional.

<custom-key-definition>

(Optional) Name of the record definition used for the custom keys for this TLR. For Connex this is 'ConnexTransactionCustomKey'.

If omitted, the collector will expect no custom fields to be passed from the TLR

<custom-params>

(Optional) A number of optional custom parameters can also be added. For Connex, these are entered in the form <token>=<value>, with each one on a new line.

For more information see Connex Custom Parameters.

TCPIP

On the HPE NonStop platform this statement 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.

<port-number>

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.

<server-proc-name>

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.

MAP RECORD

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.

<source-name>

Name of the Transaction Source to be mapped.

<record-name>

Identifies the record to which the TLR transactions should be mapped. It is possible to define multiple record mappings for the same TLR.

<filter>

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.

Example:

MAP RECORD (Logger1, ConnexAtmTransactionSummary, ATM)

ENABLE KEY

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.

<record-name>

Name of the Prognosis record for which the key is to be enabled, e.g. ConnexAtmTransactionSummary.

<key>

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 example:

TERMID+TYPE+RESPCODE.

For a list of applicable Key fields, see the Standard Transaction Key Fields.

<where-clause>

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"'

<logical-key-name>

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.

AMOUNT RANGE

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-name>

Record for which the range is to be set.

<range-type>

Amount field that this range will apply to; Total, Cash or NonCash.

<range-delimiter>

Defines a specific amount range for which separate statistics will be kept. Successive <range-delimiter> fields must increase in number.

Example:
In this example, 5 distinct amount ranges will be created (0-100, 100-200, 200-300, 300-400, 400+) for which separate statistics will be maintained when the associated key is enabled.

AMOUNT RANGE (ConnexPosTransactionSummary,Total, 100, 200, 300, 400)

BIN LENGTH

Specifies the BIN (Bank Institution Number) length to be used for the specified record. Defaults to 6 if not specified.

<record-name>

Record for which the BIN length is to be set.

<bin-length>

Number of leading characters from the Primary Account Number (PAN) to treat as the BIN.

USER FIELD

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.
FLD<n><n> is the user field number to be populated, maximum 10 (FLD1 thru FLD10).
{SEGMENT|TOKEN} (<user-field-definition>)

Contains the definition of how to extract the user field data from the custom transaction record. The syntax of this section is dependent upon the type of Transaction Log Reader being used. For the Connex Transaction Log Reader, the <user-field-definition> can be defined with SEGMENT or TOKEN statements.

SEGMENT

SEGMENT selects one of the segments (1-23) contained within a Connex message type 400, for details see the Connex Message Segment Fields. Only segment 1 is guaranteed to be present as it specifies which of the other optional segments are also present in a given message type 400.

"SEGMENT ([<segment-number>,] {STRING|INT|INT32|INT64|HEX|FLAG} (<offset>[, <length>[, <starting-bit]]))"

<segment-number> - Selects the message type 400 segment number (1-23) to extract data from (if present in a given message type 400). Segment 24 is not valid here, use the TOKEN syntax to extract data from this segment. Defaults to 1 if not specified.

{STRING|INT|INT32|INT64|HEX|FLAG} - Use one of the following parameters.

STRING

Specifies the data to be extracted in printable string format. Non-printable characters (i.e. < %h20 | > %h7f) are converted to printable ”;” characters).

INT

Specifies the data to be extracted as a TAL INT (2 bytes). The data will be placed in the target user field as a string of 5 printable, decimal digits.

The <offset> field is applicable for use with this parameter and will be rounded to an even value if specified as odd. If not specified the default is 0.

The <length> field is not applicable for use with this parameter.

INT32

Specifies the data to be extracted as a TAL INT(32) (4 bytes). The data will be placed in the target user field as a string of 10 printable, decimal digits.

The <offset> field is applicable for use with this parameter and will be rounded to a four-byte value if not evenly divisible by four. If not specified the default is 0.

The <length> field is not applicable for use with this parameter.

INT64

Specifies the data to be extracted as a TAL FIXED or INT(64) (8 bytes).  The data will be placed in the target user field as a string of 16 printable, decimal digits.

The <offset> field is applicable for use with this parameter and will be rounded to an eight-byte value if not evenly divisible by eight. If not specified the default is 0.

The <length> field is not applicable for use with this parameter.

HEX

Specifies the data to be extracted verbatim in hexadecimal printable string format, two printable characters for each selected byte.

FLAG

Defines access to a flag (bit) field based on the number of bits covered by the <starting-bit> and <length> within the field present at <offset> bytes within the specified segment. The value copied to the user field will be the decimal representation of the bit(s) specified, with leading zeroes removed.

Asterisks ”*” will be returned if the segment <segment-number> is not present, if the <offset> exceeds the size of the specified segment, or if the <length> extends beyond the end of the segment.

Example:

To extract the AUTH^BY^ALT^ROUTE field from PROCESSING^FLAG[3] into FLD1:

USER FIELD (*, FLD1, "SEGMENT(1, FLAG( 736, 1, 7))")

<offset> - Specifies the offset into the selected segment from which to start extracting data. The offset cannot exceed the length of the selected segment.

STRING or HEX: Valid values are in the range 0 - <max-size-of-the-selected-segment> in decimal.

<length> - Specifies the length of data to extract from the selected segment. The length cannot exceed the length of the selected segment.

for STRING:

The length parameter defaults to 1 and its valid value is 1-20 decimal. Also, the combination of the offset and length cannot exceed the size of the selected segment (or 20, whichever is least). If this is exceeded then no data will be moved to the target user field.

for HEX:

The length parameter defaults to 1 and its valid value is 1-10 decimal (because each source byte results in two printable characters). Also, the combination of the offset and length cannot exceed the size of the selected segment (or 10, whichever is least). If this is exceeded then no data will be moved to the target user field.

for FLAG:

The length parameter defaults to 1 and its valid range is 1-32. It specifies the number of bits to be used, starting from <starting-bit> bits from byte <offset> within the specified segment.

<starting-bit>
Only valid for FLAG type fields. Specifies the starting bit of the flag within the field starting at byte <offset> within the specified segment. Must be in the range 0 through 31, where 0 is the most significant (left-most) bit and 31 is the least significant (right-most) bit. If not specified, <starting-bit> defaults to 0.

For full details of the Connex Msg 400 Segment offset and field lengths see the Connex Message Segment Fields.

TOKEN

TOKEN selects a token number within the variable data (segment 24) segment contained within a Connex message type 400. Note that only segment 1 is guaranteed to be present as it specifies which of the other optional segments are also present in a given message type 400. The variable data segment is composed of a number of structured tokens containing self-defining data (i.e. each token type represents data of a particular definition and size).

"TOKEN(<token-number>[, (<offset>[, <length>])])"

<token-number> - This is a numeric token identifier, e.g. 5 = Node name information, or 500 = Terminal capability profile. The full list of Connex token numbers can be obtained from the TKNNAMST file of the Connex installation.

Data contained in the target token will be truncated to the size of the selected user field if larger.

<offset> - Specifies the offset into the selected token from which to start extracting data. The offset cannot exceed the self-defining length of the selected token and its proper rounding is dependent upon the constraints imposed by the data type of the self-defining token (e.g. character or hex character format).

The offset parameter defaults to 0 if not specified. Valid values are in the range 0 - <max-length-of-the-selected-token> in decimal.

This parameter is only valid with tokens that are string-based (i.e. character, hex character etc.), it is not valid with tokens that are fixed-size such as int or int32.

<length> - Specifies the length of data to extract from the selected segment.  The length cannot exceed the self-defining length of the selected token and the maximum formatted output cannot exceed that of the specified user field.

The length parameter defaults to the size of the self-defining token (i.e. the size of the selected user field, whichever is least) if not specified and its valid value is 1 - maximum-length-of-the-selected-token in decimal.

This parameter is only valid with tokens that are string-based (i.e. character, hex character etc.), it is not valid with tokens that are fixed-size such as int or int32.

Example:

USER FIELD (Connex, FLD1, "SEGMENT (4, INT( 0 ))")
USER FIELD (Connex, FLD2, "SEGMENT (1, STRING( 2, 6 ))")
USER FIELD (Connex, FLD3, "SEGMENT (19, HEX( 12, 4 ))")
USER FIELD (Connex, FLD4, "TOKEN (504)")
USER FIELD (Connex, FLD5, "TOKEN (509, ( 2 ))")
USER FIELD (Connex, FLD6, "TOKEN (511, ( 4, 2 ))")

MAP FIELD

This statement is not normally required for Connex users as Key field mapping is automatic.

Specifies the mapping of a field from a standard or custom Key field passed up by the TLR 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. Connex Transaction Sources do not require any field mapping when mapped to the Connex TransactionSummary records.

<source-name>

Name of the Transaction Source from which the field is to be mapped.

<record-name>

Name of the Transaction Summary record to which the field is to be mapped.

<key-field>

Name of the field in the 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.

<record-field>

Field within the specified <record-name> to be filled with the contents of <key-field>.

MAP MESSAGE

Provide 1 or more message mapping functions to the Transaction Log Reader.

<source-name>

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.

<method>

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

<source-field>

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. Currently, only MRCHNAME is supported.
<mapping-file>

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 Configuration folder.

The format for this file is detailed in Populate the Mapping CSV Files

Example:

MAP MESSAGE (TXNSRC1, MAP, FLD1, MRCHNAME, MerchNameMap.csv)
MAP MESSAGE (*, RANGE, TERMID, MRCHNAME, TermMerchRanges.csv)

RESPONSE FIELD

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.

<source-name>

Name of the Transaction Source containing the response code.

<response-code-field>

Name of the field to be used for response codes. For Connex this is 'RespCode'.

Example: See the following Response Codes statement description.

RESPONSE CODES

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.

<source-name>

Name of the Transaction Source for which this Response Code is to be defined.

<response-type>

One of: Approved, Denied, TimedOut.

<response-code>

Response code that will now be treated as the specified <response-type>. This overrides the default definition for this <response-code>.

Example:

RESPONSE FIELD (<Logger1>, <RESPCODE>)
RESPONSE CODES (<Logger1>, Approved, 150, 151)

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'.

Provide feedback on this article