Product Development, improvements and enhancements
When Apogee was initially conceived, it was designed to plug into any type of monitoring system, but as anyone familiar with the discipline can attest, all monitoring systems have peculiar quirks and limitations. Moreover, at that time the digital experience monitoring specialisation was nascent and not very well defined or understood in the market. It became clear that we needed to separate the synthetic transaction monitoring from the systems and real user monitoring, and offer this as a complete, independent solution. Work then started on getting a platform ready that would load scheduled tasks, run them against remote devices over a local network connection and display the results in a user-friendly interface. This platform would allow data to be accessed by third party monitoring tools.
The remote device needed to be able to run multiple tasks at the same time. This required a python-threaded model that would allow multiple threads running and querying each modem, which would then publish the results back to the server for processing and display.
The jobrunner daemon is responsible for the interface with the message queue service. It retrieves task data when scheduled by the server, then associates the task with a modem on the device. Once the task has been completed by the modem library, the data for that task is then processed by the jobrunner, geo-location type data is added, and it is then sent to the message queue in a results queue, and then waits to be processed by the server.
Additional features and enhancements
- The initial library from the prototype phase got rewritten to have the serial interface use buffered IO, instead of just writing and reading raw from the serial modem device. This helped in reading line terminators better and improved the overall stability of serial communication.
- The next enhancement was capturing and testing each output after each sequence was completed. This would allow the product to also test and confirm the output received from a USSD response. These responses were then added to the data payload for it to be displayed when an error message occurs. This new feature enabled us to annotate on the UI errors at specific time series events.
- The next feature included accepting an SMS as a final response to a USSD menu sequence. The library was updated with code that would allow decrypting an SMS message from the network.
- The SIM ToolKit (STK) feature set started to evolve after some study of Ublox’s documentation, and experimentation over various mobile networks. The library started to evolve and was included into the standard modem library. This allowed testing of STK SIM menu options, which expanded the channels available for Apogee’s testing from USSD to SMS, STK and mobile TCP/IP.
Large or small: Two options are available for mobile network implementations: one for small deployments or proofs of concept (based on the Intel NUC configuration and two to four modems); and the larger carrier grade unit which we custom developed and manufactured with our local hardware partner (ProVisual Technologies), that contains 8 modem modules.
Ease of deployment is still one of the primary issues we are working on and still actively developing.
Server platform: The server component can be deployed on premise or in the cloud, on physical or virtual hardware. It consists of various services, partly open source and partly created by Breakpoint.
In conclusion
As mentioned, the digital experience for mobile users is rarely monitored adequately, and is especially critical in markets where the majority of consumers rely on their mobile phones as their primary communications and financial tool. Apogee can provide this service. Apogee is channel agnostic and is designed to provide real-time, real service checking of mobile customer experiences across various layers of the mobile service.
Apogee is useful (even necessary) for any business that provides services over mobile or other digital channels such as USSD, mobile applications, STK or SMS.