Hot to enable support of specific cryptocurrency exchange in CCXTMT library

CCXTMT library processes requests and responses for specific cryptocurrency exchange API using a special JSON-file with processing rules. If an exchange you are interested in does not yet have a ready-made JSON-file, it's more or less simple to make it, based on corresponding exchange class from the original ccxt library, of course, provided that the exchange is supported there. Chances are that your exchange is supported because ccxt includes 100+ exchanges.

For example, if you want to work with a hypothetical exchange ABC, just grab abc.js file from the ccxt distribution, copy it into MQL5/Files folder and rename to abc.json. You can edit this file inplace, removing much javascript-specific stuff and leaving only data-related operations.

The stub of the object with transformation rules should be taken from describe method at the top of the file - look at this.deepExtend call accepting a javascript object with the exchange description. Remember that javascript objects are basically the same thing as JSON until they contain only data fields.

Then locate javascript methods for processing API requests, such as:

Public

· fetchMarkets

· fetchCurrencies

· fetchTicker

· fetchTickers

· fetchOrderBook

· fetchOHLCV

· fetchTrades

Private

· fetchBalance

· createOrder

· cancelOrder

· fetchOrder

· fetchOrders

· fetchOpenOrders

· fetchClosedOrders

· fetchMyTrades

Not everyone is required. You may concentrate only on methods which you'll actually use. For example, to build bars of specific symbol you need fetchOHLCV, and to monitor its ticks you need fetchTicker.

Every method is logically divided into 2 parts:

- preparation of http-request

- processing of http-response

Hence, you need to translate corresponding javascript operations into `request` and `response` rules.

{
  'rules':
  {
    'fetchTicker':
    {
      'request':
      {
        ...
      },
      'response':
      {
        ...
      }
    }
  }
}

Please note, that many of the methods invoke other auxiliary functions, especially when processing responses. You should investigate the code for all of them and mirror it in the rules if necessary (again, not every line of code is equally important for every use case). For example, fetchTicker body will most likely contain code to prepare the request, whereas all processing of the response is contained in parseTicker function called from fetchTicker return statement. Some of the auxiliary functions may be found in the base class Exchange.js, if they are common for all exchanges.

In addition to the specific API methods there is a common procedure of signing all requests. It is located in the function sign and should be translated into signature rules.

  'rules':
  {
    'sign':
    {
      'public':
      {
        ...
      },
      'private':
      {
        ...
      }
    }
  }

They are required and used for all requests.

The whole control and data flow is shown on this scheme:

Signatures of public and private methods are usually different. Also the rules may differ depending from http-method (GET, POST, etc.), then the hierarchy of rules will expand:

  'rules':
  {
    'sign':
    {
      'public':
      {
        ...
      },
      'private':
      {
        'GET':
        {
          ...
        },
        'POST':
        {
          ...
        },
        'PUT':
        {
          ...
        }
      }
    }
  }

Actual rules are stated using a special syntax, described in other post.

The rules for requests and responses are slightly different. JSON-selectors in requests handle parameters and optional arguments received from client MQL code which invoked corresponding method, and the rules prepare all required data for building specific http-request. JSON-selectors in responses handle data received from the server, and the rules direct the construction of resulting json (unified for all exchanges).

Of course, somewhere in-between errors may potentially happen. For that reason the json file may also provide rules for error processing. The javascript code from which the rules are derived is located in the function handleErrors in the ccxt classes. The error rules are semantically the same as for response, but they are checked before response. The error rules are optional and can be omitted. In this case CCXTMT library will handle http error codes only, and will not be able to analyze special JSON-responses with applied errors and business logic details. For example, without applied error processing you'll be unable to find out the reason why a specific request was declined, and the reason may be very different - wrong input parameters, insufficient funds, ban for too frequent requests or something else.