Enabling applications to function within the two-system setup

Let’s take a closer look at the mechanism responsible for providing the correct customer data while using the “old” familiar front-end portal (keeping the same URL as before).

This is made possible by the WebDispatcher – a component that serves as a single entry point for API requests, distributing them between the source and the target systems.

For example, when a customer self-care portal (the built-in self-care UI, the CloudPBX Self-Care Portal or other) sends an API request to Dual Version PortaSwitch, the WebDispatcher receives it, determines the current location of the customer record, directs the request to the corresponding system, and returns the result. For self-care portals and other applications that function on behalf of a customer or account (so they use the customer or account API) this process is transparent for the front-end and no changes are required on the portal side.

Similarly, when the PortaBilling admin UI of the target system sends an API request to retrieve the customer list, the WebDispatcher executes this request on both systems, consolidating the results into a unified list.

WebDispatcher is a part of the DSBC (dispatching session border controller). It is deployed on the target system and accessible via a single virtual IP (VIP) address.

WebDispatcher handles requests from applications that use:

• PortaBilling API – accessible under various realms, such as Admin, Reseller, Customer, Account, CC Staff, Distributor, or Representative.
• PortaSIP API – for configuring features such as auto-attendant, conferencing, and voicemail
• CallControl API – for managing and monitoring calls

To see how exactly the WebDispatcher distributes the requests between the source and the target systems when a customer opens their self-care interface, let’s consider the following example.

Say “Owl Telecom” is a service provider planning a Dual Version migration from MR100 to MR115. They use the default customer self-care interface that comes with PortaSwitch.

Let’s see how it works before Dual Version is deployed and provisioned:

• A customer, John Doe, accesses his self-care web interface via the URL www.customer.billing.com, associated with the IP address, 1.1.1.1.
• This IP address belongs to the source system (the only one that exists before the DV migration starts).

Here’s what happens once Dual Version is deployed and provisioned:

• WebDispatcher takes over the IP address 1.1.1.1, previously assigned to the source system
• The source system is assigned a new IP address, 1.1.1.2, while the target system receives the IP address 1.1.1.3.
• The domain names for the customer self-care interface on both the source and target system get temporary prefixes in the format “{system’s release version}-“.

  For instance:

  • Source system (MR100) – www.100-customer.billing.com
  • Target system (MR115) – www.115-customer.billing.com

As a result, when John Doe opens his “old” familiar URL www.customer.billing.com, (associated with IP 1.1.1.1), he now connects to the WebDispatcher. The WebDispatcher then automatically directs the customer to the login page of the target system. Upon entering his credentials, John logs in to the web UI of either the target or source system, depending on the location of his corresponding customer record. The process unfolds as follows:

1. The web UI sends a “session.login” API request to the WebDispatcher.
2. If the customer record is active on the target system, the authentication occurs there and the target system creates an API session for the customer to log in.

   Alternatively, if the customer record is not found on the target system (customer is not yet migrated), the request is forwarded to the source system (www.100-customer.billing.com) where the customer is authenticated:

   • The source system creates an API session.
   • The target system receives this session ID and generates a session cookie with the value “authorized-by-remote” to indicate (”remember”) the customer’s record location on the source system for processing subsequent API and web requests within this session.
   • The target system sends the response to the WebDispatcher.
3. Next, the WebDispatcher relays the response regarding the customer’s authentication from the target system to the self-care web interface, enabling the customer to successfully log in.

Subsequent customer actions, like opening an invoice, trigger more API requests from the web application to the WebDispatcher. The WebDispatcher checks for the “authorized-by-remote” session cookie and directs the requests to the corresponding system.

With the WebDispatcher mechanism, external portals (Cloud PBX or others provided by PortaOne or developed by the service provider on their side) can operate with two systems in parallel, similarly to built-in self-care interfaces.

However, since the portals communicate with PortaSwitch via the API only, the web UI displayed for customers solely relies on the portal version and does not automatically adapt based on the location of the customer’s record.

For instance, when customers open their “old” familiar URL, they all see the “old” familiar portal UI. In the backend, their data is retrieved from the source system or from the target system if a customer has already migrated.

Service providers usually launch a new version of the self-care portal in parallel with the old one and let small groups of customers test the new version. This way, service providers can fully leverage the benefits of the Dual Version system, enabling them to locate any problems and fix them without disruptions to the main customer base. Later on, when most of the customers have been migrated to the target system, service providers may encourage the customers to switch to the new portal, e.g., send them an email with the new portal URL. Eventually, when migration has been completed, service providers can just redirect the URL of the “old” portal to the new one (in the domain settings). The new portal can potentially be used by customers, who still reside on the source system (old version), with the WebDispatcher transparently providing the required data from the source system on the backend. However, in this case, some of the new portal features may be incompatible with the old system, leading to errors.

Say a service provider “Owl Telecom” offers their customers the CloudPBX Self-Care Portal. The portal:

• Is accessible for customers via the URL www.cloud.pbx.com
• Is connected to PortaSwitch via the “Retail API URL” www.customer.billing.com (its IP address is 1.1.1.1)

When Dual Version is deployed and provisioned, the WebDispatcher takes over the IP address 1.1.1.1, connecting the portal to PortaSwitch via the WebDispatcher.

Let’s see what happens when the customer accesses the portal via their “old” familiar URL www.cloud.pbx.com:

1. The portal initiates a “session.login” API request, sending it to www.customer.billing.com which now directs to the WebDispatcher.
2. The WebDispatcher receives the request and forwards it to the target system.
3. If the customer record is active on the target system, the target system processes the request and returns the response to the WebDispatcher.

   Alternatively, if the customer record is not found on the target system (indicating that the customer has not yet migrated), the target system initiates the “session.login” API request to the source system, processes the response and returns it to the WebDispatcher.

   The established API session includes the parameter indicating the system where the customer was authenticated (either the source or the target system) for subsequent API requests.

4. The WebDispatcher then returns the response to the portal, allowing the customer to log in.

After the login, subsequent customer actions, like activating an add-on, trigger additional API requests from the portal to the WebDispatcher. The WebDispatcher forwards these requests to the target system, which identifies the ongoing API session along with information on the system where this session is established. The API request is subsequently processed on the corresponding system.