Data Sharing

Data Sharing in short is a way to share information across different boundaries.

It serves as a core feature in the replication process since it determines which data must be replicated to certain destinations, directly impacting the export process.

Key Concepts

To fully understand this functionality we first need to know the following concepts:

Domain

The boundaries mentioned earlier are known by us as "Domains", they are in charge of defining where data belongs and can correspond to concepts such as vessels, offices, departments, facilities, or whole fleets.

They are not necessarily related to physical locations, and since they can reference concepts that follow some kind of organization structure, they are defined in a tree-like hierarchy, see the following example of the domains of Crystal Cruise (CC):

Installation

Installations represent physical facilities such as ships, offices, or islands, they must be associated to a unique Domain (there can not be two different Installations for the same one). For example, taking the Domains from the previous image the ones in green would be associated with an Installation:

Installed Domain

An Installed Domain determines a Domain whose shared data (explained below) can be accessed from an Installation in particular. In our applications, they determine the facilities where the user can be "located" working with the app.

Take a look at the following image, on the left we have the Installations, and on the right the Domains whose shared data they can access:

As we can see, a user running an application in the CC LLC Installation can access the available info of the Domains of all the other Installations (and itself), and therefore operate as if he were in some of these facilities, whereas a user running an application on Symphony will only be able to operate with the data of that facility.

To accomplish that, CC LLC will have an Installed Domain for each one of the Domains on its right side, whereas the other Installations will have only one for their Domain, correspondingly.

Important

Installed Domain are necessary since they are used as the source in the Sharing process.

Application

As the name suggests, it represents different products of the company: iInspector, AIMS, etc.

Table

Represents a database table that belongs to an Application and whose data can be shared across different Domains through the use of sharings.

Table Sharing

A Table Sharing (also known as Table Domain) represents a sharing rule for a Table, which starts from a Domain (taken as the source) and indicates to which other Domain (taken as destination) the information of the table can be shared.

Info

Remember when in the Installed Domain section we talked about how we can access the shared data of another Domain from a certain Installation?. Well, that shared data is determined by Table Sharings.

In order to define a sharing, we will need three things:

• The Table Id we want to share.
• The source Domain Id, from which we want to share the data.
• The target Domain Id, to which we want to share the data.

Sharing process

The sharing process involves the calculation to know the Domain we need to use for the operation we need (creation, search, etc.).

Steps

It can be summarized in the following steps:

1. Starts by searching for a Table Sharing for the Table we need, taking the current Domain (the one in which we are working) as the source.
   1. Either if there's no Table Sharing for the Table or if the Table Sharing found has the same Domain as target, then the information only can be accessed from that Domain.
   2. If no Table Sharing for the source Domain is found, then we go up in the Domains tree hierarchy and continue the search repeating the process, but using the Parent Domain of the old source as the new one.
2. Once a Table Sharing is found, the target Domain will be the boundary to use.

Important

The Domain used as source will be always taken from Installed Domains.

Example

For this example suppose we have the following tables in the database, using some of the domains in previous examples (and assuming they have the same installed domains as in the Installed Domain section):

Domain Id	Domain Name	Parent Id
991	Global
995	River Fleet	991
992	Ocean Fleet	991
991	Offices	991
11	Crystal Cruises, LLC	993
21	Crystal Symphony	992
31	Crystal Serenity	992
51	Crystal Mozart	995

We want to share Assets and Inspections, whose Tables are:

Table Id	Table Name
100	Assets
101	Inspections
102	Budget

And we have the following Table Sharings defined:

Table Id	Source Domain Id	Target Domain Id
100	51	51
101	995	995

If we try to create a new Asset standing in the Mozart Installation, the sharing process (following step 1 defined in the Sharing process steps section) will search a Table Sharing for the Assets table with the Mozart domain id (51) as its source.

Since there is a tuple that matches the criteria (the first one) then the domain to use will be 51, since its the value of the target domain id column.

Now, if we want to create a new Inspection standing in the same domain, the process will not find any Table Sharing for the Inspections table id (101) and Mozart domain id (51) as the source. In this case (following step 1.2 defined in the Sharing process steps section) we will go up the domains three now using the parent domain as the new source, which is the River Fleet and whose id is 995.

Once the process finds the Table Sharing to use (the third one) the domain id to use will be 995, which is River Fleet, meaning that the Inspections created in Mozart will be shared to River Fleet.

Finally, suppose that we now want to create a Budget, since there is no Table Sharing for the Budgets table, then the domain to use will be the one in which we are standing (following step 1.1 defined in the Sharing process steps section).