Broadleaf Microservices
  • v1.0.0-latest-prod

Key Components

TransitionRequestManager

Responsible for managing workflow state transitions. This includes ChangeSummary, ChangeSummaryGroup, and ChangeDeploy state, as well as sending out TransitionRequests to the various other microservices in order to cause them to update the sandbox workflow status of any Trackable under their purview related to the changes.

SandboxService

Manage Sandbox entity instances. Handle basic CRUD operations.

ChangeDeployService

Manage ChangeDeploy entity instances. Handle basic CRUD operations.

ChangeSummaryGroupService

Manage ChangeSummaryGroup entity instances. Handle basic CRUD operations.

ChangeSummaryService

Manage ChangeSummary entity instances. Handle basic CRUD operations.

DefaultSandboxCleanupServices

ClusterService responsible for interval polling of fully defunct, temporary Sandbox instances and converting them into their archived state. Temporary sandboxes are deemed defunct if they’ve reached a final state, i.e. all of the change summaries for the sandbox are either deployed or reverted.

WorkflowRequestCompletionListener

Handle completion messages from resource tier services. The completion messages represent the successful or failed notification of completion in response to a sandbox transition message from the sandbox service. This listener delegates to handlers for each of the various transition types (e.g. PromotionWorkflowRequestCompletionHandler).

Marketplace Vendor Security and Narrowing

If marketplace vendor functionality is enabled, then these components are registered to ensure the various change domains are vendor-discriminated and transition operations from vendor users do not have impact outside of the appropriate restrictions.

ChangeSummary, ChangeSummaryGroup, and ChangeDeploy are not Trackable, and require much more complex filtration behavior than what the standard VendorNarrowingContextInfoCustomizer/VendorVisibilityHandler ecosystem can provide. Thus, the mechanism of narrowing is implemented with completely different components that operate closer to the repository-layer.

JPA components

JpaVendorNarrowingQueryCustomizer

Somewhat analogous to the QueryInfluencer built by VendorNarrowingContextInfoCustomizer - this is the top-level component that repository methods will generally invoke to contribute vendor narrowing criteria to a query.

This delegates to the JpaVendorNarrowingCriteriaManager for entity-specific behavior.

JpaVendorNarrowingCriteriaManager

Somewhat analogous to VendorVisibilityManager - this injects all JpaVendorNarrowingCriteriaHandler implementations and delegates to the appropriate one to build vendor filtration criteria for an entity.

JpaVendorNarrowingCriteriaHandler

Somewhat analogous to VendorVisibilityHandler - this is the main component that should be implemented for each entity in order to support building vendor filtration criteria for it.

Sandboxing Configuration

At the time of this writing, there’s no sandboxable entities in this service. If a sandboxable entity is introduced in this service, the following configurations should be added:

spring:
  cloud:
    stream:
      bindings:
        persistenceOutput:
            triggeredJobEventInputPurgeSandbox:
              group: sandbox-purge-sandbox
              destination: triggeredJobEvent
broadleaf:
   transitionrequest:
     enabled: true
   changesummary:
     notification:
       active: true
   tracking:
     sandbox:
       purge:
         enabled: true

See Sandboxing In Detail for more details.

Note
 These configurations typically only affect the Granular Deployment model. For Min and Balanced deployements, these configurations are likely already added at the flexpackage-level configuration.