BEA Sample Component

Change History

Version	Date	Author	Description
0.1.0	18-03-2014	JdB	Created as a sample for explaining the design output.
0.2.0	17-10-2014	JdB	Re-created for SVT.

Scope

The scope of this document consists of:

• Services provided to enable access to the BE back end system.
• Request/Response messages of provided services.
• Mapping details of service messages between BE and EAI.

Functional Requirements

This section explains all general (service-independent) information about the adapter component behaviour. This section is linked to the set of services for the above stated version by the last section (Component Service List).

Intro

This is a sample component information resembling the adapter design.
BEA services are either:

• Functionally operable services – functionally complete and executable with reference data, or
• Functionally complete services, or
• Functional stub processes – only the interface is completed so far (for temporary solutions only), or
• Documentation processes – cut&paste from original MS Word text into HTML (restrictions apply).

Introduction

This section describes the general information about the back-end adapter for system BE.

High-Level Overview

This sections explains the general functional requirements for the BE back-end adapter component. It may also contain images for futher explanation.

Non-functional Requirements

This section explains non-functional requirements for the BE back-end adapter component as they are known at design-time.

A DesignModel is a functionally complete and comprehensive set of services offered for a certain back-end. Usually a technical design document specifies the particular technical details after development. This section gives hints on which technical or other non-funtional requirements are anticipated.

Communication

This section explains the (technical) communication interface between the BE BEA and the real back-end for BE.

This may include interface types, protocols, e.g.:
For the communication between the Back-end Adapter and the BE platform XML messages over http protocol is used.

Authentication

This section explains the applicable authentication mechanism with the back-end, e.g.,

For messages from the adapter to the back-end system an authentication procedure is needed, using configurable userid-password information. For messages from back-end system to the adapter no authentication procedure is needed.

Error Handling

This section explains how back-end error are caught and handled by the BEA in general.

Therefore, the response from the back-end shall always contain an error list and an error section that can be used for response mapping, e.g.:
All interaction with the back-end is synchronous. Every backend call can result in an error (i.e. a non-zero return code with description; in the error part of the response message). This error is translated into canonical format and added to the ResultStatusStack of the services’ response message.

Exception Handling

For asynchronous processes the Exception Handler may be used to handle the conditional process flow in case of back-end errors. This can only occur in process services and may not be used for BEA services.

The interface to the exception handler is generic and offers the choice of one or more actions to be taken by manual intervention. The exceptions section in a srvice shall list the particulary applicable exceptions.

If applicable this section can describe organisatorial steps besides the service-specific exception handling.