Subcomponents

Overview

A subcomponent represents a resource whose lifecycle is tied to a parent component, such as an output port, a workload, a data contract, etc. It is deployed as part of its parent's deployment, rather than through a separate deployment lifecycle.

This relationship is useful when several resources form one operational unit. For example, a storage component can contain several tables represented as subcomponents. The tables remain distinct resources, but their lifecycle is managed together with the storage component. A resource that needs an independently managed lifecycle should instead be represented as a separate component.

Builder structure

Subcomponents are not standalone Witboost entities. They are defined within the parent component and included as nested resources in its generated descriptor.

In the Builder, the parent component's catalog information and the project's generated descriptor in Edit and Test provide the context for these nested resources. The Subcomponents reference describes their definition and configuration for when defining their structure. As an example, you can see how to leverage subcomponents to define a data contract here.

Marketplace

The Marketplace presents published data for consumers, rather than mirroring the Builder's entity structure. A subcomponent can therefore be exposed as a consumable within a published product without becoming a standalone entity on the Builder. For this reason, it is possible to expose subcomponent as standalone consumables in the Marketplace by flagging them as consumables.

Only subcomponents marked as consumable are exposed for consumption. A parent component that is not itself consumable can still appear as a group of consumables when it contains consumable subcomponents. For example, consumers may discover the tables exposed by a storage component even when the storage component itself does not expose data directly.

Being consumable describes whether a resource exposes data for use; while being shoppable determines whether consumers can request access through the Marketplace. These roles are distinct from the shared deployment lifecycle. The Shoppable and Consumable attributes explanation covers Marketplace grouping and access-request behavior in detail.