4.1.3. Sharing elements

As seen before, the 5 main elements of a channel are its gateway IN, message definition IN, transformation, message definition OUT and gateway OUT.

These 5 elements are first-level objects. They can be configured independently of any channel, or used in many of them.

In this page, we go in more details about everything you need to know about sharing elements between different channels.

First-level objects

Gateways, Message definitions and Transformations can be configured directly through the ChannelDetail screen, in the channel in which you will reference them. But you can also focus on any of these elements in their own sections. These sections can be found under Manage & Build > Components.

Working in these sections can allow to focus on just one element.

These sections also allow some functionalities that will not be possible from the ChannelDetail screen. A simple example is viewing/editing/deleting the elements that are not referenced in any channel.

It can also be a good usage to use these sections to define first your elements, and combine them into channels only later. For example, you could already have received all the information about the formats to exchange with your partner, but still have no idea about how the communication will be done. You could already come here, define the MessageDefinition and the Transformation precisely, and only later, when you will receive the rest of the info, define the Channel and the Gateways.

Sharing or duplicating elements ?

If you have many channels, it is very likely happen that you will manipulate similar elements very often. For example, even if you receive invoices in different formats from your partners, maybe you always transform them to your own format. 

In such situations, when some elements are by nature the same (in the above example your MessageDefinition OUT), it is recommended that you don't redefine again and again similar MessageDefinitions in every channel, but that you define it only once, probably with more care and details, and reference the same instance (share it) in all the channels that need it.

By doing that, you will have only ONE instance of the MessageDefinition instead of tens of similar ones. It will be much easier to manage. Every time you make a change to this MessageDefinition, the change will immediately be propagated to all the referencing channels, as they all use the same MessageDefinition. If you had made many copies, you would have to go to every of them and make the change many times, every time that you want to make a small change to your format (add a field, add a validation, ...).

In summary, when some elements are by nature the same, you probably want that they are automatically kept in sync. You should define them only once, and reference the same instance everywhere. 

By opposition, if you want to allow that some elements can diverge, or to be able to make changes in some channel without affecting other channels, you should create different instance of your elements, even if they are very similar.

Reusing elements

To reuse already defined elements in your channels, you should use the Reuse and Save time button, instead of entering the process of defining again all the properties of the element in the left pane, that would lead to the creation of a new element.

When you want to define channels that are very similar to already existing ones, where some elements must be identical, and maybe only a few ones (ex: a gateway) must be different, another way is to use the power of the Duplicate channel action (to be found in General tab of the ChannelDetail screen).

This actions will prompt you to know, for every element, if you want to share the element with the original channel, to make a copy, or to leave the element empty (if you need to do something different, and will configure it afterwards).

Routing

If you share elements in the middle (message definitions) or at the end (gateway out) of your channel, nothing special will happen. 

But if you share the leading elements of your channel (at least the gateway IN), the system will receive the files through this shared gateway IN, and at some point will have to choose which channel it must execute.  In Babelway, this is called a Routing, and an additional tab will appear in the ChannelDetail screen when it is needed.

As a simple example, you could receive files from your client in a common mailbox, but want to process them differently if these files are orders or invoices. You will create 2 different channels, one to process the invoices and one for the orders. In these channels, the MessageDefinitions and the Transformation will be completely different. But both channels will share the gateway IN (the common mailbox). A routing will appear, where you will be able to tell that the processing should continue in one channel or the other by looking if the file is an invoice or an order.

More details about routings in the dedicated section.