Cloud-native PDF generation with List & Label Cross Platform at Swiss Life Germany

Company: Swiss Life Germany
Industry: Insurance and financial services
Application area: Sales platform / quote generation
Product: List & Label Cross Platform
Website: https://www.swisslife.de

Initial Situation

We are a leading provider in the insurance industry. We provide customized insurance for life, disability, and long-term care, along with retirement planning and financial advice for both individuals and businesses.

Our sales platform is a central component of our sales processes, through which we generate and output quotes as PDF documents. The quality, performance, and reliability of PDF generation are business-critical.

Capturing pricing-related data within the sales platform is the basis for generating PDFs.

Technical context

The sales platform is part of a complex microservices ecosystem in which rates are calculated via a graphical interface and APIs.

The new PDF generation service will be implemented in C#/.NET, and will use List & Label Cross Platform. It will also be containerized via Docker in a Kubernetes environment. Currently, the service relies on the classic List & Label.

Reporting architecture before List & Label Cross Platform

Our previous reporting architecture was based on a service developed in C++ (“doc-generator”). The central component was a print server that used the classic List & Label to generate PDFs.

PDF generation consisted of several components:

• A layout file (.lst)
• A variable file for defining the List & Label variables
• An XML input file for value assignment

Data was loaded via a custom data provider, and the final PDF was generated using the print function. The system was functionally stable but entirely tied to Windows.

First, the documents are selected and compiled. Then, the PDF file is created.

Trigger for realignment

A key driver of the realignment was the need to modernize our infrastructure. The existing system could not be transferred to a cloud-native environment.

Additionally, we wanted to improve the performance of PDF generation, because it is one of the most time-consuming processes within the platform.

Decision for List & Label Cross Platform

Based on our many years of positive experience with combit and List & Label, we quickly decided to continue relying on this technology.

List & Label Cross Platform offered us the opportunity to transfer the existing reporting logic into a modern, platform-independent architecture while continuing to use a familiar product.

Migration and challenges

Migrating from the classic List & Label to List & Label Cross Platform is not as simple as a conversion step. Automatically converting existing .lst files to the new .json format was insufficient.

Differences in the evaluation logic of conditions, as well as other discrepancies between classic and cross-platform, necessitated manual adjustments to the layout files. This phase requires an in-depth analysis of existing reports and targeted adjustments to the logic.

Final quotation document (PDF), generated using List & Label Cross Platform.

Initial assessment of benefits

There are currently no long-term evaluations available. However, we expect the following:

• Noticeable performance improvements in PDF generation
• Easier debugging
• Simplified deployment through full integration into our Kubernetes environment

Support experience

Our experience with combit support has been consistently positive.

Any questions or bugs that arose during the migration were resolved quickly and successfully. combit responded promptly to reported issues, providing new versions at short notice that fixed the respective issues.

Communication via the support center was always professional, direct, and solution-oriented.

Roadmap

Our roadmap calls for a full migration to the cross-platform version of List & Label. The goal is to replace the existing classic system entirely.

The new cross-platform service is designed to provide a full range of PDF generation capabilities and operate reliably and efficiently within a Kubernetes cluster.

Conclusion