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.

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.

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>

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.

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.

Troubleshooting

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

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