Nemo Connect search request router

Purpose

The search request router is used to automate the selection of requisite packages for search based on search query parameters.
The agency can set up a profitable search scheme for:

• searching across GDS in multiple zones,
• issuing more varied fares with minimal search transaction costs.

It is possible to bind requisite packages to a certain geography, for example, so that GDS Sirena Travel could search only domestic Russian flights.

Working Principle

Routing search requests in Nemo Connect is configured in Enable Nemo Connect search router.

Blocking and prioritizing rules

Using the router in the classic version assumes that if more than one rule fits the request, all rules are triggered and the request is routed to all triggered packages.
Via the Nemo Connect router, you can set up rules in such a way that when rules intersect, only one triggers. To do this, rules are assigned the blocking status.

• If there is at least one blocking rule among the rules suitable for the request, the router will choose one rule by priority.
• If there are no blocking rules among the rules suitable for the request, then all rules will be applied.

Rule priority is determined by the rule number (ID), or assigned manually using the Rule Priority parameter. The higher the number, the higher the priority. (see section Search request routing parameters in Nemo Connect).

• If there is a blocking rule among those suitable for the request, and manual priority is set for each triggered rule, then the rule for triggering is chosen according to the manual priority.
• If there is a blocking rule among those that match the request, and if manual priority is not set for at least one triggered rule, then the rule is chosen by rule number.

Features of sending requests when the Nemo Connect router is running

Attention! Once the Nemo Connect router is turned on, do not use geographic restrictions in Websky packets.

With the Nemo Connect router turned on, packet requests are distributed to the Nemo Connect router outside of Websky, so Websky's fine-tuning package usage restriction is no longer triggered. The search request passes through the connection requisites of the package selected in the fine-tuning to the Nemo Connect router, which distributes the request into packets according to its own rules.

Attention! For Websky's connection to Nemo Connect to be realized, at least 1 package must be included in the fine-tuning. This is a prerequisite, because Websky's requisites specify the details of the connection to Nemo Connect.

Enabling the Nemo Connect search router

To enable the search request router for an agency you must:
To Websky:

Manager:

1. Go to Product control → Airlines → Processes → Search Process → Fine Tuning.
2. Enable the Use Nemo Connect router option.
3. In the Requisites from which package will be used for the search request to Nemo Connect, select the requisite package.

Administrator (specify which settings the system will look at when searching):

1. Go to For tech support → Nemo Connect Web Services → Interaction settings.
2. Activate the Router settings option under Use settings in the Air Server from Nemo 1 for partitions.

In Nemo Connect:

1. Go to Avia Settings → Search Settings → Router Settings
2. Enable the Use Air Router option.

It is prohibited to make routing rules in Websky. Websky search router is recommended to be disabled.

Creating a search routing rule on the Nemo Connect side

To create a routing rule:

1. Go to Avia Settings → Search Settings → Router Settings.
2. Click the Add Router Rule button.
3. Enable the rule.
4. Set the rule parameters (see Search router parameters in Nemo Connect):
   • Specify the conditions for applying a rule - search request parameters under which the search will be performed by this rule.
   • Specify one or several Nemo Connect requisite packages which will be searched when the rule is applied.
   • Set the additional parameters that will be applied to the search request when applying the package.
5. Click the Save button.

Attention! You can create routing rules not only on the Nemo Connect side, but also on the Websky side (see Adding a search request routing rule for Nemo Connect on the Websky side).

Search request routing parameters in Nemo Connect

• Rule name - the name for easy work with rules.
• Rule enabled - enables the rule.
• Packet IDs to be searched - the numbers of the requisite packages from Nemo2.0 (see "Fine-tuning", first column), which will be searched for when the rule is triggered. Attention! The field is mandatory. It is forbidden to contain the numbers of production and test packages of the requisites at the same time.

Conditions of rule application

• List of departure countries - the countries of departure at which this requisite package will be triggered. The list of countries is set in ISO alpha 2 format, for example RU.
• Arrival countries list - arrival countries, at which this requisite package will be triggered. The list of countries is set in ISO alpha 2 format, for example RU.
• Departure cities list - IATA codes of departure cities, which will trigger this requisite package.
• Arrival City List - IATA codes of arrival cities, which will trigger this requisite package.
• Arrival Airport List - IATA codes of arrival airports, which will trigger the requisite package.
• Departure Airport List - IATA codes of departure airports which will trigger this requisite package.
• Disallow complex routes (more than 2 segments in the request)- for the complex routes search, the rule will be triggered only if there are no more than two segments in the route.
• All flight segments must satisfy route requirements - the rule is triggered if every flight segment satisfies the rule parameters. If this option is disabled, at least one segment must satisfy the conditions of the filter rule.
• RT-Flights Only - the rule applies to roundtrip flights only.
• Reverse rule logic - includes inversion of the rule's geographical restrictions (logic like everything but).
  For example, if the RU country is specified in the List of Departing Countries parameter when this option is enabled, the rule will apply to all flights except those departing from Russia.
• Invert departure/arrival countries - enables the inversion only by arrival/departure countries (logic like all except).
  For example if the List of Departing Countries parameter is set to AU then all the flights except the ones departing from Australia will be inverted.
• Invert departure/arrival cities - enables the inversion only by arrival/departure cities (logic like everything but).
  For example if the List of departure cities parameter is set to VOZ, all the flights except for the ones from Voronezh will be included.
• Invert departure/arrival airports - switches on the inversion by arrival/departure airports only (logic like everything but).
  For example if you have BWI in the Arrival airports list option checked, then all flights except the Baltimore/Washington area will be affected, and flights from Washington DC will not be affected.

• Required tags for this rule to trigger - mandatory tags in the search request for the rule to trigger. Tags in Nemo Connect.
• Tags for which rule is not allowed to trigger - if there are tags from this list in the request, the rule will not be applied.

• Rule uniqueness feature - assigns blocking status to a rule. If this option is enabled and if there is at least one blocking rule among the rules suitable for the request, the router will select one rule by priority. If there are no matching rules, all the rules will be applied (see section Blocking and priority of rules).
• Rule priority - works only for rules with Blocking rule option enabled. Assigns priority to a rule - the higher the number, the higher the priority. When blocking rules, the one with the highest priority is triggered (see section Blocking and prioritizing rules).
• Maximum number of days to departure date on all legs - if the setting is enabled, the rule is not triggered if the set value is exceeded.
• List of allowed days to start search - the serial number of the day of the week (starting from 1), on which it is allowed to start search.
• Strategy of processing rules with matching packets - determines the way of action when two or more rules with identical search packages are triggered, if any of these rules contains priority/undesirable airlines (parameters "Airlines for transfer as obligatory in GDS" and "airlines to be excluded from issuing"). The parameter can take three values:
  • Constrict - narrowing the search results, it is the default value and corresponds to the logic of rule processing BEFORE adding this parameter. In this mode, if there is a pair of "Common rule without filtering by airlines" + "Private rule with filter", it is the private rule that will trigger; the common rule will be ignored in favor of the private one. If at least one of the triggered rules is set to Constrict, then all rules will be narrowed.
  • Expand is an expansion of search results. In this mode, if there is such a pair, both rules will trigger, and GDS will send parallel requests with and without filtering by airlines. If there are rules with the same requisite package for each package, the parameters of the rules are merged. If there are several matching rules with the airlines filter, all the filters are merged. The airlines that are required to be sent to the GDS are merged. If there are lists of excluded airlines, their values are removed from the list of mandatory airlines. If there are no obligatory airlines, only the list of excluded airlines will be filled in.
  • Independent - rules are not merged under any circumstances. Rules with this option are processed separately from all other rules and are added to the applied ones. Thus one more search is added and such rules are excluded from the association logic in matched packages.
• Work also for reverse segments - if this option is enabled, the departure/arrival points specified in the rule will be allowed for the route with departure/arrival points in reverse - cities are checked both for OW requests there and OW - requests in the opposite direction from the specified one, including RT. The button will allow, within the framework of the departure/arrival city list rule, flights in the opposite direction as well (arrival points are checked as departure points, and departure points as arrival points).

Attention! The Include return segments setting is currently unstable, please do not use it temporarily.

Attention! Enabling departure city inversion and arrival city inversion within the same rule will NOT invert the direction of the flight, you will need to enable the inverse rule logic to invert the direction.

Adding additional parameters to the request in GDS

• Airlines to pass as mandatory to GDS - The airlines listed are passed as mandatory in the request to GDS. When attempting to limit a search request to certain airlines, you should consider whether the specified airlines are contained in the list of mandatory airlines for transmission to GDS in the router's rules. If the specified airlines are contained in the obligatory list in router rules, then the intersection of airlines from two lists (from router rules and from the request to the air server) is sent to the request. If the list of mandatory airlines is missing in the rule, the airlines are taken from the request.
• Airlines required to be excluded from search results - the airlines that are in the list are marked as undesirable for the search results while requesting from GDS.

Attention! The options "Airlines to be passed as obligatory to GDS" and "Airlines that should be excluded from search results" are not supported by all aviation content providers. The following does not support this: My Agent (Aviacenter)

• Enables replacement of economy/premium economy class in the query with All - enables search by all classes if economy or premium economy class is specified in the request.

• Add premium version of the requested class - enables additional requests for the premium version of the class specified in the search.
• Override preferred flight class - the flight class, specified by the user in the search parameters, will be changed to the preferred class when requesting to GDS.
• Maximum number of flights in GDS response - the number of flights from each GDS in the search results:
  • for GDS Sabre only fixed values can be used: 50/100/200,
  • for GDS Galileo the parameter does not work,
  • for GDS Amadeus, Sirena Travel, uAPI you can specify any positive integer number.
• Search for minimum and minimum returnable fares - adds a parameter that asks for return fares with minimum price along with minimum fares. If the option is enabled], more return fares are displayed in the search results.
• Request public fares only - this option is available for GDS Sabre only. Allows you to additionally retrieve and display to the client in search results not only the basic fares of the airline, which are usually private, but also more expensive public fares. An example of the settings usage - search for the BASIC and FLEX fare families at S7 Airlines in case if the agent has an access to them for the RCC, as by default the GDS will return only the cheapest BASIC fares for each flight.
• Restrict requesting only for direct flights - allows you to disallow searching for flights without connections to specific destinations. If this option is enabled and the user has requested a direct flight, and at least one of the requested segments fits the rule, then the rule is not considered to work and the search is not started.
• Maximum number of connections - allows you to limit the maximum number of connections in the search results. The restriction applies to each requested shoulder. It is possible to limit the number of connections from 0 (direct flights) to 3 (flights with given or less number of connections). The functionality is implemented for GDS Amadeus, Sabre, Galileo and Galileo uAPI.

Attention! If two rules are triggered simultaneously for searching in the same packet, one of which specifies "Airlines for transfer as mandatory to GDS" and "Airlines to be excluded from issuance", only "Airlines for transfer as mandatory to GDS" will be sent to the provider.

Tags in Nemo Connect

A Tag is a label that serves to identify the category or group to which an item belongs.

Tags in Websky are only used for the Nemo Connect router.

When the Nemo Connect router is enabled, tags corresponding to the request parameters are automatically added to the request from Websky to Nemo Connect.

Tags are sent to the router along with the request. They indicate request data, such as: the type of user making the search request (manager - mgr, agent - agt or anonymous user - anon), the type of search (agent API - api , meta-search - meta). Possible tags:

• b2b - search request from a B2B account,
• b2c - search request from a B2C account,
• usr - search request as a registered user,
• exp - search request on behalf of an expert,
• mgr - search request on behalf of a manager,
• agt - search launched by the user of the root agency,
• corp - search launched by the corporate client of the agency,
• subagt - search launched by the user of the subagency,
• anon - search request launched by an anonymous user,
• api - the search is launched through the agency API,
• meta - the search is launched through the meta-search,

as well as tags containing:

• user number - the user who launched the search,
• number of the group whose user launched the search,
• number of the subagency and agency of the user who started the search.

Adding a search routing rule for Nemo Connect on the Websky side

To create a routing rule:

1. Go to Product control → Airlines → Processes → Search Process → Router Settings.
2. Select the desired user, group or agency Edit.
3. Click Create a new entry.
4. Set the parameters of the rule (see Search routing parameters in Nemo Connect:
   • Specify conditions for applying a rule - search request parameters, under which the search will be performed by this rule.
   • Specify if you want to invert one or another search request parameter (country/city/arrival or departure airport).
   • Specify one or more Nemo Connect requisite packages to be searched when applying the rule.
   • Specify additional parameters that will be applied to the search request when applying the package.

1. • Select the type of rule, Constrict or Expand or Independent, it will determine what the airline filter will be used for.
2. Click the Save button.

Attention! If rules are set on a particular user/group, then only the rules of the user/group will be used.
And if there are other rules higher in the nesting hierarchy, for example on the agency, then those rules will be ignored.
In case a user/group has no rules of its own, then the first rules in the hierarchy above will be used.

Import search query routing rules into Websky

In addition to creating rules, you can import rules from the admin panel of Nemo Connect. The system will completely transfer all the settings from the associated Nemo Connect agency to the selected user or Nemo Travel group. Attention! When you import settings, your current router rules are deleted.
The associated agency is set under the administrator in 'For tech support → Nemo Connect Web Services → Interaction settings. There you need to fill in the following fields:

• User ID in Nemo Connect.
• User login in Nemo Connect.
• User password in Nemo Connect.
• The .net server environment being used.

Features of the Websky side displaying the router settings table

• A row in the table corresponds to one router rule.
• The columns correspond to the settings of the router. For details, see Search routing settings in Nemo Connect
• Column 'Intersection with shows identifiers of rules that either exactly match the rule (whose string we are considering), or our rule is a special case of the rules specified in the column. The "Intersection with" column helps you to see the intersection of rules and gives you a better understanding of the total mass of router rules.

Example

Rule ID	Intersects with	Search Parameters
001		Flights from France
002	001	Flights from Paris

Examples of routing rules in Nemo Connect

=Rules for including P subclass in search results

For Azerbaijan Airlines (J2) subclass P is the budget subclass of economy class, while for most airlines P is first class. Since Websky recognizes this subclass as first class, it is by default not available for Economy class flights.

To get flights in this subclass in the output, you need to have the system ask for both business and economy class, and then filter the results. The Nemo Connect router provides the necessary settings to adjust the request to GDS to obtain the desired rendition.

1. Go to Avia Settings → Search Settings → Router Settings.
2. Click the Add Router Rule button.
3. Check the Rule Enabled checkbox to activate the rule.
4. Enter the numbers (id) of the prop packets in Nemo Connect that will be affected by the rule in the IDs of packages to be searched field.
5. Check the Enable Economy/Premium Economy Class Substitution in the request for All checkbox.
6. Enter the Rule Name for your convenience.
7. Click the Save button.

The rule replaces Economy and Premium Economy class in the GDS request with All for the specified packages. Thus when requesting economy class fares, GDS will send flights of all classes. Unwanted results can be filtered out with search results filters.

See also

• Search request router
• Websky search request router
• Search (Air tickets)
• Global Distribution System
• Websky requisite packages
• Search request filters (Air tickets)
• Search result filters (Air tickets)
• Search result mixer (Air tickets)
• Currency