diff --git a/misc/doc/sources/interception/index.rst b/misc/doc/sources/interception/index.rst index e2037e214..6f56026db 100644 --- a/misc/doc/sources/interception/index.rst +++ b/misc/doc/sources/interception/index.rst @@ -343,6 +343,8 @@ Scripting examples You'll find below some helping examples of scripts used to intercept MO and/or MT messages. +.. _sc_hlr_lookup: + HLR Lookup routing ================== diff --git a/misc/doc/sources/resources/routing/Routable.dia b/misc/doc/sources/resources/routing/Routable.dia index 64cd9f580..f71ace152 100644 Binary files a/misc/doc/sources/resources/routing/Routable.dia and b/misc/doc/sources/resources/routing/Routable.dia differ diff --git a/misc/doc/sources/resources/routing/Routable.png b/misc/doc/sources/resources/routing/Routable.png index 616610822..e7a7aa792 100644 Binary files a/misc/doc/sources/resources/routing/Routable.png and b/misc/doc/sources/resources/routing/Routable.png differ diff --git a/misc/doc/sources/routing/index.rst b/misc/doc/sources/routing/index.rst index 42ddd93aa..546ea0132 100644 --- a/misc/doc/sources/routing/index.rst +++ b/misc/doc/sources/routing/index.rst @@ -20,16 +20,16 @@ Process flow .. figure:: /resources/routing/routing-process.png :alt: MO and MT routing process flow :align: Center - + Routing process flow -There's one **MORoutingTable** and one **MTRoutingTable** objects holding respective routes for each direction (MT or MO), -these are **Route** objects that hold one or many **Filter** (s) objects and one destination **Connector** (or many connectors +There's one **MORoutingTable** and one **MTRoutingTable** objects holding respective routes for each direction (MT or MO), +these are **Route** objects that hold one or many **Filter** (s) objects and one destination **Connector** (or many connectors in some specific cases, c.f. :ref:`Route_multiple_con`). -As explained by the above routing process flow figure, for each message and depending on its direction, a routing table is -loaded and an iterative testing is run in order to select a final destination connector or to reject (returning no connector) it, -routes are selected in descendant order, and their respective filter objects are tested against the **Routable** object (It is an +As explained by the above routing process flow figure, for each message and depending on its direction, a routing table is +loaded and an iterative testing is run in order to select a final destination connector or to reject (returning no connector) it, +routes are selected in descendant order, and their respective filter objects are tested against the **Routable** object (It is an extension of the low-level SMPP PDU object representing a message, more information in :ref:`Route_Routable`). Examples @@ -41,10 +41,10 @@ MO Routing Having the below MO routing table set through a jCli console session:: jcli : morouter -l - #MO Route order Type Connector ID(s) Filter(s) - #30 StaticMORoute http_3 + #MO Route order Type Connector ID(s) Filter(s) + #30 StaticMORoute http_3 #20 RandomRoundrobinMORoute http_1, http_2 , - #0 DefaultRoute http_def + #0 DefaultRoute http_def Total MO Routes: 3 The following routing cases are considered: @@ -67,10 +67,10 @@ MT Routing Having the below MT routing table set through a jCli console session:: jcli : mtrouter -l - #MT Route order Type Rate Connector ID(s) Filter(s) - #100 RandomRoundrobinMTRoute 0.00 smpp_1, smpp_2 + #MT Route order Type Rate Connector ID(s) Filter(s) + #100 RandomRoundrobinMTRoute 0.00 smpp_1, smpp_2 #91 StaticMTRoute 0.00 smpp_4 , - #90 StaticMTRoute 0.00 smpp_3 + #90 StaticMTRoute 0.00 smpp_3 Total MT Routes: 3 The following routing cases are considered: @@ -93,7 +93,7 @@ The following routing cases are considered: .. note:: Route's **rate** are discussed in :doc:`/billing/index`. -Router components +Router components ***************** The router components are mainly python objects having the unique responsibility of routing messages to Jasmin connectors. @@ -108,15 +108,19 @@ The **Routable** class is extended by child classes to hold necessary informatio .. figure:: /resources/routing/Routable.png :alt: jasmin.routing.Routables.* :align: Center - + jasmin.routing.Routables.* -The **SimpleRoutablePDU** is only used for Jasmin unit testing, **RoutableSubmitSm** and **RoutableDeliverSm** are used depending +The **SimpleRoutablePDU** is only used for Jasmin unit testing, **RoutableSubmitSm** and **RoutableDeliverSm** are used depending on the message direction: * MO: **RoutableDeliverSm** * MT: **RoutableSubmitSm** +All routables provide a tagging api through the *addTag()*, *hasTag()*, *getTags()*, *removeTag()*, *flushTags()* methods, +this feature is mainly used in the :doc:`interceptor `, there's a concrete example of such usage +:ref:`here `. + .. list-table:: **RoutableSubmitSm** attributes :widths: 10 10 80 :header-rows: 1 @@ -159,21 +163,21 @@ The **Connector** class is extended by child classes to represent concrete HTTP .. figure:: /resources/routing/Connector.png :alt: jasmin.routing.jasminApi.Connector and childs :align: Center - + jasmin.routing.jasminApi.Connector and childs Filter ====== -The **Filter** class is extended by child classes to define specific filters which are run by Jasmin router to match a -desired **Routable**, every filter have a public **match(routable)** method returning a boolean value (*True* if the filter +The **Filter** class is extended by child classes to define specific filters which are run by Jasmin router to match a +desired **Routable**, every filter have a public **match(routable)** method returning a boolean value (*True* if the filter matches the given **Routable**). -As explained, filters provide an advanced and customizable method to match for routables and decide which route to consider, the -figure below shows the **Filter** implementations provided by Jasmin, you can extend the **Filter** class and build a new filter +As explained, filters provide an advanced and customizable method to match for routables and decide which route to consider, the +figure below shows the **Filter** implementations provided by Jasmin, you can extend the **Filter** class and build a new filter of your own. -The **usedFor** attribute indicates the filter-route compatibility, as some filters are not suitable for both MO and MT routes like +The **usedFor** attribute indicates the filter-route compatibility, as some filters are not suitable for both MO and MT routes like the examples below: * **UserFilter** and **GroupFilter**: MO Messages are not identified by a user or a group, they are received through a connector @@ -182,20 +186,20 @@ the examples below: .. figure:: /resources/routing/Filter.png :alt: jasmin.routing.Filters.* :align: Center - + jasmin.routing.Filters.* Route ===== -A **Route** class holds one or many filters, the **matchFilters(routable)** method is called to match the given routable against -every filter of the **Route** (using *AND* operation when there's many filters), if the matching succeed, the Jamsin router will ask +A **Route** class holds one or many filters, the **matchFilters(routable)** method is called to match the given routable against +every filter of the **Route** (using *AND* operation when there's many filters), if the matching succeed, the Jamsin router will ask for the **Connector** to consider by calling **getConnector()** method which will return back the **Route** 's connector. .. figure:: /resources/routing/Route.png :alt: jasmin.routing.Routes.* :align: Center - + jasmin.routing.Routes.* Static and default routes are the simplest implemented routes, the difference between them is: @@ -205,7 +209,7 @@ Static and default routes are the simplest implemented routes, the difference be There's a lot of things you can do by extending the **Route** class, here's a bunch of possibilities: -* *Failover route*: Will always return the same connector when it is up, and will fail over/back between master and backup connectors depending on +* *Failover route*: Will always return the same connector when it is up, and will fail over/back between master and backup connectors depending on their status * *Best quality routing*: Implement a connector scoring system to always return the best quality route for a given message @@ -214,8 +218,8 @@ There's a lot of things you can do by extending the **Route** class, here's a bu Multiple connectors ------------------- -When extending **Route** class, it is possible to customize the behavior of the route and that's what **RoundrobinMORoute** and **RoundrobinMTRoute** -do, they are initially provisioned with a set of connectors, and the **getConnector()** method is overloaded to return a random connector from it; +When extending **Route** class, it is possible to customize the behavior of the route and that's what **RoundrobinMORoute** and **RoundrobinMTRoute** +do, they are initially provisioned with a set of connectors, and the **getConnector()** method is overloaded to return a random connector from it; this can be a basic usage of a load balancer route. RoutingTable @@ -228,11 +232,11 @@ The **RoutingTable** class is extended by destination-specific child classes (MO * **getAll()**: Will return all the provisioned routes * **flush()**: Will remove all provisioned routes -The **getRouteFor(routable)** will get the right route to consider for a given routable, this method will iterate through all the provisioned -routes in descendant order to call their respective **matchFilters(routable)** method. +The **getRouteFor(routable)** will get the right route to consider for a given routable, this method will iterate through all the provisioned +routes in descendant order to call their respective **matchFilters(routable)** method. .. figure:: /resources/routing/RoutingTable.png :alt: jasmin.routing.RoutingTables.* :align: Center - - jasmin.routing.RoutingTables.* \ No newline at end of file + + jasmin.routing.RoutingTables.*