Once the installation of Connect OSI TP is complete, you will want to configure Connect OSI TP. The proper configuration of Connect OSI TP sets up the gateway configuration. Configuring the Connect OSI TP gateway includes:
To define a new gateway configuration, complete the following steps.
Defining New Gateway Configurations
The configuration specified in the DMCONFIG file controls much of the operation of the BEA Connect OSI TP gateway. A sample of this file is provided in the installation directory of your BEA Connect OSI TP product software.
DMCONFIG is the ASCII version of a TUXEDO System/Domain domain configuration file. The DMCONFIG file is parsed and loaded into a binary version by the dmloadcf utility. The binary configuration file, called the BDMCONFIG file, contains information used by domain gateways to initialize the context required for communications with other domains dmadmin uses the binary file (or a copy of it) in its monitoring activity. There will be one BDMCONFIG file for each TUXEDO System/Domain application that uses the /Domain feature.
A DMCONFIG file, and its binary BDMCONFIG counterpart, are analogous to the UBBCONFIG and TUXCONFIG files of a non-/Domain System/T application. The DMCONFIG file extends the definition of a non-/Domain System/T application so that the application becomes a domain.
The BEA Connect OSI TP product software must be installed and accessible to your text editor. You must have file permission to access the install directory and modify the sample DMCONFIG file. In addition, the following prerequisites must be met to successfully complete the editing procedure:
$TUXDIR/udataobj/DMTYPE file defining the valid domain types must exist. Refer to the Appendix B, "Reference Pages," for information on the dmloadcf command.
dmloadcf must match the UID in the RESOURCES section of the TUXCONFIG file. Refer to the dmloadcf reference page in Appendix B, "Reference Pages".
The format of a domain configuration file is as follows:
Configuration File Format
DEFAULT: [ KEYWORD1 = value1 [ KEYWORD2 = value2 [...]]]
The values set on this line remain in effect until reset by another DEFAULT: line, or until the end of the section is reached. These values can also be overridden on non-DEFAULT: lines by placing the optional parameter setting on the line. If on a non-DEFAULT: line, the parameter setting is valid for that line only; lines that follow revert to the default setting. If DEFAULT: appears on a line by itself, all previously set defaults are cleared and their values revert to the system defaults.
The following steps will assist you in editing the DMCONFIG file.
Note:
Because BEA Connect OSI TP may be installed on a variety of platforms, the procedures in this section make only general references to command entries. Many steps show UNIX command examples. Be sure to use the proper syntax for your platform when making command-line entries.
Editing Procedure
install directory, for example:
cd install
examples subdirectory, for example:
cd examples
edit DMCONFIG
$exit
dmloadcf utility. This parses and loads a binary
BDMCONFIG configuration file (refer to dmloadcf reference page in
Appendix B, "Reference Pages").
The following paragraphs describe the significant parameters within specific sections of the DMCONFIG file that define new gateway configurations.
This section identifies local domains and their associated gateway groups. The section must have an entry for each gateway group (Local Domain). Each entry specifies the parameters required for the domain gateway processes running in that group.
*DM_LOCAL_DOMAINS entries have the following format.
LDOM required parameters [optional parameters]
where:
LDOM is an identifier value used to name each local domain.
LDOM must be unique within a particular configuration. As you will see in the description of the *DM_LOCAL_SERVICES section, LDOM is the identifier that connects local services with a particular gateway group.
The following parameters are required.
The following optional parameters describe resources and limits used in the operation of domain gateways:
This section identifies the known set of remote domains and their characteristics.
*DM_REMOTE_DOMAINS entries have the following format.
RDOM required parameters
where:
RDOM is an identifier value used to identify each remote domain known to this configuration.
RDOM must be unique within the configuration.
The following parameters are required.
There are no optional parameters for this section.
This section defines the addressing information required by domains of type TDOMAIN. This section should have an entry per local domain if requests from remote domains to local services are accepted on that local domain (gateway group), and an entry per remote domain accessible by the defined local domains.
*DM_TDOMAIN entries have the following format.
DOM required parameters [optional parameters]
where:
DOM is an identifier value used to identify either a local domain (LDOM) or a remote domain (RDOM) in the *DM_LOCAL_DOMAINS section or in the *DM_REMOTE_DOMAINS section.
The DOM identifier must match a previously defined LDOM in the *DM_LOCAL_DOMAINS sections or RDOM in the *DM_REMOTE_DOMAINS section.
The following parameter is required.
The following parameter is optional:
Notice that multiple entries for a particular domain may be defined in this table. Currently, only the first address is used and the remaining entries are ignored.
This section defines the addressing information required by domains of type OSITP. This section should have one entry per gateway group (local domain), and one entry per remote domain of type OSITP.
*DM_OSITP entries have the following format.
DOM required parameters [optional parameters]
where:
DOM is an identifier value used to identify a local domain (LDOM) or a remote domain (RDOM) in the *DM_LOCAL_DOMAINS section or in the *DM_REMOTE_DOMAINS section.
The DOM identifier must match a previously defined LDOM in the *DM_LOCAL_DOMAINS sections or RDOM in the *DM_REMOTE_DOMAINS section.
The following are required parameters.
The following are optional parameters.
This section specifies the access control lists used by local domain.
*DM_ACCESS_CONTROL entries have the following format.
ACL_NAME required parameters
where:
ACL_NAME is a (identifier) name used to identify a particular access control list; it must be 15 characters or less in length.
The following parameter is required.
This section provides information on the services exported by each local domain. This section is optional and if it is not specified then all local domains defined in the *DM_LOCAL_DOMAINS section accept requests to all of the services advertised by the TUXEDO System/Domain application. If this section is defined then it should be used to restrict the set of local services that can be requested from a remote domain.
*DM_LOCAL_SERVICES entries have the following format.
service [optional parameters]
where:
service is the (identifier) local name of the exported service, and it must be 15 characters or fewer in length.
This name corresponds to a name advertised by one or more servers running with the local TUXEDO System/Domain application. Notice that exported services inherit the default or special properties specified for the service in an entry in the SERVICES section of the TUXCONFIG file. Some of these parameters are: LOAD, PRIO, AUTOTRAN, ROUTING, BUFTYPE, and TRANTIME.
There are no required parameters for *DM_LOCAL_SERVICES.
The following parameters are optional.
This section provides information on services "imported" and available on remote domains.
*DM_REMOTE_SERVICES entries have the following format.
service [optional parameters]
where:
service is the (identifier) name used by the local TUXEDO System/Domain application for a particular remote service.
Remote services are associated with a particular remote domain.
There are no required parameters for the *DM_REMOTE_SERVICES section.
The following parameters are optional.
This section provides information for data-dependent routing of service requests using FML, VIEW, X_C_TYPE, and X_COMMON typed buffers.
*DM_ROUTING entries have the following format.
CRITERION_NAME required parameters
where:
CRITERION_NAME is the (identifier) name of the routing entry that was specified on the services entry.
CRITERION_NAME must be 15 characters or less in length.
The following parameters are required.
A range is either a single value (signed numeric value or character string in single quotes), or a range of the form ``lower - upper'' (where lower and upper are both signed numeric values or character strings in single quotes). Note that ``lower'' must be less than or equal to ``upper.'' To embed a single quote in a character string value (as in O'Brien, for example), it must be preceded by two backslashes ('O\\'Brien').
The value MIN can be used to indicate the minimum value for the data type of the associated FIELD; for strings and arrays, it is the null string; for character fields, it is 0; for numeric values, it is the minimum numeric value that can be stored in the field.
The value MAX can be used to indicate the maximum value for the data type of the associated FIELD; for strings and arrays, it is effectively an unlimited string of octal-255 characters; for a character field, it is a single octal-255 character; for numeric values, it is the maximum numeric value that can be stored in the field.
Thus, ``MIN - -5'' is all numbers less than or equal to -5 and ``6 - MAX'' is all numbers greater than or equal to 6. The meta-character ``*'' (wildcard) in the position of a range indicates any values not covered by the other ranges previously seen in the entry; only one wildcard range is allowed per entry and it should be last (ranges following it will be ignored).
The routing field can be of any data type supported in FML. A numeric routing field must have numeric range values and a string routing field must have string range values.
String range values for string, array, and character field types must be placed inside a pair of single quotes and cannot be preceded by a sign. Short and long integer values are a string of digits, optionally preceded by a plus or minus sign. Floating point numbers are of the form accepted by the C compiler or atof(): an optional sign, then a string of digits optionally containing a decimal point, then an optional e or E followed by an optional sign or space, followed by an integer.
When a field value matches a range, the associated RDOM value specifies the remote domain to which the request should be routed. A RDOM value of ``*'' indicates that the request can go to any remote domain known by the gateway group.
Within a range/RDOM pair, the range is separated from the RDOM by a ``:''.
If the field value is not set (for FML buffers), or does not match any specific range and a wildcard range has not been specified, an error is returned to the application process that requested the execution of the remote service.
There are no optional parameters for the *DM_ROUTING section.
The following configuration file defines a 5-site domain configuration. The example shows 4 Bank Branch domains communicating with a Central Bank Branch. Three of the Bank Branches run within other TUXEDO System/Domain domains. The fourth Branch runs under the control of another TP Domain and OSI TP is used in the communication with that domain.
The example shows the TUXEDO System/Domain Domain configuration file from the Central Bank point of view.
Listing 3-1Sample Configuration File at Central Bank
# TUXEDO DOMAIN CONFIGURATION FILE FOR THE CENTRAL BANK
#
#
*DM_LOCAL_DOMAINS
# <local domain name> <Gateway Group name> <domain type> <domain id> <log device>
# [<audit log>] [<blocktime>]
# [<log name>] [<log offset>] [<log size>]
# [<maxrdom>] [<maxrdtran>] [<maxtran>]
# [<maxdatalen>] [<security>]
# [<tuxconfig>] [<tuxoffset>]
#
#
DEFAULT: SECURITY = NONE
c01 GWGRP = bankg1
TYPE = TDOMAIN
DOMAINID = "BA.CENTRAL01"
DMTLOGDEV = "/usr/apps/bank/DMTLOG"
DMTLOGNAME = "DMTLG_C01"
c02 GWGRP = bankg2
TYPE = OSITP
DOMAINID = "BA.CENTRAL01"
DMTLOGDEV = "/usr/apps/bank/DMTLOG"
DMTLOGNAME = "DMTLG_C02"
NWDEVICE = "OSITP"
URCH = "ABCD"
#
*DM_REMOTE_DOMAINS
#<remote domain name> <domain type> <domain id>
#
b01 TYPE = TDOMAIN
DOMAINID = "BA.BANK01"
b02 TYPE = TDOMAIN
DOMAINID = "BA.BANK02"
b03 TYPE = TDOMAIN
DOMAINID = "BA.BANK03"
b04 TYPE = OSITP
DOMAINID = "BA.BANK04"
NWDEVICE = "/dev/osi"
URCH = "ABCD"
*DM_TDOMAIN
#
# <local or remote domain name> <network address> [<nwdevice>]
#
# Local network addresses
c01 NWADDR = "0x0002ff98c00b9d6d" NWDEVICE ="/dev/tcp"
c01 NWADDR = "newyork01.65432" NWDEVICE ="/dev/starlan"
# Remote network addresses
b01 NWADDR = "0x00020401c00b6d05" NWDEVICE = "/dev/tcp"
b02 NWADDR = "dallas.65432" NWDEVICE = "/dev/starlan"
b03 NWADDR = "0x00021094c00b6d9c" NWDEVICE = "/dev/tcp"
*DM_OSITP
#
#<local or remote domain name> <apt> <aeq>
# [<aet>] [<acn>] [<apid>] [<aeid>]
# [<profile>]
#
c02 APT = "BA.CENTRAL01"
AEQ = "TUXEDO.R.4.2.1"
AET = "{1.3.15.0.3},{1}"
ACN = "XATMI"
b04 APT = "BA.BANK04"
AEQ = "TUXEDO.R.4.2.1"
AET = "{1.3.15.0.4},{1}"
ACN = "XATMI"
*DM_LOCAL_SERVICES
#<service_name> [<Local Domain name>] [<access control>] [<exported svcname>]
#
#
open_act ACL = branch
close_act ACL = branch
credit
debit
balance
loan LDOM = c02 ACL = loans
*DM_REMOTE_SERVICES
#<service_name> [<Remote domain name>] [<local domain name>]
# [<remote svcname>] [<routing>] [<conv>] [<trantime>]
#
#
tlr_add LDOM = c01 ROUTING = ACCOUNT
tlr_bal LDOM = c01 ROUTING = ACCOUNT
tlr_add RDOM = b04 LDOM = c02 RNAME ="TPSU002"
tlr_bal RDOM = b04 LDOM = c02 RNAME ="TPSU003"
*DM_ROUTING
# <routing criteria> <field> <typed buffer> <ranges>
#
ACCOUNT FIELD = branchid BUFTYPE ="VIEW:account"
RANGES ="MIN - 1000:b01, 1001-3000:b02, *:b03"
*DM_ACCESS_CONTROL
#<acl name> <Remote domain list>
#
branch ACLIST = b01, b02, b03
loans ACLIST = b04
This example shows the TUXEDO System/Domain Domain Configuration file required at one of the Bank Branches (BANK01).
Listing 3-2Sample Configuration File at Branch Bank
#TUXEDO DOMAIN CONFIGURATION FILE FOR A BANK BRANCH
#
#
*DM_LOCAL_DOMAINS
#
b01 GWGRP = auth
TYPE = TDOMAIN
DOMAINID = "BA.BANK01"
DMTLOGDEV = "/usr/apps/bank/DMTLOG"
*DM_REMOTE_DOMAINS
#
c01 TYPE = TDOMAIN
DOMAINID = "BA.CENTRAL01"
*DM_TDOMAIN
#
b01 NWADDR = "0x00021094c00b689c" NWDEVICE = "/dev/tcp"
c01 NWADDR = "0x0002ff98c00b9d6d" NWDEVICE = "/dev/tcp"
*DM_LOCAL_SERVICES
#
tlr_add ACL = central
tlr_bal ACL = central
*DM_REMOTE_SERVICES
#
OPA001 RNAME = "open_act"
CLA001 RNAME = "close_act"
CRD001 RNAME = "credit"
DBT001 RNAME = "debit"
BAL001 RNAME = "balance"
*DM_ACCESS_CONTROL
#
central ACLIST = c01
To modify an existing gateway configuration, complete the following steps.
dmadmin command to access the binary BDMCONFIG file.
You can use the dmadmin command or the BEA TUXEDO graphical user interface to administer Connect OSI TP.
You can administer domain gateway groups defined for a BEA TUXEDO System/T application using dmadmin, an interactive command interpreter. The dmadmin command can operate in two modes: administration mode and configuration mode. Configuration mode allows the administrator to change a configuration while the application is running. Refer to the BEA TUXEDO/T Domain Manual for information about the dmadmin command.
To establish a gateway configuration, the BEA TUXEDO system must recognize the Connect OSI TP administrative and gateway servers. To define the Connect OSI TP servers for BEA TUXEDO, edit the UBBCONFIG file to define the Connect OSI TP administrative and gateway servers to the BEA TUXEDO system.
The following file is a sample UBBCONFIG file that defines Connect OSI TP administrative and gateway servers to the BEA TUXEDO system.
Listing 3-3 Sample UBBCONFIG File for Connect OSI TP
### Sample ubbconfig file showing Connect OSI TP modifications
*RESOURCES
# No OSI TP entries in the RESOURCES section.
*MACHINES
# No OSI TP entries in the MACHINES section.
*GROUPS
### A group must exist for each OSI TP Gateway.
#
OSIGRP # Name the group as you wish
GRPNO=1 # Choose a free group number
LMID=MACHINE # Specify the machine hosting the gateway.
TMSNAME="TMS" # Two or more TMS servers are required.
TMSCOUNT=2
*SERVERS
### One DMADM server must be configured.
#
DMADM
SRVID=1 # Choose a unique server id.
SRVGRP=OSIGRP # Place in any convenient group.
### One GWADM server must be configured for each gateway.
#
GWADM
SRVID=2 # Choose a unique server id.
SRVGRP=OSIGRP # Place into the group created for this gateway.
### One GWOSITP server must be configured for each gateway.
GWOSITP
SRVID=3 # Choose a unique server id.
SRVGRP=OSIGRP # Place into the group created for this gateway.
*SERVICES
# No OSI TP entries in the SERVICES section.
Refer to the BEA TUXEDO Reference Manual.