This article is provided solely as a professional case study of the engineering approaches, architecture patterns, technologies, and lessons learned through this work. Only information appropriate for public disclosure is presented, including publicly available, open-source, generalized, or otherwise authorized material. No proprietary source code, credentials, confidential business information, internal system details, or other restricted information is included.
The notes below focus on the problems that led to each application, some of the implementation choices made along the way, and components that may be useful in other projects. SAP product names identify the systems and APIs involved; the application logic, workflows, analysis, visualization, and automation described here were developed around those integration points.
FROM OPERATIONAL PROBLEMS TO RUNNING SOFTWARE
Most of these applications started fairly simply: a review that took too long, useful data spread across systems, a repetitive browser process, analysis that required a lot of manual interpretation, or an enterprise API that exposed information without necessarily providing the workflow a team needed around it. I’ve had the opportunity to work through those challenges over time, and several of the resulting utilities have grown into applications that now support day-to-day enterprise workflows.
The ChaRM and CAB tooling grew from the need to make change records, approval state, system context, risk signals, implementation dates, and review information easier to work with in one place. Much of the challenge was simply making information already available in enterprise systems more practical to scan, filter, export, and use during review.
BPCA Summary Writer, Relative Impact Map, NAVI-related analysis, and pre/post-import review tools came from recurring questions around change impact and regression evidence. They bring together dependency relationships, object-focused analysis, comparison logic, and reporting so that technical evidence can be easier for a reviewer to interpret while leaving the actual decision with the people responsible for it.
Working with SAP Cloud ALM also created opportunities to build smaller views around its authenticated APIs. These applications keep Cloud ALM as the authoritative source while presenting project, feature, task, release, and status information in forms that are a little easier to use for particular operational workflows.
Short-dump assistance and related diagnostic utilities started as ways to reduce some of the repetitive context gathering that happens before analysis can really begin. They organize technical evidence and surface useful signals, while keeping the engineer or reviewer responsible for interpreting the result.
Python App Studio, PythonTestCockpit, and the related deployment tooling grew from experimenting with how small Python utilities could remain easy to create while still having a reasonable path through checking, review, packaging, and installation. The goal has been to add enough structure for enterprise use without taking away the lightweight nature that makes these utilities useful.
WebFlow Studio grew from exploring a simpler way to build and maintain repeatable browser processes. It is now a functioning automation workbench with recording, reusable objects, variables and data, replay, execution, diagnostics, and a hybrid local runtime, while still keeping individual workflows understandable and editable.
Engenie and the guided-tour framework came from looking for better ways to provide help inside the applications themselves. The current implementation can use loaded operational data as authoritative context, walk users through application functions, and connect to richer AI assistance while keeping operational facts grounded in the underlying systems.
Several of these applications have progressed from small utilities into deployed tools supporting day-to-day workflows. Getting them there has provided useful experience with Cloud Foundry deployment, routing and authentication, destinations, connectivity services, APIs, persistence, role-aware behavior, local fallbacks where appropriate, and the environment-specific configuration that comes with enterprise operation.
The overall pattern is a Python/Flask control and analysis layer, a browser-facing UI, and governed adapters to SAP services. Each subtool can remain small and focused while sharing authentication, navigation, persistence, export, and deployment patterns.
These are examples of the inner applications and the kinds of functions they contain. Several can run independently; the shared shell simply gives them a common navigation and deployment surface.
Loads change-governance data through OData or structured file fallbacks, normalizes fields, supports browser-side review and exports CSV/XLSX.
Reusable pieces: OData adapters, table normalization, editable review state, export pipelines.
Reads Cloud ALM feature and transport context, resolves project/release labels, and presents sortable operational views.
Reusable pieces: REST/OData client patterns, token handling, caching, resilient label resolution.
Accepts ST22 HTML exports and turns them into structured findings with HTML, PDF, and JSON output.
Reusable pieces: BeautifulSoup parsing, rule/knowledge packs, ReportLab PDF generation.
Processes BPCA intersection data, groups change impact, adds chronology/dependency context, and produces readable summaries.
Reusable pieces: pandas analysis, XLSX parsing, classification rules, visualization and report export.
Builds transport-to-object relationship maps, identifies shared objects, and supports search/refocus across dependency hops.
Reusable pieces: graph-shaped data, deduplication, client-side filtering, interactive relationship exploration.
Analyzes object lists and optional catalogs to surface findings and create HTML/PDF/JSON reports.
Reusable pieces: parsers, scoring, mappings, lightweight persistence, structured exporters.
Transforms CTS-style queue data into an ordered operational view and can simulate import progress for training/demo purposes.
Reusable pieces: legacy HTML/XLS parsing, sequence preservation, queue-state normalization, animated UI state.
Reconciles pre-import change plans against post-import history and highlights warnings, errors, missing imports, and exceptions.
Reusable pieces: workbook correlation, reconciliation rules, evidence expansion, owner-facing Excel reporting.
Reviews Python application packages before governed publishing or deployment and returns structured code findings.
Reusable pieces: ZIP/repository inspection, policy gates, static Python analysis, HTML/JSON findings.
A controlled single-file Python workspace with run/test, managed files, review workflow, restricted execution, notebook-style practice, and approved data services.
Reusable pieces: sandboxed execution, allow-listed imports, retention controls, publish/review lifecycle.
Guides approved Python packages through deployment checks and SAP BTP packaging expectations before creating a deployable artifact.
Reusable pieces: descriptor validation, readiness gates, packaging checks, repeatable deployment guidance.
Web-focused automation built around recording, object repositories, replay, data-driven execution, scheduling, audit, and an outbound-only local Chromium client.
Reusable pieces: Playwright, HMAC-signed client tasks, resilient selectors, audit trails, local/hosted runtime split.
A contextual help layer that can understand application manifests, launch guided procedures, and point users toward relevant tools or SAP references.
Reusable pieces: application manifests, guided-tour metadata, contextual state, provider-neutral assistant adapters.
Turns roadmap workbooks into interactive owner/status/lifecycle views with editable stages and standalone exports.
Reusable pieces: openpyxl/XlsxWriter workflows, client-side visualization, structured timeline modeling.
Where cloud-to-on-premise access is unavailable, a small governed local service can retrieve data and return only the required result.
Reusable pieces: bounded local agents, encrypted configuration, job leasing, controlled fallback behavior.
| Technology | Role in the tools | Typical use |
|---|---|---|
| Python 3 | Primary application and analysis language. | Parsing, APIs, rules, automation, reports, data transformation. |
| Flask | Small web-service and server-rendered application layer. | Routes, uploads, exports, health endpoints, internal APIs. |
| pandas | Tabular normalization and analysis. | BPCA intersections, change datasets, reconciliation, filtering, aggregation. |
| openpyxl / XlsxWriter | Read and generate Excel workbooks. | Operational inputs, owner-facing reports, styled exports. |
| BeautifulSoup | HTML parsing. | ST22 exports and legacy HTML tables where an API is unavailable. |
| ReportLab | PDF generation. | Portable analysis reports and structured output. |
| matplotlib | Server-side chart generation where static graphics are useful. | Report visuals and analysis output. |
| requests | HTTP client layer. | SAP Cloud ALM APIs, OData endpoints, service-to-service calls. |
| PyJWT | JWT parsing/validation support. | Identity and authorization integration patterns. |
| boto3 | S3-compatible object persistence. | Durable application state and artifacts on supported object stores. |
| Playwright | Controlled Chromium recording and execution. | Web automation, replay, screenshots, synthetic checks. |
| psutil | Scoped local process management. | Cleaning up recorder/execution-owned Chromium processes safely. |
| JavaScript / HTML / CSS | Interactive user interface layer. | Tables, filters, layout persistence, drag/resize, guided tours, graph interactions. |
For Cloud Foundry deployment, the useful pattern is to keep runtime configuration in SAP BTP services rather than source code. A typical setup combines a Python backend, SAP Application Router, XSUAA, Destination service, Connectivity service when on-premise access is needed, and Object Store where persistence is required.
Use the router as the browser entry point, authenticate the user, and forward the authenticated request to the backend. Role checks should also be enforced server-side.
Keep backend endpoints and connection metadata in governed destinations. For private-network SAP systems, pair an OnPremise destination with SAP Connectivity service and Cloud Connector.
Describe modules, resources, bindings, and dependencies in mta.yaml, then build a repeatable MTAR instead of hand-configuring each deployment.
Consume published APIs through a narrow adapter layer so application code works with logical objects rather than embedding tenant-specific details throughout the UI.
Use shared object storage for durable state and keep transient uploads in memory where there is no reason to retain them.
Keep browser execution on an approved local client when the target application is inside a private network. Pair the client outbound-only and exchange signed task envelopes rather than creating a generic tunnel.
These SAP Help Portal references cover the platform pieces used by this architecture. They are preferable to copying environment-specific setup values into project documentation.
For smaller Python utilities and older experiments, the public workbench contains examples of SAP automation, RFC data access, reporting, and operational tooling. Think Like Python covers the progression from ABAP-oriented thinking into Python, Flask, SAP APIs and cloud deployment.
The site assistant can help point to the relevant project, library, or SAP integration topic.