Instant messaging processor (im)

Table of Contents

Description
Opportunities
Limitations
Parameters
Configuration example
See also

Description

Fast messenger messaging processor.

Provides communication with messengers. It places incoming messages from messengers in the `/rest/v1/model/im/Messages` data model collection, and sends the `sending` messages created in it to the messengers' subscribers.

Forms collections/classes: im/Accounts, im/RemoteParties, im/Messages. Allows their further modification in the direction of extending the composition of properties and variants of values of enumerated fields.

Uses the domain center collection `imchannels` (API, entity).

Table 1. System Characteristics

Code	`im`
Mode of operation	`Service`
Backup mode	`Active-Passive.`
Types of sites	`Any`
Layer	`Adapter/processor`
Placement	`Internal`
Saving and restoring state on reboot	`No`
appendix	`era_im`

Opportunities

Messages can be text, pictures, sound files, etc. The text of the message is placed in the `/im/Message` entity field. The message text is placed in the `/im/Message` entity field, and other variants are saved as attachments (`file` field) and can be accessed through the `/rest/v1/model/im/Messages/ID_MESSAGE/file`.
Supports adding adapters to different types of messengers through creating plugins (erlang) or implementing strategies in scripts.

Limitations

Each individual messenger requires unique parameters that can be set in the account options (the `options` field of the entity im/Accounts). In particular for Telegram, `token` must be specified there, and also optionally `disable_notification` (`true` | `false`) и `parse_mode` (`none`, `markDown`, `HTML`).
The platform includes a connector to the Telegram. Other connectors require project development and can be implemented as scripts (separate script for receiving messages and placing them in collections, separate script for sending one specific message).

Parameters

Description of columns in the table

Table 2. Parameters
Name	Type	Default	Description
`name`	`str`	required	Name. May consist of Latin letters and numbers, must begin with a letter.
`roletype`	`str`	required	Role Type. Possible values: `"im"`.
`iface`	`str`	required	The alias of the server network interface on which the roles will interact internally with each other.
`ext`	`json`	empty	Additional role options. Contains a json object or list.
`enabled`	`bool`	empty	Role activity flag. When set to false, the role does not participate in validation and is not started.
`group`	`int`	required	Group Number. As part of horizontal scaling, a role can be divided into multiple groups on a site, with only one instance active in each group and the rest reserved. Responsibilities between groups are shared across domain sets. Together, all groups maintain a complete domain set. All roles in the same group must have the same responsibility. Integer from `1` to `9999999`.
`order`	`int`	required	The order of a role instance within a group. Defines in what order the flow in the mode will take place Active-Passive.
`include_domains`	`array<str>`	empty	A list of domain names served by this group. Any domain of any level can be specified. Specifying a domain causes its subdomain tree to be served on this group and not on other role groups, excluding only those branches mentioned in other groups. Collectively, all role groups on a site serve a complete domain tree.

Configuration example

The configuration is managed in an application available to master domain administrators. The application hides the full content of the configuration, but it is nevertheless accessible via the API.

The configuration contains a section to describe all instances of all roles. Parameters are defined for each specific role instance.

Example node

{
  "name": "im1",
  "roletype": "im",
  "iface": "eth0",

  "group": 11330,
  "order": 1
}