Case Study: Automated Multi-Operator Report Delivery Pipeline
Handling different operator formats within one controlled reporting workflow
The client needed to deliver daily performance and configuration reports to multiple mobile network operators. Each recipient had its own data format and delivery model. One collected GPG-encrypted reports from the client's SFTP service. Another required unencrypted reports to be uploaded to its own SFTP service. We built a production reporting pipeline that preserved those differences while sharing data retrieval, failure handling, and operational controls.
Reporting requirements differed by operator
The client provides shared indoor 4G and 5G infrastructure for several mobile network operators. The reporting requirement covered cell-level performance and configuration data, but there was no single output specification. Column order, quality-of-service mappings, aggregation levels, and the required 4G or 5G data varied by operator.
Delivery was part of the requirement, not a separate hand-off. For one operator, the pipeline had to encrypt the CSV with the recipient's GPG public key and publish it to an isolated directory on the client's SFTP service. For another, it had to upload the unencrypted CSV to the operator's SFTP service.
Failures in report generation or delivery had to be visible to operations staff, who also needed a way to rerun the affected work. The client also needed a fortnightly spreadsheet for internal network-health review.
The workflow needed recipient-specific outputs and delivery models
- Operator-specific transformations had to apply the correct CSV columns, quality-of-service labels, and aggregation rules without duplicating the underlying data-access logic.
- Reports collected from the client's SFTP service had to be GPG-encrypted and published to an isolated directory for the intended operator.
- Reports sent to the other operator had to remain unencrypted and be uploaded to that operator's SFTP service.
- The two delivery paths and their connection settings had to remain separate so an output could not be published or uploaded through the wrong route.
- Authorised operations staff needed a manual rerun facility rather than having to wait for the next scheduled execution.
- A fortnightly XLSX report was also required to present 4G and 5G cell health across a database-driven list of sites.
A scheduled pipeline with separate transformation and delivery stages
We built the report scheduler and generators in TypeScript. A shared query layer retrieved performance data from Sybase through PostgreSQL foreign tables, while separate modules transformed it into each operator's required CSV structure. This kept common retrieval logic in one place while preserving the differences each recipient required. CSV output was streamed so large result sets did not have to be assembled entirely in memory.
The delivery stage followed the requirements for each recipient. For the operator that collected reports, it encrypted the output with the appropriate GPG public key and published the result to that operator's isolated directory on the client's SFTP service. For the other operator, it uploaded the unencrypted output to the operator's own SFTP service.
Generation and delivery errors were logged, with email notifications and manual reruns available to authorised staff when intervention was required.
The same scheduling layer also generated a fortnightly XLSX health report. Site selection was moved into database queries, and the spreadsheet combined 4G and 5G cell status for email distribution. Where 5G configuration attributes were not available from the reporting database, the pipeline retrieved them through the network-management platform's API client.
A production workflow designed for failures as well as scheduled runs
The pipeline runs routinely in production. Daily jobs coordinate data retrieval, operator-specific CSV generation, conditional GPG encryption, publication for collection, and outbound SFTP upload. Each operator's delivery sequence is handled as part of the scheduled workflow rather than ending when a report file has been produced.
Email alerts expose failed jobs, and the rerun control lets staff repeat the affected report generation or delivery.
Shared query logic reduces duplication, while separate transformation modules preserve the differences that matter to each operator. Format changes remain contained within the relevant module, although changes to source data or report behaviour can still require engineering work.
The pipeline was refined as reporting requirements changed
The implementation evolved over more than ten months. A screenshot-based PDF health report was replaced with a native XLSX workbook that was easier to inspect as structured data. Site lists moved from configuration files to database queries. SFTP delivery gained error reporting and manual rerun controls, while 5G configuration data was added through the network-management platform's API. These changes kept maintenance close to the systems that owned the underlying data and gave operations staff direct visibility into failures in scheduled work, with controls to rerun the affected work.
Related case studies:
- Network Performance Dashboards and Reporting over Sybase Data explains the shared PostgreSQL access layer over Sybase.
- Operational 4G/5G Cell Management covers the production interface and API client used for cell operations and later reused for configuration reporting.
Client names and identifying details have been withheld to protect confidentiality.
Need a reporting workflow across several recipients?
Tell us what needs to be generated, transformed, and delivered.
