# Interface File (*.IFCE) Reference

This chapter is provided to assist you in using interface files. Interface files are loaded into the Main Window of the Process Design Assistant as an alternative method for creating an interface. The other method of creating an interface is to interactively create one using the tools in the Main Window. The following sections describe how to use interface files:

- Overview

- Loading ATMI Services

- Interface File Example

## Overview

eLink provides you a means to integrate enterprise applications. An important part of the integration process is the creation of an interface. In eLink, an interface is composed of a set of operations to be performed on the application to which you are interfacing and their associated inputs and outputs. The definition for this interface can be recorded in a text (ASCII) file, and that file can be loaded into the Process Design Assistant Main Window.

## Loading ATMI Services

This section covers the technical details of what occurs when you use the Load button.

### Introduction to the Interface Loader

You may have an environment with many ATMI services. Manually creating these definitions using the Process Design Assistant may not be desirable.

The interface loader facility is a part of the Process Design Assistant. This reads a formatted text file consisting of ATMI service definitions and loads them into the Contract Repository Database.

Note: ATMI services are known as operations in the Process Design Assistant.

After the Loader has populated the Contract Repository, you may edit services, create new services, and group services using the Process Design Assistant.

See Usage in Chapter 3, "Specifying Business Service Contracts," for information about using the Process Design Assistant.

#### About the Interface File

The interface file is a text file that defines services and their associated parameters. The interface loader loads the services defined in the interface file into the Contract Repository using the interface file name. If a load has been performed, the interface exists in the Contract Repository.

### Syntax of the Interface 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:

- Service-level

- Parameter-level

#### Guidelines for Using Keywords

While using the keywords, follow the guidelines in Table A-1.

Table A-1 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=FML32 outbuf=FML32

#### Keyword Order in the Interface Loader Data File

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

The first keyword definition in the interface loader data text file must be the initial service=<NAME> keyword definition (shown in Listing A-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 A-2 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 A-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 Usage in Chapter 3, "Specifying Business Service Contracts," for additional information about operations.

To review the service-level keywords and values, see Table A-2.

Table A-2 Service-Level Keywords and Values

Keyword | Value
service | Any ATMI service name
export | true or false (default is false)
inbuf/outbuf | Select one of these buffer types: FML32 NONE

#### 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 Usage in Chapter 3, "Specifying Business Service Contracts," for more information about parameters.

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

Table A-3 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 0). The value for unlimited occurrences is 0. Used only by the Process Design Assistant to format test screens.

### Troubleshooting

If you encounter any problems using the interface loader utility, see Table A-4.

Table A-4 Loader Troubleshooting Table

If . . . | Then . . .
the data file is not found | check to ensure that the path is correct Note: UNC path names (of the form \\<computer name>\path) are not directly supported. To load interface files from a remote drive, first map the drive to a local drive letter.
the keyword is invalid | check to ensure that the keyword is valid for the package, service, or parameter
the value of the keyword is null | type a value for the keyword
the value is invalid | check to ensure that the value of a parameter is within the allocated range
the data type is invalid | check to ensure that the parameter is using a valid data type

## Interface File Example

The following is an example of an interface file. It can be used to load the interface for the simple funds transfer example that is used throughout this guide.

service=SubtractInteger
export=true
inbuf=FML32
outbuf=FML32
param=INTEGER_OPERAND
type=long
access=in
count=3
param=INTEGER_RESULT
type=long
access=out
count=2

service=AddInteger
export=true
inbuf=FML32
outbuf=FML32
param=INTEGER_OPERAND
type=long
access=in
count=3
param=INTEGER_RESULT
type=long
access=out
count=2

### Interface File Explained

Let us examine the first few lines of the sample interface file and explain each one as we go.

service=SubtractInteger

This line specifies an operation in the Business Interface Window called SubtractInteger.

export=true

If this line is set to true, the SubtractInteger service is exported. Therefore, it can be tested.

inbuf=FML32
outbuf=FML32

These two lines set the input and output buffer types to FML32, the only type allowed in eLink.

param=INTEGER_OPERAND

This line makes INTEGER_OPERAND a parameter of the SubtractInteger operation.

type=long

This line specifies that element INTEGER_OPERAND will be of the long integer type. An element can be specified as any of the standard C data types. int=integer variable, long=long integer, float=floating point variable, string=string variable.

access=in

This line designates parameter INTEGER_OPERAND as an input. The choices for the access setting are in=input, out=output, inout=input/output.

count=3

This line sets the Occurance variable for INTEGER_OPERAND to "3."