> For the complete documentation index, see [llms.txt](https://docs.sealights.io/knowledgebase/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealights.io/knowledgebase/knowledge-base/sealights-for-abap/how-it-works/day-zero-structural-analysis-no-execution-history-required/building-the-dependency-map.md). # Building the Dependency Map ### High-Level Description #### Core Capability The dependency map is the foundation of everything SeaLights for ABAP produces. It connects every ABAP object changed by the cycle's transports to the production-active executables that depend on it — establishing the blast radius of each change before a single test runs. All risk ranking, test recommendations, and gap identification in subsequent steps are built on top of this map. #### Interface Experience and Navigation The dependency map is not directly visible in the UI — it is the internal model that drives the outputs surfaced in the **Change Analysis** tab. The Impacted Executables count is the direct expression of the map's breadth: how many executables have at least one dependency on a changed object. *** ### Business Value & Key Use Cases * **Replacing manual dependency tracing** — Understanding which SAP programs call which functions, which functions use which tables, and which tables changed in a transport is work that would take an experienced SAP architect hours to do by hand. SeaLights produces this map automatically across every object in the transport, at a scope no manual process can match. * **Focusing effort on real risk** — By limiting the map to production-active executables and actually-changed objects, SeaLights filters out the vast majority of the SAP object inventory that is irrelevant to this release. Teams work from a focused picture, not a full object catalog. #### Impact Metrics A typical SAP system contains tens of thousands of ABAP objects. A transport may touch hundreds. Without automated dependency mapping, determining which executables are affected requires manual cross-referencing of usage logs, call hierarchies, and object dependencies — a process prone to omission. The dependency map performs this analysis exhaustively and automatically at cycle creation. *** ### Detailed Functionality #### What Gets Mapped — and What Doesn't The map is deliberately narrow. SeaLights applies two filters: **Only executables in production use** SeaLights reads usage data from SAP metadata tables to identify which executables are actively run in the production system. Executables that exist in the SAP system but have never been used in production are excluded. This keeps the map — and all downstream analysis — focused on real business risk rather than theoretical dependencies in unused code. **Only objects that actually changed** SeaLights reads the object list from the cycle's transports and maps only those objects. Unchanged objects — even those that co-exist in the same transport package or program — are not included. Every entry in the map traces back to a specific change in a specific transport. #### How the Map Is Built SeaLights pulls structural metadata from SAP tables to trace the dependency chain: which executables call or use which objects, across direct and indirect relationships. This is done entirely via metadata — no source code is read or transmitted outside the SAP landscape. The result is a graph: on one side, changed ABAP objects; on the other, the production-active executables that depend on them. A single changed object may connect to many executables. A single executable may depend on many changed objects. Both relationships are captured. #### Why Narrowness Is a Feature A naive dependency map — one that includes all executables, not just production-active ones — would dramatically overstate risk. It would flag programs that exist in the system but are never run, creating a test recommendation list bloated with irrelevant tests and a gap list full of unreachable executables. By constraining the map to what is actually in use, SeaLights ensures that every entry in the Impacted Executables count represents a real business function that a real user or process relies on. The map is smaller — and more actionable — than an unconstrained alternative would be. *** ### FAQ **Q: What types of ABAP dependencies does the map capture?** A: \[Configuration detail pending validation — the specific dependency types traced (function module calls, table accesses, include programs, class method calls, etc.) and the depth of transitive dependency traversal should be confirmed with the engineering team.] **Q: What happens when a changed object has no production-active executables depending on it?** A: The object is still tracked — it appears in the Changed Objects count in the Change Analysis tab. However, because it has no path to a production-active executable, it cannot be linked to any covering test. It will appear in the Test Gaps tab as an uncoverable object until a production usage link is established. **Q: Does the map update if the SAP system's usage patterns change after the cycle is created?** A: No. The dependency map is built at cycle creation using the usage data available at that point. Changes to production usage patterns are reflected in future cycles, not in the current one. **Q: Can the map include custom Z-programs and enhancements alongside standard SAP objects?** A: Yes. The map covers all ABAP objects regardless of whether they are standard SAP or custom — the distinction is not relevant to how dependencies are traced. *** *Part of the* [*Day Zero: Structural Analysis*](https://claude.ai/chat/how-01-day-zero.md) *section | SeaLights for ABAP* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.sealights.io/knowledgebase/knowledge-base/sealights-for-abap/how-it-works/day-zero-structural-analysis-no-execution-history-required/building-the-dependency-map.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.