Syncing external apps

If your system is using various Add-on Mart modules, our team will identify those during the pre-migration analysis stage, and we will create additional test scenarios to validate that those modules work properly in the Dual Version mode.

The API methods in Dual Version PortaSwitch can support a few different execution modes:

1. Transparent access to both systems

In this mode, no additional actions are required to access either the current (source) or the new (target) system.

The applications that use API with customer or account credentials don’t require any changes, as the customer or account can be active only on one system at a time. Upon authentication, WebDispatcher (a component of the dispatching SBC that serves as a single API entry point for both the source and the target system) detects whether the corresponding customer record is on the source or on the target system and sends all subsequent requests there.

2. Semi-transparent access to both systems

This mode means that billing entity location (also referred to as “context”) detection is partially automated. Let’s see how it works:

• If an application such as theCRM system uses an API with admin credentials, e.g., runs API methods such as get_customer_info or update_account, the corresponding API request will contain the i_customer or i_account value. The WebDispatcher will automatically detect the location of the entity, and the request will be executed on the corresponding system.
• However, let’s say your external sign-up portal creates a new customer. In this case, WebDispatcher won’t know on which system this customer should be created. Thus, your sign-up portal should explicitly call the session.set_session_context API method with the specified “context” according to your needs.
• If the system can’t determine the billing entity location for some reason, e.g., the sign-up portal doesn’t call the session.set_session_context API method, the requests will be forwarded to the target system by default.

3. Method of explicitly setting the billing entity location

This mode is used in cases when you need to get some data, e.g., the list of all CDRs, from the specific system (either source or target). In this case, the billing entity location (“context”) should be set explicitly.

• You can do this by using the values “source” or “target” in the API request.
• Remember that the “context” is the property of the session, so in case you want to be able to use it, you have to first use the session.login API method to obtain the session_id field and pass it in the auth_info parameter of all subsequent API requests.
• Once the context is set – it is retained for all further operations unless you explicitly change it.
• If you do want to change it, this can be done either by executing a session.set_session_context API request or by executing any other API method that includes i_customer or i_account, for example, update_customer (e.g., if the context is “source,” and the customer is already on the target system, the context will be changed to “target” after running this method).

When the Dual Version migration is finished, the source system can be decommissioned. You will not need to make any changes to your external applications, so long as they have been built according to PortaOne recommendations.

This also means that when you decide to proceed with your next Dual Version migration, your external application will not require another adaptation for the Dual Version migration.