The integration with IXC is done using IXC's public API and will work both by sending information from IXC to OZmap and vice versa.


Features


  •  Boxes (Initial synchronization is done by name, later by ID).    
    • OZmap Boxes Synchronization -> IXC
  • Connections (Synchronization is done using login)
    • Power synchronization client IXC -> OZmap
    • Automatic client activation based on contract status IXC -> OZmap
    • Client status synchronization IXC -> OZmap
    • Client and reservation cancellation IXC -> OZmap
    • Automatic client creation IXC -> OZmap
    • Client Coordinates Update OZmap -> IXC
  • Client Name: The connections now fetch the client's name registered in the ERP and update it in OZmap, disregarding any changes made to it in OZmap.
  • Condominiums: Ability to synchronize a condominium's splitter from OZmap -> IXC, treating each splitter as a box within the ERP.

Synchronization OZmap -> IXC


Boxes

The synchronization of boxes is based on the last update attribute of the boxes. All boxes with updates after the last synchronization cycle are retrieved. By default, this synchronization occurs every 5 minutes.

  • Creation
    • Updated Boxes: All boxes that are not "in project" and have been updated after the last synchronized box's update date are retrieved.
    • Service: From these boxes, only those with service (drop) splitters are filtered to identify that the box is for service.
    • Project: The box's project is retrieved from IXC to ensure it is added to the correct project. This search is done using the project name the box is assigned to in OZmap.
      • Example: Box 1 is in OZmap under the project "Chicago." Before being imported into IXC, the integration searches for a project named "Chicago" to find its ID and associate the box with the correct project.
    • Transmitter: The "transmitter" is retrieved from OZmap, meaning the device that serves the first service splitter of the box. The integration then searches for an OLT in IXC with the device IP found in OZmap.
      • Example: BOX 1 is in OZmap, and its transmitter is the OLT-Fiberhome-3, which has IP: 127.0.0.1. The integration then searches in IXC for an OLT with IP 127.0.0.1.
      • If the OLT is found, the box is created with the correct transmitter, ready for future activation operations.
      • If the OLT is not found, by default, the box is not imported. However, if desired, we have a configuration that can be changed to allow this creation without a connection.
    • Name + Project: A box with the same name in the same project is then searched for, to verify if it already existed before integration. If found, this box is linked in the integration to the box in OZmap, and from that point forward, they are recognized solely by their ID.
    • Local Database: After creation, a record linking ID_OZmap and ID_IXC is created in the integrator's local database. This record is used to verify if the box has already been created in IXC. In such cases, only an UPDATE is performed.
  • Update
    • If a record already exists in the local database with the ID of the box to be imported, an UPDATE is performed on the data by fetching all the information again (as if creating a new box).
    • The following are updated: Description, project, transmitter, latitude, longitude, comments, and capacity.
  • Removal
    • For each box removed in OZmap, a validation is performed to check if it exists in IXC. If it does, the box's status is updated to "I" (inactive)

Condominiums


Condominium/building synchronization consists of creating boxes in IXC for each splitter present within a condominium

  • Each condominium in OZmap is "opened," and the number of splitters within it is identified. Each of these splitters is translated into IXC as a box with N available ports. Currently, only splitters are sent to IXC;
  • After creation, condominiums are always identified by their name, unlike boxes, which can also be identified by their geographic position;
  • Updating client ports within condominiums and synchronizing client data are handled the same way as clients in boxes.

Port/Box Update


  • The port update consists of identifying that a client has been moved to a different box/port in OZmap and replicating this update to the ERP (IXCSoft);
  • The "Login" of the connections in IXC is used to identify the clients in both software systems;
  • Clients are only updated if the box they were moved to is already created in the ERP and recognized by both software systems;
  • Only clients of type Fiber ("F") and those that are Active ("A") are updated.


Client Coordinates Update


The coordinate update process involves updating the IXC client’s coordinates based on OZmap readings. This process works as follows:

  • A reading is performed for all IXC clients who have a fiber connection type (connection_type_map = "f") and an active login status;
  • The integration searches for clients in OZmap with a code matching the IXC login attribute;
  • The integration compares the latitude and longitude values registered in the IXC login with the latitude and longitude of the client’s property in OZmap. If there is any discrepancy, the IXC data will be updated according to the information in OZmap.

IXC → OZmap Synchronization


Client Creation


The automatic creation of a client in OZmap involves identifying that a client exists in IXC but not in OZmap and creating them in the box indicated in the ERP.

  • The "Login" of the connections in IXC is used to identify clients in both software systems;
  • Clients are only created if the box they are assigned to in the ERP exists in OZmap and is recognized by both software systems;
  • Only Fiber-type ("F") clients are created;
  • If the ERP contains port information, it is used when creating the client in OZmap. If this information is not available, a configuration can be used to create the client on the first available port in the box.


Client Activation


The automatic client activation involves identifying that the client’s contract is active in IXC (implanted) and sending this information to OZmap

  • The "Login" of the connections in IXC is used to identify clients in both software systems;
  • Only Fiber-type ("F") clients with an Active ("A") contract status are updated.


Client Cancellation


Client cancellation is done in two ways: clients who requested internet and canceled, and clients who were already active and canceled. All connections are found in the systems using the Login.

  • Withdrawal
    • All inactive logins with a withdrawal contract are searched;
    • The client/property/drop created in OZmap for reservation purposes is removed from the system.
  • Cancellation
    • All inactive logins without a contract are searched;
    • The client is removed from the property;
    • The last connection (splitter/port) of the client, along with its code, is added to the property that remains in the system;
    • The drop is disconnected from the splitter port (Configurable).


Status and Power Synchronization


The Status synchronization is based on the client’s Login. The "radusuarios" table has a login attribute that identifies the client’s connection, and this value should match the "code" field of the client in OZmap.

  • Logins
    • All Logins with Active ("A") status and Fiber ("F") technology are searched from IXC;
    • All contracts with Active ("A") status and a valid login (previously retrieved) are searched from IXC. For each login, the status in OZmap is updated based on the "online" attribute.


Required Data


To activate the integration, the following data must be provided to the OZmap team:

  • IXC URL;
  • API Access Key for IXC.