Syntax of the Bulk Loader Data Files

Each service definition consists of properties and parameters that have a set number of parameter properties. Each property is represented by a keyword and a value.

Keywords are divided into two levels:

Guidelines for Using Keywords

The ibld command reads the service definitions from a text file. While using the keywords, follow the guidelines in Table 4-2.

Table 4-2 Guidelines for Using Keywords

Guideline Example

Each keyword must be followed by an equal sign (=) and the value.

Correct: type=string

Incorrect: type

Only one keyword is allowed on each line.

Correct: type=string

Incorrect: type=string access=out

Any lines not having an equal sign (=) are ignored.

Correct: type=string

Incorrect: type string

Certain keywords only accept a well defined set of values.

The keyword, access accepts these values: in, out, inout, noaccess

The input file may contain multiple service definitions.

service=INQUIRY
<service keywords and values>
service=DEPOSIT
<service keywords and values>
service=WITHDRAWAL
<service keywords and values>
service=TRANSFER
<service keywords and values>

Each service definition consists of multiple keywords and values.

service=deposit
export=true
inbuf=VIEW32
outbuf=VIEW32
inview=INVIEW
outview=OUTVIEW

Keyword Order in the Bulk Loader Data File

Keyword order must be maintained within the data files to ensure an error-free transfer during the bulk load.

The first keyword definition in the bulk loader data text file must be the initial service=<NAME> keyword definition (shown in Listing 4-1). Following the service=<NAME> keyword, all of the remaining service keywords that apply to the named service must be specified before the first param=<NAME> definition. These remaining service keywords can be in any order. Refer to Table 4-3 for a list of the service keywords and values.

Next, specify all the parameters associated with the service. Following each of the param=<NAME> keywords are all the parameter keywords that apply to the named parameter until the next occurrence of a parameter definition. These remaining parameter keywords can be in any order. When all the parameters associated with the first service are defined, specify a new service=<NAME> keyword definition.

Listing 4-1 Correct Example of Hierarchical Order in a Data File
service=<NAME>
<service keyword>=<value>
<service keyword>=<value>
<service keyword>=<value>
param=<NAME>
<parameter keyword>=<value>
<parameter keyword>=<value>
param=<NAME>
<parameter keyword>=<value>
<parameter keyword>=<value>

Using Service-Level Keywords and Values

A service is equivalent to an operation. A service definition must begin with the "service=" keyword. See Tasks for additional information about operations.

Note: Services using CARRAY or STRING buffer types should only have one parameter in the service. The recommended parameter name for a CARRAY service is "CARRAY" with "carray" as the data type. For a STRING service, the recommended parameter name is "STRING" with "string" as the data type. See Tasks for more information.

To review the service-level keywords and values, see Table 4-3.

Table 4-3 Service-Level Keywords and Values

Keyword Value

service

Any BEA TUXEDO service name

export

true or false (default is false)

inbuf/outbuf

Select one of these buffer types:

FML
FML32
VIEW
VIEW32
STRING
CARRAY

inview

Any view name for input parameters (optional; only if VIEW or VIEW32 buffer type is used)

outview

Any view name for output parameters (optional)

Using Parameter-Level Keywords and Values

A parameter begins with the "param=" keyword followed by a number of parameter keywords until another "param" or "service" keyword, or end-of-file is encountered. The parameters can be in any order after the "param" keyword.

See Tasks for more information about parameters.

To review the parameter-level keywords and values, see Table 4-4.

Table 4-4 Parameter-Level Keywords and Values

Keyword Values

param

Any parameter name

type

byte
short
integer
float
double
string
carray

access

in
out
inout
noaccess

count

Maximum number of occurrences (default is 1). The value for unlimited occurrences is 0. Used only by the Contract Repository Editor to format test screens.