SEP - Electronic Request Processing

Design and development of a complex process platform that covers dozens of request types for a distribution company, automates their processing across both internal and external systems, and provides full process and data traceability.

The brief

The request agenda was fragmented across several partial solutions and manual steps. Each type of request has its own behavior – different notifications, statements, resolver teams, state model, deadlines, validations and dependencies on surrounding systems. The client needed a single platform that would:

• support the processing of N different request types over a shared data structure,
• allow each type to have its own configuration of process, states, deadlines, statements and assignment rules,
• orchestrate communication with third-party systems (creating and updating entities in SAP, GIS and others),
• provide operational reporting and a complete history of activities for each request,
• and remain extensible with new request types over the long term without touching the core.

The solution

We designed and built SEP – a server-side process platform that acts as a single reliable place for the entire request lifecycle. At its heart is a configuration and process model that separates what should be done from how it is done:

• Request type configuration – notification and statement templates, validation logic, deadline/calendar type, available actions (in which state, for which role, with what effect: approval/rejection, requesting a statement, supervisor review), resolver assignment rules and a state model with transitions.
• BPMN processes – each request type is modelled in Camunda and assembled from existing reusable tasks; only new, specific logic is programmed. The platform currently contains over 140 BPMN processes across more than 20 domains (connections, installation lists, production processes, e-shop services, deadline schedules, cancellations and more).
• Orchestration agent – manages the conversation with third-party systems: it translates synchronous/asynchronous communication, handles retries of failed tasks, timeouts and a maximum number of attempts, so that manual operator intervention is eliminated.

Integrations

SEP both exposes and consumes REST APIs and communicates with the surrounding ZSDIS ecosystem:

• SAP via SAP PO (SOAP/REST translation, both synchronous and asynchronous communication),
• Active Directory (LDAP) for authentication, roles and organizational structure,
• Document storage – the IXOS content server for document archiving,
• GIS, pricing services, e-shop, manufacturers, delivery points and other internal interfaces,
• SMTP for notifications and generated statements.

Traceability and reporting

The platform records the history of activities for every request and provides a data foundation for reporting – the data content of requests together with processing data (states, times, rejection reasons, deadline compliance). It includes operational daily reporting of error states, which flags failed orchestrations before they become visible externally.

Architecture and operations

We also addressed the demanding engineering details that determine the reliability of a process platform in production:

• Synchronization of two databases (the domain and process databases) – transaction consistency, asynchronous continuations and checkpoints set directly in the BPMN model.
• Process versioning – with every deployment we automatically migrate running instances to the latest process version using our own migrator; non-migratable cases are handled in a controlled way.
• Self-healing processing – a job periodically finds and retries failed tasks, removing the need for manual intervention via Cockpit.
• History retention – active process data is kept only briefly and the complete history is moved to the domain database, queryable via API, saving both memory and performance.

Deployment and monitoring

The platform runs on OpenShift across 4 environments (DEV, TEST, STAGING, PROD) with rolling deployment and readiness and liveness probes. The delivery includes a Dockerfile, OpenShift deployment descriptors and a GitLab CI pipeline. Monitoring is provided by Spring Boot Actuator with metrics in Prometheus/Grafana (including Camunda metrics) and centralized logging via ELK.

Benefits

• One platform instead of a fragmented agenda – more than 20 process domains and 140+ executable processes covered by a shared data and configuration model.
• Extensibility without touching the core – a new request type is created mostly through configuration and by assembling a process from existing tasks, not by rewriting the application.
• Automation of cross-system communication – the orchestration agent and self-healing processing of failed tasks have significantly reduced the need for manual intervention.
• Full traceability – a history of activities, states and deadlines for every request as a basis for both operational and managerial reporting.
• Long-term operation – the solution has been in production and continuously evolving since 2022, confirming the sustainability of the chosen architecture.