Supply-chain impact graph

Problem and backend

This example traces orders, routes, parts, and dependency cycles across a supply network. It uses TinkerGraph to isolate modeling from container and network variance. Read core model and TinkerPop first; use the selection guide before production.

Model

• Nodes: Supplier/Part/Warehouse/Route/Carrier/CustomerOrder
• Edges: SUPPLIES/REQUIRED_BY/STOCKED_AT/USES_ROUTE/DELIVERS_TO/OPERATES_ROUTE/ALTERNATE_PART
• Key properties: supplierId, partId, routeId, carrierId, orderId, criticality, status

Prerequisites and release boundary

Use JDK 21, commit 3e0fa7cb9e3bc70c2743aeebda2487f3e45e4907, and the checked-in wrapper. Examples are not published; run this release fixture as a Gradle project from the release source checkout. In a consumer application, select only bluetape4k-dependencies:<ecosystem-version> and add the required graph module without an individual version.

Run and observe

./gradlew :supply-chain-graph-examples:test --tests "io.bluetape4k.graph.examples.supplychain.TinkerGraphSupplyChainImpactTest"

The tests assert visibility of order-1001, route-air-express, and gps-module, and detect the battery dependency cycle. A failure points to a missing supply relation, reversed dependency, or cycle-detection boundary.

Reading order

1. Schema
2. Service
3. Shared executable contract
4. Concrete TinkerGraph test
5. Build file

Continue from data-lineage, then read ktor-graph. Also see paired APIs, testing, and operations.

Exercises and production gaps

Add one result-changing edge and assertion; repeat through the suspend API; then run a persistent-backend concrete test serially. Add disconnected and malformed inputs as diagnostics. This fixture does not prove throughput, clustering, authorization, tenant isolation, migration, backup, remote-driver timeout, or index quality.