Resources are categorized into Global Resources and Application Resources. Each type of resource has unique characteristics that determine its usage, dependencies, and how it’s promoted between environments. Understanding these differences is crucial for efficient application development, management, and deployment.
Global Resources are elements designed to be reused across multiple applications or business contexts. These resources are often organized within libraries, enabling consistency and efficiency by providing a central repository of shared components.
Reusability: Global Resources are created with the intention of reuse. They include common design elements, themes, fonts, and other assets that can be referenced by multiple applications.
Dependency Rules: Libraries, which store Global Resources, cannot have dependencies on other libraries or applications. This ensures that Global Resources remain standalone, maximizing their adaptability across various business cases.
Application Independence: These resources are not application-specific, making them versatile for broad use cases. Applications can reference libraries without requiring modifications to the core resources.
Promotion Workflow: Global Resources within libraries are promoted separately from applications. They are typically imported into the Designer UI in target environments as part of their own libraries.
Configuration Management: When libraries are promoted, existing configurations, such as generic parameters, are replaced by application-level configurations in the target environment.
Application Resources are resources specific to a particular business use case. Unlike Global Resources, these resources are confined to the context of the application they belong to, allowing for tailored configurations and dependencies on one or more libraries.
Business Specificity: Application Resources are tailored to a specific application, addressing unique business requirements.
Dependencies on Libraries: Applications can reference libraries to access Global Resources, allowing for customization and adaptability.
Configurability: Application-specific configurations are defined at the development stage, and values can be updated as needed in upper environments through environment variables or direct parameter overrides.
Processes: Defined BPMN workflows specific to the application’s business logic.
CMS Components: Custom CMS enumerations, substitution tags, and media items unique to the application.
Task Management:
Views: Configurable interfaces to display task-related data based on process definitions.
Hooks: Users with task management permissions can create hooks to trigger specific process instances, such as sending notifications when events occur.
Stages: Stages that allow task progression through different statuses.
Allocation rules: Define how tasks are assigned to users or teams.
Integration Designer:
Systems: A system is a collection of resources—endpoints, authentication, and variables—used to define and run integration workflows.
Workflows: A workflow defines a series of tasks and processes to automate system integrations. Within the Integration Designer, workflows can be configured using different components to ensure efficient data exchange and process orchestration.
Configuration Parameters: Application-specific rendering settings like applicationUuid, locale, language, and process parameters.
Application Builds: Builds represent finalized versions of the application, including all associated metadata and linked library versions.
Application Settings: Configure various aspects of a project like platform type, default theme, formatting, etc.
Promotion Workflow: Only builds (not commits) are eligible for promotion to upper environments. Builds are exported from the development environment and imported into target environments via the Designer UI.
Design Asset Handling: During import, any referenced design assets are created if absent but are not updated, ensuring consistency in upper environments.
Configuration Parameters Overrides: Upper environment values replace development defaults, and these can be managed through environment variables, enabling flexibility without direct development environment access.