> For the complete documentation index, see [llms.txt](https://docs.editran.onesait.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.editran.onesait.com/documentacion-editran/open-v5.3-en/readme.md).

# Editran Platform

Indra's Editran platform is structured into two essential components:

* **Communications Platform (Editran/P**). It includes all the common services directly related to communication facilities (protocol, interfaces with TCP transmission services, local networks, etc.).
* **Generic Application Interface Module (Editran/G**). It isolates the communication services provided by Editran/P from the user applications, serving as the link between them and the transmission processes

![scheme](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-c6c3c2a149a9e49ae8fbb75775e1b8ed5bc2d34f%2Fesquema.png?alt=media)

## Description

Editran transmits files, with a given structure, from a local end to a remote one. These files are called send and receive buffers.

To obtain send buffers from conventional application files and, conversely, to obtain these application files from receive buffers, it is necessary to use upload and download programs which, as a whole, can be referred to as the application interface.

The current Generic Application Interface, hereinafter Editran/G, has been developed with the dual goal of greatly increasing the functionality of the existing interfaces, while at the same time remaining compatible with the previous ones, so that an entity that installs the latest version of Editran/G will be able to:

* Do without the previous interfaces.
* Exchange data with entities that have a previous version of Editran/G, in compatibility mode with that version.
* Exchange data with entities that have the same version of Editran/G, both in compatible mode (same functionality as the previous interfaces with improvements in the process) and in native mode (extended functionality).

## Send and receive buffers

These are the temporary files used by Editran during sending or receiving.

A buffer file contains data corresponding to a single transmission session.

The record length may be (including the key) from 13 to 9999. When the remote end is a HOST, only values 252 or 4050 are valid.

The buffers are made up of:

* A first control record with the sequence number of the key set to zero. This record contains, among others, the following data and may affect an interface:
  * Total number of records.
  * Number of confirmed records.
  * Indicator of fully sent or received.
  * Availability indicator for Editran.
  * Exchange session number.
* Several data records with the key sequence number in order from 1 to the total number exchanged.

## Integration with Editran/G

To work with Editran/G it is necessary to maintain a profile file with information about:

* Local entity. Nine numeric characters are used for identification.
* Remote entity. Same as above.
* Presentation application. Identified by 6 alphanumeric characters. It is used to define the nature of the information to be exchanged.
* Presentation session. Identified by a name that we recommend defining with the code (or name) of the remote entity + the presentation application (for example, 9999-TEST). The information contained in this profile largely comes from the three previous corresponding profiles.

A presentation session can consist of up to 20 transmission sessions or, which is the same, the information to be exchanged can be transmitted multiplexed over up to 20 connections at the same time.

The presentation session goes through different states that reflect the point reached in file sending and receiving. The specific Editran/G document explains the different states and the operations that are or are not allowed in each case.

The messages generated by the various components of Editran/G are recorded in a log file. This file can be queried and listed using various selection criteria.

There are commands provided with the installation that can invoke the same functions as those in the operator menu to facilitate integration with customers' applications.

It is possible to work with Editran/G in **compatible mode with versions 5.0, 5.1 and 5.2 and in native mode with versions 5.3**. The operating mode is determined by the remote Editran/G version of the Presentation profile.

### General characteristics

When operating in native mode, there are general functions (specified in the presentation profiles) and specific functions (determined by the converters used).

General functions include, among others:

* Ability to process send application files with fixed-length, variable-length, hybrid records and/or binary files.
* A presentation session can use up to 20 Editran transmission sessions; hence the identification of the presentation application does not correspond to that of the transmission application defined in Editran. This can also happen in the case where there is only one transmission session associated with a presentation session.
* The send application information can be subjected to several optional presentation functions (cryptography, compression and EBCDIC/ASCII translation) and is loaded into specific buffers, up to a maximum of 20, depending on the number of transmission sessions specified and the chosen split criterion.
* The presentation session number is tracked between two ends, so it increases with successive exchanges. This number will be passed to the exchange session number in the send and receive buffers, so transmission will not be allowed if it does not match at both ends.
* editran/P will send to the remote side using the transmission sessions specified in local editran/G, which must be consistent with those defined in remote editran/G. In these transmission sessions, the presentation functions to be performed by editran/P, cryptography, compression and/or CRC could be defined, but it would not make much sense if they have already been applied to the application data.
* At the remote end, the information will be received in buffers, up to a maximum of 20, depending on the transmission sessions used. Within this information there will be header data so that remote editran/G can verify that the options used on the sender are consistent with those on the receiver, and information about the characteristics of the received information. The information from the receive buffer or buffers is unloaded into as many application files as were used in the send loading at the other end, after performing the presentation functions in reverse.

### Specific characteristics

The specific functions are associated with the version of remote Editran/G indicated in the presentation profiles. Below are some of the most notable features of each version. The change documents for each version can be consulted for more detailed information.

#### Version 3.0, 3.1

* The maximum number of files that can be transmitted is 9999 between homogeneous environments (Unix, Windows) and 99 for the rest.
* It transmits fixed- or variable-format files from 1 to 99999 bytes per record. Between homogeneous environments they can also be exchanged in binary mode.
* The logical unit of transmission (or batch) is the file. In other words, no application synchronisms are incorporated.
* Data compression and alphabeting is done at the presentation level, not per file.
* RSA authentication is incorporated.

#### Version 4.0

* Sending files in binary mode to any environment is allowed.
* Features such as compression and translation are applied from this version onward at file level.
* Optional translation on receipt is incorporated.
* The user may define tables to adapt Editran character sets to those of each entity locally.

#### Version 4.1

* Verification of the signature of transmitted files.
* Triple DES cryptography.
* One file per Presentation is generated with the list of sent/received files.
* New Editran/GC module for external exchange of RSA keys.

#### Version 5.0

* There is no limit on the number of files that can be sent in each transmission.
* There is no limit on the size of the application file. Files larger than 2 Gbytes are supported.
* It is not necessary to define the alphabet of the remote entity.

#### Version 5.1

* Incorporation of send operations with remote download confirmation.

#### Version 5.2

* Security improvement: AES encryption and 2048- and 4096-bit RSA keys.
* Integration with the Editran/FF module for control in the sending of signed files.
* New license file format to improve management in entities with several local codes.
* Daily report of transmitted files. This is an optional feature that the administrator can enable.

#### Version 5.3

* Compatibility with protocol versions lower than disappears **5.0**.
* To avoid the most vulnerable encryption cases, Editran 5.3 removes cryptographic version 2.2. The use of 3DES (with triple key) associated with higher cryptography versions is still allowed.
* The possibility of configuring a download acknowledgment on sending is offered.
* The option to increment presentation number is removed.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.editran.onesait.com/documentacion-editran/open-v5.3-en/readme.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
