Type to start searching...

Channel

Channels are abstract integration endpoints representating the Network Transport Layer. They are used to send or receive Messages.

Description
A channel is an abstract integration endpoint that works through a particular transport adapter. Currently supported transports include:


    * HTTP - both as a client and as a server - make any custom http message from our system.
    * Message Queue - send and receive using JMS
    * UDP - send and receive using the User Datagram Protocol
    * TCP - send and receive using the Transmission Control Protocol.
    * Mail - send and receive email messages. Not fully implemented as a channel yet.
    * File - send and receive using a set of directories.
    * Kafka - Send messages to a Kafka Server.
    * Generic - for a custom developed channel.
    * ObjectQueue - domain model message queueing.

Channels specify their communication protocol and other relevant information through their ChannelType. Channels are configured and bound to physical communication addresses through Connections, with which applications are deployed.

Integration Channels support a Send and Receive interface for interaction with external systems, whereas DataSources support a CRUD interface. Most channels can work as senders and as receivers. Channel interaction is message based and can be asynchronous where the persistence interface for DataSources is synchronous.

An advantage of NexJ integration engine channels is that regardless of transport, they have the same interface. Rather than dealing with different channels to external systems through their own APIs, channel adapters present them as the same API.

In NexJ Studio, Channels appear under the Integration tab of the Repository Navigator.

When deployed, Channels are accessed at the <ServerURL>/channel/<ChannelName> URL.

Channels may be bound to Services to which they will forward messages they receive.

Properties
anyAttribute

Any attribute

category : string

The category of the channel.

combine

Resolution algorithm for multiple bound services processing the same message. (Default none - meaning multiple services with the same message is not supported)

Valid values based on“string”.
none

Multiple services declaring the same message in their associated Interface Request messages are not supported. (Default)

first

Only the first one among the bound services with a matching message in their Interface Request messages is invoked.

all

All the services with a matching message in their Interface Request messages are invoked.

When multiple services are bound to a channel and a message is forwarded to more than one of those services, the initial "this" variable in those services refers to the same object. This should be taken into account if the original message object can be updated in any of the services – you might want to modify a copy of the message instead.
description : string

Channel description.

idle : boolean

True to disable the channel if it is not used by an enabled channel.

receive : boolean

True if the channel can receive messages.

send : boolean

True if the channel can send messages.

stealth : boolean

True to supress the debug logging, unless nexj.system.core.meta.integration.Channel.<name> category dump logging is enabled.

type : string

Channel type.

warningTimeout : nonNegativeLong

Timeout in milliseconds before a warning is generated, 0 for infinite timeout.

Valid values based on“long”.
0 (minInclusive)
Content